Use the rename config command to give a configuration file a different name. Use a name that is unique among the configuration files on the system.
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 |
| Issued for: |
source system |
| Related commands: |
copy config, edit config, list config, view config |
Syntax
| rename config {filename to newname |
Syntax description
| filename to newname |
- filename is the name of the configuration that you want to rename. Configuration names are case-sensitive.
- to is a required part of the syntax.
- newname is the new name you are giving the configuration.
Example:
sp_ctrl(sysA)> rename config sales to sales2 |
Use the repair status command to view the status of the last compare or repair job run. The repair 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.
For details and examples about using the repair status command, see the job status command
Usage
| Supported sources: |
PostgreSQL |
| Supported targets: |
PostgreSQL |
| Authorization level: |
Operator (2) |
| Issued for: |
source system |
| Related commands: |
compare status, job status |
Syntax
| repair 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_id |
Displays status history for the job with the specified SharePlex-assigned job ID.
Example: sp_ctrl(sysA)> repair 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)> repair status 2828.HR.SRC_TEST3 |
| all |
Displays a summary line for every job with history in the database.
Example: sp_ctrl(sysA)> repair 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)> repair status2828 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)> repair status detail |
| status |
Displays status history for previous jobs with the specified status.
Example: sp_ctrl(SysA)> repair 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 |
The verify config command is intended for use as a preventive measure to avoid certain activation and replication problems. It is intended to be used to test activation to ensure that it will complete successfully.
The verify config command verifies tables only.
This command can be used to:
- Verify the syntax of the entries in the configuration file.
- Report an error if the source object is not supported for replication by SharePlex.
- Report if a host name specified in a route is unreachable.
- Report if there are duplicate specifications for a single object.
- Report if an object specification will be skipped and the reason why.
What the verify config command does not support
The verify config command does not:
- Verify activation time.
- Verify target objects or the target database name.
Verifying added or changed objects in an active configuration
To verify objects that you want to add to an active configuration or objects that you want to change (such as routing changes), it is suggested that you copy and modify the active configuration and then run the verify command against that copy.
Viewing the results of the verification
The verify config command retains control of the sp_ctrl interface until the verification is completed.
The command will read the entire config file and logging errors.
The results of the verify are displayed to the screen within sp_ctrl. If you would like to view detailed results you may:
- Issue the verify config command in sp_ctrl using the detail option
- Navigate to the results file directly using the path displayed to the screen after issuing the verify config command.
Usage
| Supported sources: |
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 |
| Authorization level: |
Viewer (3) |
| Issued for: |
source system |
| Related commands: |
activate config |
Syntax
| verify config filename |
detail |
Supported wildcard syntax
SharePlex supports the following SQL wildcards for tablename
- Percent (%) wildcard to specify a string.
- Underscore (_) wildcard to specify a single-character.
For more information on supported wildcard syntax, see Use Wildcards to Specify Multiple Tables.
Syntax description
| filename |
filename is the name of the configuration to be verified. |
| detail |
This option will display a greater level of detail to the screen.
Example:
sp_ctrl(sysA)> verify config myconfig detail
In this example, the myconfig file will be verified and the results will be displayed with a higher level of detail. |
Use the view partitions command to view the row partitions in one partition scheme or all partition schemes in a horizontally partitioned replication configuration.
For more information about how to configure horizontally partitioned replication, see the SharePlex Administration Guide.
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: |
add partition, drop partition, drop partition scheme, modify partition |
Syntax
|
view partitions for {scheme_name | all} |
Syntax description
| scheme_name |
Show the row partitions for the specified partition scheme. |
| all |
Show all row partitions, grouped according to the names of their partition schemes. |
Examples
sp_ctrl> view partitions for scheme1
sp_ctrl> view partitions all
