In that case your redo will be over written and if the db crashes at that point you would get the error 'tablespace_name needs recovery' and ask you for the archivelog file :)
Printable View
In that case your redo will be over written and if the db crashes at that point you would get the error 'tablespace_name needs recovery' and ask you for the archivelog file :)
But my database is in NOARCHIVELOG mode so I can't recover and that can't be the case.
The checkpoint not complete only indicated that the CKPT process hasn't finished updateing the datafile and controlfile headers it as far as I am aware hasn't anything to do with this issue.
Thanks for your continued interest in this.
A
The entire checkpointing process is a collaboration between CKPT and DBWR - "checkpoint not complete" will cause any changes to hang, it will carry on flushing dirty buffers utill the redolog can be overwritten (and normal business resumes).Quote:
Originally posted by alison
The checkpoint not complete only indicated that the CKPT process hasn't finished updateing the datafile and controlfile headers it as far as I am aware hasn't anything to do with this issue.
(To quote Tom Kyte - "[CKPT] . . . . doesn't do a checkpoint (that's mostly the job of DBWn)").
Yes I see what you mean.
However the fact that the checkpoint is complete is not really what I'm asking.
Lets say that the checkpoint is complete, DBWR has written dirty blocks to disk (both data and RBS) it's what happens in the event of an instance failure that I'm confused about.
Lets take this scenario - 2 redo log groups
Group 1 - LS# 100 - transaction 1 begins.
More transaction go on some committed some not - T1 still uncommitted
Group 2 - LS# 101 yet more transaction T1 still not committed, checkpoint for group 1 complete dirty blocks written to disk.
Group 1 - LS# 102 yet more transactions T1 not committed.
Log sequence 100 holds information regarding T1 but has now been overwritten by sequence no 102.
Instance crashes, how does T1 roll back, both datablock and rollback block information gone - keeping in mind that I am in NOARCHIVELOG mode.
Hope this clears up the question, thanks for your continued interest
A
Quote:
Originally posted by adewri
In that case your redo will be over written and if the db crashes at that point you would get the error 'tablespace_name needs recovery' and ask you for the archivelog file :)
But in that case my database will not be able to be started, I have no archivelogs and therefore can't recover the tablespace to the current point in time.
Surely Oracle will never allow this to happen, the result of that will be a broken database with no option but to go back to the last backup?
How can that be the case?
Well i'm sorry to say that it is the case...
Thats why its recommended to keep DB in archive log mode...
In such a case only option will be...
1. put _allow_resetlogs_corruption=true in init parameter file.
2. recreate the control files.
3. open database with resetlogs.
But this will give you a very inconsistent database.
HTH
Exactly - it's not the question, it's the answer!Quote:
Originally posted by alison
However the fact that the checkpoint is complete is not really what I'm asking.
In context of instance recovery, the redologs are there to allow DBWR to run asynchronously - but it can not be allowed to get too far behind. (Ignoring questions of media recovery, you could imagine running DBWR in a synchronous mode and not having any redologs.)
In your example, when LS#102 tries to use Group1 everything stops until the changes in LS#100 have gone to disk: both data and rollback. So you no longer need LS#100 to rollback T1 - what you need is in the RBS on disk, except for (perhaps) changes in LS#101 (and then LS#102).
(Amar - I don't think you're right on this one.)
I can't disagree with that ! ! ! ! :)Quote:
Originally posted by adewri
its recommended to keep DB in archive log mode...
DaPi
Thanks it's getting a little clearer.
I see that all the information that I need to roll back the transaction is now on disk, but what tells SMON (or the Server Process) to roll it back, it is no longer covered by any redo log, therefore how does Oracle know that it is uncommitted?
Where is that information stored if not in the Redo Log's
Cheers
A