Use the clear status command to remove old warning messages from the Status Database.
To use this command:
- Issue the show statusdb detail command to find out which messages can be cleared. Clearable messages have a Yes in the Clear column.
- If you don’t want to clear all messages, make a note of the status ID of each one that you want to clear.
- Issue the clear status command for each status ID, or use the all argument to remove all clearable messages at once.
SharePlex puts a message in the Event Log identifying the messages that were cleared.
This command clears messages from the Status Database for the default system. To clear messages from a Status Database on a different system, use the [onhost] option.
Note: Some messages cannot be cleared.
Usage
| Supported sources: |
PostgreSQL |
| Supported targets: |
PostgreSQL |
| Authorization level: |
Operator (2) |
| Issued for: |
source or target system |
| Related commands: |
show statusdb |
Syntax
| clear status {statusID| all} |
[ on host |
on host:portnumber |
on login/password@host |
on login/password@host:portnumber ] |
Syntax description
| statusID |
The SharePlex-assigned ID of an individual message (obtained using the show statusdb command) that you want to remove.
Example:
sp_ctrl(sysA)>clear status 20 |
| all |
This argument removes all clearable messages.
Example:
sp_ctrl(sysA)>clear status all |
Remote options
These options enable you to issue the command on a remote machine and to script commands that include a login name, password, port number, or combination of those items.
| on host |
Execute the command on a remote system (one other than the one where the current sp_ctrl session is running). You are prompted for login credentials for the remote system. If used, must be the last component of the command syntax.
Example: sp_ctrl(sysB)>status on SysA |
| on host:portnumber |
Execute the command on a remote system when a remote login and port number must be provided. If used, must be the last component of the command syntax.
Example: sp_ctrl(sysB)>status on SysA:8304 |
| on login/password@host |
Execute the command on a remote system when a remote login, password, and host name must be provided. If used, must be the last component of the command syntax.
Example:sp_ctrl(sysB)>status on john/spot5489@SysA |
| on login/password@host:portnumber |
Execute the command on a remote system when a remote login, password, host name, and port number must be provided. If used, must be the last component of the command syntax.
Example: sp_ctrl(sysB)>status on john/spot5489@SysA:8304 |
Use the compare and compare using commands (collectively known as the comparison commands) to verify that a target table is in synchronization with its source table.
- The compare command compares individual source and target tables or any number of tables in a given schema through the use of wildcards. When comparing individual tables, you can make use of column-based filtering to control the rows that are selected for comparison.
- The compare using command compares all of the tables listed in the active configuration or in another file that contains a subset of the tables in the active configuration.
After running a comparison, you can run the repair or repair using command to repair any out-of-sync rows.
Note: A running comparison or repair does not affect the source tables in any way. SharePlex logs into the database only to query for read consistency, and the locks on the source tables are brief. SharePlex briefly locks the target tables during the processing, but users can continue accessing them with little or no awareness of the lock.
Supported operations
SharePlex can detect and repair out-of-sync rows in a target table that are caused by DML operations: INSERT, UPDATE, DELETE.
Not supported
SharePlex does not support (and will skip) the comparison and repair of the following:
-
Sequences
- Tables for which transformation was used
- Network configurations in which a pass-through server is used to pass data between the source and target servers.
- Comparisons and repairs are not supported in a cascading replication environment.
-
Do not perform DDL on a table that is being compared or repaired. A comparison does not detect out-of-sync conditions caused by DDL operations, including those that SharePlex supports. If the DDL changes the table definition, it invalidates the SELECT statement that is built by the comparison process to get the rows that need to be compared.
Once you correct an out-of-sync condition caused by DDL, you can use the repair command to resynchronize the data in the rows.
- Comparison and repair command strings longer than 255 characters are not supported. This is an operating system limitation. To work around this limitation, use the edit command on the source system. You can type the command string within a text file, and then the command automatically executes the file.
See the SharePlex Release Notes for additional information about data types that are supported by compare and compare using.
Other conditions
- The tables that you want to compare or repair must be part of an active configuration file.
- Uncommitted transactions on a source table prevent the comparison and repair processes from obtaining the brief locks they need to obtain read consistency. Make certain that all transactions are committed before you run a comparison or repair.
-
Replication latency reduces the performance of compare and repair processing. The message from the source that spawns the comparison and repair processes on the target is sent through the queues with the replicated data. Delays caused by a data backlog also delay the spawn message and can cause the source process to lose its read consistency. If possible, perform comparisons and repairs during off-peak hours.
- Do not truncate a table that is being compared or repaired. The comparison commands take a snapshot of each source table when they start. If a table is truncated, the table view in the snapshot is truncated, and this can cause the command to return invalid out-of-sync conditions.
-
To repair a view, the following must be true:
- The view table must contain all of the constraint columns of the underlying table.
- The names of the constraint columns in the view must be identical to the names of the constraint columns in the underlying table.
-
To enhance the performance of the Compare process, SharePlex supports parallel hints via the SP_DEQ_PARALLELISM parameter, allowing you to specify the degree of parallelism, i.e., the number of worker processes to be launched.
By default, the PostgreSQL database optimizer selects the best-suited query execution plan for SQL statements, which may not be directly related to the degree of parallelism specified in the parallel hints. pg_hint_plan makes it possible to adjust execution plans using parallel hints each time a query is executed. SharePlex internally utilizes the pg_hint_plan extension if it is installed or configured in the database.
The example syntax to use parallel queries is as follows:
The pg_hint_plan extension supports the Parallel hint: Parallel(table <# of workers> [soft|hard])
SharePlex uses Parallel hints with hard parsing support: Parallel(table <# of workers> [hard])
Note: The number of workers should be less than the CPU VCore of the database system.
Special use cases
The following scenarios require special handling when running a comparison.
| Consolidated replication |
Consolidated replication is supported if the target database and Post processes are configured to add the ID of the source host to each row. To compare or repair the correct rows in the central target table, use the targetwhere option and base the where clause on the source ID value.
For example, to compare a table in the database at the Eastern headquarters of a company to the correct rows in the central corporate database, you could use a source ID of "East" for the Eastern database and then base the targetwhere clause on that value. Use the same targetwhere clause in the repair command. The comparison and repair processes can use the source ID value to select only the rows that are valid for the Eastern database.
To use the comparison or repair commands for any implementation of consolidated replication, other than one that identifies a source ID, may result in the unwanted deletion of target rows. For more information about this configuration, see the SharePlex Administration Guide.
You may need to combine the targetwhere option with the standard where option to ensure that the target rows are selected accurately. |
| Peer-to-peer replication |
In a peer-to-peer configuration, you must decide which system is the trusted source system and which is the secondary, or target, system. The secondary system is the one where any repairs will be performed. Before you run a comparison or repair in a peer-to-peer environment, follow these steps:
- Stop user access on the secondary system and wait for replicated operations from that system to post to the trusted source database. Users can continue to access the source database.
- Issue the qstatus command on the source and secondary systems.
- When there are 10 or fewer messages in the queues, run the comparison from the source system.
- During a comparison, you can permit user access to the source and secondary databases after the sp_xdesvr and sp_xdeclt start.
- Use the repair command with the where option to repair selected rows in a target table without locking users out of the table.
For more information about this configuration, see the SharePlex Administration Guide. |
| Tables without keys |
The comparison and repair commands issue a SELECT statement with an ORDER BY clause on the source and target systems. The ordering is faster if large tables have a primary key or a unique, non-null key and an index (preferably a unique index). Otherwise, all of the columns are used as a key.
If a table has no unique row identifier, but does have one or more columns that can identify a row as unique, you can use the compare command with the orderby option. When this option is used, SharePlex prints a notice to the sp_xdesvr log on the source system that the command used those columns as a key.
Limitation: Data inconsistency is likely to occur in replication or compare-repair processes when SharePlex replication involves tables containing non-key columns with duplicate data. |
| Tables with extra source or target columns |
Use the compare command with the sourcewhere or targetwhere clause if the source or target table contains extra columns and those columns contain unique values on which to base the sorting. See Control which rows are compared. |
How the comparison works
A comparison detects out-of-sync conditions in a target table that are caused by DML operations:
- extra or missing rows
- rows whose values do not match
When you run the compare or compare using command on the source system, SharePlex initiates the following events:
- The sp_cop process spawns a sp_xdesvr (server) process on the source system.
- The sp_desvr process returns control and use of the sp_ctrl interface to the user, and replication continues while the comparison proceeds.
- The sp_xdesvr process sends a message to the Post process to initiate a sp_xdeclt (client) process on the target system.
- The server and client processes establish direct communication with each other.
- The processes perform a sanity check by comparing the number of rows in the source and target tables. If the difference in the number of rows between a source and target table is larger than 20 percent, the command terminates. The sanity check prevents wasting time to compare or repair tables that could be fixed more quickly by reloading the target data. You can use the copy or append command to reload the target data or use another method of your choosing. To override the sanity check, reissue the compare command with the override option.
- To override the sanity check, reissue the Compare command with Override option.
-
If the row count passes the sanity check, the tables are compared as follows:
- If the compare command is being used, sp_xdesvr selects the source rows, and sp_xdeclt selects the target rows, then the rows are sorted and compared.
- If the compare using command is being used, the sp_xdesvr process creates a number of processing threads on the target system. The value set by the SP_DEQ_THREADS parameter controls the number of threads created. Each thread spawns an sp_xdeclt (client) process. The server and client processes establish direct communication with each other. The processing load is divided among the client processes. The rows from each source and target table are selected, sorted and compared.
- When finished, the processes write their log files, and you can view the results with the show compare command.
Manage the SQL log file
The compare and repair commands write the SQL that is needed to repair any out-of-sync rows to a SQL file in the same location as the log files. If only a compare command is issued, SharePlex does not execute these SQL statements. If a repair command is issued, the command works identically to the compare commands except that it executes the SQL statements to repair the out-of-sync rows.
You can suppress the output of the SQL log file. Some reasons to suppress this file are:
- The data contains sensitive information. The SQL log file is written in clear text. By not producing a SQL log file, the sensitive data is not persisted to disk, which may satisfy security requirements for data at rest, such as those required to meet PCI compliance standards.
- The compared or repaired tables have a very large number of out-of-sync rows. A log file of this size can consume a large amount of disk space.
To suppress the SQL log file, use the nosqllog option with the compare or repair command.
To suppress the output of the SQL log file for all compare and repair runs while the current instance of SharePlex is running, set the SP_SYS_SECURE_MODE environment variable to 1. This variable must be set before starting SharePlex, so if the sp_cop process is running it must be restarted after setting this variable. When sp_cop is run with this environment variable, the compare and repair commands will not put data into SQL files and the Post process will not put data into the SharePlex error log.
Run multiple processes
All of the compare and repair commands enable you to run multiple processes concurrently. Multiple compare and repair commands can operate concurrently, each processing a pair of source and target tables, or you can use one command with PostgreSQL wildcards to specify multiple sets of tables. See the SharePlex Administration Guide for more information about how SharePlex supports wildcards.
A maximum of 20 SharePlex processes can use the post queue at the same time, including the replication processes and the comparison and repair processes. It is recommended that you allow a maximum of five comparison and repair processes to run at any given time.
If a comparison or repair fails because the limit is reached, SharePlex logs a message to the Event Log.
Note: You can run multiple commands more easily by using the edit command to edit a previous command to create a new one.
Compare a subset of a configuration
You can compare subsets of an active configuration file in the following ways.
-
To compare all of the tables in replication that belong to one schema, use the compare command with a wildcard:
sp_ctrl> compare scott.%
-
To compare all of the tables in a configuration file, use the compare using command:
sp_ctrl> compare using myconfig
-
To compare all of the tables in replication to one target route, use the compare using command with the at option:
sp_ctrl> compare using config.active at prodsys@r.database_name
- To compare a custom subset of the tables in a configuration, specify them in a compare file. This is a plain text file that lists only the source tables that you want to compare. The target tables are taken from the configuration file at the time of comparison. You can create a compare file by using the create config or copy config command. Make certain to give this file a name that makes it clear it is not a configuration file. See the command syntax for more information.
Control which rows are compared
The compare and repair commands have where options that enable you to filter the rows that are selected for processing. By default, these commands affect all rows of a table and ignore columns in the target table that are not contained in the source table.
-
Use the where option to filter rows based on identically named columns in the source and target tables.
- Use the where option for a table that uses vertically partitioned replication. The source and target columns can have different names. Base the where selection on the source columns. SharePlex reads the column mappings from the configuration file to build the correct WHERE clause for the target table.
-
Use the sourcewhere and targetwhere options if one or more extra columns exists in either the source or target table and those rows contain values that determine row uniqueness.
- Use sourcewhere if the source table contains the extra columns.
- Use targetwhere if the target table contains the extra columns.
To use this option correctly:
- SharePlex combines the where option with the sourcewhere or targetwhere option to create the complete WHERE clause.
Important! If you plan to run both a comparison and repair for a target table that has extra rows, only use targetwhere to compare for UPDATEs and DELETEs. The repair command cannot determine the correct values for INSERTs. To work around this issue, set a default value for the extra columns or manually update the inserted rows.
Identify processes
Every time that a comparison or repair command is issued, the job ID is shown in the sp_ctrl display. If the sp_ctrl display is not available, you can view the job ID by running the compare status command.
View status and results in sp_ctrl
To view the status or results of a comparison, use the compare status command in sp_ctrl.
- The basic command displays the processing status of the most recently started comparison job, as well as other comparison jobs that are still running.
- Additional options can be used to display a status summary for comparison jobs for which there is history, or to display detailed information about a comparison job.
For more information, see Compare status.
View warnings and errors
The sp_xdesvr and sp_xdeclt processes write a log file on the system where they run. The logs are stored in the log sub-directory of the SharePlex variable-data directory.
The name of the log written by the sp_xdesvr process is xdesvr_<jobid>_r.<dbid>_p<process id>.log, where:
- JobID is the SharePlex-assigned job ID.
- DBID is the database ID of the PostgreSQL instance.
- ProcessID is the process ID of the sp_xdesvr process.
The names of the files written by the sp_xdeclt process are xdeclt_<jobid>-<tableid>_r.<dbid>_p<processid>.log appended with either .log or .sql, where:
- JobID is the SharePlex-assigned job ID for the job.
- TableID is the SharePlex-assigned table ID for the table in the job.
- DBID is the database ID of the PostgreSQL instance.
- SourceHost is the name or IP address of the source host.
- ProcessID is the process ID of the sp_declt process.
Example log file names:
xdesvr_7_r.aparopka_p4970.log
xdeclt_7-1_r.aparopka_p25095.log
xdeclt_7-1_r.aparopka_p25095_01.sql
To control disk usage, the logs are aged in a circular fashion. SharePlex generates a new log file when the current log reaches the size limit. New logs are created up to a maximum number of logs, and then SharePlex starts overwriting the oldest log.
Note: For the compare using command, there rarely is more than one log file.
Cancel a compare job
Use the cancel command to stop a running comparison or repair job.
sp_ctrl(sysA)>cancel JOBID
For more information, see Cancel.
Manage compare history and logs
SharePlex retains a history of each finished job in the database on the source system. The SP_SYS_JOB_HISTORY_RETENTION parameter controls how long history is retained.
To clear this history on demand, use the clear history command. When SharePlex removes the history of a job, it also removes the log file that was the source of the history.
To remove the log files from the source system without clearing the job history from the database, use the remove log command. You can also use this command to remove old log files from the target system.
To control the size of the log files, set the SP_DEQ_LOG_FILESIZE parameter.
To produce separate SQL files for INSERT, UPDATE, and DELETE operations, rather than use just one file for all operation types, use the log split option.
Control the batch size
You can control the size of the block of rows that is fetched when the process makes its SELECT query. The block size is calculated based on the value set with the SP_DEQ_MALLOC parameter. The value is divided equally by the number of comparison threads to be used, and then it is recalculated based on the size of all of the columns added together.
Repair out-of-sync rows
To repair out-of-sync rows found by the comparison, use the repair or repair using command. See Repair / repair using.
Usage
| Supported sources: |
PostgreSQL |
| Supported targets: |
PostgreSQL |
| Authorization level: |
Operator (2) |
| Issues on: |
source system |
| Related commands: |
Repair / repair using |
Syntax
| compare owner.source_table[.partition] |
[ at target_host@r.target_db ] |
[ forr.source_db ] |
[ {include | exclude} "column_list" ] |
[ key ] |
[ log rowdata ] |
[ log split ] |
[ {nolocksource | nolocktarget} ] |
[ nosqllog ] |
[ not "exception_list" ] |
[ orderby "column_list” ] |
[Override parameter to the compare and repair command] |
[ parallelism degree ] |
[ quickcheck ] |
[ sourcewhere “clause” ] |
[ threadsthread_count ] |
[ targetwhere “clause” ] |
[ totarget_owner.target_table[.partition] ] |
[ where “clause” ] |
[ on host |
on host:portnumber |
on login/password@host |
on login/password@host:portnumber ] |
| compare using filename |
[key] |
[log rowdata] |
[log split] |
[parallelismdegree] |
[port port_number] |
[quickcheck] |
[threadsthreads_count] |
[ on host |
on host:portnumber |
on login/password@host |
on login/password@host:portnumber ] |
Syntax description
Required command components
| compare owner.source_table[.partition] |
The basic command compares all of the source rows with all of the target rows.
owner.source_table is the owner and name of the source table. Use double quotes to enforce case-sensitivity or spaces within a name, for example “HR”.emp.
Wildcarded table names (but not owner names) are supported. To be compared, tables that satisfy a wildcard in this command must be listed (explicitly or by wildcard) in the active replication configuration. For more information about how SharePlex handles wildcards, see the SharePlex Administration Guide.
Example
sp_ctrl(sysA)>compare scott.emp
sp_ctrl(sysA)>compare scott.emp.west |
| compare using filename |
The basic command compares all of the source rows with all of the target rows in the tables listed in filename.
filename is the name of the file that contains the names of the source tables that you want to compare.
Example
sp_ctrl(sysA)>compare using sales |
Optional command components
| at target_host@r.target_database_name |
Valid for compare
Compares the source table to only one of its targets. Use when the source table replicates to multiple target systems.
target_host is the name of the target system.
target_db is the name of the target database name.
Example
sp_ctrl(SysA)>compare scott.emp at prod@r.database_name |
| for r.DBID |
Valid for compare
Specifies the PostgreSQL instance that contains the source table. Use when the same source table is in multiple PostgreSQL instances on a system.
DBID is the database name of the PostgreSQL source instance. It is case-sensitive and must be typed as it appears in the config file.
When used, this option must appear after the required command arguments, but it can appear in any order with other options.
Example
sp_ctrl (SysA)>compare scott.emp for r.database_name |
| {include | exclude} "(column_list") |
Valid for compare
Filters the columns to be compared.
- Use include to specify columns that you want to compare. No other columns are compared. You must include all of the key columns in an include clause.
- Use exclude to compare all columns except those specified with exclude. Do not exclude any key columns.
(column_list) is the list of columns to include or exclude.
- Separate each name with a comma. No spaces are permitted in the list unless the name of a column contains spaces.
- Enclose the column list within double quote marks.
- List columns in any order. The sort is performed in ascending order.
- Column names are not case-sensitive.
- When used, this option must appear after the required arguments of the command, but it can appear in any order with other options.
Note: There could still be rows that are out-of-sync in the columns that were not compared.
Example
sp_ctrl (SysA)>compare scott.emp exclude "color, weight" |
| key |
Valid for compare and compare using
Performs a fast comparison of large tables. This command does not compare all of the data values. It compares one of the following:
Important: Even if the keys or the orderby values match, the tables remain out of synchronization if values in other columns do not match.
When used, this option must appear after the required command arguments. It can appear in any order with other options.
Do not use this option to base a comparison on a SharePlex key definition. For more information about SharePlex key definitions, see the SharePlex Administration Guide.
Example
sp_ctrl (SysA)>compare scott.emp key
sp_ctrl(sysA)>compare using sales key |
| log rowdata |
Valid for compare and compare using
Directs the client process to produce a SQL file that logs the actual row data rather than hash values. The file is produced on the target system. If the value of any of these data types is very large, SharePlex may not be able to log the actual data.
IMPORTANT! The purpose of this SQL file is to provide a view of the data that was compared. Do not use it to repair target tables. The data values that were captured when the command was run may be different from those currently in the database. Use the repair command to repair any out-of-sync rows.
Example
sp_ctrl(sysA)>compare scott.emp log rowdata
sp_ctrl(sysA)>compare using sales log rowdata |
| log split |
Valid for compare and compare using
Directs the client process to split its SQL file into three different files based on the operation type: one for INSERTs, one for UPDATEs, and one for DELETEs.
Example
sp_ctrl(sysA)>compare scott.emp log split
sp_ctrl(sysA)>compare using sales log split |
|
{nolocktarget | nolocksource} |
Valid for compare
Prevents the comparison process from locking tables during the comparison phase of a run that includes a repair. Normally, SharePlex locks the tables momentarily during a comparison to get a read-consistent view, and then unlocks them immediately, but SharePlex always locks target tables during a repair. SharePlex locks source tables momentarily during a repair to get a read-consistent view.
Example
sp_ctrl(sysA)>compare scott.emp nolocksource
sp_ctrl(sysA)>compare scott.emp nolocktarget |
| nosqllog |
Suppresses output of the SQL log file. This file contains the SQL that is needed to repair out-of-sync rows. Some reasons not to output this file include:
- The data contains sensitive information. The SQL log file is written in clear text. By not producing a SQL log file, the sensitive data is not persisted to disk, which may satisfy security requirements for data at rest, such as those required to meet PCI compliance standards.
- The compared or repaired tables have a very large number of out-of-sync rows. A log file of this size can consume a large amount of disk space.
|
| not “exception_list” |
Valid for compare
Specifies an exception list of tables not to compare when the table specification includes wildcards.
“exception_list” is a list of names of the tables not to compare.
- Use the owner.tablename format.
- Separate each name with a comma. No spaces are permitted in the list.
- Enclose the list within double quote marks.
- List the tables in any order.
- When used, this option must appear after the required arguments of the command, but it can appear in any order with other options.
Example
sp_ctrl(SysA)>compare scott.% not (%temp%) |
| orderby “column_list” |
Valid for compare
Specifies columns for the comparison process to use in its ORDERBY clause when it sorts rows to be compared. This option enables comparisons to be performed on tables that have no primary or unique key.
“column_list” is the names of the columns to use in the ORDERBY clause.
- Separate each name with a comma. No spaces are permitted in the list unless the name of a column contains spaces.
- Enclose the column list within double quote marks.
- List columns in any order. The sort is performed in ascending order.
- Column names are not case-sensitive.
- When used, this option must appear after the required arguments of the command, but it can appear in any order with other options.
Example
sp_ctrl(SysA)>compare scott.emp where “file >001005” orderby “Last Name,Division”
When running a comparison from the command line of the operating system, quoted strings must have an extra set of escaped double quotes:
/productdir/bin/sp_ctrl compare scott.emp orderby “\“Last Name,Division\”” |
| override |
Valid for compare and compare using
Overrides the sanity check and allows the comparison of tables that are out-of-sync beyond the sanity check threshold.Use an alternative method to re-sync the target table, similar to the initial process used for instantiating the target database/table. For more information about sanity check, see how the comparison works.
Example:
SP_ctrl (sysA) > compare scott.emp override
SP_ctrl (sysA) > compare using sales override |
|
quickcheck |
Valid for compare and compare using
Performs an initial check to determine if any rows are out of synchronization. As soon as one out-of-sync row is detected, the process stops. No further information is returned. No out-of-sync row information is logged to the compare SQL file.
Do not use this option with the key option or any of the where options.
This option does not support LONG columns.
Example
sp_ctrl(sysA)>compare scott.emp quickcheck
sp_ctrl(sysA)>compare using sales quickcheck |
| parallelism degree |
Valid for compare and compare using
Adds a parallel hint to the SELECT statement. For degree, set the degree of parallelism.
Example
sp_ctrl(sysA)>compare scott.emp parallelism 4
sp_ctrl(sysA)>compare using sales parallelism 4 |
| sourcewhere “clause” |
Valid for compare
Bases the comparison on one or more columns in the source table when those columns do not exist in the target table. Rows filtered by this condition on the source table will be locked.
- Enclose clause within double quote marks and refer to tables by their fully qualified names, for example scott.emp.
- Use double quote marks to enforce case sensitivity or spaces within a table name.
- Dates must be in the format of 'YYYYSMMDDHH24MISS'. To convert a date to that format, use the PostgreSQL TO_DATE function. For example if c1 is a DATE column, the WHERE clause "c1 > '10-SEP-2001'" will not work, but "c1 > to_date('10- SEP-2001', 'DD-MON-YYYY')" will work.
-
When running a comparison from the command line of the operating system, quoted strings must have an extra set of escaped double quotes, like the following example:
sp_ctrl>compare scott.emp sourcewhere “\“file >001005\””
- When used, this option must appear after the required command arguments, but it can appear in any order with other options.
Example #1:
sp_ctrl(sysA)>compare scott.emp sourcewhere “file >001005”
Example #2:
The following example shows how the sourcewhere and where options are combined to get the desired result. Only the source comparison process will use the sourcewhere clause, but both the source and target comparison processes will use the where clause.
sp_ctrl(SysA)>compare scott.emp sourcewhere “deptno = 200” where “mgr = ‘SMITH’” |
| targetwhere "clause" |
Valid for compare
Bases the comparison on one or more columns in the target table when those columns do not exist in the source table. Rows filtered by this condition on the target table will be locked.
- Enclose the clause within double quote marks and refer to tables by their fully qualified names, for example scott.emp.
- Use double quote marks to enforce case sensitivity or spaces within a table name.
- Dates must be in the format of 'YYYYSMMDDHH24MISS'. To convert a date to that format, use the PostgreSQL TO_DATE function. For example if c1 is a DATE column, the WHERE clause "c1 > '10-SEP-2001'" will not work, but "c1 > to_date('10- SEP-2001', 'DD-MON-YYYY')" will work.
-
When running a comparison from the command line of the operating system, quoted strings must have an extra set of escaped double quotes:
/productdir/bin/sp_ctrl compare scott.emp targetwhere “\“file >001005\””
- When used, this option must appear after the required command arguments, but it can appear in any order with other options.
Example #1:
sp_ctrl(SysA)> compare scott.emp targetwhere “file >001005”
Example #2:
The following example shows how the targetwhere and where options are combined to get the desired result. Only the target comparison process will use the targetwhere clause, but both the source and target comparison processes will use the where clause.
sp_ctrl(SysA)>compare scott.emp where “deptno = 200” targetwhere “mgr = ‘SMITH’” repair |
| threads thread_count |
Valid for compare and compare using
Sets the number of processing threads that are used by the comparison process.
Example
sp_ctrl(sysA)>compare scott.emp threads 4
sp_ctrl(sysA)>compare using sales threads 4 |
| to target_owner.target_table[.partition] |
Valid for compare
Compares the source table to only one of its targets. Use when the source table replicates to multiple target systems and the target tables have different names.
This option can also be used to specify a target partition.
compare source_owner.source_table.[source_partition] to target_owner.target_table.[target_partition]
Example
(Compares a partition)
sp_ctrl(SysA)>compare scott.emp.east to scott.allemp.alleast |
| where “clause” |
Valid for compare
Include a WHERE clause in the SELECT statement on both the source and target systems. The WHERE clause acts as a filter to compare specific rows. Rows filtered by this condition will be locked.
For “clause” specify a standard WHERE clause that does not include subqueries.
- Enclose the clause within double quote marks and refer to tables by their fully qualified names, for example scott.emp.
- Use double quote marks to enforce case sensitivity or spaces within a table name.
- Dates must be in the format of 'YYYYSMMDDHH24MISS'. To convert a date to that format, use the PostgreSQL TO_DATE function. For example if c1 is a DATE column, the WHERE clause "c1 > '10-SEP-2001'" will not work, but "c1 > to_date('10- SEP-2001', 'DD-MON-YYYY')" will work.
- When used, this option must appear after the required command arguments, but it can appear in any order with other options.
Example
sp_ctrl (SysA)>compare scott.emp where “region=4” |
Remote options
These options enable you to issue the command on a remote machine and to script commands that include a login name, password, port number, or combination of those items.
| on host |
Execute the command on a remote system (one other than the one where the current sp_ctrl session is running). You are prompted for login credentials for the remote system. If used, must be the last component of the command syntax.
Example: sp_ctrl(sysB)>status on SysA |
| on host:portnumber |
Execute the command on a remote system when a remote login and port number must be provided. If used, must be the last component of the command syntax.
Example: sp_ctrl(sysB)>status on SysA:8304 |
| on login/password@host |
Execute the command on a remote system when a remote login, password, and host name must be provided. If used, must be the last component of the command syntax.
Example:sp_ctrl(sysB)>status on john/spot5489@SysA |
| on login/password@host:portnumber |
Execute the command on a remote system when a remote login, password, host name, and port number must be provided. If used, must be the last component of the command syntax.
Example: sp_ctrl(sysB)>status on john/spot5489@SysA:8304 |
Use the compare status command to view the status of the last compare or repair job run. The compare status command can be used to view detailed status on a compare or repair job or a portion of a compare or repair job, or to view status on all compare and repair jobs for which SharePlex has history.
Note: For details and examples about using the compare status command, see the job status command.
Usage
Syntax
| job status |
[job_id]
[Job_id.table_id]
[all]
[full]
[detail]
[status] |
[ on host |
on host:portnumber |
on login/password@host |
on login/password@host:portnumber ] |
Syntax description
| job status |
Shows status of all compare and repair jobs for which SharePlex has history. |
| job_id |
Displays status history for the job with the specified SharePlex-assigned job ID.
Example:
sp_ctrl(sysA)>job status 2828.2 |
|
job_id.table_id |
Displays status history for the job with the specified SharePlex-assigned job ID and table.
Example:
sp_ctrl(sysA)>job status 2828.HR.SRC_TEST3 |
| all |
Displays a summary line for every job with history in the database.
Example:
sp_ctrl(sysA)>job status all |
| full |
Displays the status of every object in the job. By default, the job status command displays the status of those objects not completed, or completed with an exceptional status.
Example:
sp_ctrl(sysA)>job status 2828 full |
| detail |
Displays detail information for every object reported upon. By default, the job status command displays a summary line for every object reported upon. Note that the detail information is the same as is displayed for the job_id.table_id option.
Example:
sp_ctrl(sysA)>job status detail |
| status |
Displays status history for previous jobs with the specified status.
Example:
sp_ctrl(sysA)>job status "Error" |
Remote options
These options enable you to issue the command on a remote machine and to script commands that include a login name, password, port number, or combination of those items.
| on host |
Execute the command on a remote system (one other than the one where the current sp_ctrl session is running). You are prompted for login credentials for the remote system. If used, must be the last component of the command syntax.
Example: sp_ctrl(sysB)>status on SysA |
| on host:portnumber |
Execute the command on a remote system when a remote login and port number must be provided. If used, must be the last component of the command syntax.
Example: sp_ctrl(sysB)>status on SysA:8304 |
| on login/password@host |
Execute the command on a remote system when a remote login, password, and host name must be provided. If used, must be the last component of the command syntax.
Example:sp_ctrl(sysB)>status on john/spot5489@SysA |
| on login/password@host:portnumber |
Execute the command on a remote system when a remote login, password, host name, and port number must be provided. If used, must be the last component of the command syntax.
Example: sp_ctrl(sysB)>status on john/spot5489@SysA:8304 |
Use the copy config command to copy a configuration file and save the copy under a different file name.
Copying the configuration allows you to:
- Save a replica for backup purposes
- Use the copy as the basis for composing a new configuration using the edit config command
- Change an active configuration. You can make your changes to the copy with the edit config command while replication under the current configuration continues, and then activate the new configuration when you are ready.
This command copies the configuration to the same source system as the original configuration. To copy a configuration file to a different system, you can transfer the file via tape, CD, or FTP. To see a list of configurations on a system, use the list config command. To view the contents of a configuration, use the view config command.
Usage
| Supported source: |
PostgreSQL (on-prem), Amazon RDS for PostgreSQL, Amazon Aurora for PostgreSQL, Azure Database for PostgreSQL Flexible Server, and Google Cloud SQL for PostgreSQL |
| Supported targets: |
PostgreSQL, Oracle, SQL Server, Kafka, Amazon RDS for PostgreSQL, Amazon Aurora for PostgreSQL, Azure Database for PostgreSQL Flexible Server, and Google Cloud SQL for PostgreSQL |
| Issues on: |
source system |
| Related commands: |
activate config, create config, list config, show config, verify config, view config |
Syntax
| copy config filename to newname |
Syntax description
| filename tonewname |
- filename is the name of the configuration that you want to copy. Configuration names are case-sensitive.
- to is a required part of the syntax.
- newname is the name you are giving to the copy. It must be unique among configurations on the system.
Example: sp_ctrl(sysA)>copy config sales to sales2 |
