8.3 xDB Replication Server CLI Commands

Table of Contents Previous Next


8 xDB Replication Server Command Line Interface : 8.3 xDB Replication Server CLI Commands

Note: Though most commands described in this section apply to both single-master and multi-master replication systems, those commands that apply only to single-master replication systems are noted with For SMR only. Those commands that apply only to multi-master replication systems are noted with For MMR only. The same notation is used for command parameters that may apply only to single-master replication systems or multi-master replication systems.
For the examples used in this section, it is assumed that the xDB Replication Server CLI commands are executed after you have made XDB_HOME/bin your current working directory, thereby eliminating the need to specify the full path of XDB_HOME/bin for each execution of the edb-repcli.jar file. For example, assuming xDB Replication Server is installed in the default installation directory you have issued the following command in Linux:
Whenever the repsvrfile parameter appears in the examples, file ~/pubsvrfile contains the publication server login information and is located in the user’s home directory while ~/subsvrfile contains the subscription server login information. For Windows, the equivalent usage is %HOMEPATH%\pubsvrfile and %HOMEPATH%\subsvrfile.
The examples in this section were run on Linux so you will see use of the Linux continuation character, which is a backslash (\), to show how an xDB Replication Server CLI command can be continued onto the next line if you do not want to wrap the text in your terminal window. For Windows, use the Windows continuation character, which is a caret (^).
The help command provides a syntax summary of all xDB Replication Server CLI commands.
The version command provides the xDB Replication Server CLI’s version number.
The repversion command provides the xDB Replication Server’s version number.
The file containing the publication server login information.
The registerkey command allows you to register the xDB Replication Server product with your product license key.
–repsvrfile pubsvrfile
-keyfile product_key_file
See Section 3.5 for additional information on registering the xDB Replication Server product.
The file containing the publication server login information.
Path to the file containing the xDB Replication Server product license key. The license key must be specified on a single line in product_key_file in the license key format xxxxx-xxxxx-xxxxx-xxxxx-xxxxx. The license key must be specified on the first non-empty line of the file. (That is, if the file happens to contain multiple lines of text, the first line of text is interpreted as the license key.) Leading or trailing white space characters surrounding the license key are ignored.
The file xdbkey contains the product license key in the following format:
The registerkey command is then executed to register the product.
The encrypt command encrypts the text supplied in an input file and writes the encrypted result to a specified output file. Use the encrypt command to generate an encrypted password that can be copied into a text file that will be referenced by an xDB Replication Server CLI command that requires a user name and the user’s password.
-encrypt –input infile –output pwdfile
The text in infile is processed using the MD5 encryption algorithm, and the encrypted text is written to file pwdfile. Make sure that infile contains only the text that you want to encrypt and that there are no extraneous characters or empty lines before the text or after the text that you want to encrypt.
The file infile contains the word “password”.
The encrypt command is then executed producing a file named pwdfile.
The content of file pwdfile contains the encrypted form of “password”.
The uptime command prints the time interval since the publication server has been up and running.
The file containing the publication server login information.
The addpubdb command adds a publication database definition.
-repsvrfile pubsvrfile
{ -dbpassword encrypted_pwd | -dbpassfile pwdfile }
[ -urloptions jdbc_url_parameters ]
[ -filterrule filterid_1[,filterid_2 ] ...]
[ -nodepriority priority_level ]
The addpubdb command creates a new publication database definition. The addpubdb command displays a unique publication database ID that is assigned to the newly created publication database definition. The publication database ID is used to identify the publication database definition on which to operate when running other xDB Replication Server CLI commands.
See Section 5.2.2 for details on the database connection information that must be supplied when adding a publication database definition for a single-master replication system. See sections 6.2.2 and 6.3 for a multi-master replication system.
The file containing the publication server login information.
Specify oracle if the database is an Oracle database. Specify enterprisedb if the database is an Advanced Server database in Oracle compatible configuration mode. Specify postgresql if the database is a PostgreSQL database or an Advanced Server database in PostgreSQL compatible configuration mode. Specify sqlserver if the database is a Microsoft SQL Server database.
The port number on which the database server is listening for connections.
The encrypted password of the publication database user. See Section 8.3.5 for directions on using the encrypt command to generate an encrypted password.
Specify sid if the Oracle system ID (SID) is used to identify the publication database in the database parameter. Specify servicename if the Oracle service name is used to identify the publication database in the database parameter.
Extended usage of JDBC URL parameters such as for support of SSL connectivity. (See Section 7.10 for information on SSL connectivity to the publication database.)
For MMR only: Applies to non-MDN nodes. Comma-separated list of filter IDs identifying the filter rules from the set of available table filters to enable on the corresponding tables in the new master node. Use the printpubfilterslist command to obtain the filter IDs for the available filter rules in the publication (see Section 8.3.17). Note: There must be no white space between the comma and filter IDs.
Specify s if this command applies to a single-master replication system. Specify m if this command applies to a multi-master replication system. If omitted, the default is s.
For MMR only: Applies to non-MDN nodes. Set this option to true if you want the publication table definitions replicated from the master definition node when creating a new master node. Set this option to false if you have already created the table definitions in the new master node. If omitted, the default is true. Do not specify this parameter when creating the master definition node.
For MMR only: Applies to non-MDN nodes. Specify this option if you want an initial snapshot replication to be performed when creating the master node. Omit this option if you do not want an initial snapshot replication to be performed when creating the master node.
Note (For MMR only): Unless you intend to use the offline snapshot technique (see Section 7.9), it is suggested that you specify this option. An initial snapshot replication must be performed from the master definition node to every other master node before performing synchronization replications on demand (see Section 8.3.42) or by a schedule (see Section 8.3.44). If a newly added master node did not undergo an initial snapshot, any subsequent synchronization replication may fail to apply the transactions to that master node. The initial snapshot can also be taken by performing an on demand snapshot (see Section 8.3.41).
Set this option to true if you want the output from the snapshot to be displayed. Set this option to false if you do not want the snapshot output displayed. If omitted, the default is true.
Note: This option may be given only directly following the specification of the -initialsnapshot option.
For MMR only: Integer value from 1 through 10 assigning the priority level to a master node with 1 having the highest priority and 10 having the lowest priority.
Specify T to use the trigger-based method of synchronization replication for this publication database. Specify W to use the log-based (WAL) method of synchronization replication for this publication database. If omitted, the default is T.
The following example adds a publication database definition for an Oracle database. The encrypted password is given on the command line with the dbpassword parameter. A publication database ID of 1 is assigned to the database by the publication service.
The following example adds a publication database definition for an Advanced Server database. The encrypted password is read from a file named pwdfile with the dbpassfile parameter. A publication database ID of 2 is assigned to the database by the publication service.
The following example adds a publication database definition for a master node (other than the master definition node) in a multi-master replication system where an initial snapshot is not invoked (the initialsnapshot parameter is omitted). Filter rules with filter IDs 8 and 16 are applied to this master node. A node priority level of 3 is assigned to the master node.
Note: A publication must be created in the master definition node before creating additional master nodes. See Section 8.3.14 for the command to create a publication.
The printpubdbids command prints the publication database IDs of the publication database definitions.
The file containing the publication server login information.
The printpubdbidsdetails command prints the connection information for each publication database definition.
dbid:host:port:dbname:user
Note: The database user’s password is not displayed.
The file containing the publication server login information.
The port number on which the database server is listening for connections.
For MMR only: The printmdndbid command prints the publication database ID of the master definition node.
The file containing the publication server login information.
The updatepubdb command provides the ability to change the connection information for an existing publication database definition identified by its publication database ID.
-repsvrfile pubsvrfile
{ -dbpassword encrypted_pwd | -dbpassfile pwdfile }
[ -urloptions jdbc_url_parameters ]
[ -nodepriority priority_level ]
See Section 5.2.2 for details on the database connection information that must be supplied for a publication database definition for a single-master replication system. See sections 6.2.2 and 6.3 for a multi-master replication system.
The file containing the publication server login information.
The port number on which the database server is listening for connections.
The password of the database user in encrypted form. See Section 8.3.5 for directions on using the encrypt command to generate an encrypted password.
Specify sid if the Oracle system ID (SID) is used to identify the publication database in the database parameter. Specify servicename if the Oracle service name is used to identify the publication database in the database parameter.
Extended usage of JDBC URL parameters such as for support of SSL connectivity. (See Section 7.10 for information on SSL connectivity to the publication database.) Specification of the urloptions parameter completely replaces any existing JDBC URL parameters that may have previously been specified with this database. Omission of the urloptions parameter deletes any existing JDBC URL parameters that may have previously been specified with this database.
For MMR only: Integer value from 1 through 10 assigning the priority level to a master node with 1 having the highest priority and 10 having the lowest priority.
The removepubdb command removes a publication database definition.
–repsvrfile pubsvrfile
See Section 7.6.7 for additional information on removing a publication database.
The file containing the publication server login information.
The gettablesfornewpub command lists the tables and views that are available for inclusion in a new publication from a given publication database definition.
-gettablesfornewpub –repsvrfile repsvrfile –pubdbid dbid
The file containing the publication server login information.
For the publication database definition identified by publication database ID 1, the tables available for inclusion in a publication are EDB.DEPT, EDB.EMP, and EDB.JOBHIST. The view available for inclusion in a publication is EDB.SALESEMP.
The createpub command creates a new publication.
-repsvrfile pubsvrfile
-tables schema_t1.table_1 [ schema_t2.table_2 ] ...
[ -views schema_v1.view_1 [ schema_v2.view_2 ] ...]
"ordinal_t1:filtername_t1:filterclause_t1"
[ "ordinal_t2:filtername_t2:filterclause_t2" ] ...]
"ordinal_v1:filtername_v1:filterclause_v1"
[ "ordinal_v2:filtername_v2:filterclause_v2" ] ...]
ordinal_t1:{ E | L | N | M | C:customhandler_t1 }
[ ordinal_t2:{ E | L } N | M | C:customhandler_t2 } ] ...]
ordinal_t1:{ E | L | N | M | C:customhandler_t1 }
[ ordinal_t2:{ E | L } N | M | C:customhandler_t2 } ] ...]
The createpub command adds a new publication subordinate to the publication database definition with the publication database ID given by parameter pubdbid. If the publication is designated as snapshot-only by setting parameter reptype to s, then any views listed after the views parameter are ignored.
See Section 5.2.3 for additional information on creating a publication for a single-master replication system. See Section 6.2.3 for a multi-master replication system.
Note: The schema names, table names, and view names that you supply as values for the tables and views parameters are case-sensitive. Unless quoted identifiers were used to build the database objects, Oracle names must be entered using uppercase letters (for example, EDB.DEPT), and Advanced Server names must be entered in lowercase letters (for example edb.dept). See Section 10.4.5 for additional information on quoted identifiers and case translation.
The file containing the publication server login information.
Specify s if the publication is to be a snapshot-only publication. Specify t if the publication is to allow synchronization replications.
The name of the schema containing the nth table of the tables parameter list. This value is case-sensitive.
The table name of the nth table in the tables parameter list. This value is case-sensitive.
For SMR only: The name of the schema containing the nth view of the views parameter list. This value is case-sensitive.
For SMR only: View name of the nth view in the views parameter list. This value is case-sensitive.
The filter clause to be applied to the table in the tables parameter list at the position indicated by ordinal_tn.
For SMR only: The ordinal number (that is, the position in the list counting from left to right starting with 1) of a view in the views parameter list to which an attribute is to be applied.
For SMR only: The filter clause to be applied to the view in the views parameter list at the position indicated by ordinal_vn.
For MMR only: For the conflict resolution option, specify E for earliest timestamp conflict resolution, L for latest timestamp conflict resolution, N for node priority conflict resolution, M for manual conflict resolution, or C for custom conflict handling. The specified conflict resolution applies to the table in the position given by ordinal_tn counting from left to right in the tables parameter list. If omitted the default is E.
For MMR only: For the standby conflict resolution option, specify E for earliest timestamp conflict resolution, L for latest timestamp conflict resolution, N for node priority conflict resolution, M for manual conflict resolution, or C for custom conflict handling. The specified conflict resolution applies to the table in the position given by ordinal_tn counting from left to right in the tables parameter list. If omitted the default is M.
For MMR only: For the conflict resolution option or the standby conflict resolution option, specify customhandler_tn as the function name with an optional schema prefix (that is, formatted as schema.function_name) as given in the CREATE FUNCTION command for the custom conflict handling function created for the table in the tables parameter list at the position indicated by ordinal_tn. The custom conflict handling function must be added to the master definition node. See Section 6.6.8.2 for an example of adding the custom conflict handling function using PSQL. The custom handler name option must be specified if and only if the conflict resolution option or the standby conflict resolution option is set for custom conflict handling with the C value.
Specify s if this command applies to a single-master replication system. Specify m if this command applies to a multi-master replication system. If omitted, the default is s.
In the following example, a publication named dept_emp is created that contains the EDB.DEPT and EDB.EMP tables of an Oracle database. The replication method is synchronization.
In the following example, a publication named salesemp is created that contains the EDB.SALESEMP view of an Oracle database. The replication method is snapshot-only.
In the following example, a publication named analysts_managers is created that contains the edb.dept table and employees from the edb.emp table who are analysts or managers. The tables are in an Advanced Server database. The replication method is snapshot-only.
The following example creates a publication for a multi-master replication system. One table filter is defined on table edb.dept and three table filters are defined on table edb.emp. Table edb.dept is assigned node priority conflict resolution and latest timestamp as the standby conflict resolution strategy. Table edb.emp is assigned earliest timestamp conflict resolution and manual resolution (the default) as its standby strategy.
The printpublist command prints a list of publication names.
The file containing the publication server login information.
If the pubdbid parameter is specified, only the publication names subordinate to the publication database definition specified by dbid are printed. If the pubdbid parameter is omitted, all publication names subordinate to the publication server are printed.
The printpublishedtables command prints a list of tables and views that belong to the given publication.
-printpublishedtables pubname -repsvrfile pubsvrfile
The file containing the publication server login information.
The printpubfilterslist command prints a list of table filters that are defined in the given publication.
-printpubfilterslist pubname -repsvrfile pubsvrfile
The file containing the publication server login information.
The table filters in publication analysts_managers are printed.
The addtablesintopub command adds tables or views into an existing publication.
-repsvrfile pubsvrfile
[ -tables schema_t1.table_1 [ schema_t2.table_2 ] ...]
[ -views schema_v1.view_1 [ schema_v2.view_2 ] ...]
"ordinal_t1:filtername_t1:filterclause_t1"
[ "ordinal_t2:filtername_t2:filterclause_t2" ] ...]
"ordinal_v1:filtername_v1:filterclause_v1"
[ "ordinal_v2:filtername_v2:filterclause_v2" ] ...]
ordinal_t1:{ E | L | N | M | C:customhandler_t1 }
[ ordinal_t2:{ E | L } N | M | C:customhandler_t2 } ] ...]
ordinal_t1:{ E | L | N | M | C:customhandler_t1 }
[ ordinal_t2:{ E | L } N | M | C:customhandler_t2 } ] ...]
The addtablesintopub command updates an existing publication identified by pubname. If the publication is snapshot-only, then any views listed after the views parameter are ignored.
See Section 7.6.3.1 for additional information on adding tables to a publication.
Note: The schema names, table names, and view names that you supply as values for the tables and views parameters are case-sensitive. Unless quoted identifiers were used to build the database objects, Oracle names must be entered using uppercase letters (for example, EDB.DEPT), and Advanced Server names must be entered in lowercase letters (for example edb.dept). See Section 10.4.5 for additional information on quoted identifiers and case translation.
The file containing the publication server login information.
The name of the schema containing the nth table of the tables parameter list. This value is case-sensitive.
The name of the nth table in the tables parameter list. This value is case-sensitive.
For SMR only: The name of the schema containing the nth view of the views parameter list. This value is case-sensitive.
For SMR only: The name of the nth view in the views parameter list. This value is case-sensitive.
The filter clause to be applied to the table in the tables parameter list at the position indicated by ordinal_tn.
For SMR only: The ordinal number (that is, the position in the list counting from left to right starting with 1) of a view in the views parameter list to which an attribute is to be applied.
For SMR only: The filter clause to be applied to the view in the views parameter list at the position indicated by ordinal_vn.
For MMR only: For the conflict resolution option, specify E for earliest timestamp conflict resolution, L for latest timestamp conflict resolution, N for node priority conflict resolution, M for manual conflict resolution, or C for custom conflict handling. The specified conflict resolution applies to the table in the position given by ordinal_tn counting from left to right in the tables parameter list. If omitted the default is E.
For MMR only: For the standby conflict resolution option, specify E for earliest timestamp conflict resolution, L for latest timestamp conflict resolution, N for node priority conflict resolution, M for manual conflict resolution, or C for custom conflict handling. The specified conflict resolution applies to the table in the position given by ordinal_tn counting from left to right in the tables parameter list. If omitted the default is M.
For MMR only: For the conflict resolution option or the standby conflict resolution option, specify customhandler_tn as the function name with an optional schema prefix (that is, formatted as schema.function_name) as given in the CREATE FUNCTION command for the custom conflict handling function created for the table in the tables parameter list at the position indicated by ordinal_tn. The custom conflict handling function must be added to the master definition node. See Section 6.6.8.2 for an example of adding the custom conflict handling function using PSQL. The custom handler name option must be specified if and only if the conflict resolution option or the standby conflict resolution option is set for custom conflict handling with the C value.
Specify s if this command applies to a single-master replication system. Specify m if this command applies to a multi-master replication system. Note: This parameter is not required and may be completely omitted. It is present to provide support for its usage in previous xDB Replication Server CLI versions.
In the following example, table edb.jobhist and view edb.salesemp are added to an existing publication named analysts_managers.
The removetablesfrompub command removes tables from a publication.
-repsvrfile pubsvrfile
[ -tables schema_t1.table_1 [ schema_t2.table_2 ] ...]
[ -views schema_v1.view_1 [ schema_v2.view_2 ] ...]
See Section 7.6.3.2 for additional information on removing tables from a publication.
Note: The schema names, table names, and view names that you supply as values for the tables and views parameters are case-sensitive. Unless quoted identifiers were used to build the database objects, Oracle names must be entered using uppercase letters (for example, EDB.DEPT), and Advanced Server names must be entered in lowercase letters (for example edb.dept). See Section 10.4.5 for additional information on quoted identifiers and case translation.
The file containing the publication server login information.
The name of the schema containing the nth table of the tables parameter list. This value is case-sensitive.
The name of the nth table in the tables parameter list. This value is case-sensitive.
The name of the schema containing the nth view of the views parameter list. This value is case-sensitive.
The name of the nth view in the views parameter list. This value is case-sensitive.
In the following example, table edb.jobhist and view edb.salesemp are removed from the analysts_managers publication.
The addfilter command adds the definition of table filter rules to the specified publication.
See Section 8.3.38 for information on enabling table filter rules.
–repsvrfile pubsvrfile
[ -tables schema_t1.table_1 [ schema_t2.table_2 ] ...]
[ -views schema_v1.view_1 [ schema_v2.view_2 ] ...]
"ordinal_t1:filtername_t1:filterclause_t1"
[ "ordinal_t2:filtername_t2:filterclause_t2" ] ...]
"ordinal_v1:filtername_v1:filterclause_v1"
[ "ordinal_v2:filtername_v2:filterclause_v2" ] ...]
See Section 2.2.11 for additional information on table filters.
Note: The schema names and table or view names that you supply as values for the tables or views parameters are case-sensitive. Unless quoted identifiers were used to build the database objects, Oracle names must be entered using uppercase letters (for example, EDB.DEPT), and Advanced Server names must be entered in lowercase letters (for example edb.dept). See Section 10.4.5 for additional information on quoted identifiers and case translation.
The file containing the publication server login information.
The name of the schema containing the nth table of the tables parameter list. This value is case-sensitive.
The name of the nth table in the tables parameter list. This value is case-sensitive.
For SMR only: The name of the schema containing the nth view of the views parameter list. This value is case-sensitive.
For SMR only: The name of the nth view in the views parameter list. This value is case-sensitive.
The filter clause to be applied to the table in the tables parameter list at the position indicated by ordinal_tn.
For SMR only: The ordinal number (that is, the position in the list counting from left to right starting with 1) of a view in the views parameter list to which an attribute is to be applied.
For SMR only: The filter clause to be applied to the view in the views parameter list at the position indicated by ordinal_vn.
In the following example, a table filter is added to table edb.emp in publication analysts_managers.
The updatefilter command changes the filter clauses of the specified tables or views.
–repsvrfile pubsvrfile
"filterid_1:filterclause_1"
[ "filterid_2:filterclause_2" ] ...
See Section 2.2.11 for additional information on table filters.
The file containing the publication server login information.
Filter ID identifying the filter rule for which the filter clause is to be changed. Use the printpubfilterslist command to obtain the filter IDs for the available filter rules in the publication (see Section 8.3.17).
The filter clause with filter ID 26 in publication analysts_managers is modified.
The removefilter command deletes the table filter from the specified publication.
–repsvrfile pubsvrfile
-filterid filterid
See Section 2.2.11 for additional information on table filters.
The file containing the publication server login information.
Filter ID identifying the filter rule to be deleted. Use the printpubfilterslist command to obtain the filter IDs for the filter rules in the publication (see Section 8.3.17).
In the following example, the filter rule with filter ID 26 is removed from publication analysts_managers.
For MMR only: The printconfresolutionstrategy command prints the conflict resolution strategy and the standby conflict resolution strategy of the specified table.
–repsvrfile pubsvrfile
-table schema_t.table_name
See Section 6.6 for additional information on conflict resolution.
Note: The schema name and table or view name that you supply as values for the table parameter are case-sensitive. Unless quoted identifiers were used to build the database objects, Oracle names must be entered using uppercase letters (for example, EDB.DEPT), and Advanced Server names must be entered in lowercase letters (for example edb.dept). See Section 10.4.5 for additional information on quoted identifiers and case translation.
The file containing the publication server login information.
The name of the schema containing table_name. This value is case-sensitive.
In the following example, the conflict resolution strategy on Advanced Server table edb.emp in publication emp_pub is printed.
For MMR only: The updateconfresolutionstrategy command changes the conflict resolution strategy or standby conflict resolution strategy of the specified table.
–repsvrfile pubsvrfile
-table schema_t.table_name
[ -customhandlername customhandler ]
See Section 6.8 for additional information on updating the conflict resolution strategy.
Note: The schema name and table or view name that you supply as values for the table parameter are case-sensitive. Unless quoted identifiers were used to build the database objects, Oracle names must be entered using uppercase letters (for example, EDB.DEPT), and Advanced Server names must be entered in lowercase letters (for example edb.dept). See Section 10.4.5 for additional information on quoted identifiers and case translation.
The file containing the publication server login information.
The name of the schema containing table_name. This value is case-sensitive.
For the conflict resolution option, specify E for earliest timestamp conflict resolution, L for latest timestamp conflict resolution, N for node priority conflict resolution, M for manual conflict resolution, or C for custom conflict handling.
For the standby conflict resolution option, specify E for earliest timestamp conflict resolution, L for latest timestamp conflict resolution, N for node priority conflict resolution, M for manual conflict resolution, or C for custom conflict handling.
For the custom handler name option, specify customhandler as the function name with an optional schema prefix (that is, formatted as schema.function_name) as given in the CREATE FUNCTION command for the custom conflict handling function. The custom conflict handling function must be added to the master definition node. See Section 6.6.8.2 for an example of adding the custom conflict handling function using PSQL. The custom handler name option must be specified if and only if the conflict resolution option or the standby conflict resolution option is set for custom conflict handling with the C value.
The conflict resolution strategy on Advanced Server table edb.emp in publication emp_pub is modified to use latest timestamp conflict resolution with a standby strategy of node priority conflict resolution.
Custom conflict handling is set for the edb.dept table along with the custom conflict handling function edb.custom_conflict_dept.
For MMR only: The setasmdn command sets a master node to the role of master definition node.
-setasmdn pubdbid
–repsvrfile pubsvrfile
See Section 6.10 for additional information on setting the master definition node.
The file containing the publication server login information.
The setascontroller command sets a publication database to be designated as the controller database. The publication database may be the master database of a single-master replication system or a master node of a multi-master replication system.
–repsvrfile pubsvrfile
See Section 7.7 for additional information on setting the controller database.
The file containing the publication server login information.
The validatepub command checks if any of the definitions of the tables in the given publication have changed since the publication was created.
–repsvrfile pubsvrfile
See Section 7.6.5 for additional information on validating publications.
The file containing the publication server login information.
Specify s if this command applies to a single-master replication system. Specify m if this command applies to a multi-master replication system.
The validatepubs command checks if any of the definitions of the tables subordinate to the given publication database definition have changed since the publication was created.
–repsvrfile pubsvrfile
See Section 7.6.5 for additional information on validating publications.
The file containing the publication server login information.
Specify s if this command applies to a single-master replication system. Specify m if this command applies to a multi-master replication system.
In the following example, the Oracle publication database definition identified by publication database ID 1 is validated.
The removepub command removes one or more publications.
-removepub pubname_1 [ pubname_2 ] ...
–repsvrfile pubsvrfile
See Section 7.6.6 for additional information on removing a publication.
The file containing the publication server login information.
Specify s if this command applies to a single-master replication system. Specify m if this command applies to a multi-master replication system.
A publication named dept_emp is removed from a single-master replication system.
The replicateddl command applies an ALTER TABLE statement to a publication table in all databases of a replication system as well as updates the xDB Replication Server insert/update/delete triggers and shadow table associated with that publication table.
–repsvrfile pubsvrfile
-table schema_t.table_name
-ddlscriptfile script_file
See Section 7.8 for additional information on DDL change replication.
The file containing the publication server login information.
The name of the schema containing table_name. This value is case-sensitive.
The name of the table in the ALTER TABLE statement whose definition is to be modified. This value is case-sensitive.
Path to the file containing the ALTER TABLE statements.
The following example shows the addition of a column named title to table edb.emp. The ALTER TABLE statement is in the text file addcolumn.sql as shown by the following:
The replicateddl command is executed using the addcolumn.sql file to update the triggers and shadow tables on the master nodes:
For SMR only: The addsubdb command adds a subscription database definition.
-repsvrfile subsvrfile
{ -dbpassword encrypted_pwd | -dbpassfile pwdfile }
[ -urloptions jdbc_url_parameters ]
The addsubdb command creates a new subscription database definition. The addsubdb command displays a unique subscription database ID that is assigned to the newly created subscription database definition. The subscription database ID is used to identify the subscription database definition on which to operate when running other xDB Replication Server CLI commands.
See Section 5.3.2 for details on the database connection information that must be supplied when adding a subscription database definition.
Note: Support of single-master replication systems where Oracle is the subscription (that is, the target) database has been deprecated and may be removed in a future release. It is recommended to avoid creation of a single-master replication system where Oracle is the subscription database.
Note: Support of single-master replication systems where SQL Server is the subscription (that is, the target) database has been deprecated and may be removed in a future release. It is recommended to avoid creation of a single-master replication system where SQL Server is the subscription database.
The file containing the subscription server login information.
Specify oracle if the database is an Oracle database. Specify enterprisedb if the database is an Advanced Server database in Oracle compatible configuration mode. Specify postgresql if the database is a PostgreSQL database or an Advanced Server database in PostgreSQL compatible configuration mode. Specify sqlserver if the database is a Microsoft SQL Server database.
The port number on which the database server is listening for connections.
The encrypted password of the subscription database user. See Section 8.3.5 for directions on using the encrypt command to generate an encrypted password.
Specify sid if the Oracle system ID (SID) is used to identify the subscription database in the database parameter. Specify servicename if the Oracle service name is used to identify the subscription database in the database parameter.
Extended usage of JDBC URL parameters such as for support of SSL connectivity. (See Section 7.10 for information on SSL connectivity to the subscription database.)
The following example adds a subscription database definition for an Oracle database. The encrypted password is given on the command line with the dbpassword parameter. A subscription database ID of 1 is assigned to the database by the subscription server.
The following example adds a subscription database definition for an Advanced Server database. The encrypted password is read from a file named pwdfile with the dbpassfile parameter. A subscription database ID of 2 is assigned to the database by the subscription server.
For SMR only: The printsubdbids command prints the subscription database IDs of the subscription database definitions.
The file containing the subscription server login information.
For SMR only: The printsubdbidsdetails command prints the connection information for each subscription database definition.
dbid:host:port:dbname:user
Note: The database user’s password is not displayed.
The file containing the subscription server login information.
The port number on which the database server is listening for connections.
For SMR only: The updatesubdb command provides the ability to change the connection information for an existing subscription database definition identified by its subscription database ID.
-repsvrfile subsvrfile
{ -dbpassword encrypted_pwd | -dbpassfile pwdfile }
[ -urloptions jdbc_url_parameters ]
See Section 5.3.2 for details on the database connection information that must be supplied for a subscription database definition.
The file containing the subscription server login information.
The port number on which the database server is listening for connections.
The password of the database user in encrypted form. See Section 8.3.5 for directions on using the encrypt command to generate an encrypted password.
Specify sid if the Oracle system ID (SID) is used to identify the subscription database in the database parameter. Specify servicename if the Oracle service name is used to identify the subscription database in the database parameter.
Extended usage of JDBC URL parameters such as for support of SSL connectivity. (See Section 7.10 for information on SSL connectivity to the subscription database.) Specification of the urloptions parameter completely replaces any existing JDBC URL parameters that may have previously been specified with this database. Omission of the urloptions parameter deletes any existing JDBC URL parameters that may have previously been specified with this database.
For SMR only: The removesubdb command removes a subscription database definition.
-removesubdb –repsvrfile subsvrfile –subdbid dbid
See Section 5.5.6 for additional information on removing a subscription database.
The file containing the subscription server login information.
For SMR only: The createsub command creates a new subscription.
-subsvrfile subsvrfile
-pubsvrfile pubsvrfile
-pubname pubname
[ -filterrule filterid_1[,filterid_2 ] ...]
The createsub command adds a new subscription subordinate to the subscription database definition with the subscription database ID given by parameter subdbid.
See Section 5.3.3 for additional information on creating a subscription.
The file containing the subscription server login information of the subscription server under which the new subscription is subordinate.
The file containing the publication server login information of the publication server under which the publication is subordinate to which the new subscription is to be associated.
Comma-separated list of filter IDs identifying the filter rules from the set of available table filters to enable on the corresponding tables in the new subscription. Use the printpubfilterslist command to obtain the filter IDs for the available filter rules in the publication (see Section 8.3.17). Note: There must be no white space between the comma and filter IDs.
In the following example, a subscription named dept_emp_sub is created in the Advanced Server subscription database identified by subscription database ID 2. The subscription is associated with a publication named dept_emp.
For SMR only: The printsublist command prints a list of subscription names.
-printsublist -repsvrfile subsvrfile -subdbid dbid
The file containing the subscription server login information.
The enablefilter command enables one or more filter rules on a single-master replication system subscription or on a multi-master replication system master node other than the master definition node.
The enablefilter command is used when it is desired to apply a filter rule to a subscription or a non-MDN node, but the filter rule did not yet exist or it was neglected to be included with the subscription or the non-MDN node when these components were initially created.
-repsvrfile pubsvrfile
{ -subname subname | -dbid dbid }
-filterids filterid_1 [ filterid_2 ] ...
See Section 2.2.11 for additional information on table filters.
The table filter was added to an existing publication using the addfilter command (see Section 8.3.20) or by the xDB Replication Console (see Section 7.6.4).
The table filter was added to an existing publication using the addfilter command (see Section 8.3.20) or by the xDB Replication Console (see Section 7.6.4).
For SMR: Use the enablefilter command or the xDB Replication Console (see Section 5.5.4).
For MMR: Use the enablefilter command or the xDB Replication Console (see Section 6.9).
The file containing the publication server login information.
For SMR only: The name of the subscription containing the tables on which the filter rules are to be enabled.
For MMR only: The publication database ID of the non-MDN node containing the tables on which the filter rules are to be enabled.
One or more filter IDs separated by space characters identifying the filter rules from the set of available table filters to enable on the corresponding tables in the SMR subscription specified by subname or in the MMR non-MDN node specified by dbid. Use the printpubfilterslist command to obtain the filter IDs for the available filter rules in the publication (see Section 8.3.17).
The disablefilter command disables one or more filter rules on a single-master replication system subscription or on a multi-master replication system master node other than the master definition node.
-repsvrfile pubsvrfile
{ -subname subname | -dbid dbid }
-filterids filterid_1 [ filterid_2 ] ...
See Section 2.2.11 for additional information on table filters.
For SMR: Use the disablefilter command or the xDB Replication Console (see Section 5.5.4).
For MMR: Use the disablefilter command or the xDB Replication Console. (see Section 6.9).
For either SMR or MMR: Use the removefilter command (see Section 8.3.22) or the xDB Replication Console (see Section 7.6.4).
The file containing the publication server login information.
For SMR only: The name of the subscription containing the tables on which the filter rules are to be disabled.
For MMR only: The publication database ID of the non-MDN node containing the tables on which the filter rules are to be disabled.
For SMR only: The dosnapshot command performs snapshot synchronization on the specified subscription in a single-master replication system.
-dosnapshot subname -repsvrfile subsvrfile
See Section 5.4.1 for additional information on performing snapshot replication.
The file containing the subscription server login information.
Set this option to true if you want the output from the snapshot to be displayed. Set this option to false if you do not want the snapshot output displayed. If omitted, the default is true.
For MMR only: The dommrsnapshot command performs snapshot synchronization on the specified master node in a multi-master replication system.
–repsvrfile pubsvrfile
The file containing the publication server login information.
Set this option to true if you want the output from the snapshot to be displayed. Set this option to false if you do not want the snapshot output displayed. If omitted, the default is true.
In the following example snapshot replication is performed on publication emp_pub to the target master node identified by publication database ID 9.
The dosynchronize command performs synchronization replication on the specified subscription for a single-master replication system, or for an entire multi-master replication system.
-dosynchronize { subname | pubname }
-repsvrfile { subsvrfile | pubsvrfile }
-dosynchronize subname –repsvrfile subsvrfile
-dosynchronize pubname -repsvrfile pubsvrfile -repgrouptype m
Note (For SMR only): The dosynchronize command can be used on a subscription without first having to perform a snapshot using the dosnapshot command. The dosynchronize command automatically performs the first required snapshot.
Note (For MMR only): Be sure an initial snapshot replication has been performed from the master definition node to every other master node in the multi-master replication system. If a newly added master node did not undergo an initial snapshot, any subsequent synchronization replication may fail to apply the transactions to that master node. The initial snapshot could be taken when the master node is first added (see Section 6.3 or Section 8.3.7) or by performing an on demand snapshot (see Section 6.5.1 or Section 8.3.41).
See Section 5.4.2 for additional information on performing synchronization replication for a single-master replication system. See Section 6.5.2 for a multi-master replication system.
For SMR only: The name of the subscription for which synchronization replication is to be performed.
For MMR only: The name of the publication for which synchronization replication is to be performed.
For SMR only: The file containing the subscription server login information.
For MMR only: The file containing the publication server login information.
Specify s if this command applies to a single-master replication system. Specify m if this command applies to a multi-master replication system. If omitted, the default is s.
In the following example, synchronization replication is performed on publication emp_pub of a multi-master replication system. Note that the -repgrouptype m parameter is required in this case.
For SMR only: The confschedule command creates a schedule as to when recurring replications are to be initiated for a single-master replication system.
-confschedule subname –repsvrfile subsvrfile
{ -realtime no_of_sec |
-daily hour minute |
-weekly day_of_week hour minute |
-monthly month day_of_month hour minute |
-cronexpr "cron_expression"
If the remove parameter is specified, then the schedule is deleted from the subscription. No other parameters other than subname and repsvrfile can be specified in this case.
If the remove parameter is omitted, then the jobtype parameter and one of parameters realtime, daily, weekly, monthly, or cronexpr must be specified along with the subname and repsvrfile parameters. If there is an existing schedule for subscription subname, it will be replaced by the new schedule.
See Section 7.2 for additional information on creating a schedule.
The file containing the subscription server login information.
If the remove parameter is specified, then any existing schedule is removed from the subscription. If the remove parameter is not specified, then a schedule is created for the subscription.
Specify s if the scheduled replication is to be done by snapshot. Specify t if the scheduled replication is to be done by synchronization. If the associated publication is a snapshot-only publication, then -jobtype s must be used.
The day of the week. This can be any of the following values: SUN, MON, TUE, WED, THU, FRI, or SAT. This value is case insensitive so Sun and sun will work as well as SUN.
The month of the year. This can be any of the following values: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, or DEC. This value is case insensitive so Jan and jan will work as well as JAN.
The day of the month. This can be any integer greater than or equal to 1, and less than or equal to the number of days in month.
A cron expression. See appendix Section 10.4.3 for information on writing a cron expression.
For MMR only: The confschedulemmr command creates a schedule as to when recurring replications are to be initiated for a multi-master replication system.
Note: Be sure an initial snapshot replication has been performed from the master definition node to every other master node in the multi-master replication system. If a newly added master node did not undergo an initial snapshot, any subsequent synchronization replication initiated by a schedule may fail to apply the transactions to that master node. The initial snapshot could be taken when the master node is first added (see Section 6.3 or Section 8.3.7) or by performing an on demand snapshot (see Section 6.5.1 or Section 8.3.41).
-confschedulemmr pubdbid -pubname pubname
–repsvrfile pubsvrfile
{ -realtime no_of_sec |
-daily hour minute |
-weekly day_of_week hour minute |
-monthly month day_of_month hour minute |
-cronexpr "cron_expression"
If the remove parameter is specified, then the schedule is deleted from the publication. No other parameters other than pubdbid, pubname, and repsvrfile can be specified in this case.
If the remove parameter is omitted, then one of parameters realtime, daily, weekly, monthly, or cronexpr must be specified along with the pubdbid, pubname, and repsvrfile parameters. If there is an existing schedule for publication pubname, it will be replaced by the new schedule.
See Section 7.2 for additional information on creating a schedule.
The file containing the publication server login information.
If the remove parameter is specified, then any existing schedule is removed from the publication. If the remove parameter is not specified, then a schedule is created for the publication.
The day of the week. This can be any of the following values: SUN, MON, TUE, WED, THU, FRI, or SAT. This value is case insensitive so Sun and sun will work as well as SUN.
The month of the year. This can be any of the following values: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, or DEC. This value is case insensitive so Jan and jan will work as well as JAN.
The day of the month. This can be any integer greater than or equal to 1, and less than or equal to the number of days in month.
A cron expression. See appendix Section 10.4.3 for information on writing a cron expression.
In the following example, a schedule is created to perform synchronization replication on publication emp_pub subordinate to the master definition node whose publication database ID is 6. Replication is to occur daily at 8:00 AM.
The printschedule command prints a recurring replication schedule.
-printschedule { subname | pubname }
-repsvrfile { subsvrfile | pubsvrfile }
-printschedule subname –repsvrfile subsvrfile
-printschedule pubname -repsvrfile pubsvrfile -repgrouptype m
For SMR only: The name of the subscription for which the schedule is to be printed.
For MMR only: The name of the publication for which the schedule is to be printed.
For SMR only: The file containing the subscription server login information.
For MMR only: The file containing the publication server login information.
Specify s if this command applies to a single-master replication system. Specify m if this command applies to a multi-master replication system. If omitted, the default is s.
For SMR only: The updatesub command allows you to update certain metadata of a given subscription. This metadata allows the subscription server to find the host running the publication server that manages the publication associated with the subscription.
-subsvrfile subsvrfile
-pubsvrfile pubsvrfile
-host newpubsvr_ipaddress
-port newpubsvr_port
The updatesub command allows you to update the subscription metadata consisting of the IP address and port number identifying the publication server that is the parent of the publication associated with the subscription.
You would use the updatesub command in the scenario where you have built your replication system using IP addresses that are valid at that point in time. At some later point, the IP address assigned to the host running the publication server has changed.
You use the host and port parameters of the updatesub command to supply the new network address identifying the publication server.
See Section 5.5.3 for additional information on updating a subscription.
The file containing the subscription server login information for the subscription server in which subscription subname was created.
The file containing publication server login information for the publication server that manages the publication associated with subscription subname. Note that the values that you supply for newpubsvr_ipaddress and newpubsvc_port must be the same as the values set in fields host and port in file pubsvrfile.
The new IP address for the publication server that manages the publication associated with subscription subname. This value must be the same as the IP address specified for field host in file pubsvrfile.
The new port number for the publication server that manages the publication associated with subscription subname. This value must be the same as the port number specified for field port in file pubsvrfile.
If the publication server host IP address has been changed to 192.168.2.7, then make sure the publication server login information in file pubsvrfile.prop contains the new IP address as shown by the following:
To update the metadata for subscription dept_emp_sub so that its subscription server can find the new publication server host, run the following command:
For SMR only: The removesub command removes a subscription.
-removesub subname –repsvrfile subsvrfile
See Section 5.5.5 for additional information on removing a subscription.
The file containing the subscription server login information.
A subscription named dept_emp_sub is removed.
The confcleanupjob command creates a schedule as to when shadow table history is to be deleted.
-confcleanupjob pubdbid –repsvrfile pubsvrfile
{ -minutely no_of_minutes |
-hourly no_of_hours |
-daily hour |
-weekly day_of_week hour |
-cronexpr "cron_expression"
If the disable parameter is specified, then the schedule is deleted. No other parameters other than pubdbid and pubsvrfile can be specified in this case.
If the disable parameter is omitted, then the enable parameter and one of parameters minutely, hourly, daily, weekly, or cronexpr must be specified along with the pubdbid and pubsvrfile parameters.
See Section 7.5.1 for additional information on creating a schedule for shadow table history cleanup.
The file containing the publication server login information.
If the disable parameter is specified, then any existing shadow table history cleanup schedule is removed from the publication database definition. If the disable parameter is not specified, then enable must be specified.
The day of the week. This can be any of the following values: SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, or SATURDAY. This value is case insensitive so Sunday and sunday will work as well as SUNDAY.
A cron expression. See appendix Section 10.4.3 for information on writing a cron expression.
The cleanshadowhistforpub command deletes the shadow table history for the specified publication.
–repsvrfile pubsvrfile
[ -mmrdbid dbid_1[,dbid_2 ] ...]
See Section 7.5.2 for additional information on cleaning up shadow table history.
The file containing the publication server login information.
For MMR only: The publication database ID of the master node for which the shadow table history is to be deleted. This parameter is required for a multi-master replication system specifying one or more comma-separated, publication database IDs. Note: There must be no white space between the comma and publication database IDs.
The cleanrephistoryforpub command deletes the replication history for the specified publication.
-cleanrephistoryforpub pubname –repsvrfile pubsvrfile
See Section 7.5.3 for additional information on cleaning up replication history.
The file containing the publication server login information.
The cleanrephistory command deletes the replication history for all publications in the specified publication server.
See Section 7.5.3 for additional information on cleaning up replication history.
The file containing the publication server login information.
In the following example, replication history is deleted for all publications in the publication server identified by the content of file pubsvrfile.prop.

8 xDB Replication Server Command Line Interface : 8.3 xDB Replication Server CLI Commands

Table of Contents Previous Next