11 Managing Logical Change Records (LCRs)

Example of Constructing and Executing Row LCRs

The example in this section creates PL/SQL procedures to insert, update, and delete rows in the hr.jobs table by constructing and executing row LCRs. The row LCRs are executed without being enqueued or processed by an apply process. This example assumes that you have configured an Oracle Streams administrator named strmadmin and granted this administrator DBA role.

Complete the following steps:

1. Create a PL/SQL procedure named execute_row_lcr that executes a row LCR:

   CONNECT strmadmin/user-password
   
   CREATE OR REPLACE PROCEDURE execute_row_lcr(
                    source_dbname  VARCHAR2,
                    cmd_type       VARCHAR2,
                    obj_owner      VARCHAR2,
                    obj_name       VARCHAR2,
                    old_vals       SYS.LCR$_ROW_LIST,
                    new_vals       SYS.LCR$_ROW_LIST) as
     xrow_lcr  SYS.LCR$_ROW_RECORD;
   BEGIN
     -- Construct the row LCR based on information passed to procedure
     xrow_lcr := SYS.LCR$_ROW_RECORD.CONSTRUCT(
       source_database_name => source_dbname,
       command_type         => cmd_type,
       object_owner         => obj_owner,
       object_name          => obj_name,
       old_values           => old_vals,
       new_values           => new_vals);
     -- Execute the row LCR
     xrow_lcr.EXECUTE(FALSE);
   END execute_row_lcr;
   /
   

2. Create a PL/SQL procedure named insert_job_lcr that executes a row LCR that inserts a row into the hr.jobs table:

   CREATE OR REPLACE PROCEDURE insert_job_lcr(
                    j_id     VARCHAR2,
                    j_title  VARCHAR2,
                    min_sal  NUMBER,
                    max_sal  NUMBER) AS
     xrow_lcr   SYS.LCR$_ROW_RECORD;
     col1_unit  SYS.LCR$_ROW_UNIT;
     col2_unit  SYS.LCR$_ROW_UNIT;
     col3_unit  SYS.LCR$_ROW_UNIT;
     col4_unit  SYS.LCR$_ROW_UNIT;
     newvals    SYS.LCR$_ROW_LIST;
   BEGIN
     col1_unit := SYS.LCR$_ROW_UNIT(
       'job_id', 
       ANYDATA.ConvertVarchar2(j_id),
       DBMS_LCR.NOT_A_LOB,
       NULL,
       NULL);
     col2_unit := SYS.LCR$_ROW_UNIT(
       'job_title', 
       ANYDATA.ConvertVarchar2(j_title),
       DBMS_LCR.NOT_A_LOB,
       NULL,
       NULL);
     col3_unit := SYS.LCR$_ROW_UNIT(
       'min_salary', 
       ANYDATA.ConvertNumber(min_sal),
       DBMS_LCR.NOT_A_LOB,
       NULL,
       NULL);
     col4_unit := SYS.LCR$_ROW_UNIT(
       'max_salary', 
       ANYDATA.ConvertNumber(max_sal),
       DBMS_LCR.NOT_A_LOB,
       NULL,
       NULL);
     newvals := SYS.LCR$_ROW_LIST(col1_unit,col2_unit,col3_unit,col4_unit);
     -- Execute the row LCR
     execute_row_lcr(
       source_dbname => 'DB1.NET',
       cmd_type      => 'INSERT',
       obj_owner     => 'HR',
       obj_name      => 'JOBS',
       old_vals      => NULL,
       new_vals      => newvals);  
   END insert_job_lcr;
   /
   

3. Create a PL/SQL procedure named update_max_salary_lcr that executes a row LCR that updates the max_salary value for a row in the hr.jobs table:

   CREATE OR REPLACE PROCEDURE update_max_salary_lcr(
                    j_id         VARCHAR2,
                    old_max_sal NUMBER,
                    new_max_sal NUMBER) AS
     xrow_lcr      SYS.LCR$_ROW_RECORD;
     oldcol1_unit  SYS.LCR$_ROW_UNIT;
     oldcol2_unit  SYS.LCR$_ROW_UNIT;
     newcol1_unit  SYS.LCR$_ROW_UNIT;
     oldvals       SYS.LCR$_ROW_LIST;
     newvals       SYS.LCR$_ROW_LIST;
   BEGIN
     oldcol1_unit := SYS.LCR$_ROW_UNIT(
       'job_id', 
       ANYDATA.ConvertVarchar2(j_id),
       DBMS_LCR.NOT_A_LOB,
       NULL,
       NULL);
     oldcol2_unit := SYS.LCR$_ROW_UNIT(
       'max_salary', 
       ANYDATA.ConvertNumber(old_max_sal),
       DBMS_LCR.NOT_A_LOB,
       NULL,
       NULL);
     oldvals := SYS.LCR$_ROW_LIST(oldcol1_unit,oldcol2_unit);
     newcol1_unit := SYS.LCR$_ROW_UNIT(
       'max_salary', 
       ANYDATA.ConvertNumber(new_max_sal),
       DBMS_LCR.NOT_A_LOB,
       NULL,
       NULL);
     newvals := SYS.LCR$_ROW_LIST(newcol1_unit);
     -- Execute the row LCR
     execute_row_lcr(
       source_dbname => 'DB1.NET',
       cmd_type      => 'UPDATE',
       obj_owner     => 'HR',
       obj_name      => 'JOBS',
       old_vals      => oldvals,
       new_vals      => newvals);  
   END update_max_salary_lcr;
   /
   

4. Create a PL/SQL procedure named delete_job_lcr that executes a row LCR that deletes a row from the hr.jobs table:

   CREATE OR REPLACE PROCEDURE delete_job_lcr(j_id VARCHAR2) AS
     xrow_lcr   SYS.LCR$_ROW_RECORD;
     col1_unit  SYS.LCR$_ROW_UNIT;
     oldvals    SYS.LCR$_ROW_LIST;
   BEGIN
     col1_unit := SYS.LCR$_ROW_UNIT(
       'job_id',
       ANYDATA.ConvertVarchar2(j_id),
       DBMS_LCR.NOT_A_LOB,
       NULL,
       NULL);
     oldvals := SYS.LCR$_ROW_LIST(col1_unit); 
     -- Execute the row LCR
     execute_row_lcr(
       source_dbname => 'DB1.NET',
       cmd_type      => 'DELETE',
       obj_owner     => 'HR',
       obj_name      => 'JOBS',
       old_vals      => oldvals,
       new_vals      => NULL);
   END delete_job_lcr;
   /
   

5. Insert a row into the hr.jobs table using the insert_job_lcr procedure:

   EXEC insert_job_lcr('BN_CNTR','BEAN COUNTER',5000,10000);
   

6. Select the inserted row in the hr.jobs table:

   SELECT * FROM hr.jobs WHERE job_id = 'BN_CNTR';
   
   JOB_ID     JOB_TITLE                           MIN_SALARY MAX_SALARY
   ---------- ----------------------------------- ---------- ----------
   BN_CNTR    BEAN COUNTER                              5000      10000
   

7. Update the max_salary value for the row inserted into the hr.jobs table in Step 5 using the update_max_salary_lcr procedure:

   EXEC update_max_salary_lcr('BN_CNTR',10000,12000);
   

8. Select the updated row in the hr.jobs table:

   SELECT * FROM hr.jobs WHERE job_id = 'BN_CNTR';
   
   JOB_ID     JOB_TITLE                           MIN_SALARY MAX_SALARY
   ---------- ----------------------------------- ---------- ----------
   BN_CNTR    BEAN COUNTER                              5000      12000
   

9. Delete the row inserted into the hr.jobs table in Step 5 using the delete_job_lcr procedure:

   EXEC delete_job_lcr('BN_CNTR');
   

10. Select the deleted row in the hr.jobs table:

    SELECT * FROM hr.jobs WHERE job_id = 'BN_CNTR';
    
    no rows selected
    

LOB Assembly Considerations

The following are issues to consider when you use LOB assembly:

• To use a DML or error handler to process assembled LOBs at multiple destination databases, LOB assembly must assemble the LOBs separately on each destination database.

• Row LCRs captured on a database running a release of Oracle prior to Oracle Database 10g Release 2 cannot be assembled by LOB assembly.

• Row LCRs captured on a database running Oracle Database 10g Release 2 or later with a compatibility level lower than 10.2.0 cannot be assembled by LOB assembly.

• The compatibility level of the database running an apply handler must be 10.2.0 or higher to specify LOB assembly for the apply handler.

• Row LCRs from a table containing any LONG or LONG RAW columns cannot be assembled by LOB assembly.

• The SET_ENQUEUE_DESTINATION and the SET_EXECUTE procedures in the DBMS_APPLY_ADM package always operate on original, nonassembled row LCRs. Therefore, for row LCRs that contain LOB columns, the original, nonassembled row LCRs are enqueued or executed, even if these row LCRs are assembled separately for an apply handler at the destination database.

• If rule-based transformations were performed on row LCRs that contain LOB columns during capture, propagation, or apply, then an apply handler operates on the transformed row LCRs. If there are LONG or LONG RAW columns at a source database, and a rule-based transformation uses the CONVERT_LONG_TO_LOB_CHUNK member function for row LCRs to convert them to LOBs, then LOB assembly can be enabled for apply handlers that operate on these row LCRs.

• When a row LCR contains one or more XMLType columns, any XMLType and LOB columns in the row LCR are always assembled, even if the assemble_lobs parameter is set to FALSE for a DML or error handler.

LOB Assembly Example

This section contains an example that uses LOB assembly with a DML handler. The example scenario involves a company that shares the oe.production_information table at several databases, but only some of these databases are used for the company's online World Wide Web catalog. The company wants to store a photograph of each product in the catalog databases, but, to save space, it does not want to store these photographs at the non catalog databases.

To accomplish this goal, a DML handler at a catalog destination database can add a column named photo of data type BLOB to each INSERT and UPDATE made to the product_information table at a source database. The source database does not include the photo column in the table. The DML handler is configured to use an existing photograph at the destination for updates and inserts.The company also wants to add a product_long_desc to the oe.product_information table at all databases. This table already has a product_description column that contains short descriptions. The product_long_desc column is of CLOB data type and contains detailed descriptions. The detailed descriptions are in English, but one of the company databases is used to display the company catalog in Spanish. Therefore, the DML handler updates the product_long_desc column so that the long description is in the correct language.

The following steps configure a DML handler that uses LOB assembly to accomplish the goals described previously:

Step 1   Add the photo Column to the product_information Table

The following statement adds the photo column to the product_information table at the destination database:

ALTER TABLE oe.product_information ADD(photo BLOB);

Step 2   Add the product_long_desc Column to the product_information Table

The following statement adds the product_long_desc column to the product_information table at all of the databases in the environment:

ALTER TABLE oe.product_information ADD(product_long_desc CLOB);

Step 3   Create the PL/SQL Procedure for the DML Handler

This example creates the convert_product_information procedure. This procedure will be used for the DML handler. This procedure assumes that the following user-created PL/SQL subprograms exist:

• The get_photo procedure obtains a photo in BLOB format from a URL or table based on the product_id and updates the BLOB locator that has been passed in as an argument.

• The get_product_long_desc procedure has an IN argument of product_id and an IN OUT argument of product_long_desc and translates the product_long_desc into Spanish or obtains the Spanish replacement description and updates product_long_desc.

The following code creates the convert_product_information procedure:

CREATE OR REPLACE PROCEDURE convert_product_information(in_any IN ANYDATA)
IS
  lcr                      SYS.LCR$_ROW_RECORD;
  rc                       PLS_INTEGER;
  product_id_anydata       ANYDATA;
  photo_anydata            ANYDATA;
  long_desc_anydata        ANYDATA;
  tmp_photo                BLOB;
  tmp_product_id           NUMBER;
  tmp_prod_long_desc       CLOB;
  tmp_prod_long_desc_src   CLOB;
  tmp_prod_long_desc_dest  CLOB;
  t                        PLS_INTEGER;
BEGIN
  -- Access LCR
  rc := in_any.GETOBJECT(lcr);
  product_id_anydata := lcr.GET_VALUE('OLD', 'PRODUCT_ID');
  t := product_id_anydata.GETNUMBER(tmp_product_id);
  IF ((lcr.GET_COMMAND_TYPE = 'INSERT') or (lcr.GET_COMMAND_TYPE = 'UPDATE')) THEN
    -- If there is no photo column in the lcr then it must be added
    photo_anydata := lcr.GET_VALUE('NEW', 'PHOTO');
    -- Check if photo has been sent and if so whether it is NULL
    IF (photo_anydata is NULL) THEN
      tmp_photo := NULL;
      ELSE
      t := photo_anydata.GETBLOB(tmp_photo);
    END IF;
    -- If tmp_photo is NULL then a new temporary LOB must be created and
    -- updated with the photo if it exists
    IF (tmp_photo is NULL) THEN
      DBMS_LOB.CREATETEMPORARY(tmp_photo, TRUE);
      get_photo(tmp_product_id, tmp_photo);
    END IF;
    -- If photo column did not exist then it must be added
    IF (photo_anydata is NULL) THEN
      lcr.ADD_COLUMN('NEW', 'PHOTO', ANYDATA.CONVERTBLOB(tmp_photo));
      -- Else the existing photo column must be set to the new photo
      ELSE
        lcr.SET_VALUE('NEW', 'PHOTO', ANYDATA.CONVERTBLOB(tmp_photo));
    END IF;
    long_desc_anydata := lcr.GET_VALUE('NEW', 'PRODUCT_LONG_DESC');
    IF (long_desc_anydata is NULL) THEN
      tmp_prod_long_desc_src := NULL;
      ELSE
      t := long_desc_anydata.GETCLOB(tmp_prod_long_desc_src);
    END IF;
    IF (tmp_prod_long_desc_src IS NOT NULL) THEN
      get_product_long_desc(tmp_product_id, tmp_prod_long_desc);
    END IF;
    -- If tmp_prod_long_desc IS NOT NULL, then use it to update the LCR
    IF (tmp_prod_long_desc IS NOT NULL) THEN
      lcr.SET_VALUE('NEW', 'PRODUCT_LONG_DESC',
                    ANYDATA.CONVERTCLOB(tmp_prod_long_desc_dest));
    END IF;
  END IF;
  -- DBMS_LOB operations also are executed 
  -- Inserts and updates invoke all changes
  lcr.EXECUTE(TRUE);
END;
/

Step 4   Set the DML Handler for the Apply Process

This step sets the convert_product_information procedure as the DML handler at the destination database for INSERT, UPDATE, and LOB_UPDATE operations. Notice that the assemble_lobs parameter is set to TRUE each time the SET_DML_HANDLER procedure is run.

BEGIN
  DBMS_APPLY_ADM.SET_DML_HANDLER(
    object_name         => 'oe.product_information',
    object_type         => 'TABLE',
    operation_name      => 'INSERT',
    error_handler       => FALSE,
    user_procedure      => 'strmadmin.convert_product_information',
    apply_database_link => NULL,
    assemble_lobs       => TRUE);
  DBMS_APPLY_ADM.SET_DML_HANDLER(
    object_name         => 'oe.product_information',
    object_type         => 'TABLE',
    operation_name      => 'UPDATE',
    error_handler       => FALSE,
    user_procedure      => 'strmadmin.convert_product_information',
    apply_database_link => NULL,
    assemble_lobs       => TRUE);
  DBMS_APPLY_ADM.SET_DML_HANDLER(
    object_name         => 'oe.product_information',
    object_type         => 'TABLE',
    operation_name      => 'LOB_UPDATE',
    error_handler       => FALSE,
    user_procedure      => 'strmadmin.convert_product_information',
    apply_database_link => NULL,
    assemble_lobs       => TRUE);
END;
/

Step 5   Query the DBA_APPLY_DML_HANDLERS View

To ensure that the DML handler is set properly for the oe.product_information table, run the following query:

COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A5
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A20
COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A10
COLUMN USER_PROCEDURE HEADING 'Handler Procedure' FORMAT A25
COLUMN ASSEMBLE_LOBS HEADING 'LOB Assembly?' FORMAT A15

SELECT OBJECT_OWNER, 
       OBJECT_NAME, 
       OPERATION_NAME, 
       USER_PROCEDURE,
       ASSEMBLE_LOBS
  FROM DBA_APPLY_DML_HANDLERS;

Your output looks similar to the following:

Table
Owner Table Name           Operation  Handler Procedure         LOB Assembly?
----- -------------------- ---------- ------------------------- ---------------
OE    PRODUCT_INFORMATION  INSERT     "STRMADMIN"."CONVERT_PROD Y
                                      UCT_INFORMATION"
 
OE    PRODUCT_INFORMATION  UPDATE     "STRMADMIN"."CONVERT_PROD Y
                                      UCT_INFORMATION"
 
OE    PRODUCT_INFORMATION  LOB_UPDATE "STRMADMIN"."CONVERT_PROD Y
                                      UCT_INFORMATION"

Notice that the correct procedure, convert_product_information, is used for each operation on the table. Also, notice that each handler uses LOB assembly.

Requirements for Constructing and Processing LCRs Without LOB Assembly

The following requirements must be met when you are constructing LCRs with LOB columns and when you are processing LOB columns with a DML or error handler that has LOB assembly disabled:

• Do not modify LOB column data in a row LCR with a DML handler or error handler that has LOB assembly disabled. However, you can modify non-LOB columns in row LCRs with a DML or error handler.

• Do not allow LCRs from a table that contains LOB columns to be processed by an apply handler that is invoked only for specific operations. For example, an apply handler that is invoked only for INSERT operations should not process LCRs from a table with one or more LOB columns.

• The data portion of the LCR LOB column must be of type VARCHAR2 or RAW. A VARCHAR2 is interpreted as a CLOB, and a RAW is interpreted as a BLOB.

• A LOB column in a user-constructed row LCR must be either a BLOB or a fixed-width CLOB. You cannot construct a row LCR with the following types of LOB columns: NCLOB or variable-width CLOB.

• LOB WRITE, LOB ERASE, and LOB TRIM are the only valid command types for out-of-line LOBs.

• For LOB WRITE, LOB ERASE, and LOB TRIM LCRs, the old_values collection should be empty or NULL, and new_values should not be empty.

• The lob_offset should be a valid value for LOB WRITE and LOB ERASE LCRs. For all other command types, lob_offset should be NULL, under the assumption that LOB chunks for that column will follow.

• The lob_operation_size should be a valid value for LOB ERASE and LOB TRIM LCRs. For all other command types, lob_operation_size should be NULL.

• LOB TRIM and LOB ERASE are valid command types only for an LCR containing a LOB column with lob_information set to LAST_LOB_CHUNK.

• LOB WRITE is a valid command type only for an LCR containing a LOB column with lob_information set to LAST_LOB_CHUNK or LOB_CHUNK.

• For LOBs with lob_information set to NULL_LOB, the data portion of the column should be a NULL of VARCHAR2 type (for a CLOB) or a NULL of RAW type (for a BLOB). Otherwise, it is interpreted as a non-NULL inline LOB column.

• Only one LOB column reference with one new chunk is allowed for each LOB WRITE, LOB ERASE, and LOB TRIM LCR.

• The new LOB chunk for a LOB ERASE and a LOB TRIM LCR should be a NULL value encapsulated in an ANYDATA.

An apply process performs all validation of these requirements. If these requirements are not met, then a row LCR containing LOB columns cannot be applied by an apply process nor processed by an apply handler. In this case, the LCR is moved to the error queue with the rest of the LCRs in the same transaction.

Requirements for Apply Handler Processing of LCRs with LOB Assembly

The following requirements must be met when you are processing LOB columns with a DML or error handler that has LOB assembly enabled:

• Do not use the following row LCR member procedures on LOB columns in row LCRs that contain assembled LOBs:

  • SET_LOB_INFORMATION

  • SET_LOB_OFFSET

  • SET_LOB_OPERATION_SIZE

  An error is raised if one of these procedures is used on a LOB column in a row LCR.

• Row LCRs constructed by LOB assembly cannot be enqueued by a DML handler or error handler. However, even when LOB assembly is enabled for one or more handlers at a destination database, the original, nonassembled row LCRs with LOB columns can be enqueued using the SET_ENQUEUE_DESTINATION procedure in the DBMS_APPLY_ADM package.

An apply process performs all validation of these requirements. If these requirements are not met, then a row LCR containing LOB columns cannot be applied by an apply process nor processed by an apply handler. In this case, the LCR is moved to the error queue with the rest of the LCRs in the same transaction. For row LCRs with LOB columns, the original, nonassembled row LCRs are placed in the error queue.

Requirements for Rule-Based Transformation Processing of LCRs with LOBs

The following requirements must be met when you are processing row LCRs that contain LOB columns with a rule-based transformation:

• Do not modify LOB column data in a row LCR with a custom rule-based transformation. However, a custom rule-based transformation can modify non-LOB columns in row LCRs that contain LOB columns.

• You cannot use the following row LCR member procedures on a LOB column when you are processing a row LCR with a custom rule-based transformation:

  • ADD_COLUMN

  • SET_LOB_INFORMATION

  • SET_LOB_OFFSET

  • SET_LOB_OPERATION_SIZE

  • SET_VALUE

  • SET_VALUES

• A declarative rule-based transformation created by the ADD_COLUMN procedure in the DBMS_STREAMS_ADM package cannot add a LOB column to a row LCR.

• Rule-based transformation functions that are run on row LCRs with LOB columns must be deterministic, so that all row LCRs corresponding to the row change are transformed in the same way.

• Do not allow LCRs from a table that contains LOB columns to be processed by an a custom rule-based transformation that is invoked only for specific operations. For example, a custom rule-based transformation that is invoked only for INSERT operations should not process LCRs from a table with one or more LOB columns.