Conference orarep::nomahs::dbstars

755.0. "INVLOGTRN -- and others" by BROKE::BASTINE () Wed Mar 26 1997 14:48

From the DDD notes file... don't want this to get lost.

     <<< NOMAHS::DISK$NOMAHS1:[NOTES$LIBRARY]DEC_DATA_DISTRIBUTOR.NOTE;1 >>>
                      -< The Replication Option for Rdb >-
================================================================================
Note 272.0         INVLOGTRN, INVLOGTYP, INVLOGCLA, INVJOUVER         No replies
BROKE::PROTEAU "Jean-Claude Proteau"                112 lines  24-MAR-1997 16:04
--------------------------------------------------------------------------------

    	    INVLOGTRN -- INVLOGTYP -- INVLOGCLA -- INVJOUVER
    	    INVLOGREC -- PREMATEOT -- ERRLOGSIZ -- VINNOTFND


		If you are experiencing such errors, they
		are an indication of corruption in the
		RDB$CHANGES table of the source database.

We are eager to get to the bottom of these problems.  To diagnose what might be
going on, we would like to look at a full backup of your database files.  If the
database is just too big, or if it contains confidential information, perhaps
you can provide us with a subset of the files or a dump of some of the database
pages.

When the problems occur, you usually cannot wait long to fix them and get back
to normal.  But fixing them means you have to REINITIALIZE the transfers and
restart them.  This wipes out the evidence we need to see what happened.  Usual-
ly we are not available right away to investigate.  For that reason, we ask you
to make a backup of the database files and then make them available to us.  If
you cannot make the files available to us, then dump information from some of
the database pages and send that to us.  When you do, please submit an Oracle
bug report.

If a full database backup is impractical, we would like to see the following
subset of files:

1. The source database root file (.RDB)

2. The RDB$SYSTEM storage area (.RDA) including snapshot file (.SNP)

3. The segmented string storage area (.RDA) and snapshot file (.SNP) if this
   storage area is different from RDB$SYSTEM

4. The TSER values from the target databases in the RDB$VINTAGE tables.  This
   tells us the last good transaction and, by implication, the next transaction
   in RDB$CHANGES which shows a corruption.  To obtain the TSER values from the
   target databases, attach to each database and perform the following queries:

   If the target is an Rdb database:

       select RDBVMS$VINTAGE_TRANSFER_NAME,RDB$VINTAGE_TSER from RDB$VINTAGE;

   If the target is other than an Rdb database:

       select DDAL$TRANSFER_NAME,DDAL$TRANSFER_TSER from DDAL$TRANSFER_INFO;

   If you have several replication transfers failing for the same reason on the
   one source database, you should expect to see the same TSER value listed for
   each transfer when examining the target database.

If you cannot save the database files, perhaps you can dump some of the database
pages and send us a file (or printout) containing the dump.  The steps involved
are these:

a.  First look at the target databases to determine the last good TSER value,
    as shown in step 4 above.  For reference in the steps below, let's call
    this value LAST_GOOD_TSER.

b.  Determine from the source database the transaction in RDB$CHANGES that is
    causing the problem:

    select RDB$TRANSACTION_TID,RDB$TRANSACTION_TSER from RDB$CHANGES
    where RDB$TRANSACTION_TSER > LAST_GOOD_TSER LIMIT TO 1 ROW;

    This will list the next transaction number (TSER) in sequence that follows
    the one recorded in the target database.  It is the TSER of the transaction
    causing the transfers to fail.  You must do a query like the one above;
    you cannot assume that adding one to the TSER value will work.  That's be-
    cause of the way Rdb assigns TSER values.  Sometimes there are gaps, with
    some numbers not used.

c.  Once you have the offending TSER value, you also have another transaction
    number (from RDB$TRANSACTION_TID).  This TID value is the Rdb TSN number
    assigned when the transaction started.  You need this TSN number rather
    than the TSER number in order to locate all the rows in RDB$CHANGES that
    belong to the same transaction.  I'll explain why with an illustration.
    Let's say you have a transaction that was long enough to require three rows
    to be written to the RDB$CHANGES table.  Here is an example of one such
    transaction (not shown is the RDB$TRANSACTION_CHANGES column):

    RDB$TRANSACTION_TID  RDB$TRANSACTION_SEQUENCE  RDB$TRANSACTION_TSER
    -------------------  ------------------------  --------------------

    	  4998                       1                      0
    	  4998                       2                      0
    	  4998                       3                      2501

    The SEQUENCE number column allows us to sort the rows in the order in which
    they were written.  Note that only the last row of the set contains a valid
    TSER number.  That's because the TSER is assigned when the transaction is
    about to be committed.  The TID column (TSN number) is the same for all
    three rows.  For reference below, we'll call this number BAD_TID.

    Issue the following query to get this information plus the database key of
    each of these rows:

    select RDB$TRANSACTION_TID,RDB$TRANSACTION_SEQUENCE,RDB$TRANSACTION_TSER,
    DBKEY from RDB$CHANGES where RDB$TRANSACTION_TID = BAD_TID;

d.  Now you have the database keys for each of the three rows in our example of
    a bad transaction in RDB$CHANGES.  Use RMU to dump the database pages con-
    taining these three rows.  The database keys consists of three parts:
    logical-area-number:database-page-number:line-number, such as, 49:558:0.

    Determine in which physical storage area the RDB$CHANGES table (in this case
    logical area 49) exists.  For Rdb versions 6.1 or earlier, it is always
    physical area 1.  Here's an example of the RMU command you would use.

    RMU/DUMP/AREA=1/START=558/END=558/OPTION=DEBUG/OUTPUT=DUMP.LIS source.RDB