Replayable reorganizations enable a secondary system on a standby server to roll forward through a reorganization and have the effects of that reorganization applied.
When a reorganization is initiated on a primary database server, it must be possible for a secondary database to have the effects of the reorganization applied, which is made possible by auditing the reorganization operations in the database journal. This allows the reorganization to be replayed on the secondary database server when the journals are received.
The mechanism that is used to support replaying reorganizations on a secondary database can also be used to roll-forward through a reorganization when the database is not located on a primary server.
If archival recovery is enabled, you can use the database backup or recovery operation to roll-forward through a reorganization, as long as the appropriate journals are available.
You can replay reorganizations only when archival recovery is enabled (that is, the
Replayable reorganizations must be restarted if a system failure results in a reorganization terminating. The reorganization is restarted at the last checkpoint established during the reorganization.
Restart an interrupted reorganization by using the Restart Reorg command from the Schema menu Reorg command submenu or the JadeReorgApp application and specifying the restartReorg value in the
For details about inhibiting the creation of .bak files during a reorganization, see "Location of Files In Reorganizations", later in this chapter.
If you are running in a Synchronized Database Environment (SDE), you should disable tracking on at least one secondary database while a reorganization is in progress on the primary database. The reorganization process on the primary database appends redo information to the journals, which continue to be transferred to attached secondary systems even when tracking is disabled. When the reorganization has been completed successfully on the primary system, you can then enable tracking, allowing the secondary system to replay the reorganization to regain synchronization with the primary database. If the reorganization fails for any reason, the secondary database remains synchronized with the primary database at the point prior to the reorganization being initiated.
Performing a non-replayable reorganization on a primary is recommended only for lengthy reorganizations in which re-cloning is the preferred option, as a non-replayable reorganization on a primary database cannot be replayed on a secondary database and you must therefore re-clone the secondary database from the primary.