check subscription

Finds the materialization status of a subscription to a replication definition or a publication.

Syntax

check subscription sub_name
	for {table_rep_def | function_rep_def |
	[publication pub_name | database replication definition db_repdef]
	with primary at data_server.database}
	with replicate at data_server.database

Parameters

sub_name – The name of the subscription to check.
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.
database replication definition db_repdef – Specifies the name of the database replication definition 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. Include this clause only for 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, data_server.database is the name of the logical data server and database.

Examples

Example 1 – Checks the status of the subscription titles_sub for the replication definition titles_rep, where the replicate database is SYDNEY_DS.pubs2:
```
check subscription titles_sub
 for titles_rep
 with replicate at SYDNEY_DS.pubs2
```
Example 2 – Checks the status of 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:
```
check subscription pubs2_sub
 for publication pubs2_pub
 with primary at TOKYO_DS.pubs2
 with replicate at SYDNEY_DS.pubs2
```

Usage

Use check subscription to find the status of a subscription during subscription materialization or dematerialization, or during the process of refreshing a publication subscription. The subscription can be to a table replication definition, function replication definition, or publication.

See the Replication Server Administration Guide Volume 1 for more information about subscriptions.
Execute check subscription at the Replication Server that manages the database where the replicate data is to be stored or the Replication Server that manages the primary database.

The results of check subscription differ depending on where the command is executed. If the Replication Server manages both the primary and replicate database, check subscription returns two status messages.
To check publication status, use check publication. See check publication command for more information.
Refer to the Replication Server Troubleshooting Guide for detailed information about monitoring subscriptions using check subscription.

Messages Returned by check subscription

When you execute check subscription at a replicate Replication Server, it returns one of these messages.

In a warm standby application, there may be two lines of output showing the status at the active and at the standby replicate database.

INVALID	`sub_name doesn’t exist`
REMOVING	`REMOVING subscription sub_name from system tables at the Replicate.`
DEMATERIALIZING	`Subscription sub_name is DEMATERIALIZING at the Replicate.`
VALID	`Subscription sub_name is VALID at the Replicate.`
VALIDATING	`Subscription sub_name is VALIDATING at the Replicate.`
MATERIALIZED	`Subscription sub_name has been MATERIALIZED at the Replicate.`
ACTIVE	`Subscription sub_name is ACTIVE at the Replicate.`
ACTIVATING	`Subscription sub_name is ACTIVATING at the Replicate.`
ACTIVATING	`Subscription sub_name is ACTIVATING at the Standby of the Replicate.`
QCOMPLETE and ACTIVE	`Subscription sub_name is ACTIVE at the Replicate and Materialization Queue has been completed.`
QCOMPLETE	`Materialization Queue for Subscription sub_name has been completed.`
ACTIVE and not QCOMPLETE	`Subscription sub_name is ACTIVE at the Replicate, but Materialization Queue for it has not been completed.`
DEFINED	`Subscription sub_name has been defined at the Replicate.`

In addition to the above messages, executing check subscription at a replicate Replication Server may return one of these messages:

ERROR	`Subscription sub_name has experienced an unrecoverable error during Materialization or Dematerialization. Please consult the error log for more details.`
PENDING	`Other subscriptions are being created or dropped for the same replication definition/database. Subscription sub_name will be processed when previous requests are completed.`
RECOVERING	`Subscription sub_name has experienced a recoverable error during Materialization or Dematerialization. It will be recovered by Subscription Daemon (dSub).`

When you execute check subscription at a primary Replication Server, it returns one of these messages:

INVALID	`subscription_name doesn’t exist`
DEMATERIALIZING	`Subscription sub_name is DEMATERIALIZING at the PRIMARY.`
VALID	`Subscription sub_name is VALID at the PRIMARY.`
ACTIVE	`Subscription sub_name is ACTIVE at the PRIMARY.`
ACTIVATING	`Subscription sub_name is ACTIVATING at the PRIMARY.`
DEFINED	`Subscription sub_name has been defined at the PRIMARY.`

When you execute check subscription for a subscription created with the direct_load option that is in the intial-load phase, it returns a status similar to:

Subscription sub_name is ACTIVE at the replicate. 
Subscription sub_name is ACTIVE at the primary. 
Subscriptions sub_name progress: initial loading, xx% done, xxxxx commands remaining.

When you execute check subscription for a subscription created with the direct_load option that is in the catch-up phase, it returns a status similar to:

Subscription sub_name has been MATERIALIZED at the replicate. 
Subscription sub_name is VALID at the primary. 
Subscriptions sub_name progress: catchup, xx% done, xxxxx commands remaining.

Permissions

Any user may execute this command.