Wednesday 12 June 2013

ALTER SYSTEM ARCHIVE LOG CURRENT is the best practice for production backup scripts with RMAN.(RMAN-06054,ORA-00279,ORA-00289)

ALTER SYSTEM ARCHIVE LOG CURRENT is the best practice for production backup scripts with RMAN. alter system archive log current

I must admit - today I learned new thing about RMAN restore and this is good enough reason for a blog post.


channel c1: reading from backup piece /var/otp/fullbkp_dir/ARCH_OTP_20101117_0tlt6lum_s8221_p1
channel c1: restored backup piece 1
failover to piece handle=/oracle/backup/ARCH_OTP_20101117_0tlt6lum_s8221_p1 tag=ARCHIVELOGS
channel c1: restore complete, elapsed time: 00:11:44
archive log filename=/oracle/oradata/archive/arch_1_33610_586538926.arc thread=1 sequence=33610
unable to find archive log
archive log thread=1 sequence=33611
released channel: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 11/18/2010 10:50:16
RMAN-06054: media recovery requesting unknown log: thread 1 seq 33611 lowscn 48852472202
RMAN> exit


$ sqlplus "/as sysdba"

SQL> recover database using backup controlfile until cancel;
ORA-00279: change 48852472202 generated at 11/17/2010 01:54:16 needed for
thread 1
ORA-00289: suggestion :
/oracle/oradata/archive/arch_1_33611_586538926.arc
ORA-00280: change 48852472202 for thread 1 is in sequence #33611

Specify log: {<ret>=suggested | filename | AUTO | CANCEL}
CANCEL
Media recovery cancelled.

This sitation will raise at the time of recover database .

Reason 1.
ALTER SYSTEM SWITCH LOGFILE command is using for production backup scripts with RMAN Backup.


Reason 2.

If we start a RESTORE database with a BACKUP controlfile and Flash Recovery Area is defined, RMAN execute and implicit crosscheck and catalog of all the objects in the Flash Recovery Area.


I will be explain briefly regarding reason 1

both ALTER SYSTEM SWITCH LOGFILE and ALTER SYSTEM ARCHIVE LOG CURRENT will force a log switch, but they do it in different ways!   

Both the SWITCH LOGFILE and ARCHIVE LOG CURRENT write a quiesce checkpoint, a firm place whereby that last redo log is a part of the hot backup, but ARCHIVE LOG CURRENT waits for the writing to complete.  This can take several minutes for multi-gigabyte redo logs.  

Conversely, the ALTER SYSTEM SWITCH LOGFILE command is very fast and returns control to the caller in less than a second while ALTER SYSTEM ARCHIVE LOG CURRENT pauses.  

As we see below, the ALTER SYSTEM SWITCH LOGFILE is fast because it does not wait for the archiver process (ARCH) to complete writing the online redo log to the archivelog log filesystem:

It issues database checkpoint
 It immediately starts writing to the next redo log
 In the background, the “switch logfile” command tells the ARCH background process to copy the “old” redo log file to the redo log filesystem.  


 ALTER SYSTEM  SWITCH LOGFILE
 asynchronous . This command is fast to return to the invoking program because the writing of the redo log to the OS filesystem is done in the background.  There is a very small risk in cases where the ARCH process cannot complete writing the redo log, such as cases where the OS archivelog file directory is out of space.  It is also risky because the calling script may move on to a subsequent step, assuming that the redo has been written.  Some scripts will place a SLEEP 60 command in their backup script to allow time for the redo to complete writing, but this is not a best practice.  



 ALTER SYSTEM ARCHIVE LOG CURRENT
 synchronous.  This is faster to return because this command waits until the online redo log has completed the writing of the redo log file to the filesystem.  This command is safer because it waits for the OS to acknowledge (ACK) that the redo log has been successfully written.  Hence, ALTER SYSTEM ARCHIVE LOG CURRENT is the best practice for production backup scripts with RMAN.



  RAC:  If you are running RAC, the ALTER SYSTEM ARCHIVE LOG CURRENT will switch the logs on all RAC nodes (instances), whereas ALTER SYSTEM SWITCH LOGFILE will only switch he logfile on the instance where you issue the switch command.  Hence, ALTER SYSTEM ARCHIVE LOG CURRENT is a best practice for RAC systems.


The ALTER SYSTEM ARCHIVE LOG CURRENT allows you to specify the thread to archive while the ALTER SYSTEM SWITCH LOGFILE archives only the current thread.  If you do not pass the thread parameter, Oracle will archive all full online redo logs. 




10 comments:

  1. Dear sir,
    could i ask u about the following case
    server1: i have incremental backups and full bkps taken with rman i did take the backup pieces and put them on server2 and i then i had created a database in archivelog to restore inside it the backup pieces then i got the previous error and when i tried ur solution cancel the db tolds me that
    ORA-01194: file 3 needs more recovery to be consistent
    ORA-01110: data file 3: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\GEOX\SYSAUX01.DBF'

    what can i do plz?

    ReplyDelete
    Replies
    1. Thanks Ahamad

      Would you please follow my post
      http://bashokan77.blogspot.in/2013/06/oracle-11g-ora-01194-file-1-needs-more.html

      if you have any doubt then plz comment

      Delete
    2. use set until time "to_date('04/12/2021 10:30:00','MM/DD/YYYY HH24:MI:SS')"; in your recovery script.

      sample:
      run
      {
      ALLOCATE AUXILIARY CHANNEL 'dup1' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup2' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup3' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup4' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup5' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup6' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup11' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup21' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup31' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup41' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup51' TYPE DISK;
      ALLOCATE AUXILIARY CHANNEL 'dup61' TYPE DISK;
      set until time "to_date('04/12/2021 10:30:00','MM/DD/YYYY HH24:MI:SS')";
      duplicate database to 'sblppxx' backup location '/u191/bkp/sblppxxx/rman';
      }

      Delete
  2. knowing well that i should copy the redo log files i dnt now why and i should change the DBID which does not make sense

    ReplyDelete
    Replies

    1. well ahamed

      Change the dbid to match that of the database being restored

      Delete

    2. There are many ways to restore a database using an RMAN backup - this example assumes you are performing a Disaster-Recovery restore of all data and recovering the entire database with the same SID and the same disk/tablespace layout.
      You will need the following information:
      Database SID: ________
      Database SYS password: ________
      Disk layout and sizes: ________
      Database ID (DBID): ________

      Delete
  3. note: i am working on oracle 10G
    could u please answer me on my personal email??
    ahmed.kamal8383@gmail.com
    or can we do the steps one by one?

    ReplyDelete
    Replies
    1. Can you follow my new post for you
      in oracle 10g have almost same steps.


      http://bashokan77.blogspot.in/2013/07/oracle-11g-rman-restore-example.html

      Delete
  4. ##################
    HI CAN U EXPLAIN VRIEF WITH AN EXAMPLE IN 11GR2 ### TO SPECIFY THREAD

    The ALTER SYSTEM ARCHIVE LOG CURRENT allows you to specify the thread to archive while the ALTER SYSTEM SWITCH LOGFILE archives only the current thread. If you do not pass the thread parameter, Oracle will archive all full online redo logs.

    ReplyDelete
  5. Hello Ashokan
    I've a question related, not entirely adhering to your topic title. I have a 450+ GB database (11gR2 11.2.0.4) & using RMAN I am planning to take a cold backup
    run
    {
    shutdown immediate;
    startup mount;
    backup database;
    }

    I want to restore this backup to a new server for some TESTING insuring all the last moment transactions are available with the backup.
    I am not a DBA, a developer who could handle an instance with moderate skills and so far from the Oracle documents, I have acquired the following:

    Should I do a media recovery when restoring from a cold backup? If yes, why?

    regards,

    rajesh

    ReplyDelete