SharePlex 10.2.1 - Installation and Setup Guide

Demonstration of vertically partitioned replication

Note: Before proceeding, make certain the SharePlex demonstration objects are installed. See Prework for the demonstrations.

In this demonstration you will :

1. Specify a column partition in the configuration file. A column partition replicates only the data changes that are made to the specified columns.

2. Activate the configuration.
3. Load data into the source table and verify replication of the specified columns to the target.

Prepare the tables

Note: In this demonstration, the demonstration objects are assumed to be in the schema named demo. Substitute the actual schema, if different.

1. If you ran previous demonstrations, do the following:

   1. On the source and target, run sp_ctrl and issue the following command to shut down sp_cop.

      sp_ctrl (source) shutdown

      sp_ctrl (target) shutdown

   2. On the source and target, run the ora_cleansp utility according to the instructions in "ora_cleansp" in the SharePlex Reference Guide. This removes the queues from the previous demonstrations and deactivates the previous configuration.

2. On the source and target, TRUNCATE the od_employee and od_salary tables.

   SQL> truncate table demo.od_employee;

   SQL> truncate table demo.od_salary;

Configure the column partition

Perform these steps on the source system.

1. In sp_ctrl, deactivate the od_config configuration.

   sp_ctrl(source)>deactivate config od_config

2. Confirm that the configuration deactivated successfully. The name od_config should appear under File Name, and the State column should show that it is inactive.

   sp_ctrl(source)>list config

3. In sp_ctrl, open the od_config configuration file for editing.

   sp_ctrl(source)>edit config od_config

4. In the text editor, edit the configuration file to change the entry for the od_employee table so that it uses a column partition.

   # od_config configuration file datasource:o.source_SID
   demo.od_department	demo.od_department	target_system@o.target_SID
   demo.od_salary !(SAL_VALUE)	demo.od_salary	target_system@o.target_SID
   demo.od_timesheet	demo.od_timesheet	target_system@o.target_SID
   demo.od_employee (EMP_NO, EMP_FIRST_NAME, EMP_LAST_NAME	demo.od_employee	target_system@o.target_SID

   Where:

   • source_SID is the ORACLE_SID of the source database.
   • target_system is the name or IP address of the target system.
   • target_SID is the ORACLE_SID of the target database.
   • !(SAL_VALUE) is the syntax for an excluded column partition. All columns except the one listed are replicated.

   • (EMP_NO, EMP_FIRST_NAME, EMP_LAST_NAME) is the syntax for a column partition. Only the listed columns are replicated.

     NoteS: 

     • This configuration file template is set up in table form to show the source, target, and routing elements clearly. In a real configuration file, the source (including the column partition), target, and routing map should be in that order, all on one line.
     • Any columns that are defined as NOT NULL must be included in the column partition, because SharePlex replicates a NULL into columns that are not in the column partition.
5. Save the file, then exit the editor. SharePlex automatically saves the file in the config sub-directory.

Activate the configuration

Perform these steps on the source system. When you activate a configuration, SharePlex is ready to capture transactional changes that are made to the specified source data.

1. Activate the configuration.

   sp_ctrl(source)>activate config od_config

   Note: Configuration names are case-sensitive.

2. Confirm that the configuration activated successfully. The name config od_config should appear under File Name, and the word Active should appear under State.

   sp_ctrl(source)>list config

Replicate data

1. On the source, log in as the demo schema owner and execute the od_add_emps procedure to populate the od_employee and od_salary tables. This procedure has one IN parameter that specifies the number of employees to insert per department:

   • The default number of departments is 5.
   • Use an IN parameter of 100 to create 500 new employees in the od_employee table and 500 entries in the od_salary table.

   SQL>exec od_add_emps(100);

2. On the source, select all rows from the source od_employee table.

   SQL> select * from od_employee;

   There should be values in all of the columns of the table.

3. On the target, select all rows from the target od_employee table.

   SQL> select * from od_employee;

   There should only be values in the EMP_NO, EMP_FIRST_NAME, and EMP_LAST_NAME columns. The other columns should contain null values.

4. On the target, select all rows from the target od_salary table.

   SQL> select * from od_salary;

   There should only be values in the SALE_EMP_NO and SAL_CHANGED columns. The SAL_VALUE column should contain only nulls.

Demonstration of transformation

Note: Before proceeding, make certain the SharePlex demonstration objects are installed. See Prework for the demonstrations.

In this demonstration, you will use a supplied transformation procedure to have SharePlex replicate data from two separate source tables and apply it to one target table.

Prepare the objects

Note: In this demonstration, the demonstration objects are assumed to be in the schema named demo. Substitute the actual schema, if different.

1. If you ran previous demonstrations, do the following:

   1. On the source and target, run sp_ctrl and issue the following command to shut down sp_cop.

      sp_ctrl (source) shutdown

      sp_ctrl (target) shutdown

   2. On the source and target, run the ora_cleansp utility according to the instructions in ora_cleansp. This removes the queues from the previous demonstrations and deactivates the previous configuration.

2. On the source and target, TRUNCATE the od_employee and od_salary tables.

   SQL> truncate table demo.od_employee;

   SQL> truncate table demo.od_salary;

3. On the target, 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

4. On the target, log into SQL*Plus as the user who owns the SharePlex demonstration objects, then run the transform.sql script from the util sub-directory of the SharePlex product directory. This installs transformation routines named od_transform_employee_insert and od_transform_employee_update. You are prompted for:

   • a schema and tablespace
   • the name of the SharePlex database user

Configure SharePlex

1. On the target, open the transformation.SID file (where SID is the ORACLE_SID of the target database) in a text editor. This file is located in the data sub-directory in the SharePlex variable-data directory.

   Note: Post checks this file to determine if there is a transformation procedure that it must call instead of posting the operation to the database.

2. Create the following entries in the transformation.SID file.

   Separate each column with at least a few spaces or a tab character.

   demo.od_employee	I	demo.od_transform_employee_insert
   demo.od_employee	U	demo.od_transform_employee_update
   demo.od_salary	I	demo.od_transform_employee_insert
   demo.od_salary	U	demo.od_transform_employee_update

   Note: The components of each entry are as follows, in the order they must appear:

   • The target table to which a transformation procedure is assigned.
   • The operation type for which the specified transformation procedure will be called.
   • The name of the assigned transformation procedure to use. Multiple entries can be used to assign different procedures to different operation types for the same table.

3. On the target, enable the following parameter.

   sp_ctrl(target)> set param SP_OPO_XFORM_EXCLUDE_ROWID 1

4. On the source, create a configuration file named od.transform that replicates the od_salary and od_employee tables.

   sp_ctrl(source)> create config od_transform

5. In the text editor, build your configuration file based on the following template.

   datasource:o.source_SID
   demo.od_salary	demo.od_salary	target_system@o.target_SID
   demo.od_employee	demo.od_employee	target_system@o.target_SID

6. Save the file, then exit the editor. SharePlex automatically saves the file in the config sub-directory.

Activate and start replication

1. On the source, activate the configuration.

   sp_ctrl(source)> activate config od_transform

2. Confirm that the configuration activated successfully. The name od_transform should appear under File Name, and the word Active should appear under State.

   sp_ctrl(source)>list config

3. On the source, log in as the demo schema owner, then execute the od_add_emps procedure to populate the od_employee and od_salary tables. Use an IN parameter of 10 to create 50 new employees in the od_sales_emp_data table.

   SQL> exec od_add_emps(10);

View the transformed data

1. On the target, run SQL*Plus.

2. In SQL*Plus, select all rows from od_sales_emp_data.

3. View the transformed data. You should see the following results:

   • The EMPLOYEE_NAME column contains the first and last name of the employee. Compare this to the source od_employee table, where the first and last names are in separate columns.
   • The DEPARTMENT column contains the department name. Compare this to the source od_employee table, where the EMP_DEPT_NO column contains a number. The transformation procedure transformed the replicated department number into the department name by referencing the od_department table.
   • The SALARY column contains the salary from the od_salary table.
4. [OPTIONAL] To see how transformation works for UPDATEs, you can update the od_employee table manually. The od_transform_employee_update procedure will make the transformation. To further this demonstration, you may construct a transformation procedure for DELETEs.

Demonstration of conflict resolution

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:

• Timestamp priority – This demonstration is based on UPDATEs. Whichever row was updated LAST takes priority when there is a conflict.
• Trusted-source priority – In the following steps, you will define one system as the “trusted” source that takes priority in the event of a conflict. This demonstration is based on INSERTs. All INSERTs that originate on the trusted source will override INSERTs from the other system. In this demonstration, the trusted source is peer1 and the other system is peer2.

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.

Prepare the objects

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).

1. Run sp_ctrl.

2. Shut down SharePlex.

   sp_ctrl(peer1)> shutdown

3. Run the ora_cleansp utility according to the instructions in ora_cleansp. This removes the queues from the previous demonstrations and deactivates the previous configuration.
4. TRUNCATE  the od_employee tables.

5. 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

6. Log into SQL*Plus as the user who owns the SharePlex demonstration objects.

7. 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:

   • A schema and tablespace for the procedure
   • The name of the SharePlex database user.
   • The name of the system that will be the trusted source of accurate data. As in a production deployment, operations the trusted source take priority during a conflict. This system is known as peer1 in this demonstration. The other system is known as peer2 in this demonstration.

Configure SharePlex

1. 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.

2. 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.

3. On each system, start sp_cop.
4. On each system, start sp_ctrl.

5. 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

6. 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 LIST PARAM MODIFIED.

Activate and start replication

1. On peer1, activate the od_peer1 configuration.

   sp_ctrl(peer1)> activate od_peer1

2. On peer2, activate the od_peer2 configuration.

   sp_ctrl(peer2)> activate od_peer2

3. 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

Demonstrate trusted-source priority

In this demonstration, an INSERT that originates on peer1 will override a conflicting INSERT that is replicated from peer2.

1. On both systems, stop the Post process.
2. On both systems, log in to SQL*Plus as demo (the owner of the demonstration objects).

3. 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'));

4. 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'));

5. On both systems, restart the Post processes.
6. On peer2, issue the COMMIT.
7. On peer1, issue the COMMIT. This operation should generate a conflict, which Post resolves automatically based on instructions in the conflict_resolution.SID file.
8. On both systems, view the demo.exc_table to verify that the conflict was resolved. See View the conflict resolution results.

Demonstrate timestamp priority

In this demonstration, whichever row was updated LAST takes priority when there is a conflict.

1. On both systems, stop the Post process.
2. On both systems, log in to SQL*Plus as demo (the owner of the demonstration objects).

3. 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;

4. 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;

5. On both systems, issue COMMITs at the same time.

6. 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

7. On both systems, start the Post process.
8. On both systems, select the row that you updated to verify that it contains the more recent EMP_TIMESTAMP value.

View the conflict resolution results

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.

Demonstration of Oracle DDL replication

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.

Verify that DDL replication is enabled

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

Test DDL replication

1. 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.

2. On the source, add a column to splex.demo_src.

   SQL> alter table splex.demo_src add (department varchar2(30) not null default 'unknown');

3. 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.

4. 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;

5. 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.

6. On the source, drop the department column.

   SQL> alter table splex.demo_src drop column department;

7. On the target, describe the splex.demo_dest table.

   SQL> describe splex.demo_src;

   The table should now contain only the original three columns.

8. 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.

9. 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;

10. 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.

11. On the source, TRUNCATE Tsplex.demo_src.

    SQL> TRUNCATE TABLE splex.demo_src;

12. On the target, verify that splex.demo_dest is empty.

    SQL> select * from splex.demo_dest;