This chapter explains how to maintain data when it exists in more than one place and is potentially unsynchronized.
This chapter covers the following topics:
Data that is maintained in more than one place is subject to becoming out of synch. This chapter presents the following processes to help you keep multiple data sources synchronized:
Inventory and Bills of Material data must be maintained in the production instance. You can maintain the CZ schema with the data in the production instance by:
Eliminating any unused data by Purging Configurator Tables
Redoing Sequences resets the sequences after the CZ schema has been restored from a dump file
When a runtime Oracle Configurator is deployed, the data is stored in the CZ schema directly through networked use. During deployment, further imports are performed to refresh the CZ schema as Oracle Applications or legacy data changes. The procedures that perform the import prevent customer-specific groups of fields in the CZ schema from being altered or nulled out even when other fields in the row are replaced during an import session.
For additional information about refreshing data in your CZ schema, see Refreshing Imported Data.
Large databases affect performance. For example, large amounts of data in the import tables may cause data import to fail. The following concurrent programs delete unnecessary data:
Note: A data import session must not be running when there is a purge concurrent program request. Similarly, a purge session must not be running when there is a data import concurrent program request.
The Purge Configurator Tables concurrent program physically deletes all logically-deleted records in the tables and subschemas of the CZ schema.
Each CZ schema table has delete-propagation rules that affect the results of running the Purge Configurator Tables concurrent program.
The Purge Configurator Tables concurrent program:
Propagates deletions to additional records not marked as deleted, such as physically deleting children of a logically-deleted PS_NODE record.
Physically deletes all EXPRESSION_NODE records attached to a deleted rule.
Does not physically delete a record that is logically-deleted if there is a non-deleted reference to that record, such as preserving a deleted PS_NODE that is used in a non-deleted rule.
See Purge Configurator Tables for details on running this concurrent program.
Import performance can be improved if you purge the import tables in your database instance. The Purge Configurator Import Tables concurrent program deletes data in all CZ_IMP tables. The concurrent program also deletes the corresponding data in the CZ_XFR_RUN_INFOS and CZ_XFR_RUN_RESULTS control tables.
See Purge Configurator Import Tables for running this concurrent program.
If you want to improve import performance but also retain recent import information, then the Oracle Configurator Administrator should run the Purge To Date Configurator Import Tables concurrent program. Unlike the Purge Configurator Import Tables concurrent program that deletes all data in the CZ_IMP tables, the concurrent program only deletes the oldest data in the CZ_IMP tables. The data for the specified past number of days is retained. The concurrent program also deletes the corresponding data in CZ_XFR_RUN_INFOS, and CZ_XFR_RUN_RESULTS control tables.
See Purge To Date Configurator Import Tables for details on running this concurrent program.
If you want to improve import performance but also retain recent import run information, then the Oracle Configurator Administrator should run the Purge To Run ID Configurator Import Tables concurrent program. Purge To Run ID Configurator Import Tables only deletes data in the CZ_IMP tables up to the specified input Run ID. The concurrent program also deletes the corresponding data in the CZ_XFR_RUN_INFOS, and CZ_XFR_RUN_RESULTS control tables
See Purge To Run ID Configurator Import Tables for details on running this concurrent program.
After restoring a schema from a backup file, you should refresh the database sequences. The REDO_SEQUENCES procedure is invoked by the packages CZ_MANAGER.sql and CZ_subschema_MGR.sql (for example, CZ_PS_MGR.sql).
Depending on the parameters that you enter, the REDO_SEQUENCES procedure either alters or recreates the sequence objects in the database that are used to allocate primary keys for tables in the CZ schema. The procedure checks the current high primary key value in the database and sets a new start value that is greater than the current high value. The procedure uses the default incremental value specified by OracleSequenceIncr setting in the CZ_DB_SETTINGS table unless you specify a new increment. See OracleSequenceIncr for more information.