Conference orarep::nomahs::dbstars

775.0. "DDAL-E-BADDBKSTO on replication update transfer" by BROKE::GREEN () Fri Apr 25 1997 15:03

Copyright (c) 1997 by Oracle Corporation.  All Rights Reserved.

KEYWORDS: Replication DDD ROR DDAL-E-BADDBKSTO
                                                 
TITLE:    Replication transfer fails with DDAL-E-BADDBKSTO error

PRODUCT:  Rdb Replication Option

OP/SYS:   OpenVMS VAX or AXP

SOURCE:   Oracle Worldwide Customer Support


SYMPTOM:  A Rdb Replication transfer fails with a DDAL-E-BADDBKSTO error msg.


RESPONSE:  This error has only appeared in replication update transfers which
           retain deleted source rows in the target table.  This type of
           transfer is called an archive transfer.  An archive transfer is
           created using the /WITH_NO_DELETE qualifier.

           In the transfer log file the DDAL-E-BADDBKSTO error message also
           includes a hex representation of the source row's DBKEY value.
           This error will arise if the real source DBKEY value already
           exists in the target table's DDAL$DBKEY column.  In an archive 
           transfer you cannot have duplicate DDAL$DBKEY values unless the
           values are NULL.

           The DDAL$DBKEY column in the target table contains an encrypted
           hex representation of the real source table's DBKEY value.  You
           cannot issue a SQL SELECT statement using the DDAL$DBKEY value in
           a WHERE clause.  

           The steps to find the target row with the duplicate DDAL$DBKEY
           value are as follows:

           1. Get the hex DBKEY string from the failed transfer log file.
           2. Do an RMU/DUMP/LAREA of the logical area in the target database
              to an output file.  This will probably result in a huge output 
              file so monitor the size of the file with DIR/SIZE/FULL and 
              also check available disk space with SHOW DEV commands.
           3. Use the VMS SEARCH command to search the output file created
              in step 2 for the hex DBKEY string. Use /WIN= in the SEARCH
              command so that you can see more surrounding data around the 
              DBKEY string.
           4. The DDAL$DBKEY column is always the first column in the target
              table and is 8 bytes long.  You will need to do a SHOW TABLE(COL)
              command to see the column offsets and datatypes of the target
              table.  You then need to start translating the column data from
              the output file from step 2. You will have to decipher enough
              columns until you have enough values to do a SQL SELECT command 
              which will return just that one row.  At this point you could
              issue a SELECT DBKEY FROM target_table WHERE command if you 
              want to find and dump the actual page in the target table.  

              How can this problem occur?  A missed delete transaction from
              the source database's RDB$CHANGES table could create this problem
              at a later date.  Because the delete operation never made it to
              the target table (and the row was deleted from the source db)
              that DBKEY value could get reused over time on an insert 
              operation in the source table. The next time the transfer runs 
              the insert will fail with this error.  Customers should never
              manually update the RDB$CHANGES table.

WORKAROUND:  Either mark the existing target row as a deleted row by changing
             the DDAL$DBKEY column to NULL and then restart the transfer or 
             else reinitialize the transfer.


\
\ CONTRIBUTORS:
\
\	Technical: Don Green
\	Editorial: 
\
\

Talked to Don.  He sent to either Marilyn or Mem on 4/25/97 thru 
oracle office.