Instance recovery mechanism

Hi,
I try to understand the mechanism of instance recovery of Oracle 8i/ Oracle 9i database and I am little bit confused, since I got some opposed information about that.
Please find below my questions:
1. Is SCN number assigned to all transactions or ONLY to committed transactions?
2. Is the checkpoint number the highest SCN number after an checkpoint event?
3. After checkpoint event, dirty buffer are written to database files by DBWR. Does DBWR write only dirty buffers of committet transactions or does DBWR write out all dirty buffers in the DB buffer cache?
Thanks in advance for your answers!
regards
Peter

1. The system change number (SCN) is updated whenever there is a commit.
2. If you are talking about the checkpoint_change# in the v$database table, yes
3. All dirty buffers are written to disk. Data files can and do contain uncommitted data
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Similar Messages

  • Purpose of ONLINE REDO LOG FILES - Media or Instance recovery or BOTH ?

    Hi
    Currently studying this topic for the 1z0-031 exam and am a little confused.
    my books (from instructor led class) say
    -redo logs are a mean to provide redo transactions in the event of a DATABASE recovery
    -redo log buffer gets flushed to redo log files to provide a recovery mechanism in case of MEDIA FAILURE
    Then it says
    -Online redo log files are used in a situation such as an INSTANCE FAILURE to recover uncommitted data which has not yet been written to the data files
    - online redo log files are used for RECOVERY only.
    Am i misunderstanding? Or are redo log files for both MEDIA and INSTANCE recovery? Or just INSTANCE ?
    confused....
    Amanjit

    Online Redo Log Files are used in a sense for both Media and Instance Recovery. If your database is in NoArchive Mode then you will only be able to use the Redo Log Files for instance recover. But if you are running in Archive Log Mode then Redo Log Files are archived and will allow you to recover from media failure.

  • Error Handling/Recovery Mechanism in ODI

    can u ps provide sum infor related to Error handling/recovery mechanism in ODI?
    say for instance a link breaks down while moving data from source to staging or/and staging to target..what will happen?? is it like that the processed records will be dumped into the target table, or no record will be moved into the target table?
    Is it like "ZERO or ALL" kindaa stuff that ODI works on?
    I really need help on this?

    There is an option - Restart in the Operator. When you right click and click on restart .ODI will start from the steps failed.
    I beleive if the database is down then restart can help you but if the agent is down , then you might need to start the session completely ,reason being when agent send the SQL process to database it wait till the Database process and send the record back to it.During that interval if the agent goes down the database would have processed the records but agent wouldn't be ready to read those record and by the time you bring the agent up ,the session would have died and so you would need to start the session again.
    You can test and see if the Restart option helps you .

  • Oracle Concepts: Clarity required on Instance Recovery

    One of my colleague was discussing instance recovery with me.
    We discussed about checkpoint position, instance recovery phases (rolling forward & rolling back ), then he asked me whats the point of rolling forward (applying redo logs) and then rolling back (applying undo blocks), why not applying only committed transactions?
    I told him that this happens because:
    1) roll forward to recreate the scenario just before when Instance crashed
    2) roll forward/roll back is the fastest way to recover
    I am not sure from where I got this learning, may be some blog or article (probably not from Oracle Docs), but is it correct?
    Regards,
    Ankit Rathi

    OnB wrote:
    The 2nd point is completely wrong!Let me elaborate the context of 2nd point, it was mentioned in context of applying only committed transactions during recovery. As all the change vectors go in the redo log files, had there been any mechanism to identify only committed transactions, it would have taken more time (its really hypothetical as there is no mechanism exists, right?) by that mechanism to identify committted transactions (from redo logs) than simply rolling forward and rolling back.There is no context in that point, it's wrong , plain and simple!
    There is a mechanism to identify committed transactions and that's called commit . But when you are doing recovery, you are not recovering just the committed transactions but you are recreating the entire scene before the crash which means, you would be required to apply both the uncommitted and committed work/change vectors. Going by your logic, if Oracle would start searching for the committed transactions, it would have many issues. One, time taken would be more higher. Two, there may be an instance that the commit was issued but before the commit complete message could reach the user, instance got terminated so how about those blocks which may be now in data file and have got an active transaction status and are unsure whether they are committed or not. And last, the way LGWR writes is just to keep on pushing change vectors to the redo stream in the order of the SCN. So for doing a recovery, you would need to reapply all of that changed data in that same SCN ordering.
    The meaning of instance recovery is that you are not having a physical file crashed or deleted but there was a memory loss and few buffers were left out from being written to the data files and now, data files , control file and log files are not in synch.
    The second point, where you are saying its the fastest, is wrong because even for the instance recovery , it can take a very long time and it would depend on how much work was left over before the instance was crashed. Roll Forward is the way to bring the data files in synch with the redo log files and the control files. So if the data files were on Checkpoint Number 100 and the control files and redo log files recorded the number as 120, the missing 20 numbers gap would be reentered in the data files because only then, the database would be opened. Now, your friend's question that why not only committed transaction because you never say a transaction is only done when there is a commit. Whenever any DML is encountered , it's going to cause a transaction. And you do want that missing work to be recreated to ensure that if there was a commit issued before the instance was crashed , next time, Oracle would ensure that work is there and if not , it would be rolled back. And most importantly, in the redo log files all the change vectors go, not just for the committed transactions .This is fine, same understanding here.
    Bring in your own thoughts now that how much you understood from this explanation before I start to get into more technical terms.I would like to know your view about the 1st point. Suppose, something went wrong (in terms of transactions) due to which instance crashed, if it rolls forward (as it happens automatically) during next start-up, will it crash again?
    It would be rolled back in the case of the instance (next) startup. If all what you are doing is plain DML's they won't crash the instance as long as you haven't encountered any bug in the case of which, next time also the instance may crash.
    Aman....

  • Undo behavior during instance recovery

    i'm confused about 2 concepts in applying undoin the case of instance failure
    1.the common concepts of instance recovery which states :
    a) when instance crash, oracle automatically applies all redo in the redo file to roll the db forward to the last scn be4 the failure
    b) & redo data also contains the undo data, it also undo the uncommitted changes from the old valuesin the undo.
    that'sok
    2.but refereing to 10g database concepts (ch17 high availability-p317 if pdf)
    url: http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/high_av.htm#sthref2531
    it says:
    •With fast-start fault recovery, the Oracle database is opened for access by applications without having to wait for the undo, or rollback, phase to be completed.
    •The rollback of data locked by uncommitted transaction is done dynamically on an as needed basis.
    •If the user process encounters a row locked by a crashed transaction, then it just rolls back that row.
    •The impact of rolling back the rows requested by a query is negligible.
    •Fast-start fault recovery is very fast, because undo data is stored in the database, not in the log files.
    •Undoing a block does not require an expensive sequential scan of a log file.
    so which situation is applicable in case of instance recovery
    & do the undo behvior stated above in case of fast start fault recovery is an option or that's the default
    thnx alot

    Hi,
    Whatever changes are made to the database, are recorded in redo log buffer cache sequentially and then shifted to redo log files. Suppose redo logs recorded following changes in the database in following sequence.
    insert a row
    update a row
    commit;
    delete a row
    Now Instance crashes before these changes were written into the database (data remains in buffer cache until checkpoint)
    Now during instance recovery, data which was still in buffer cache and not written to the data files, will be applied in same sequence. All undo data for update/delete is in redo log files and will be applied in the same sequence.
    Salman

  • Uncommited transactions remain after Instance Recovery

    After Instance Recovery, the database seems to contain uncommitted transactions. Please provide an explanation for the following:
    create table t1
    as
    select *
    from all_objects;
    commit;
    create table t2
    as
    select *
    from all_objects;
    update t2
    set object_id = 1 where rownum = 1;
    shutdown abort;
    Neither table t2 nor the update to it were committed (right?), therefore, once the database starts up t2 should not be there. On the contrary, it is still there. In the Oracle Database Backup and Recovery Advanced Guide 10g Release 2, page 11-9, explains how the uncommitted transactions are removed (rolled back) in the Roll Backward step (transaction recovery) of the Instance recovery process.
    Any insight on this is highly appreciated. Thanks.

    Note also following scenario run with SYSDBA privileges:
    bas002> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Prod
    PL/SQL Release 10.2.0.2.0 - Production
    CORE    10.2.0.2.0      Production
    TNS for 32-bit Windows: Version 10.2.0.2.0 - Production
    NLSRTL Version 10.2.0.2.0 - Production
    bas002>
    bas002> drop table t2;
    drop table t2
    ERROR at line 1:
    ORA-00942: table or view does not exist
    bas002> create table t2
      2  as
      3  select *
      4  from all_objects;
    Table created.
    bas002>
    bas002> update t2
      2  set object_id = 1 where object_id=258;
    1 row updated.
    bas002>
    bas002> shutdown abort;
    ORACLE instance shut down.
    bas002> startup
    ORACLE instance started.
    Total System Global Area  192937984 bytes
    Fixed Size                  1288484 bytes
    Variable Size             130025180 bytes
    Database Buffers           54525952 bytes
    Redo Buffers                7098368 bytes
    Database mounted.
    Database opened.
    bas002>
    bas002> select count(*) from t2 where object_id=1;
      COUNT(*)
             0
    bas002>Message was edited by:
    Pierre Forstmann

  • Auto-recovery mechanism(S) of oracle database???

    Hi,
    I read that if the database is closed abnormally, say to power failure, then once the database is re-opened, the RECO foreground process will recover all transactions that were in-doubt, that is neither commited or rolled back, how does it do??? can anyone explain on that???...???

    this is the instance recovery. do not confuse with database recovery.
    If you suddenly power-off of your db server while running, in most cases, only the uncommited transaction are lost.
    You should read the doc

  • Does Linux filesystem undermine Oracle's recovery mechanism?

    I've been an Oracle DBA for 10 years and have been using Oracle
    on Linux for several months, but am not a Linux expert by any
    means. A client told me something about the filesystem Linux uses
    (x2?) that I find hard to believe. Can anyone shed some light on
    this?
    The claim is that the Linux filesystem does not implement
    synchronous writes correctly. The implication is that when a user
    commits a transaction and Oracle flushes the redo log to disk,
    Oracle may think the redo information has been successfully
    written when in fact its still sitting in a buffer somewhere
    waiting to write. If a drive failure occurs, the redo might never
    get written, but meanwhile the user has already been informed
    their transaction has been committed.
    Oracle does not flush data block buffers to disk when you commit
    a transaction. Only the redo is flushed. If the instance were to
    fail, Oracle reads the redo when you restart the instance and
    performs instance recovery automatically.
    If the Linux filesystem does not implement synchronous writes
    legitimately, then the recovery mechanisms in Oracle are
    compromised--indeed a successful commit is not a guarantee of
    data permanence.
    Its hard to believe that this could be true; I don't see how
    Oracle Corporation could put so much effort into porting their
    flagship products to Linux if data permanence cannot be
    guaranteed.
    Is my client mistaken in their understanding of the Linux
    filesystem? Any insights from the Linux gurus out there would be
    gratefully appreciated!
    Regards,
    Roger Schrag
    Database Specialists, Inc.
    null

    Roger Schrag (guest) wrote:
    : I've been an Oracle DBA for 10 years and have been using
    : Oracle on Linux for several months, but am not a Linux expert
    : by any means. A client told me something about the filesystem
    : Linux uses (x2?) that I find hard to believe. Can anyone shed
    : some light on this?
    : The claim is that the Linux filesystem does not implement
    : synchronous writes correctly. The implication is that when a
    : user commits a transaction and Oracle flushes the redo log to
    : disk, Oracle may think the redo information has been
    : successfully written when in fact its still sitting in a
    : buffer somewhere waiting to write. If a drive failure occurs,
    : the redo might never get written, but meanwhile the user has
    : already been informed their transaction has been committed.
    The problem doesn't lie with Linux - fsync() and O_SYNC are
    supported and, AFAIK, behave correctly.
    The problem is that Oracle doesn't appear to use them. The redo
    logs arnt fsync'ed on commit, nor do they appear to be opened
    with O_SYNC.
    Data loss will result, as you point out, if the RDBMS doesn't
    tell the operating system to save the data synchronously.
    Play with strace()ing the RDBMS background processes and confirm
    this for yourself.
    I'm not in a position to progress this with Oracle. Someone,
    obviously, should, otherwise the next article on ZDNet could be
    "Linux causes massive Oracle dataloss"..
    null

  • Recovery Mechanism in Solaris

    Hi to all,
    I am new to Solaris (comimg from HP-UX world) and I was wondering if there is some tool in Solaris world for making exact image of the system and use it afterwards to restore the system as it was at the moment of taking the image.
    HP-UX have such tool called ignite make_tape_recovery and is very handy tool fot this pourpuse.
    Something like this in Solaris?

    dejan.stojcevski wrote:
    Thanks a lot Ivan.
    This answered my question.
    I will search around to learn some more about flash archives and see what they can do too.
    Anyway a little comparisson with HP's make_tape_recovery:
    1. make_tape_recovery creates a bootable tape. No need to boot from instalation CD. You boot directly from the tape. ufsdump is not doing this.
    2. make_tape_recovery does not require to partition the underlying root disk. It is doing this automatically. ufsdump does not have this functionality.
    3. make_tape_recovery is fully automated backup/recovery mechanism mining after you boot from the tape you can return around 1 hour and you will have completly recovered system. ufsdump requires mounting/unmounting of slices.This sounds a lot like SCO's root/boot floppy/tape restore solution.
    Yet I think that this comparison is not correct because Sun's ufsdump and HP's make_tape_recovery are two diferent types of software (different philosophy). Sun's ufsdump is like HP's fsbackup utility - tools for full file system backups. HP's make_tape_recovery <=> Sun's ??? (flash archives maybe?)I don't think Sun has anything like this and the closest you could get would be a Flash archive or a Jumpstart server. And then you would still have to do a restore after a machine has been booted up.
    The closest you could get to something like in the Sun world would probably be "Bare Metal Restore" from Veritas, now Symantec.
    alan

  • Need Instance Recovery?

    I have a very strange situation right now:
    1) Turn on Archive log Mode
    2) Everything works fine ( both database & oracle apps)
    3) Weekly full backup successful
    4) Daily backup successful
    5) Oracle databas hangs (shutdown & startup the database, same problem)
    6) Turn off Archive log Mode
    7) delete all archive logs
    8) Everything works fine ( both database & oracle apps)
    9) Try to turn on Archive log Mode again.
    Failure: with message need to instance recovery???? How come it is? The Archive Log Mode is off and the database and oracle application works fine.
    Any ideas? Or how to fix it?
    FAN
    Message was edited by:
    user623471

    Without really knowing the time gap and transaction volumes (ie archivelog rates) at these steps, and the exact message ...... possibly speculating ....
    but I think that the most likely cause is that the ArchiveLog Destination filesystem is out of space for new archivelogs. That would cause
    a. The "hang" at step 5 {because Oracle can't archive the active/current redolog}
    b. The "hang" at startup in step 5 {because Oracle *still* cant archive ...}

  • Undo tablespace  and instance recovery

    Is UNDO tablespace is mandatory during instance recovery. ?
    Suppose my undo tablespace has some active transaction and instance crashes making undo tablespace inaccessible.
    Will database search for that undo tablespace during startup or I can simply create a new one and set as new undo tablespace ?
    With Regards
    Amt

    Hi,
    >>I am actually confused
    Keep in mind that If an Oracle instance crashes, any changes that are made in the SGA are not written to the data files. When you restart the instance, the SMON background process automatically performs instance recovery by performing the following tasks:
    • Rolling forward changes that are made in the online redo log files but not in the data files. Since all the committed transactions are written to the online redo log files, these are successfully recovered as result of rolling forward changes from the online redo log files to the data files.
    • Opening the database. After the database is opened, users can log on and access any data that is not locked by un-recovered transaction.
    • Rolling back all the uncommitted transactions.
    In resume, during database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the datafiles.
    But if your UNDO tablespace crashed, then you will need recover it, using steps like
    1) shutdown abort (If the instance yet is up)
    2) cp -a /backup/undo01.dbf /u01/oradata (restore the latest recent backup file)
    3) startup mount
    4) recover database or recover datafile '/u01/oradata/undo01.dbf'
    5) alter database open;
    In some cases, re-create it, also resolve the problem:
    http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5669213349582
    Missing UNDO tablespace in restore backup
    >>I checked in test setup and it is actually waiting for missing UNDO tablespace.
    Which exactly test you are doing?
    Cheers

  • Instance recovery

    SMON process perform instance recovery from online redo log files.
    does this means that data in undo segment, is not available at next instance startup, is it only available in memory?
    if undo data is available in undo tablespace, why redo log files are used to perform instance recovery?

    Tell me did you try find the answer or explanation in documentation first? I don't think so.
    Oracle is one of best documented database (IMHO) and there are still people who are omitting this good documentation (honestly I don't understand why they do that).
    Now back to your question.
    During instance recovery there are two phases:
    rollforward phase (cache recovery) - applying informations from redo logs
    rollback phase (transaction recovery) - rollback all uncommited transactions. This phase uses undo segments (if undo management = auto) or roll back segments (if undo management = manual).
    Maybe you should try read more documentation rather than books with lack explanation.

  • Instance recovery by SMON

    Hi,
    are you agree with the followings :
    Your database is running in the ARCHIVELOG mode. After an instance crash, you start up the database by issuing the STARTUP
    command. Instance recovery is initiated by the SMON background process.
    The information used for instance recovery will be derived from the control file.
    The uncommitted changes are rolled back using information in the undo segments.
    The committed and uncommitted changes stored in the online redo log are applied to the
    affected data blocks.Many thanks.

    Oracle instance recovery. I am remebering, one day i was talking with one of my the best and great oracle expert friend and i asked him; "Suppose you have got a chance to ask one question from OCM; what will you ask? He said; i will ask him explain how and when oracle perfrom instance recovery". So you can judge what is instance recovery and how much lengthy is this topic. But if i have to explain then first i will collect some notes from forum and google and the text will be as follow :
    1. The recovery is triggered by smon comparing thre control files and data file headers. If the stop scn of the datafile doesn't match with the checkpoint scn of control file, recovery is triggered(hope I remember correctly). After that recovery starts. There are changes in it from 9i but don't think its neded here. Read on the docs!
    Source:Re: instance recovery in oracle 9i
    Writer:Aman....
    Please read replies by Kamran and Pavan in the above thread.
    2. There is no Instance Recovery at the STARTUP and MOUNT phases. Instance Recovery is at the OPEN phase.
    Source:how oracle will come to know weather it is Instance recovery or Media Recovery
    Writer:Hemant K Chitale
    3. Re: crash recovery/ instance recovery
    Writer:Eduardo Legatti
    etc. etc.
    I mean if i wish to write a note on instance recovery i will collect some good and clear replies by forum experts (as i showed example above) and then will shape-up in my language and then; i will post that text in the forum; so that necessary correction too can be performed (if required).
    Regards
    Girish Sharma

  • Crash & instance recovery

    what is the difference between crash recovery and instance recovery???

    From http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96519/recov.htm#1004618
    Crash recovery is used to recover from a failure either when a single-instance database crashes or all instances of an Oracle Real Application Clusters database crashes. Instance recovery refers to the case where a surviving instance recovers a failed instance in an Oracle Real Application Clusters database.

  • Crash recovery/ instance recovery

    Hi,
    How do oracle identifies crash recovery/ instance recovery
    is required?
    Regards,
    Mathew

    Hi,
    >>But how do oracle identifies dabase is abnormally down and crash recovery is required?
    I think that the checkpoint information that is desynchronized in redo log files and datafiles. It is necessary understand what is a checkpoint and what the CKPT process do. A checkpoint is a moment in time when all the changes (dirty blocks) made in the database buffer cache are made to the data files. The checkpoint is performed by the CKPT process and it creates an entry in the control file to identify the point in the online redo log file from where the instance recovery should begin in case of an instance failure. One of the ways a checkpoint is initiated is by the data block writer (DBWR) process. The DBWR process initiates a checkpoint by writing all modified data blocks in the data buffers (dirty buffers) to the data files. After a checkpoint is performed, all committed transactions are written to the data files. If the instance were to crash at this point, only new transactions that occurred after this checkpoint would need to be applied to the database to enable a complete recovery. Therefore, the checkpoint process determines which transactions from the redo logs need to be applied to the database in the event of a failure and subsequent recovery.
    Cheers

Maybe you are looking for