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 the 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:
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 |
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.
On peer1, UPDATE the EMP_TIMESTAMP column of the od_employee table as follows.
SQL (peer1) > UPDATE OD_EMPLOYEE SET EMP_TIMESTAMP = to_date('01/01/2017','MM/DD/RRRR') WHERE EMP_NO = 1;
On peer2, UPDATE the same column using a different update value. but the same key value.
SQL (peer2) > UPDATE OD_EMPLOYEE SET EMP_TIMESTAMP = to_date('02/02/2017','MM/DD/RRRR') WHERE EMP_NO = 1;
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 that will remain there until SharePlex receives a COMMIT operation.
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
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, insert a row into splex.demo_src.
SQL> insert into splex.demo_src values (‘Jane’, ‘1 Oak Street’, ‘123-123-1234’, sales);
SQL> commit;
On the target, select the new row from splex.demo_dest.
SQL> select * from splex.demo_dest where department = 'sales';
The query should return one record, the one you inserted where the department name is sales.
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.
On the source, insert an invalid row into splex.demo_src.
SQL> insert into splex.demo_src values (‘Tom’, ‘2 State Street’, ‘555-444-3333’, accounting);
SQL> commit;
The target should return "ORA-00913: too many values" indicating that the department column was dropped.
On the source, a valid row into splex.demo_src.
SQL> insert into splex.demo_src values (‘Mary’, ‘3 Elm Street’, ‘555-555-5555’);
SQL> commit;
On the target, select the new row from splex.demo_dest.
SQL> select * from splex.demo_dest where name = 'Mary';
The query should return the record, which was replicated successfully.
On the source, TRUNCATE Tsplex.demo_src.
SQL> TRUNCATE TABLE splex.demo_src;
On the target, verify that splex.demo_dest is empty.
SQL> select * from splex.demo_dest;
Solve license utility problems
Solve database connection problems
Solve SharePlex startup problems
This chapter reviews some common problems that you could experience when installing or running SharePlexfor the first time after installation.
Sometimes there are special installation instructions that supersede or supplement certain instructions in this manual. In addition, there can be known issues for this version that you should be aware of during or after installation. Please read the Release Notes for the version of SharePlex that you are installing before you begin the installation process.
The inability of SharePlex components to perform initial TCP operations can sometimes appear to be license key or license utility errors. If you know you entered the correct key and machine IDs, verify that all systems on which you are loading SharePlex are connected to the network. The network node name and IP address of each system must be established sufficiently to allow SharePlex to perform TCP operations, even though the machines themselves are not yet configured. Also check to make sure that nobody has renamed the /etc/resolv.conf file (if using a DNS nameserver).
If you received this error message: “Cannot add license: License key is illegal,” it could be that you entered an invalid license key. Assuming that you retyped the key correctly and still received an error, it probably means that the license key, though valid, is not the correct key for this system. Except for trial keys, which are generic, license keys are assigned to a specific machine according to the machine’s identification number (such as “host ID” on Sun systems).
You probably received at least two license keys from Quest — one for a source system and one for a target system — or if you are installing on multiple machines in a cluster, you should have a key for each one. Verify that the key you entered is the one that was issued for this system by comparing it to the machine identification number for which it was issued.
To view the machine ID and add a key on a Windows system
To view the machine ID and add a key on a Unix or Linux system
Run the splex_uname application from the install sub-directory of the SharePlex product directory on the machine whose ID number you want to confirm. It displays the ID number for the local machine, as shown in the example below.
Run the splex_add_key utility from the SharePlex product directory and add the license key and SiteMessage code from the email that your company received from the Quest licensing team.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. 利用規約 プライバシー Cookie Preference Center