Note: Before proceeding, make certain the SharePlex demonstration objects are installed. See Prework for the demonstrations .
In this demonstration, you will configure SharePlex to use generic conflict resolution procedures to resolve a replication conflict. Generic conflict resolution allows you to use one PL/SQL procedure to resolve conflicts for multiple tables.
The following conflict-resolution strategies are demonstrated:
IMPORTANT! Peer-to-peer replication is not compatible with all business applications. When suitable for an environment, it requires careful analysis and execution, including the creation of custom conflict resolution procedures that are typically more complex than those in this demonstration. Do not use this demonstration as the foundation of a production peer-to-peer deployment. For more information about peer-to-peer replication, see SharePlex Administration Guide.
Note: In this demonstration, the demonstration objects are assumed to be in the schema named demo. Substitute the actual schema, if different.
Perform these steps on both systems (for both databases).
Shut down SharePlex.
sp_ctrl(peer1)> shutdown
Grant the user who owns the demonstration objects the system privilege to execute the sp_cr package, which was installed in the SharePlex schema when SharePlex was first installed.
SQL>grant execute on sp_cr to user_name
Run the p2p.sql script from the util sub-directory of the SharePlex product directory. This installs the od_employee_gen demonstration conflict resolution routine.
You are prompted for the following:
Perform the following steps to configure SharePlex:
On each system, open the conflict_resolution.SID file (where SID is the ORACLE_SID of the local database) in a text editor. This file is located in the data sub-directory of the SharePlex variable-data directory.
Note: Post checks this file when there is a replication conflict to determine if there is a resolution procedure to call.
On each system, create the following entries in the conflict_resolution.SID file. Separate each column with at least a few spaces or a tab character.
demo.od_employee | IUD | demo.od_employee_gen |
Note: The first component is a table, the second specifies the operation types for which a resolution routine will be called if there is a conflict on that table, and the third is the name of the resolution routine that will be used.
On peer1 (the trusted source), create a configuration file named od_peer1 that replicates the od_employee table to the od_employee table on peer2.
sp_ctrl(peer1)> create config od_peer1
demo.od_employee | demo.od_employee | peer2@o.SID |
On peer2 (the secondary source), create a configuration file named od.peer2 that replicates the od_employee table to the od_employee table on peer1.
sp_ctrl(peer2)> create config od_peer2
demo.od_employee | demo.od_employee | peer1@o.SID |
NOTE: In order for post to detect out-of-sync inserts where all columns are identical, set SP_OPO_SUPPRESSED_OOS to 0. Issue this command from sp_ctrl: set param SP_OPO_SUPPRESSED_OOS 0 and verify the parameter is set by using the list param modified command.
Perform the following steps to activate and start replication:
On peer1, activate the od_peer1 configuration.
On peer2, activate the od_peer2 configuration.
On each system, confirm that the configuration activated successfully. The name od_peer1 or od_peer2 (depending on the system) should appear under File Name, and the word Active should appear under State.
sp_ctrl(source)>list config
In this demonstration, an INSERT that originates on peer1 will override a conflicting INSERT that is replicated from peer2.
On peer2, insert a row into od_employee but do not issue a COMMIT.
SQL (peer2) > INSERT INTO OD_EMPLOYEE VALUES (1,'John','Doe',to_date('04/01/1949','MM/DD/RRRR'),1,to_date('01/01/2017','MM/DD/RRRR'));
On peer1, insert the same row (same values) but do not issue a COMMIT.
SQL (peer1) > INSERT INTO OD_EMPLOYEE VALUES (1,'John','Doe',to_date('04/01/1949','MM/DD/RRRR'),1,to_date('01/01/2017','MM/DD/RRRR'));
In this demonstration, whichever row was updated LAST takes priority when there is a conflict.
Note: The EMP_TIMESTAMP field, along with the other columns, must be modified to a non-null value in order for timestamp priority to function. The stored procedure won't be able to resolve the conflict if the timestamp column in the UPDATE statement is not being updated or is being modified to a null value. Out-of-sync problems will then be seen.
On peer1, UPDATE the EMP_FIRST_NAME and EMP_TIMESTAMP columns of the od_employee table as follows.
SQL (peer1) > UPDATE OD_EMPLOYEE SET EMP_FIRST_NAME = 'James', EMP_TIMESTAMP = to_date('01/01/2017','MM/DD/RRRR') WHERE EMP_NO = 1;
On peer2, UPDATE the same column using a different update values. but the same key value.
SQL (peer2) > UPDATE OD_EMPLOYEE SET EMP_FIRST_NAME = 'Harry', EMP_TIMESTAMP = to_date('02/02/2017','MM/DD/RRRR') WHERE EMP_NO = 1;
On both systems, issue COMMITs at the same time.
On both systems, view the post queue to make sure the update operation is in the queue. You will see a message in each queue.
sp_ctrl(peer1)>qstatus
sp_ctrl(peer2)>qstatus
A table named exc_table was installed in the schema that you specified when you installed the demonstration objects. You can view it through SQL*Plus to view information about each conflict. The following is the table description.
Column | Description |
---|---|
EXC_NO | The exception number of the conflict. |
EXC_TYPE | The type of SQL statement, whether INSERT, UPDATE or DELETE. |
EXC_TARGET_TABLE | The table on which the conflict occurred. |
EXC_FIXED |
The results of the conflict resolution routine. YES means that the routine was successful. NO means that the routine failed and the row needs to be manually changed to the correct value. |
EXC_INFO | The cause of the conflict. |
EXC_TIMESTAMP | The time that the conflict occurred on this machine. |
This demonstration shows the default DDL replication support that is enabled when SharePlex is installed. You can enable other DDL replication with parameters, as needed.
Note: This demonstration supports Oracle source and targets only.
On the source, verify that the SP_OCT_REPLICATE_DDL parameter is set to the default of 3. This parameter controls basic DDL replication.
sp_ctrl(source)>list param modified capture
The SP_OCT_REPLICATE_DDL parameter should not be listed in the output. If it is, issue the following command:
sp_ctrl(source)>reset param SP_OCT_REPLICATE_DDL
Perform the following steps to test DDL replication:
On the source, TRUNCATE splex.demo_src to make certain it is empty.
SQL> truncate table splex.demo_src;
SharePlex replicates the TRUNCATE command to the target.
On the source, add a column to splex.demo_src.
SQL> alter table splex.demo_src add (department varchar2(30) not null default 'unknown');
On the target, describe the splex.demo_dest table.
SQL> describe splex.demo_src;
The table should now contain four columns, including the new department column.
On the source, drop the department column.
SQL> alter table splex.demo_src drop column department;
On the target, describe the splex.demo_dest table.
SQL> describe splex.demo_src;
The table should now contain only the original three columns.
The Database Setup utilities automatically configure a source or target database to allow SharePlex connections and to establish required database components that support replication.
Run the Database Setup utility for HANA (hana_setup) on a target HANA system to establish a user account, schema, and tables for use by SharePlex.
HANA on supported platforms
The only supported connection method to HANA is by connect string. Connection through a DSN is not supported.
The setup utility must be run as a HANA Administrator in order to grant SharePlex the required privileges to operate on the database and to create the SharePlex database account.
Run the hana_setup program from the bin subdirectory of the SharePlex product directory.
Important! If you installed the SharePlex instance on any port other than the default of 2100, use the -p option to specify the port number. For example, in the following command the port number is 9400.
$ /users/splex/bin> hana_setup -p9400 |
Table 5: Setup Prompts and Responses
Prompt | Response |
---|---|
Enter the HANA connection string [] : |
Enter a connection string that connects to the HANA database system. The required components of a connection string for SharePlex to connect to HANA are:
Example: SERVERNODE=server1.dept.abc.corp:30015;DRIVER=/usr/sap/hdbclient/libodbcHDB.so;CHAR_AS_UTF8=1 You do not have to supply a user, password, and default database, because the setup utility prompts for those. |
Enter the HANA Administrator name : |
Enter the name of the HANA Administrator. This user will perform the work on the SharePlex account. |
Enter the password for the Administrator account : |
Enter the password of the Administrator. |
Enter the name of the database : |
Enter the name of the database that you want to contain the tables and other objects for use by SharePlex. You can enter the name of a new or existing database. |
Database name database does not exist. Would you like to create it? [y] : |
If this prompt is displayed, the specified database does not exist. Press Enter to have the setup utility create it for you. |
Would you like to create a new SharePlex user [y]: |
Press Enter to accept the default to create a new SharePlex database user account and schema of the same name in the specified database, or enter n to use an existing SharePlex account. |
Enter the name of the new SharePlex user: Enter the name of the existing SharePlex user: |
One of these prompts is displayed depending on whether you elected to create a new user or use an existing user. Enter the name of the SharePlex user.
|
Enter the password of the SharePlex user : |
Enter the password of the SharePlex user account. |
Re-enter the password for the SharePlex user : |
This prompt is only shown if you created a new user. Enter the SharePlex password again. |
A successful setup terminates with a message similar to the following:
Completed SharePlex for HANA database configuration
SharePlex User name: splex
Database name: ndb5
Target specification in SharePlex configuration: r.ndb5
Before you start SharePlex replication to a HANA target, grant the following privileges to the SharePlex database user in that target (where SP_USER is the name of the SharePlex database user):
Additionally, log in as the owner of each schema that contains objects that you want to replicate, then make the following grants on the schema:
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center