Show TOC

check subscriptionLocate this document in the navigation structure

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.