Skip to main content

We have a customer who is upgrading from Apps8 On-Prem to Apps10 on our (Managed) Cloud

 

   They currently ( in Apps8) use the ‘File Share’ as their document repository and our Cloud services team have clearly indicated that the only option they will support is ‘Database Repository’

 

   Questions:

  • Should we be concerned with the growth in the Db size or performance of routine tasks such as “db backup” with moving so many files into the “database repository”
  • Have you had other customers who are asked to do a similar change as part of their upgrade to Cloud Services
  • Is there a best practice for “moving” files from ‘File Share’ to ‘Database Repository’ as part of an upgrade project  

Hi Praveen, thanks for posting here.

It's hard to comment on how big of a problem it will be unless we know the total size of their document repository today. Apart from database backup and recovery times, which might or might be a problem here, database storage in the cloud is the most expensive storage there is...

What is the total size of their current document repository?

You can move files from a Shared or FTP document repository to the database repository using a built-in document file transfer assistant that we have (it's in the navigator, named Change Document Repository). You probably need to do that before you uplift the database to the cloud, since you will not be able to use the assistant once the database is running in the cloud (our middle tier will not be able to access the customers shared folders).
 

Hi Mathias,

 

  The current repository ( first site going live) is 89GB; We are looking to bring in 3 additional ( new) divisions into the Apps10 instance. The  starting size of the repository once all divisions are in the instance could be 275GB and can grow from there 

 

Will you be able to comment on the Db backup, maintenance  and recovery tasks  associated with the above figure?  Will this be a concern? 

 

Thanks,

Praveen 

@Tim Jenner 

Would you have the time to comment on this? That’s a lot of documents, but also a bit from those X TB limits I have heard about.

 

 

The time for us to do backups became a problem when we were something over 350Gb if I remember correctly.  We then moved the documents to an ftp site as a result, we’re over 1 million document revisions at this point and growing on 5 divisions, 25 sites.  I don’t have times and sizes to give empirical data, but believe it will be a problem for you before you reach a hard limit.

As stated above, IFS only supports database repositories for Apps 10 document storage in our cloud services.  As ShawnBerk mentions, as databases grow larger various administration and management activities including (but not limited to) backups do become more challenging. However, there is a maximum database size defined as part of the sizing for the Apps 10 cloud solutions and since IFS provides this as a service this naturally includes a number of elements designed to ensure we can deliver the service even if the database grows all the way up to the defined limit.

Provided the total database size, including the size of the document repository, remains within the size limit for the service which has been purchased there should not be any issues.  You obviously need to model the growth over time to make sure you don’t hit a problem in the future, and ensure the correct size of service is used - but IFS offers Apps 10 cloud service configurations all the way up to 4.8TB max database size so in this case it sounds unlikely to be a limiting factor.

Alos adding @PeterR for awareness and comment.

Reply


Terms & ConditionsCookie settings