Conference orarep::nomahs::rdb_60

5104.0. "DIOFREE$UNMARK_AIJ_RECORDS +46C and +270" by chsr38.ch.oracle.com::ROHR (The Packers did it!) Wed Mar 05 1997 07:51

Customer did a drop and recreate storage areas (without quitting SQL) and got
a bugcheck. 6.1A release notes mention a bug fixed in ECO4 (this is not
documented in the ECO4 release notes however), where a restore just pages would
put the logical area of the page to 0 and thereby causing a bugcheck.

The customer had to close and reopen the database to gain access to the new
storage areas.

Now was this really fixed in 6.1 ECO4 (which is the customer's version) or only
in 6.1A and is the following bugcheck related at all . I am currently trying 
to reproduce this.

Thanks,
Regina


Saved PC = 0108C3AC : STD$DUMP_ALPHA_VMS_STACK + 000000DC
Saved PC = 01070B94 : KOD$BUGCHECK_DUMP + 00000CB4
Saved PC = 00F3C304 : KOD$BUGCHECK_AND_EXIT_HNDLR + 000000A4
Saved PC = 80006F04 : S0 address
Saved PC = B840E2BC : S0 address
***** Exception at 00F1BDBC : DIOFREE$UNMARK_AIJ_RECORDS + 0000046C
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000242, 
						PC=00F1BDBC, PS=00000009
Saved PC = 00F99C24 : PIOUTL$UNMARK_ONE_BUFFER + 00000614
Saved PC = 00F9A63C : PIOUTL$UNMARK_PIO_QUE + 0000040C
Saved PC = 00FD2164 : DIOUN$CRLA + 00000434
Saved PC = 00FD0D60 : DIO$UN_DO + 00000070
Saved PC = 00FC3078 : RUJUTL$ROLLBACK_LOOP + 00000250
Saved PC = 00FC07D8 : RUJ$VERB_ROLLBACK + 00000050
Saved PC = 00F3ED84 : KOD$VERB_FAILURE + 000000F4
Saved PC = 00DB1024 : RDMS$$TOP_DSDI_CLEANUP + 00000094
Saved PC = 00DB0B6C : RDMS$$TOP_DSDI_HNDLR + 0000017C
Saved PC = 80006F04 : S0 address
Saved PC = B840E2BC : S0 address
***** Exception at 00F1BBC0 : DIOFREE$UNMARK_AIJ_RECORDS + 00000270
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000242, 
                                             PC=00F1BDBC, PS=00000009
Saved PC = 00F99C24 : PIOUTL$UNMARK_ONE_BUFFER + 00000614
Saved PC = 00F9A63C : PIOUTL$UNMARK_PIO_QUE + 0000040C
Saved PC = 00F91688 : PIOFETCH$SELECT_VICTIM_BCB + 000002C0
Saved PC = 00F903F4 : PIO$FETCH_UPD + 0000029C
Saved PC = 00F8EA40 : PIO$FETCH + 000003C8
Saved PC = 00F25844 : DIOLAREA$INIT_CLUMP + 000000FC
Saved PC = 00F25508 : DIOLAREA$FIND_GOOD_PAGE + 00000110
Saved PC = 00F20218 : DIO$RECORD_LOCATION + 00000238
Saved PC = 00F2064C : DIOSTORE$STORE_SEG + 000000C4
Saved PC = 00F20430 : DIO$STORE + 000001B8
Saved PC = 00FB0984 : PSIIBUILD$BUILD_FROM_BOTTOM + 00000794
Saved PC = 00FA9A6C : PSII$CREATE_TREE + 00000114
Saved PC = 00DA4104 : RDMS$$KOD_CREATE_TREE + 0000017C
Saved PC = 00DA3868 : RDMS$$KOD_CREATE_INDEX + 00000518
Saved PC = 00D28354 : RDMS$$CREATE_INDEX_INFO + 0000249C
Saved PC = 00D016D0 : RDMS$$RELEASE_DDL_REQUEST + 00000F30
Saved PC = 0115E0BC : BLI$CALLG + 000000BC
Saved PC = 00F3D8B8 : KOD$SETSTK_AND_CONTINUE + 00000140
Saved PC = 00F3D5FC : KODSTREAM$DO_THREAD + 000000E4
Saved PC = 00F3D438 : KOD$STREAM_REQUEST + 000002A0
Saved PC = 00F3E73C : KOD$STALLAST + 0000008C
Saved PC = 00F3E860 : KOD$STALLAST_RMS + 00000108
Saved PC = 80092410 : S0 address
Saved PC = 8009396C : S0 address
Saved PC = 00B3C9C4 : Image RDMSHR + 000329C4
Saved PC = 00B3C02C : Image RDMSHR + 0003202C
Saved PC = 009154C0 : Image RDB$SHARE + 0014B4C0
Saved PC = 008A4D88 : Image RDB$SHARE + 000DAD88
Saved PC = 008FDE64 : Image RDB$SHARE + 00133E64
Saved PC = 008BF7FC : Image RDB$SHARE + 000F57FC
Saved PC = 008C4918 : Image RDB$SHARE + 000FA918
Saved PC = 008CE2E4 : Image RDB$SHARE + 001042E4
Saved PC = 007FFF6C : Image RDB$SHARE + 00035F6C
Saved PC = 006F8F18 : Image RDBSHR + 00072F18
Saved PC = 006E8A88 : Image RDBSHR + 00062A88
Saved PC = 00697110 : Image RDBSHR + 00011110
Saved PC = 0025E930 : Image SQL$ + 0024E930
Saved PC = 0025D6E8 : Image SQL$ + 0024D6E8
Saved PC = 0016375C : Image SQL$ + 0015375C
Saved PC = 00253E94 : Image SQL$ + 00243E94
Saved PC = 0016396C : Image SQL$ + 0015396C
Saved PC = 001634FC : Image SQL$ + 001534FC
Saved PC = 0015866C : Image SQL$ + 0014866C
Saved PC = 7F9D42E0 : P1 address

    

    Well,
    
    I got some more info from the site's consultant (makes more sense as
    there is index stuff in the stack):
    
    drop area creat area create unique index - bugcheck          
                                                            
    drop area create area close and open db create unique index - bugcheck
    
    drop area close & open db create area create unique index - ok 
    
    They do not remember having done a rmu/restore justpages to rdb$system.
    (They usually prefer a complete restore in case of problems.)
    
    Regina
    

    Can s.o. see from the stack  why it failed? Quota? Resources?
    Inconsistent data in memory?
    
    Thanks,
    Regina

    I don't believe this bugcheck is at all related to the problem
    mentioned in the 6.1A release notes.
    
    The cause?  Not sure, but I suspect it has to do with Rdb attempting to
    unmark all buffers before it has completed creating a logical area. 
    Sounds like a likely problem for a BUG report.  Please try and
    reproduce it.  If you cannot reproduce it then go ahead and submit a
    complete bugcheck dump along with the command the customer believes
    they executed.  There is a reasonable chance someone may be able to
    figure it out with just the bugcheck, but a reproducible case would be
    much more likely to elicit a fix.

    Re: .3:
    
    >>>Sounds like a likely problem for a BUG report.  Please try and
    >>>reproduce it.  If you cannot reproduce it then go ahead and submit a
    >>>complete bugcheck dump along with the command the customer believes
    >>>they executed.  There is a reasonable chance someone may be able to
    >>>figure it out with just the bugcheck, but a reproducible case would be
    >>>much more likely to elicit a fix.
    
    No luck with reproducing. Bugged 469763.
    /Regina