This content has been marked as final. Show 6 replies
That only means currently there are no ACTIVE (not yet backed up) archivelogs in the archivelog destination(s). No backups are checked here.
Thanks Werner..This means that it is just a message.
One more question related to Archive Log backups -
traditionally DBAs used to take backup of an Archivelog by spupplying "alter system archive log current" before taking the backup. somewhat like -
allocate channel t1 device type 'sbt_tape' PARMS="ENV=(TDPO_OPTFILE=/oracle/TESTDB/tdpo.opt)";
sql 'alter system archive log current';
backup archivelog all delete input;
release channel t1;
But, since RMAN automatically archives CURRENT redo log at the start of the archivelog backup, do we REALLY need to pass sql 'alter system archive log current'; before starting the archivelog backup in the script?
RMAN> backup archivelog all;
Starting backup at 11-MAR-10
current log archived ===========> RMAN automatically archived the CURRENT redo log
released channel: ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
related question to this is - Since it generates one archived log everytime it takes the archived log backup, this backup may get hung if the archived destination is 100% full. Is there any way we can take the archive log backup without generating an extra archived log before the start of the backup?
You are right the 'alter system archive log current' command is not necessary,although you still find it in many scripts. I think it's a relic from the times,when we made manual backups. That's the official definition:
When taking a backup of archived redo logs that includes the most recent log (that is, a BACKUP ... ARCHIVELOG command is run without the UNTIL or SEQUENCE option) if the database is open, then before beginning the backup, RMAN will switch out of the current online redo log group, and all online redo logs that have not yet been archived, up to and including the redo log group that was current when the command was issued. This ensures that the backup contains all redo that was generated prior to the start of the command.
'Backup archivelog all' without the mentioned options means always a COMPLETE backup, as said in the definition the backup has to contain all redo generated before the start of the command. The reason is backup consistency. So you cannot avoid the log switch,otherwise you wouldn't get a backup of the current online log.
'Backup archivelog all' in mount state will not trigger a log switch (because it's simply not possible),the same is true for any UNTIL option.
But in 'normal business' you always have a log switch.
Thanks for the explanation
Is works best for the COMPLETE backup if we archive the CURRENT redo log
BUT Suppose my archivelog destination is 100% full and I don't have any space where I can move the archived logs, I will be left with no option if RMAN automatically archives the CURRENT log before running the backup as there will be no space in archivelog destination and due to it whole database can be in hung state. Can we bypass this default behaviour of auto archiving of CURRENT online redo log by RMAN before taking the backup. This was although the backup won't be COMPLETE but atleast the backup will be able to run and database can be be saved from getting hung.
Your thought please :-)
Secondly, while running the Archive log backup, oracle creates an archived log for CURRENT online redo log BUT While shutting down the database, Oracle doesn't create any Archived log for CURRENT online redo log
Is it because Oracle moves all the data from DB Cache and CURRENT online Redo log file to DataFiles once we shutdown the database and since it's already there in the DataFiles there is no need of archiving the CURRENT redo log file.
OK, with some simple test, I got my answer to this point.
Actually RMAN is quite smart and it takes the complete backup of archivelogs by archiving the CURRENT redo log IF there is space on the archive log destination and if the destication is 100% full then it will do an incomplete backup by not archiving the CURRENT redo log. This is what I was looking for. One thing is sure in both the cases, we don't need to issue sql 'alter system archive log current'; before taking the archive log backup.