To replicate transactions that affect the data in a table in the primary database, that table must be marked for replication, and replication must be enabled for the marked table.
Marking a table can be separate from enabling replication for that table. If the value of the pdb_dflt_object_repl parameter is true, replication is enabled automatically at the time a table is marked. For more information, see “Enabling and disabling replication for marked tables”.
The table-marking process of trigger-based Replication Agents for Microsoft SQL Server is different from the table-marking processes of the Replication Agent for UDB and the Replication Agent for Oracle.
When a table is marked for replication, a trigger-based Replication Agent creates several transaction log objects in the primary database to support replication for that table:
Shadow table – prefixSH_xxx
Blob shadow table – prefixBSH_xxx
Shadow-row procedure – prefixSRP_xxx
Blob shadow-row procedure – prefixBSRP_xxx
Insert trigger – prefixINSTRG_xxx
Update trigger – prefixUPDTRG_xxx
Delete trigger – prefixDELTRG_xxx
where:
prefix is the 1 to 3-character transaction log prefix string specified by the pdb_xlog_prefix parameter.
xxx is an automatically generated alphanumeric counter, which is incremented each time an object is marked in the primary database.
The prefix string recorded in the pdb_xlog_prefix parameter
is used for naming all Replication Agent transaction log database objects.
For example, if the value of the pdb_xlog_prefix parameter is ra_ (the default), and two tables have already been marked, the Replication Agent generates the following transaction log object names for the third marked table:
Shadow table – ra_SH_c
Blob shadow table – ra_BSH_c
Shadow-row procedure – ra_SRP_c
Blob shadow-row procedure – ra_BSRP_c
Insert trigger – ra_INSTRG_c
Update trigger – ra_UPDTRG_c
Delete trigger – ra_DELTRG_c
If triggers exist on the table, the Replication Agent attempts
to insert its trigger code, leaving the existing trigger code intact.
You can configure the Replication Agent instance to simply build a script
to mark the table—but not execute it—by setting
the value of the pdb_auto_run_scripts parameter
to false. To complete the table marking, you
must manually execute the script.
If you need to change the schema of a marked table in the primary database, you must unmark the table to remove the shadow table, stored procedure, and triggers that Replication Agent creates for the primary table, and then change the primary table’s schema and re-mark the table.
If you change the schema of a primary table, you may
need to rematerialize the replicate table.
When you unmark a table marked for replication, a trigger-based Replication Agent removes the transaction log objects for that table from the primary database.
Sybase Replication Agent provides two ways to unmark an object:
Normal unmarking – The Replication Agent first checks to see if replication is disabled for the table, then it checks for any unprocessed transactions in the transaction log. If replication is not disabled, or if there are any unprocessed transactions in the transaction log, the unmarking operation fails.
Force unmarking – The Replication Agent unmarks the table immediately, without checking the replication enabled status or looking for unprocessed transactions in the transaction log.
Forced unmarking can cause transactional inconsistency
between the primary database and replicate database. In general,
use it only when you are removing the entire transaction log and
discontinuing replication from the primary database, or in troubleshooting
procedures.
When a table is marked for replication with the log-based Replication Agent for UDB (DB2), the Replication Agent does the following:
Logs in to the primary database and sets the value of the table’s DATA CAPTURE option to DATA CAPTURE CHANGES.
Adds a row to the Replication Agent marked objects table in the primary database. Each row in the marked objects table lists attributes of a table marked for replication in the primary database.
If you need to change the schema of a marked table, you must:
Lock the table so that new operations cannot change any data in the table.
Wait for the Replication Agent to complete its processing of any logged transactions in the table.
Quiesce the Replication Agent instance.
Change the table’s schema, without changing the DATA CAPTURE option.
Unlock the table to allow normal user or client access.
Use the Replication Agent resume command to restart replication.
If you change the schema of a primary table, you may
need to rematerialize the replicate table.
When you unmark a table marked for replication with the log-based Replication Agent for UDB, the Replication Agent does the following:
Logs in to the primary database and restores the value of the table’s DATA CAPTURE option to the value it had before the table was marked.
Deletes the table’s row in the Replication Agent marked objects table.
When a table is unmarked, any subsequent operations that affect the data in that table are ignored (not replicated).
In the event that the Replication Agent for UDB must re-scan
the transaction log (such as when recovering from a replication
error), transactions recorded prior to unmarking a table will not
be replicated.
When a table is marked for replication with the log-based Replication Agent for Oracle, the Replication Agent does the following:
Connects to the RASD
Records the mark status for the table in the RASD Article for that table.
When a table is marked, any subsequent operations that affect the data in that table are replicated.
When you unmark a table marked for replication with the log-based Replication Agent for Oracle, the Replication Agent does the following:
Connects to the RASD
Records the unmark status for the table in the RASD Article for that table
When a table is unmarked, any subsequent operations that affect the data in that table are ignored (not replicated).
