Continuing with of my previous blogs on BusinessObjects File repository servers here is another one for Managing File Repository servers. Below are some of the best practices for managing File repository servers.
A. Setting Instance limits at various folder levels based on the Business requirement
It is always recommended to maintain only instances that are required in the system at any point of time. Managing reports that are no longer required by the business will take unnecessary disk space in Output file repository. This is the place where Instance management is come in to picture where you can limit instances based following criteria
- Number of Instances
- Age of Instance
- Instance limit for Users/Groups
To understand more about the Instance management planning you can refer here BusinessObjects Instance Management
B. Control the report storage in Users personal folders.
- Personal folders
Controlling document storage with in User’s personal folder has also equally important compared to that of instance management. Replication of same report in multiple places will again create the report duplication in turn the space utilization in Input File store. To avoid this we should have a firm security in place so that only the authorized users can create/copy the reports that too only in their personal folders with their report level personalisation.
Managing reports inside User’s inbox is also a cumbersome task for the administrator as there are no utility/feature/Security rights to limit the number of objects for user’s Inbox. It is the responsibility of the administrator to manually monitor user’s Inbox volume on periodic basis and notify the user for deletion. There are some SDK utilities using which Administrators can limit User’s inbox documents though there is no out-of –box solution.
C. Use of Repository Diagnostic Tool to minimize the CMS Database and File store synchronization issues
In most of the BusinessObjects deployments there could be a possibility for a discrepancy between File repository store and the CMS database. This could be due to CMS server crashes and Input/output FRS crash. As a result the report that is available in file store might miss its corresponding entry in CMS database and the related entry CMS database could miss its counterpart in File repository store.
Repository Diagnostic Tool will be handy to identify and resolve inconsistencies between CMS database and the File repository. Refer the below wiki page to understand more about RDT. http://wiki.sdn.sap.com/wiki/display/BOBJ/How+to+use+Repository+Diagnostic+Tool
Hope you find this interesting.
File Repository Servers Management – Blogs