oracle 11G: ALTER SYSTEM ARCHIVE LOG CURRENT is the best practi...: ALTER SYSTEM ARCHIVELOG CURRENT is the best practice for production backup scripts with RMAN. I must admit - today I learned new thing ab...
Wednesday, 12 June 2013
oracle 11G: ORA-01194: file 1 needs more recovery to be consis...
oracle 11G: ORA-01194: file 1 needs more recovery to be consis...: ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '...../system01.dbf' ORA-01547: warning: RECOV...
Cause: An incomplete recovery session was started, but an insufficient number
of redo logs were applied to make the file consistent.
The named file was not closed cleanly when it was last opened by the
database.
The most likely cause of this message is forgetting to restore the
file from a backup before doing incomplete recovery.
Action: The file must be recovered to a time when it was not being updated.
Either apply more redo logs until the file is consistent or restore
the file from an older backup and repeat recovery.
if you face this type of error , after appling all redo log and archive log successfuly.you can consider to setup "_allow_resetlogs_corruption" this undocumented parameter .
Explanation :
==========
Before thinking about the use of the undocumented parameter "_allow_resetlogs_corruption" all other avenues of database recovery must have been exhausted. Because this parameter forces the opening of the datafiles even if their SCNs do not match up. Then at the next checkpoint the old SCN values are over-written. This could leave the database in an unknown state as far as concurrency.
For that reason, you must export and rebuild your database after using belows recovery method Most of the time, this recovery method is required when a data file has been left in hot backup mode through several backup cycles without an intervening shutdown and startup. Upon shutdown and startup the database will complain that a file (usually file id#1 the SYSTEM tablespace) needs more recovery and asks for logs past all available archive logs and online logs.
An other scenario could be that the database is recovered from a hot backup and the above scenario occurs, or, the database asks for an archive log that is before any that are available (usually for the ROLLBACK segment tablespace datafiles.)
In the Course of doing this... you may come up with Issues
ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '..../system01.dbf'
or
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 12 needs more recovery to be consistent ORA-01110: data file 12: ..../data01.dbf'
If all available archive logs are applied and all available online redo logs applied and the error is not corrected, only then should use of the parameter "_allow_resetlogs_corruption" be considered. Make sure a good backup of the database in a closed state (all files) is taken before attempting recovery using "_allow_resetlogs_corruption".
Cause: An incomplete recovery session was started, but an insufficient number
of redo logs were applied to make the file consistent.
The named file was not closed cleanly when it was last opened by the
database.
The most likely cause of this message is forgetting to restore the
file from a backup before doing incomplete recovery.
Action: The file must be recovered to a time when it was not being updated.
Either apply more redo logs until the file is consistent or restore
the file from an older backup and repeat recovery.
if you face this type of error , after appling all redo log and archive log successfuly.you can consider to setup "_allow_resetlogs_corruption" this undocumented parameter .
Explanation :
==========
Before thinking about the use of the undocumented parameter "_allow_resetlogs_corruption" all other avenues of database recovery must have been exhausted. Because this parameter forces the opening of the datafiles even if their SCNs do not match up. Then at the next checkpoint the old SCN values are over-written. This could leave the database in an unknown state as far as concurrency.
For that reason, you must export and rebuild your database after using belows recovery method Most of the time, this recovery method is required when a data file has been left in hot backup mode through several backup cycles without an intervening shutdown and startup. Upon shutdown and startup the database will complain that a file (usually file id#1 the SYSTEM tablespace) needs more recovery and asks for logs past all available archive logs and online logs.
An other scenario could be that the database is recovered from a hot backup and the above scenario occurs, or, the database asks for an archive log that is before any that are available (usually for the ROLLBACK segment tablespace datafiles.)
In the Course of doing this... you may come up with Issues
ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '..../system01.dbf'
or
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 12 needs more recovery to be consistent ORA-01110: data file 12: ..../data01.dbf'
If all available archive logs are applied and all available online redo logs applied and the error is not corrected, only then should use of the parameter "_allow_resetlogs_corruption" be considered. Make sure a good backup of the database in a closed state (all files) is taken before attempting recovery using "_allow_resetlogs_corruption".
example:-
1) Do a "SHUTDOWN NORMAL" of the database
2) Set/Add the below parameter in pfile like
_allow_resetlogs_corruption = true
3) Do a "STARTUP MOUNT pfile='pfile_location_name' " and "ALTER DATABASE OPEN RESETLOGS;"
4) If the database asks for recovery, use an UNTIL CANCEL type recovery and apply all available archive and on-line redo logs, then issue CANCEL and reissue the "ALTER DATABASE OPEN RESETLOGS;" command. like below..
SQL > recover database until cancel;
( if ask recovery for something issue CANCEL)
then
SQL> ALTER DATABASE OPEN RESETLOGS;
5) Wait a couple of minutes for Oracle to sort itself out
6) Do a "SHUTDOWN NORMAL"
7) Remove the above parameter . (if pfile use)
8) Do a database "STARTUP" and check your ALERT.LOG file for errors.
9) export (successful exp) the data and rebuild (create a new db) the entire database for error free Database .
1) Do a "SHUTDOWN NORMAL" of the database
2) Set/Add the below parameter in pfile like
_allow_resetlogs_corruption = true
3) Do a "STARTUP MOUNT pfile='pfile_location_name' " and "ALTER DATABASE OPEN RESETLOGS;"
4) If the database asks for recovery, use an UNTIL CANCEL type recovery and apply all available archive and on-line redo logs, then issue CANCEL and reissue the "ALTER DATABASE OPEN RESETLOGS;" command. like below..
SQL > recover database until cancel;
( if ask recovery for something issue CANCEL)
then
SQL> ALTER DATABASE OPEN RESETLOGS;
5) Wait a couple of minutes for Oracle to sort itself out
6) Do a "SHUTDOWN NORMAL"
7) Remove the above parameter . (if pfile use)
8) Do a database "STARTUP" and check your ALERT.LOG file for errors.
9) export (successful exp) the data and rebuild (create a new db) the entire database for error free Database .
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.
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.
Monday, 3 June 2013
ORA-30079: cannot alter database timezone when database has TIMESTAMP WITH LOCAL TIME ZONE columns
ORA-30079: cannot alter database timezone when database has TIMESTAMP WITH
LOCAL TIME ZONE columns
SQL> SELECT DBTIMEZONE FROM DUAL;
DBTIME
------
+00:00
SQL> conn / as sysdba
Connected.
SQL> alter database set time_zone='EST';
alter database set time_zone='EST'
*
ERROR at line 1:
ORA-30079: cannot alter database timezone when database has TIMESTAMP WITH
LOCAL TIME ZONE columns
SQL> alter table OE.ORDERS drop column ORDER_DATE ;
Table altered.
SQL> alter database set time_zone='EST';
Database altered.
LOCAL TIME ZONE columns
SQL> SELECT DBTIMEZONE FROM DUAL;
DBTIME
------
+00:00
SQL> conn / as sysdba
Connected.
SQL> alter database set time_zone='EST';
alter database set time_zone='EST'
*
ERROR at line 1:
ORA-30079: cannot alter database timezone when database has TIMESTAMP WITH
LOCAL TIME ZONE columns
SQL> alter table OE.ORDERS drop column ORDER_DATE ;
Table altered.
SQL> alter database set time_zone='EST';
Database altered.
Subscribe to:
Posts (Atom)