Dropping primary tables or stored procedures from an Adaptive Server affects data replication and should be done with caution.
If updates are made to the primary table and the table is dropped from the Adaptive Server, Adaptive Server error 9104 is displayed in the Adaptive Server error log (for the RepAgent) or LTM error log:
Message: 9104 ’Cannot identify the object on the INSERT log record for database ’MY_PDB1’, XACT ID Rid pageid = 0xa0f; row num = 0x5, RID Rid pageid = 0xa0f; row num = 0x6. Information associated with the INSERT log record is not replicated.
The log record for a replicated data operation references another log page, called the oampage, that has information about the replicated object. Since the table was dropped, the oampage is deallocated and the data cannot be replicated. If the oampage is assigned to a newly created object, the Adaptive Server may associate log records for the dropped object with the new object.
In the following example, the oampage for foo may be allocated to foo_bar after foo is dropped:
update table foo drop table foo create table foo_bar update foo_bar
In the preceding example, Adaptive Server sends the first update record as an update to foo_bar instead of foo. If the new table has a much larger row size, then an Adaptive Server segmentation fault may occur.
To prevent this error from occurring, wait until the RepAgent or LTM has processed all updates for a primary table before dropping it. See the Replication Server Administration Guide for instructions to drop tables.
Except for replication definitions, schema changes to primary objects may also produce incorrect or unexpected log scan results. Make these changes with caution.
Dropping or recreating replicated stored procedures leads to unpredictable results; schema alterations have the same effect. Make these type of changes only after the RepAgent or LTM has processed all the records for the stored procedure.
Errors may also occur at the Replication Server, check the Replication Server for error messages.
