To stop updates at the primary and take a snapshot, you can use either of two bulk materialization methods:
Using the Adaptive Server mount command
Using the Adaptive Server dump and load, select, or bcp command
Use these methods to retrieve data from the primary database if you are able to suspend updates to the primary data. To maintain consistency, all updates to the primary database are suspended for the duration of the materialization.
Retrieving data from the primary database using
the Adaptive Server mount command
This procedure uses mount to retrieve data from the primary database. You can use this method only if you are using Adaptive Server version 12.5.1 or later, and your primary and replicate databases are identical.
Verify that the entire replication system is working. See Chapter 1, “Verifying and Monitoring Replication Server” in the Replication Server Administration Guide Volume 2 for details.
Suspend updates to the data in the primary database by stopping client applications that generate transactions against the primary data directly or indirectly through Replication Servers.
Quiesce the replication system components involved with replicating data from the primary Replication Server to the replicate Replication Server.
Use admin quiesce_for_rsi at the primary and replicate Replication Servers and any intermediate Replication Servers.
Execute the Adaptive Server command quiesce database tag_name hold db_name list [for external dump] to manifest_file [with override]] to generate the manifest file. See the Adaptive Server Enterprise Reference Manual for more information.
Take a snapshot of the subscription data from the primary database by creating a data dump of both the database and log devices. You can create a data dump using utilities such as tar or zip, or the UNIX dd command.
Use mount database to begin loading the snapshot data into the replicate database.
Resolve the mismatch of user information between the master database and the loaded user database.
Use rs_init to add the replicate database to the replication system if it is not already there.
Execute define subscription at the replicate Replication Server.
Use check subscription at the primary and at the replicate Replication Servers to verify that the subscription has been defined. When the subscription status is DEFINED at both servers, continue to step 11.
Execute activate subscription at the replicate Replication Server.
Use check subscription at the primary and at the replicate Replication Server to verify that the subscription has been activated. When the subscription status is ACTIVE at both servers, continue to step 13.
Execute quiesce release to resume updates to the primary data.
Execute validate subscription at the replicate Replication Server.
Use check subscription at the primary and at the replicate Replication Server to verify that the subscription is VALID at both servers.
When you have completed this procedure, the subscription is created, the replicate data is consistent with the primary data, and replication is active.
Retrieving data from the primary database using
the Adaptive Server dump and load, select or bcp commands
This procedure retrieves data from the primary database using the Adaptive Server dump and load, select, or bcp commands and utilities.
Verify that the entire replication system is working. Refer to Chapter 1, “Verifying and Monitoring Replication Server” in the Replication Server Administration Guide Volume 2 for details.
Suspend updates to the data in the primary database by stopping client applications that generate transactions against the primary data.
Quiesce the replication system components involved with replicating data from the primary Replication Server to the replicate Replication Server.
Use admin quiesce_force_rsi at the primary and replicate Replication Servers and at any intermediate Replication Servers.
Execute suspend log transfer for the primary database.
Take a snapshot of the subscription data from the primary database using a select statement or a database dump.
Execute define subscription at the replicate Replication Server.
Use check subscription at the primary and at the replicate Replication Servers to verify that the subscription has been defined. When the subscription status is DEFINED at both servers, continue to step 9.
Execute the activate subscription command, using the with suspension clause, at the replicate Replication Server.
Use check subscription at the primary and at the replicate Replication Server to verify that the subscription has been activated.When the subscription becomes active at the replicate Replication Server, the DSI connection to the replicate Replication Server is suspended.
When the subscription status is ACTIVE at both servers, continue to step 11.
Execute resume log transfer from the primary database at the primary Replication Server.
Begin loading the snapshot data into the replicate database.
While you wait for the data to finish loading in the
replicate database, you can continue with the next step.
Execute validate subscription at the replicate Replication Server to validate the subscription.
Use check subscription at the primary and at the replicate Replication Server to verify that the subscription status is VALID for both servers.
When the snapshot data has finished loading in the replicate database, execute resume connection to resume the connection to the replicate database.
When you have completed this procedure, the subscription is created, the replicate data is consistent with the primary data, and replication is active.
