While a primary database is open and active with updating transactions in progress, journals continue to be generated and transferred to connected secondary servers. You can delay the application of transactions at one or more secondary databases by disabling tracking.
This can be very useful in scenarios such as application deployment, especially one involving a database reorganization that cannot be guaranteed to succeed. In scenarios involving such upgrades, you should disable tracking on at least one secondary database. When invoked, the schema load and reorganization processes on the primary appends redo information to journals, which continue to be transferred to attached secondary servers even when tracking is disabled.
Once the application deployment has completed successfully on the primary system, you can enable tracking again, allowing the secondary to replay the schema load and reorganization processes to regain synchronization with the primary database. If an application load should fail for any reason, the secondary database with tracking disabled remains synchronized with the primary at the point prior to the upgrade.