[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

5081.0. "What things set 'inconsistent' flag in RMU/DUMP/HEAD ?" by NOMAHS::SECRIST (Rdb WWS; [email protected]) Wed Feb 26 1997 17:08

    
    	What are all of the things that can set the flag in the "database 
    	recovery" section of an RMU/DUMP/HEADER that makes RMU/DUMP report 
    	"Database is  inconsistent and has been modified" ?
    
    	Regards,
    	rcs
T.RTitleUserPersonal
Name
DateLines
5081.1Restore of area without recovery?bouvs.us.oracle.com::OAKEYI'll take Clueless for $500, AlexWed Feb 26 1997 17:1614
>>    <<< Note 5081.0 by NOMAHS::SECRIST "Rdb WWS; [email protected]" >>>
>>          -< What things set 'inconsistent' flag in RMU/DUMP/HEAD ? >-

>>    	What are all of the things that can set the flag in the "database 
>>    	recovery" section of an RMU/DUMP/HEADER that makes RMU/DUMP report 
>>    	"Database is  inconsistent and has been modified" ?
    
Right off hand the operation that comes to mind is restoring an area 
without following that by a recover.  If you restore an area, the area is 
marked inconsistent and will be marked as consistent as soon as you recover 
from the AIJ.

Do they have corrupt pages in the CPT?  Did they restore an area?

5081.2Things that make you go "Hmmmmmm"NOMAHS::SECRISTRdb WWS; [email protected]Wed Feb 26 1997 18:0416
    
    Hmmm.  That's what came to mind for me too, but they swear they
    haven't restored anything out of synch or used RMU/ALTER, etc.
    The database came from an EXPORT/IMPORT they did some moons ago
    to overcome file fragmentation, and they're command procedure
    does an online VERIFY/NOROOT and full AIJ backup daily with
    either full or incremental RMU backups and everything is clean
    in the logs.  They're going to scour the logs, but then I
    couldn't figure out any other way this would have been set.
    They have got to be missing something or have a late-night
    hacker nobody knows about ;-)
    
    Thanks,
    rcs
    
    
5081.3m5.us.oracle.com::LWILCOXChocolate in January!!Thu Feb 27 1997 11:146
I do remember several reports some time ago where customers would export
\import and then end up with this flag on.  Never did figure out why or
how and it did not seem to cause trouble...I think there might be some
old notes about this.

Liz
5081.4NOVA::SMITHIDon&#039;t understate or underestimate Rdb!Thu Feb 27 1997 11:389
~I do remember several reports some time ago where customers would export
~\import and then end up with this flag on.  Never did figure out why or
~how and it did not seem to cause trouble...I think there might be some
~old notes about this.

Seems unlikely, that would mean this was possible after a CREATE DATABASE
(which is all IMPORT does).

ian
5081.5m5.us.oracle.com::LWILCOXChocolate in January!!Thu Feb 27 1997 13:318
  <<< Note 5081.4 by NOVA::SMITHI "Don't understate or underestimate Rdb!" >>>


>>Seems unlikely, that would mean this was possible after a CREATE DATABASE
>>(which is all IMPORT does).

You bet it seems unlikely.  Note 1486 in 5.0 notesfile was the one I
remembered.