activate subscription

For a subscription to a replication definition or a publication, starts the distribution of updates from the primary to the replicate database and sets the subscription status to ACTIVE. The activate subscription command is part of the bulk materialization process, or part of the process of refreshing a publication subscription.

Syntax

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

Parameters

sub_name – The name of the subscription to be activated.
for table_rep_def – Specifies the name of the table replication definition the subscription is for.
for function_rep_def – Specifies the name of the function replication definition the subscription is for.
for publication pub_name – Specifies the name of the publication the subscription is for.
with primary at data_server.database – Specifies the location of the primary data. If the primary database is part of a warm standby application, data_server.database is the name of the logical data server and database. Use this clause only with a subscription for a publication.
with replicate at data_server.database – Specifies the location of the replicate data. If the replicate database is part of a warm standby application that uses logical connections, data_server.database is the name of the logical data server and database.
with suspension – Suspends the Data Server Interface (DSI) for the replicate database after changing the subscription status. While the DSI is suspended, Replication Server holds updates for the replicate database in a stable queue. After you load the initial data and resume the DSI, Replication Server applies the updates. In a warm standby application, this clause suspends the active database DSI and the standby DSI.
with suspension at active replicate only – In a warm standby application, suspends the active database DSI but not the standby DSI.
with catchup_queue – Instructs Replication Server to start a catchup queue to store the DMLs for the primary table. The DML operations in the catchup queue are applied to the replicate table when validate subscription is issued, before the subscription becomes VALID.

Examples

Example 1 – Activates the subscription titles_sub for the table replication definition titles_rep, where the replicate database is SYDNEY_DS.pubs2. This command suspends the DSI.
```
activate subscription titles_sub
 for titles_rep
 with replicate at SYDNEY_DS.pubs2
 with suspension
```
Example 2 – Activates the subscription myproc_sub for the function replication definition myproc_rep, where the replicate database is SYDNEY_DS.pubs2.
```
activate subscription myproc_sub
 for myproc_rep
 with replicate at SYDNEY_DS.pubs2
```
Example 3 – Activates the subscription pubs2_sub for the publication pubs2_pub, where the primary database is TOKYO_DS.pubs2 and the replicate database is SYDNEY_DS.pubs2.
```
activate subscription pubs2_sub
 for publication pubs2_pub
 with primary at TOKYO_DS.pubs2
 with replicate at SYDNEY_DS.pubs2
```
Example 4 – Activates the subscription titles_sub for the table replication definition titles_rep with the catchup_queue clause, where the replicate database is SYDNEY_DS.pubs2. The DMLs for the primary table being activated are put in a catchup queue. The subscription becomes VALID only after all the DML operations in the catchup queue are applied at the replicate table.
```
activate subscription titles_sub
 for titles_rep
 with replicate at SYDNEY_DS.pubs2
 with catchup_queue
```

Usage

Use activate subscription to activate a subscription at the primary and replicate Replication Servers. The subscription can be to a table replication definition, function replication definition, database replication definition, or publication.
This command begins the second step in the bulk materialization process. The first step is the creation of the subscription using define subscription.
To complete bulk materialization, load the data from media, resume the connection to the replicate database if it was suspended, and execute validate subscription.
Execute activate subscription at the Replication Server where you created the subscription.
activate subscription changes the status of a subscription from DEFINED to ACTIVE. Subsequent updates at the primary data server are distributed through the primary Replication Server.
If you have added any new articles to a publication with an existing subscription, you must refresh the publication subscription by materializing the new data in order to create subscriptions for the new articles.

After using define subscription to begin this process, use activate subscription to activate the new article subscriptions. Then manually load the subscription data for the new article subscriptions, and use validate subscription to validate the publication subscription.
When you activate a publication subscription, all of its article subscriptions are activated at the same time, rather than one at a time.
This command modifies RSSD tables at multiple sites. Use check subscription at the primary and replicate Replication Servers to see the effects on each.
For more information about subscription materialization, see the Replication Server Administration Guide Volume 1.

The with suspension clause

When you use the with suspension clause, activate subscription suspends the DSI after changing the subscription status. This prevents the replicate Replication Server from sending updates for the replicated table before the subscription data is loaded.

After the data is loaded 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 version until after the subscription is materialized.
If the database is part of a warm standby application, the with suspension clause suspends the DSI for the active database and standby DSI after changing the subscription status. This allows you to load the data into both databases before allowing updates to continue in the active database.

If you load the data into the active database with logging (for example, by using logged bcp or by executing transactions in the active database), use the clause with suspension at active replicate only, so that the standby DSI is not suspended. In this case, you do not have to load the subscription data into the standby database because it is replicated from the active database.

The with catchup_queue clause

When you use the catchup_queue clause, the DML operations on the primary table that is being materialized 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).
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. Materialization fails when an update changes the primary key.
(For primary Microsoft SQL Server, DB2 UDB, or Oracle database only) If a subscription is created with the direct_load option and if you are anticipating updates to the primary table during materialization time, you must enable the ra_set_autocorrection Replication Agent command to allow Replication Agent to send the values for all columns to the downstream Replication Server.

Permissions

activate subscription can be executed by users with “create object” permission at the replicate Replication Server and “primary subscribe” permission at the primary Replication Server.