Oracle Database Discussions

Hi,

Well, you can do something similar, if before making the backup you perform:

ALTER SYSTEM SWITCH LOGFILE;

Regards,

Mario Alcaide

http://marioalcaide.wordpress.com

Because they won't be in a read consistent state for use in a restore. You should at least run an 'ALTER SYSTEM ARCHIVE LOG CURRENT' to write the current redo records to an archive log prior to the backup in order to backup the maximum amount of data changes.

you dont need it because redolog log file change . redolog file cirrcular. for example redologfile change every 30 min.

last night 3am I did my backup log sequence number is 121
now 1pm log sequence number 141

redologfile only contain at the moment 139 140 141.

you had backup 121 than you had archivelog 122 123 124.....140 and you use last current redo 141..

archivelog means copy of redologfile

regards

Zekeriya besiroglu

I agree that redologs keep increasing but isn't it the case we can recover atleast until that point of time if we have the backup of redologs.

Contents of redo logs which you have already got from the current/active redo log file. Archive logs are the offline copies of redo logs so for any point in time recovery you need FULL backup of datafiles + archive logs till that point.

Regards
Asif Kabir

An Archivelog is a Redolog. What people call redolog is "ONLINE Redo Log'.

An ArchiveLog is a closed file.

An Online Redo Log is in "flux" when it is being written to by LGWR. An OS copy of it cannot get a consistent image of it. Oracle handles the risk of fractured blocks in datafiles with the ALTER TABLESPACE/DATABASE BEGIN BACKUP command that marks a file as being in backup mode. There is no such method to mark an Online Redo Log file.

Say your Online Redo Log is 500MB in size.
At time t1, your OS level "cp" command starts reading the file.
At time t4, LGWR starts writing to it.
Between t1 and t4, the "cp" command has copied out blocks from the file as of the last SEQ# that had ben assigned to it. After t4, from block 0 onwards, LGWR keeps overwriting information with the redo -- change vectors -- as are for transactions from this point (t4) which is a new SEQ#.

If you were to attempt to use that copy of the Redo Log file it would be corrupt as the head and first 'N' blocks are as of an older SEQ# while subsequent blocks are as of a latter SEQ# !


Now, you might say that you would *lock* the file before copying it out. If you lock the file, LGWR would fail when attempting to write to it and the database instance would crash.

Hemant K Chitale
http://hemantoracledba.blogspot.com

Thanks a lot everyone!