redo log
cmn, November 27, 2015 - 11:22 am UTC
yes ,yes, you are right !!!
i am very interest that If there are missing redo logs then you should restore from backup, causing loss of data,
How can I carry out a test for that ? Destructive testing.
can you show me a exaplam ? or tell me how can i do .
November 27, 2015 - 2:07 pm UTC
Just run the database for a while, making enough changes to reuse the redo logs. Kill it by pulling the power or similar. When you start it up again it'll ask you for redo logs that don't exist.
See the MOS note in the answer.
Make sure you have a backup before you do this!
noarchivelog , Destructive testing
cmn, November 27, 2015 - 11:32 am UTC
I mean that how i destructive data at noarchivelog mode ?
what log file that i can see ? alter.log ?
thanks!
November 27, 2015 - 2:09 pm UTC
Not sure what you mean? If you're running in noarchivelog, then when you restart after failure you can have missing redo logs. Therefore you have to restore from your last backup, losing any modifications made after this.
noarchivelog , Destructive testing
cmn, November 28, 2015 - 5:21 pm UTC
Thank for your patiently answer.
But I tried: update a big table,sure that switch a lots of redo log. restart DB after showdown the computer,not asking for me about
redo log .
But I can see something in alter.log that some blocks need to redo .
I want to know how it will be lost data in noarchivelog mode. Then I can avoid it。
I hope that you show a test 。thank you，thank you very much!!!
November 30, 2015 - 3:25 am UTC
Do select * from v$log_member to get the redo log files.
Then start a job running to update rows on your database.
Then remove those files
Restart your database.
You forget Checkpoints
Hemant K Chitale, December 02, 2015 - 3:14 am UTC
You forget that Oracle does Checkpoints.
As Oracle starts cycling through the 3 online redo logs, it does checkpoints. These mean that changes (and these include both the table and the undo) are flushed to the database files.
At instance recovery from a shutdown abort, Oracle needs to roll-forward redo only since the last completed checkpoint. This may well be within the last redo log only or it might have to go back one or two redo logs if those checkpoints hadn't been completed. (If checkpoint for all three redo logs hadn't completed, the database would have halted till the checkpoint for at least the oldest redo log was completed).
So, even 1GB of redo can be generated with 3x50MB of online redo logs in NOARCHIVELOG mode.
The rest of the discussion is about actual loss of the redo log files themselves.
Hemant
checkpoint
cmn, December 02, 2015 - 3:06 pm UTC
*Checkpoints*, yes ,I have forgot!
Yes ,checkpoint will be happened when switch redo log !!! so it never need the old redo log which already switch .
Thank your very much. I see.
But you refer that all redo log will checkpoint(maybe).
I am very interesting about that.
Can you tell me →how/when it will be happen ?
redo
cmn, December 02, 2015 - 3:29 pm UTC
So, when shudown abort .
Just read a litter redo log which (dirty data in cache ) no write to datafile by dbwr.
Yes or no ?
December 03, 2015 - 2:01 am UTC
WHen you shutdown abort, the datafiles may not precisely represent the true state of the data. But the redo logs contain enough information to correct them when the database is restarted. (Hence the term "instance recovery").
If you have not got those redo logs available...then you're facing data loss.
Crosscheck my understanding
Michael, December 03, 2015 - 10:23 am UTC
Chris, just for crosscheck
Dirty blocks are written to the datafiles with every checkpoint.
crash recovery:
+ commited transactions are redone USING THE ONLINE REDO LOGS
+ uncommited Transactions are rolled back OUT OF THE UNDO TABLESPACE
correct?
December 03, 2015 - 1:10 pm UTC
Not really. Because undo is just another datafile.
Its *all* about redo. The redo brings the datafiles back into alignment with "reality". At that point, your undo datafile(s) are not back in sync, and hence then we look for uncommitted transactions and roll them back.
Buts its all about the redo.
Checkpoints
Hemant K Chitale, December 03, 2015 - 3:24 pm UTC
A Checkpoint occurs at a log switch. However, it may happen that the Checkpoint begun at the log switch for redo log group#1 may not have completed before Oracle rolls through groupss# 2 and 3. So, in such cases, I explicitly issue an ALTER SYSTEM CHECKPOINT to allow Oracle to overwrite group#1. At that point, we can be sure that the old entries in group#1 are no longer required, even if there were to be SHUTDOWN ABORT.
Moreover, Oracle does periodic incremental checkpoints, advancing the RBA and checkpoint. So, in most cases, Instance Recovery after an Abort should not even need to read the whole of the online redo log group. It would need to apply redo only from the last checkpoint RBA.
As for undo, that is also captured in the redo. That is why Oracle can rollback after the rollforward, because the rollback information in the undo is also applied by the rollforward.
Hemant