Conference orarep::nomahs::dbms

>      Is this a possible memory glitch, and upgrading VMS and DBMS would
>    help ?  If not, what should I look at next ?
    
    A lot of things could cause this. The bugcheck needs to be examined
    more fully. The next thing I would look at are the routines on the call
    stack, to see what was being done.
    
    Peter

    
    Posting stack for Mark O'Neil.  If anyone can provide some insight
    tonight, the customer would appreciate it.
    
    Thanks,
    Lisa 
    
    Saved PC = 80006F04 : S0 address
    Saved PC = 9BDE42BC : S0 address
    ***** Exception at 00B43140 : PIOFETCH$WITHIN_DB + 00000448
    %COSI-F-BUGCHECK, internal consistency failure
    Saved PC = 00B41064 : PIO$FETCH_RET + 000002BC
    Saved PC = 00B40A7C : PIO$FETCH + 000004BC
    Saved PC = 00B0855C : DIOFETCH$FETCH_VISIBLE_SEG + 00000498
    Saved PC = 00B07B68 : DIOFETCH$FETCH_ONE_LINE + 0000048C
    Saved PC = 00B0901C : DIOFETCH$SCAN_ONE_PAGE + 000002D0
    Saved PC = 00B0730C : DIO$FETCH_AREA + 00000194
    Saved PC = 00AF2A88 : DSIFIND$SCAN_AREA + 00000068
    Saved PC = 00AF2884 : DSI$FIND_WITHIN_AREA + 00000304
    Saved PC = 00AD0B30 : LSIFETCH$WITHIN_REALM2 + 00000130
    Saved PC = 00AD097C : LSIFETCH$WITHIN_REALM + 00000184
    Saved PC = 00AD04F4 : LSIFETCH$RSE1 + 0000019C
    Saved PC = 00ACF99C : LSI$FETCH + 0000007C
    Saved PC = 009F9788 : DBM$DML + 000001A8
    Saved PC = 009F8714 : DBM$32X + 00000314
    Saved PC = 00D3590C : BLI$CALLG + 000000BC
    Saved PC = 00B21910 : KOD$SETSTK_AND_CONTINUE + 00000140
    Saved PC = 00B216A0 : KODSTREAM$DO_THREAD + 00000188
    

    >    ***** Exception at 00B43140 : PIOFETCH$WITHIN_DB + 00000448
    
    	this bugcheck means that a page number was requested that is past
    the end of a storage area.  I'd first recommend that the database gets
    completely verified.  From there, I dunno.  Sounds like a bad DBKEY is
    probably getting passed around.

He did a complete verify and it came up clean.

He also did a full backup and restore, all successful.

Is there is anyway to locate such a bad dbkey if it is floating around?
He did a full verify and it didn't pick up anything and he sees the problem
in 2 different areas of the database. 

What can we do to find this?

Thanks,
Renee (for Mike)

    one would need to dig through the dump file to find the offending dbkey
    and from there try to determine where it originated.

    Post the stack with the register dumps and we probably can pinpoint the
    cause.

    FYI, the cause of the bugcheck:
    
    The FETCH was for a sequential walk of the realm.  The problem only
    occurs in batch retrieval jobs.  When walking the realm, DBMS checked
    the TSN index and determined that it needed to fetch the snapshot page
    to get a visible version of the record.  The snapshot page was empty,
    hence the bugcheck.
    
    All the snapshot pages were empty, as they should be, because the
    database was just restored.  The problem was with the TSN number for
    this line in the TSN index.  It was erroneous.
    
    The currency indicators in the bugcheck did not point to this problem
    page.  The problem page was in the buffers seen in the bugcheck.  
    
    To find the problem page, I started with the record's current dbkey
    (FETCH DBKEY), turned on the currency update display (SET
    CURSIG), and looped through fetching the next record in a batch
    retrieval transaction.  Starting with the last dbkey shown before
    the bugcheck, I had to dump pages till I found the next record (the 
    problem record).
    
    To fix the problem, we updated the record. This fixed the TSN number
    for the line in the TSN index.
    
    Per the customer, this problem record was current when the node
    crashed.
    
    Diane

    How erroneous was the TSN?