[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

5015.0. "cosi_mem_get_vm during recover (6.1a)" by UKVMS3::SHISCOCK (stand and deliver) Tue Feb 11 1997 06:41

    Hi,
    
    My customer is testing a procedure to restore a live database onto
    another system and then roll forward any aij's. This is just a
    temporary situation to move operations from one system to another
    while one has some firmware upgrades. By restoring and then applying
    any aij's he hopes to minimize downtime when the production system
    is switched across.
    
    After he restored the database successfully he tried to apply the aij.
    This bugchecked with
    
    exception @ cosi_mem_get_vm +a9c
    cosi-f-unexperr
    system-f-illpagcnt
    
    The aij was a no quiet point backup. The live db has circular aij
    enabled.
    
    The live system is running rdb 6.1-04 whereas the copy system has
    6.1a. Both have axp vms 6.2-2h1.
    
    I've asked for the dump and email of the stack section. I also
    asked them to verify the live database.
    
    Anything else I need to check?
    
    Any ideas?
    
    cheers,
    
    Steve
         
T.RTitleUserPersonal
Name
DateLines
5015.1NOVA::R_ANDERSONOracle Corporation (603) 881-1935Tue Feb 11 1997 09:099
Your customer is probably applying the AIJ journals out of sequence.

This situation is not allowed in Rdb7 but is "tolerated" in Rdb v6.1 and earlier
because the customer is allowed to try to apply any journal regardless of
whether it can be applied.

Recommendation: Start the recovery with the previous AIJ journal.

Rick
5015.2aborts with the aij it says it needsUKVMS3::SHISCOCKstand and deliverTue Feb 11 1997 09:3812
         
    The database backup was created on-line also. Once restored it
    says it needs aij 136 which is the one that bugchecks. So
    he's trying to apply 136 and 137. 
    He claims to have tried 135,136 & 137 but says that 135 is too
    old. Even so I can't see with two journals he could get them
    out of sequence. Wouldn't it complain about the sequence numbers
    in the first place.
    
    thanks so far,
    
    Steve
5015.3Looks strangesvrav1.au.oracle.com::MBRADLEYI was dropped on my head as a baby. What's your excuse?Tue Feb 11 1997 18:539
Rdb 6.1 and earlier weren't that good at handling noquiet point AIJ 
backups.

Having said that, I am surprised to see an illegal page count error from 
doing this.

G'day,

Mark.
5015.4-<Looks familiar...>-< Looks familiar... >-< Looks familiar...>-< Looks familiar...>NOVA::BALL_AWed Feb 12 1997 14:025
    The ILLPAGCNT is being returned from a call to $expreg requesting 33630
    pagelets - we are going to take a look at the AIJ itself - and Hi Mark,
    this looks awfully like the 'post scenario...
    
    ALan 
5015.5possibly the aij, but it may be the db as wellNOVA::BRYDENWed Feb 12 1997 14:2912
        Alan,
        
        	The customer is using noquiet point for both aij and
        database? When they restored teh database backup, which backup was
        it? The database needs to be restored to a known good point and
        then incrementals rolled forward.
        
        	Does the customer have a quietpoint backup of their
        database that they can go back to and then roll forward? As you
        said what were teh first few blocks in the aij?
        
        Dave
5015.6okay on quiet-point testUKVMS3::SHISCOCKstand and deliverThu Feb 13 1997 03:277
    
    The customer did a new test using a quiet-point db backup and
    this worked. Guess they'll need to re-think using noquiet
    aij and db backups.
    
    cheers,
    Steve
5015.7NOVA::R_ANDERSONOracle Corporation (603) 881-1935Thu Feb 13 1997 07:434
...at least until the next ECO comes out, which includes enhancements to better
detect this problem...

Rick
5015.8do quiet on weekend, noquiet during week..NOVA::BRYDENThu Feb 13 1997 14:1918
        Steve,
        
        	We had exactly the same thing happen down here a while
        back.... Custoemr took a quiet point backup and then subsequent
        backups were no-quietpoint.... day 65 comes along and they have a
        failure, tried the latest noquietpoint backup, restored and rolled
        forward the aij.... it failed. They ultimately had to go back to
        the quietpoint from 65 days earlier and then luckily roll forward
        all teh aij's.
        
        	What this site did was a full quietpoint on the weekends
        and then noquietpoint incrementals during the week. this meant
        they only had to go back a max of 6 days to get a synch point.
        
        	Were you able to determine whether it was the aijs, that
        caused the cproblem or was it the state of teh db?
        
        Dave 
5015.9We should see from the dumpsvrav1.au.oracle.com::MBRADLEYI was dropped on my head as a baby. What&#039;s your excuse?Sun Feb 16 1997 19:0813
As has been said, a dump of the first few blocks of the AIJ file would be 
helpfull.

In any event, even with the next ECO of 6.1, which may not evidence this
problem, you still may have to go baclk to the most recent noqiet point AIJ
backup to get a good roll forward. 

In V7 you only have to go back to the most recent of a quiet database or a 
quiet AIJ backup.

G'day,

Mark.