activate subscription Command

Use activate subscription during bulk materialization to start the distribution of updates from the primary to the replicate database for a subscription.

activate subscription sets the subscription status to ACTIVE.

Execute active subscription at the Replication Server where you created the subscription using the define subscription command. The syntax for activate subscription is:

activate subscription subscription
	for { table_rep_def | function_rep_def | publication pub_name |
	with primary at data_server.db }
with replicate at data_server.db
[with suspension [at active replicate only] | with catchup_queue]

where subscription is the name of the subscription to activate, table_rep_def is the name of the table replication definition the subscription is for, function_rep_def is the name of the function replication definition the subscription is for, pub_name is the publication the subscription is for, and data_server.db identifies the primary or replicate database.

Use the with suspension clause to suspend the DSI after the subscription status changes to ACTIVE. This prevents the replicate Replication Server from sending updates for the replicated table before the subscription data is loaded. After loading the data at the replicate site, execute resume connection to apply the updates.

If you do not use with suspension, you should prohibit updates to the primary table until the subscription is materialized.

If the database is part of a warm standby application, the with suspension clause suspends the DSI for the active and standby databases. This let you load the data into both databases before allowing updates to the active database. If you load the data into the active database with logging, use the with suspension at active replicate only clause so that the standby DSI remains active. In this case, subscription data is replicated from the active database. The DSI for the active database in a warm standby application is suspended. The clause does not suspend the DSI for the standby database.

Use the with catchup_queue clause to instruct Replication Server to start a catchup queue to store the DMLs for the primary table. Subsequent updates to the primary table are stored in a catchup queue. After the bulk materialization is complete and when you issue the validate subscription command, the subscription becomes VALID after all the DML operations in the catchup queue are applied to the replicate table.

If you use the catchup_queue clause, you no longer need to specify with suspension or restrict DML operations during bulk materialization (that is, the time between activate subscription and validate subscription command execution).

Note: When DML operations in a catchup queue are applied to the replicate table, each insert operation is converted into a delete followed by an insert, delete is delete, and update is update. Materialization fails if an update changes the primary key.

See Replication Server Reference Manual > Replication Server Commands > activate subscription.