Refer to the topics below for information on maintaining a catalog.
You modify settings manually using various elements in the instanceconfig.xml file to change these settings.
You can deploy catalogs and simple objects (for example, a dashboard with privileges) to a production environment from a test environment, as described in the following sections:
You deploy a Catalog to production using BAR files.
See Moving Oracle Business Intelligence Between Environments.
You can deploy objects (for example, a dashboard with privileges) to a production environment from a test environment.
(Optional) If you are deploying a catalog object to a new production environment.
Archive the catalog object in the test environment and unarchive it in the production environment as follows:
Archive the catalog object in the test environment using one of the following:
Oracle BI Presentation Services.
Catalog Manager.
Copy the archived file to the production computer.
On the production computer, unarchive the object.
For information about how to unarchive an object, see Archiving and Unarchiving Using Catalog Manager.
Set the permissions on the object as appropriate.
(Optional) If you are deploying the catalog to an existing production environment.
Copy and paste new or updated objects from the test catalog into the production catalog as follows:
Open two Catalog Manager windows: one with the test catalog, and another with the production catalog.
Selectively copy and paste the folders from the test catalog into the production catalog.
If you copy and paste folders where the same content has been changed in the test or production environments, then test content overwrites the production content.
If you upgrade to a newer version of Oracle Business Intelligence or install a patch and work with objects in the catalog, then you might notice that certain objects are not being accessed as quickly as in the previous release.
This change can occur if objects are not upgraded properly. You can confirm the need to update by viewing the metrics in Fusion Middleware Control. In the Catalog folder, find a metric called "Reads Needing Upgrade" with description "The number of objects read that required upgrading." If the number is large, then you can resolve this issue by updating objects in the catalog using the Administration page in Presentation Services.
You upgrade to new versions of Oracle Business Intelligence by following the instructions in the Upgrade Guide for Oracle Business Intelligence. To upgrade Catalog objects follow Task 5: Upgrade the Oracle BI Repository and Catalog in Upgrade Guide for Oracle Business Intelligence. Oracle recommends that you upgrade when Presentation Services is not running. If you suspect that the upgrading of objects was not performed thoroughly during the upgrade process, then you can update the objects yourself using the Administration page. The advantage of this approach is that Presentation Services can stay up and running during the update.
Bear the following points in mind as you prepare to update objects:
If you are performing a rolling upgrade of machines in a cluster, then do not use this option or the UpgradeAndExit configuration setting until all machines in the cluster are upgraded.
Use this option on only one node in a cluster at a time.
The catalog is a dynamic component which requires maintenance.
Over time, inconsistencies can develop in the catalog as links are broken, users are deleted, or NFS file system issues are encountered. These inconsistencies can eventually lead to incorrect behavior, such as the inability to edit an agent's recipient list. You can periodically take the production system offline and validate the catalog, to be informed of and to take corrective action on inconsistencies.
This section contains the following topics about validating the catalog:
The process of validating the catalog involves creating a report for the catalog in offline mode and seeing the objects that require adjustment or removal.
You might fix some objects manually in offline mode. Then run the validate operation again to allow the system to "clean" by deleting any unnecessary objects. You repeat the process of creating the report, manually fixing errors, and cleaning the catalog until it is validated.
You can validate the system to ensure processes run smoothly.
The validation process performs the following tasks:
Ensures that each object in the catalog is larger than zero bytes.
Ensures that each item in the catalog has a valid corresponding .atr file.
Ensures that each link in the catalog is valid.
Ensures that the files in the account cache are valid.
Ensures that all XML objects in the catalog pass schema validation.
Attempts to repair object names that were damaged by ftp programs.
Before you validate the catalog, keep in mind certain guidelines.
Use care when validating a catalog in a development environment, if that environment has a different security store from the production environment. If the validation is performed with a different security store, then many accounts might be removed from the catalog.
When you turn on any validation of the catalog, all ACLs (that is, all privileges and every item's permissions) are "scrubbed," which means that dead accounts are removed from them and any changed items are written to disk. Therefore, even if you simply create a report without fixing any broken items automatically, you might find that the catalog is still extensively "changed."
Before validating the catalog in a clustered environment, do one of the following:
Shut down the Presentation Services cluster and run the validation directly against the cluster's catalog.
Make a copy of the cluster's catalog and run the validation against that copy.
Before using the 7-Zip utility to make a copy of a catalog, first shut down all nodes in the Presentation Services cluster or put all nodes in that cluster into Maintenance Mode (which is the recommended approach).
Be aware that any changes that are made to the catalog online concurrently to the validation process are not included in the validation.
While backing up the catalog is always good practice, there is no practical difference between running validate against the catalog directly versus running the validation on a backup copy.
You can perform a basic validation of the catalog on an ad-hoc basis as needed, immediately before pushing content from a development environment to a production environment, or per a regular schedule, such as on the first Tuesday of every month.
As part of the process of validating the catalog, you include elements in the instanceconfig.xml file that run the validation when you restart Presentation Services.
The following procedure describes how to edit the instanceconfig.xml file to include these elements.