[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_60

Title:Oracle Rdb - Still a strategic database for DEC on Alpha AXP!
Notice:RDB_60 is archived, please use RDB_70..
Moderator:NOVA::SMITHISON
Created:Fri Mar 18 1994
Last Modified:Fri May 30 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5118
Total number of notes:28246

5098.0. "checksum 00000001 and PIO$FETCH_UPD +5B5" by chsr38.ch.oracle.com::ROHR (The Packers did it!) Tue Mar 04 1997 03:39

    My favourite bank stumbled over a page with checksum 00000001. Article 
    about checksum errors sent. As some others in this notesfile they claim 
    they HAVE NOT done manipulations thereby causing this checksum.
    
    In fact their recover fell over with the following (can s.o. please confirm
    that the bugcheck has to do with the strange checksum). 
    
    To the best of our knowledge, there is still no recognized Rdb problem?
    
    V6.1.0.4
    
    Saved PC = 000449E6 : KOD$BUGCHECK_AND_EXIT_HNDLR + 00000036           
    Saved PC = 00028646 : DBR + 00000826                                        
    ***** Exception at 00070F78 : PIO$FETCH_UPD + 000005B5                        
    Saved PC = 80000014 : S0 address                                            
    Saved PC = 0006FEA5 : PIO$FETCH + 000001B2                                  
    Saved PC = 00072F15 : PIO$UPDATE_FIB + 000000A9                             
    Saved PC = 000700F4 : PIO$FETCH + 00000401 
    Saved PC = 0003DE35 : DIOUN$MARK + 000001B2                                 
    Saved PC = 0003CC9C : DIO$UN_DO + 000000C0                                  
    Saved PC = 0002B0BE : DBR$RESOLVE + 00000722                                
    Saved PC = 00028C36 : DBR$RECOVER + 000005EF          
    Saved PC = 0002856D : DBR + 0000074D                                        
    Saved PC = 00027E1D : DBR$MAIN + 000000A1                                   
    Saved PC = 806B48E4 : S0 address                                            
    Saved PC = 806B4895 : S0 address  
    
    Thanks,
    Regina
    
    PS for a little whining: If the powers in engineering would respond to 
    our request to have access to sources, we could look this up on our own.  
    
T.RTitleUserPersonal
Name
DateLines
5098.1HOTRDB::PMEADPaul, [email protected], 719-577-8032Tue Mar 04 1997 09:295
    Yes, the exception indicates a checksum problem.
    
    Considering how many people have reported problems with a checksum of 1
    I am inclined to believe Rdb is broken somehow.  I don't know what the
    problem is, however.
5098.2What can we check next time?chsr38.ch.oracle.com::ROHRThe Packers did it!Tue Mar 04 1997 11:1614
    What can I propose to check when it happens again:
    
    dump of concerned page for timestamp and TSN?
    
    dump of AIJ for that TSN and timeframe?
    
    What else?
    
    Thanks,
    Regina
    
    
    
    
5098.4Don't know... Will checkchsr38.ch.oracle.com::ROHRThe Packers did it!Tue Mar 04 1997 12:007
    Don't know, will ask. As this is a bank I doubt for the 6.1-0 but Eco 1
    could well be.
    
    Was there a problem that would only show up years later? Thanks for
    more information,
    Regina                                                   
    
5098.3HOTRDB::PMEADPaul, [email protected], 719-577-8032Tue Mar 04 1997 12:065
    Has this db ever been updated by an Alpha system running Rdb V6.1-0 or
    V6.1-01?  If so, when did they upgrade to V6.1-02 or later?
    
    A complete page dump would be a good start.  The timestamp being the
    thing I would be most interested in seeing.
5098.5HOTRDB::PMEADPaul, [email protected], 719-577-8032Tue Mar 04 1997 12:106
>    Was there a problem that would only show up years later? Thanks for
>    more information,
    
    I don't know.  I am suspicious of some potential odd interaction when
    re-checksumming pages that were checksummed using the old incorrect
    algorithm.