Requirement | Completed? (Y/N) |
---|---|
Confirm database ownership Make certain that the SQL Server source databases that you will be replicating are owned by a SQL Server user, not a domain user. |
|
Configure a Data Source Name Create a System (not User) Data Source Name (DSN) for the SQL Server database on the Windows system. The DSN can use either Windows NT authentication or SQL Server authentication. If you configure the DSN to use NT authentication and are using SQL Server 2012 or later, grant the NTAuthority\SYSTEM user the sysadmin fixed server role. ( For earlier versions of SQL Server, sysadmin is granted to the NT Authority\SYSTEM user by default.) Test connection to the database through this DSN. If SharePlex will be replicating data from, or to, databases that are in different SQL Server instances on the same system, each of those databases must have a unique name. Because SharePlex identifies a database by its name, if two or more databases have the same name, SharePlex will only connect to one of them. If databases in different SQL Server instances have the same name but you are only using SharePlex for one of them, the names can remain identical without causing connection conflicts. |
|
Install SQL Server Replication Components SharePlex Capture makes use of the underlying components of the native SQL Server replication components. SQL Server Replication must be installed before you install and set up SharePlex, and then the SharePlex Database Setup utility must be run to configure a local Distribution Agent. This utility is typically run as part of the SharePlex installation procedure. |
|
Be ready to quiesce the source database Before you activate a configuration to capture from a SQL Server source, you must quiesce the tables that are in that configuration. The tables must remain quiesced for the entire activation process. |
|
Satisfy requirements for database naming These use cases can cause connection problems for SharePlex unless resolved as recommended. Names of replication databases are identical among local instances If SharePlex will be replicating data from, or to, databases that are in different SQL Server instances on the same system, each of those databases must have a unique name. Because SharePlex identifies a database by its name, if two or more databases have the same name, SharePlex will only connect to one of them. If databases in different SQL Server instances have the same name but you are only using SharePlex for one of them, the names can remain identical without causing connection conflicts. Source and target have the same name, but different case SQL Server source and target databases that have the same name but different case collation can cause connection problems for SharePlex. If you cannot either change the case of the databases to be identical, or rename one of them to a different name, you can use the following workaround after you install SharePlex and run the mss_setup utility. Workaround:
Example: r.my_database: database: MY_DATABASE dsn: my_sp1 dstype: sqlserver password: 558ec793ac plugin: sqlserver plugin_direction: target plugin_version: 1 user: qarun r.MY_DATABASE: database: MY_DATABASE dsn: my_sp1 dstype: sqlserver password: 558ec793ac plugin: sqlserver plugin_direction: target plugin_version: 1 user: qarun |
|
Considerations if replicating to Oracle These use cases apply only if you are replicating from SQL Server to an Oracle target. Character column definitions: SQL Server defines CHAR and VARCHAR data in bytes, whereas Oracle can define it in bytes or characters depending on the semantics definition of the database or the specific table. Additionally, SQL Server allows larger maximum column sizes than Oracle. To allow for these differences in column length, adjustments must be made to the Oracle target table definitions as follows to ensure that the target columns can fit all of the data:
To view a table representing these relationships, see Set up replication from SQL Server to Oraclein the SharePlex Installation and Setup Guide. Letter Case: To support replication between a source of one database type and a target of another type, the letter case of the names of the source and target columns must be the same, for example the column names on both sides in lower case or both sides in upper case. If the case differs between the source and target column names, use the column mapping feature to map the column names in the configuration file. |
|
Ensure varchar(max) length compatibility If replicating varchar(max) data to a SQL Server target, make certain that the data size does not exceed 1GB in length. Although SQL Server supports varchar(max) data of up to 2 GB in length, the Windows ODBC driver supports VARCHAR(max) data of up to 1 GB in length. Sample ODBC error message, which is included in the Post error message: [ODBC SQL Server Driver]Invalid precision value. |
Requirement | Completed? (Y/N) |
---|---|
Perform any required database upgrades. Perform any required database upgrades before you install SharePlex. This ensures that SharePlex gets the most current object definitions when you run Database setup during the installation and setup steps. |
|
Confirm the database release version. Verify that the release version of the database is supported by SharePlex. For more information, see Basic system requirements. |
|
Consider character sets When replicating to an Open Target target (non-Oracle target), SharePlex supports replication from any Oracle Unicode character set and the US7ASCII character set. SharePlex posts data to Open Target in the Unicode character set, and therefore if the source data is Unicode or US7ASCII, no conversion on the target is required. However, if the following are true, conversion is required on the target:
To perform conversion with an Oracle client on Linux
To perform conversion with an Oracle client on Windows
To apply Unicode and US7ASCII data without conversion If the source data is Unicode or US7ASCII and you are not replicating LOB data, no conversion or Oracle client is needed. Set the SP_OPX_NLS_CONVERSION parameter to 0 to disable conversion, and then restart Post if it is running. |
|
Consider Case To support replication between a source of one database type and a target of another type, the letter case of the names of the source and target columns must be the same, for example the column names on both sides in lower case or both sides in upper case. If the case differs between the source and target column names, use the column mapping feature to map the column names in the configuration file. |
|
Install the appropriate ODBC driver. Verify that the appropriate ODBC driver is installed for your target, and install one if there is not one present. For Microsoft SQL Server, make certain to do the following:
Install the Microsoft SQL Server ODBC Driver. It must be that driver, not the Microsoft SQL Server Native Client, or SharePlex will return an error when you run the Database Setup utility to configure Post to connect to the database. To tell the difference between the two drivers:
To test a driver with SharePlex you can use the OTS utility. You can use a standalone version of this utility before you install SharePlex, or you can run the utility from the installation directory after you install SharePlex. See the OTS documentation in the SharePlex Reference Guide for more information. Note: SharePlex is already certified to work through ODBC with SQL Server, PostgreSQL, and Sybase targets. |
|
Enable case sensitivity on key columns Enable case-sensitivity for the data of any character-based primary key columns or columns that form a unique index. This ensures that Post compares the correct source and target key values so that it updates the correct target row and prevents unique constraint errors. Unless the key values are case sensitive, cases like the following can happen: Create table Sales (CustName varchar(20) primary key); insert into Sales values (‘abc company’); (Succeeds) insert into Sales values (‘ABC Company’); (Fails with unique constraint violation error) |
|
Disable triggers, cascade deletes, and foreign keys on the target tables. Triggers, cascaded DELETES, and foreign keys must be disabled on Open Target tables. DML changes resulting from triggers, cascaded DELETES, and foreign keys on the source system enter the transaction log and are replicated to the target database by SharePlex. If the same mechanisms are allowed to occur on the target parent table, they initiate changes to the child tables that are duplicated through replication. These duplicate operations cause out-of-sync errors. All tables with foreign keys to one another must all be included in the replication configuration for accurate replication of the source foreign key results. All tables with referential constraints must exist in the target database. If you leave one or more out, the referential integrity could become corrupted. |
|
To get additional information Additional post-installation setup steps are required to support Open Target database targets. For more information, see Set up replication between different database types. |
|
(SQL Server target) Configure a System Data Source Name Create a System (not User) Data Source Name (DSN) for the SQL Server database on the Windows system. The DSN can use either Windows NT authentication or SQL Server authentication. If you configure the DSN to use NT authentication and are using SQL Server 2012 or later, grant the NTAuthority\SYSTEM user the sysadmin fixed server role. ( For earlier versions of SQL Server, sysadmin is granted to the NT Authority\SYSTEM user by default.) Test connection to the database through this DSN. Important! If SharePlex will be replicating data from, or to, databases that are in different SQL Server instances on the same system, each of those databases must have a unique name. Because SharePlex identifies a database by its name, if two or more databases have the same name, SharePlex will only connect to one of them. If databases in different SQL Server instances have the same name but you are only using SharePlex for one of them, the names can remain identical without causing connection conflicts. |
SharePlex integrates with Oracle Clusterware cluster hardware and software to maintain the high availability of data capture and uninterrupted replication to your targets. If the node where SharePlex is running fails or must be taken out of the cluster for maintenance, SharePlex can be started on another server by the cluster software. SharePlex start and stop is controlled through the cluster.
These instructions assume that the cluster solution is already installed according to the cluster documentation, tested, and is functioning, and they are not a substitute for the documentation. Additional steps that are specific to your cluster installation may be required.
The following diagram shows SharePlex installed into an Oracle RAC cluster:
© 2023 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy