[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

4312.0. "RMU/RECOVER runs out of memory" by ukvms3.uk.oracle.com::PJACKSON (Oracle UK Rdb Support) Mon Jul 22 1996 07:24

T.RTitleUserPersonal
Name
DateLines
4312.1NOVA::R_ANDERSONOracle Corporation (603) 881-1935Mon Jul 22 1996 21:0113
4312.2 RMU/RECOVER runs out of memory ORAREP::TKTV41::MIYASHITAYoichi Miyashita/Systems SupportTue Feb 18 1997 06:3097
  Hello,

  Our customer has a bugcheck dump during AIJ recovery.
  We tried dump AIJ and the command failed with the following error.
  AIJ is contains rmu/load record. This transaction has 50000 records per
  one transaction.

  We think that it causes of store too many records within one transaction
  in continued AIJ.

  1. Is process working set increasing while one transaction recovery ?
 
  2. If so, number of record containing one transaction is limited to
     VIRTUALPAGECNT when AIJ recovery.

  3. Where can we find more details about the problems ?
 
  4. Has it been given up or is there a workaround available ?



  $ rmu/dump/after BACUSS_MAIN_1.AIJ/out=dump1.log

  %COSI-F-EXQUOTA, exceeded quota
  -SYSTEM-F-VASFULL, virtual address space is full
  %RMU-F-FATALOSI, Fatal error from the Operating System Interface.


  Best Regards,
               Yoichi



*** Config ***

    DEC Rdb V6.1-1
    VMS  V6.2-1H3

*** RMU/RECOVER bugcheck ***  

  $ SEAR RMUBUGCHK.DMP "Saved PC","-F-","****"

  Saved PC = 003DC2EC : STD$DUMP_ALPHA_VMS_STACK + 000000DC
  Saved PC = 003C1794 : KOD$BUGCHECK_DUMP + 00000CB4
  Saved PC = 0010B210 : RMU$HNDLR + 00000378
  Saved PC = 80495D44 : S0 address
  Saved PC = F37B02BC : S1 address
  ***** Exception at 8048F00C : S0 address
  %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=22184000,
  PC=8048F00C,PS=0000001B
  Saved PC = 002DC14C : KUTREC$NORMAL_ROLLFORWARD + 000001A4
  Saved PC = 002D3BA8 : KUTREC$RECOVER_JOURNAL + 00001360
  Saved PC = 002D2184 : KUTREC$RECOVER + 000002B4
  Saved PC = 00179860 : RMUREC$RECOVER_ACTION + 00000838
  Saved PC = 00178D38 : RMUCLI$RECOVER + 00000628
  Saved PC = 000F3C4C : RMU$MAIN + 00000D5C
  Saved PC = 7EE7E160 : P1 address
  %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=42384030,
  PC=000ED0B4,PS=0000001B


  $ sear/sta/noout TEMP_AIJ.DMP;1 "Resizing"

  Files searched:                 1       Buffered I/O count:         4
  Records searched:           17542       Direct I/O count:           0
  Characters searched:       595681       Page faults:               82
  Records matched:             1219       Elapsed CPU time:  0 00:00:00.70
  Lines printed:                  0       Elapsed time:      0 00:00:01.43


$ rmu/dump/after BACUSS_MAIN_1.AIJ;1/end=1
*------------------------------------------------------------------------------
* DEC Rdb V6.1-1                                        18-FEB-1997 19:37:47.57
*
* Dump of After Image Journal
*     Filename: DPA6000:[MIYA.JT]BACUSS_MAIN_1.AIJ;1
*
*------------------------------------------------------------------------------

1/1              TYPE=O, LENGTH=510, TAD=16-FEB-1997 00:38:32.16, CSM=00
    Database _DSA703:[BH_TDPDB.MAIN.V600]BACUSS_MAIN.RDB;1
    Database timestamp is 14-FEB-1997 05:07:49.28
    Facility is "RDMSAIJ ", Version is 601.0
    AIJ Sequence Number is 1
    Transactions from AIJ sequence number 0 may span into this journal
    Last Commit TSN is 533
    Synchronization TSN is 0
    Type is Normal (unoptimized)
    Open mode is Continuation
    Journal was backed up on 17-FEB-1997 21:10:04.78
    Backup type is Quiet-Point
    I/O format is Block
    Commit-to-Journal optimization disabled
    Switchover by process 206004C0

Display terminated at user request after AIJ record 1

4312.3HOTRDB::LASTOVICAIs it possible to be totally partial?Tue Feb 18 1997 10:0712
     VASFULL,  virtual address space is full
    
      Facility:     SYSTEM, System Services
    
      Explanation:  The virtual address space is full.
    
      User Action:  Reboot and increase the amount of allowable virtual address
                    space. If this message is associated with a vector disabled
                    (VECDIS) status code, insufficient process virtual address
                    space exists to allow the current process's mainline vector
                    state to be saved.
    
4312.4svrav1.au.oracle.com::MBRADLEYI was dropped on my head as a baby. What's your excuse?Wed Feb 19 1997 21:445
Have you tried rolling forward starting with the previous AIJ?

G'day,

Mark.