I would recommend you to either use file system or database and not both of them at the same time.
In order to achieve your requirement the archiver utility can be used to convert the files from JDBC storage to file system. Refer the KM article Doc ID 1642986.1 and create a new rule with file system as storage option. It could take few days/weeks depending upon the document volume in your repository.
For the option 1, you need to create a new storage rule for file system and make it as a default one so that the new documents will be routed to file system and the existing documents will be stored in database.
What's the use case? It's obviously not DB licensing, etc, since option 1 keeps files in the DB.
From a security standpoint, most customers would prefer files stored in the DB. Keeping them as BLOBs helps obfuscate the files to keep them from prying eyes. It also tends to make system backups a bit easier, since the files can be backed up using standard DB tools.
It's a 3TB DB size & growing rapidly. This migration is required due to i) Backups taking longer time ii) Performance iii) Cost
Will moving the contents to Filesystem be a better architecture?
If not, what is the best architecture in the case(keeping in mind easier to achieve). Any specific benefits/deltas of each below:
1. Previous content to be accessible from DB as before & new contents to be in Filesystem
2. All contents to be migrated to Filesystem
3. Partitioning Database repository.
4. Any other
It's a client requirement may be due to ease as File Store Provider offers to relocate files easily,ability to have the web-viewable files.
Can you help with the solution please
Any specific reason to use either DB/Filesystem & not both?
Would any downtime be needed for the same. Since it's a production with 3 TB DB size. Can migration be completed in small archives daily after usage hours?
I believe, the steps Doc ID 1642986.1 can be done on the same domain irrespective of what's shared in this link: Webcenter content data migration from database to filesystem ?
I honestly don't see the use case described by your client as being legitimate.
- Regardless of the storage medium, a storage rule gives you the option of using webviewable files. The difference here is that the web viewable files are not present on the file system until a request for the file is made. The file is then extracted from the DB, and placed into a temp area. This is all transparent to the user, and the benefits of storing files in the DB (de-duplication of files, file encryption, etc based on your DB configuration) outweigh the very slight overhead involved in retrieving a file.
- In reality, even with files stored on the file system, no one other than the content server process should be accessing these files directly. Changing the files directly on the file system is a recipe for disaster, not to mention that unauthorized users (like your network admins) could see files they normally could not see via the Content Server UI.
- The file store provider works to totally abstract the need to "know" where or how files are stored. It's intended to be invisible, as the Content Server is aware of how to store and retrieve the files. These operations are best left to the Content Server process.
- As mentioned before, backups are greatly simplified using DB storage as well.
Exporting and importing files is covered extensively in the Oracle documentation. Likewise, creating file store provider rules are covered liberally in the product documentation.
Storing files as BLOBs does come with its issues. We have had database files become so large that they were difficult to manage and forced us to rethink how we were backing them up as we learned that full backups were taking all day. Our WCC databases became extreme outliers vs the other databases that our DBA's had to manage, since we were the only databases storing files. However our storage team already had a good system for this as file systems are made for backing up large amounts of data. Also, upgrading the multi-terabyte databases to new versions and servers was much slower and riskier than the smaller databases which could be recovered very quickly. Depending on your set up, you may be running out of the limited and quick resources available to your database and do not want to use it as a substitute for cheap network storage. Also I believe SecureFiles is an extra license and you may not need the added security.
Either way, you should detail to the client all the benefits of database storage and verify that this is really what they want to do. If they are set on it ManojC's description is exactly what you want to do.
First create a new storage rule that points to File system and update it to be the new default. This will take care of new content.
Then, if you decide, you can go and export the existing data with Archiver and re-import it using the new storage rule to move it from one to the other.