Unusable redo log

When trying to startup the database
ORA-00314 error message occures
that is the online log is corrupted or is an old version.
Do I have to recover the database from backup
in such a case? I have no other copy of redo log files,
they are just mirrored on disk array.

Hi,
>>there another way than having to recover database from backups.
Maybe ...
Firstly, make a backup of your database files before to try any recover operation.
1) Your database was consistent before this error ? Have you tried re-create your controlfiles with RESETLOGS option ?
2) Maybe using _allow_resetlogs_corruption forces the opening of the datafiles even if their SCNs do not match up; then, on the next checkpoint, the old SCN values are overwritten. This could leave the database in an unknown state as far as concurrency.
Take a look on these links below:
http://orafaq.com/parms/parm36.htm
http://www.sidibe.net/allow_resetlog.html
Cheers

Similar Messages

Delete old and unused Archived Redo Log Files

Hello forum!
My db was in ARCHIVELOG mode and It created 9GB of archived redo log files.
Now I put the db in NOARCHIVELOG mode, can I delete all the ARLF? am I sure that the DB never need those files in the future?
If yes, how can I delete them? I will use 'del' operative system command?
In addition, I found this command:
SQL>alter database open resetlogs;
is it useful for my purpose?
thank you!

You are safe to remove those archivelog files if you altered your database to no archive log mode. Just remove them from OS level
Please bear in mind that database in no archivelog mode will lost data in the event of disaster.
SQL>alter database open resetlogs;Doesn't help in your situation, it's use to bring up database after incomplete recovery.

Online redo log files being removed physically

Grid Infra version: 11.2.0.4
RDBMS Version: 11.2.0.4
Although this is a RAC DB, this is not a RAC-specific question. Hence posting it here.
Few months back, I remember issuing a command similair to below (DROP LOGFILE GROUP ...) and the redo log files were still physically present in the diskgroup.
If I remember correctly, the file is not deleted physical so that we can use the REUSE functionality (ALTER DATABASE ADD LOGFILE MEMBER '+REDO/orcl/onlinelog/redo1b.log' reuse to group 11; ) ie. you can use the REUSE command to add the logfile of the same name which is physically present in OS Filesystem/Diksgroup to redo log group.
But today, after I issued the below command, I checked the diskgroup location from ASMCMD
SQL> alter database drop logfile group 31;
Database altered.
From ASMCMD, I can that the file has disappeared physically. Is this a new feature with 11.2.0.4 or am I missing something here ?
ASMCMD> ls +DATA/msblprd/onlinelog/group_31.548.833154995
ASMCMD-8002: entry 'group_31.548.833154995' does not exist in directory '+DATA/msblprd/onlinelog/'

Just to add to what Aman has said.
It is a bad practice not to let OMF decide the placement of Online redo logs because of this issue especially when you use ASM.
Executing rm command in Linux/Unix is easy but Dropping ASM aliases in the disk group can be a hassle.
This is documented.
"When a redo log member is dropped from the database, the operating system file is not deleted from disk. Rather, the control files of the associated database are updated to drop the member from the database structure. After dropping a redo log file, ensure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log file."
http://docs.oracle.com/cd/E11882_01/server.112/e25494/onlineredo.htm#ADMIN11324
BTW . You don't even need to set db_create_online_log_dest_n to enable OMF for ORLs.
SQL> show parameter log_dest
NAME                                 TYPE        VALUE
db_create_online_log_dest_1          string
db_create_online_log_dest_2          string
db_create_online_log_dest_3          string
db_create_online_log_dest_4          string
db_create_online_log_dest_5          string
SQL> show parameter db_create_file_dest
NAME                                 TYPE        VALUE
db_create_file_dest                  string      +MBL_DATA
alter database add logfile thread 4
group 31 ('+MBL_DATA','+MBL_FRA') size 4096M,
group 32 ('+MBL_DATA','+MBL_FRA') size 4096M,
group 33 ('+MBL_DATA','+MBL_FRA') size 4096M,
group 34 ('+MBL_DATA','+MBL_FRA') size 4096M ;
Database altered.
And redo logs will be neatly placed as shown below
   INST     GROUP# MEMBER                                             STATUS           ARC
         4         31 +MBL_DATA/bsblprd/onlinelog/group_31.276.832605441 UNUSED           YES
                      +MBL_FRA/bsblprd/onlinelog/group_31.297.832605445 UNUSED           YES
                   32 +MBL_DATA/bsblprd/onlinelog/group_32.547.832605451 UNUSED           YES
                      +MBL_FRA/bsblprd/onlinelog/group_32.372.832605457 UNUSED           YES
                   33 +MBL_DATA/bsblprd/onlinelog/group_33.548.832605463 UNUSED           YES
                      +MBL_FRA/bsblprd/onlinelog/group_33.284.832605469 UNUSED           YES
                   34 +MBL_DATA/bsblprd/onlinelog/group_34.549.832605475 UNUSED           YES
                      +MBL_FRA/bsblprd/onlinelog/group_34.359.832605481 UNUSED           YES

Redo log tuning - improving insert rate

Dear experts!
We've an OLTP system which produces large amount of data. After each record written to our 11.2 database (standard edition) a commit is performed (the system architecture can't be changed - for example to commit every 10th record).
So how can we speed up the insert process? As the database in front of the system gets "mirrored" to our datawarehouse system it is running in NOARCHIVE mode. I've already tried placing the redo log files on SSD disks which speeded up the insert process.
Another idea is putting the table on a seperate tablespace with NOLOGGING option. What do you think about this?
Further more I heard about tuning the redo latches parameter. Does anyone have information about this way?
I would be grateful for any information!
Thanks
Markus

We've an OLTP system which produces large amount of data. After each record written to our 11.2 database (standard edition) a commit is >>performed (the system architecture can't be changed - for example to commit every 10th record).Doing commit after each insert (or other DML command) doesn't means that dbwriter process is actually writing this data immediately in db files.
DBWriter process is using an internal algorithm to decide where to apply changes to db files. You can adjust the writing frequency into db files by using "fast_start_mttr_target" parameter.
So how can we speed up the insert process? As the database in front of the system gets "mirrored" to our datawarehouse system it is running >>in NOARCHIVE mode. I've already tried placing the redo log files on SSD disks which speeded up the insert process.Placing the redo log files on SSD disks is indeed a good action. Also you can check buffer cache hit rate and size. Also stripping for filesystems where redo files resides should be taken into account.
Another idea is putting the table on a seperate tablespace with NOLOGGING option. What do you think about this?It's an extremely bad idea. NOLOGGING option for a tablespace will lead to an unrecovearble tablespace and as I stated on first sentence will not increase the insert speed.
Further more I heard about tuning the redo latches parameter. Does anyone have information about this way?I don't think you need this.
Better check indexes associated with tables where you insert data. Are they analyzed regularly, are all of them used indeed (many indexes are created for some queries but after a while they are left unused but at each DML all indexes are updated as well).

Reg:Redo log files

Hi,
By mistake the redo log files have been removed.
Hence we tried to create the redo log files.
After creating it when select * from v$log is done, it is as follows
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
FIRST_CHANGE# FIRST_TIM
1 1 0 1073741824 1 YES UNUSED
0
3 1 0 1073741824 1 YES UNUSED
0
2 1 0 1073741824 1 NO CURRENT
179433372 20-NOV-10
Due to this, whatever alter command we use, it is not working.
For ex.
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/alcatel/oracle/oradata/SNM/system01.dbf'
SQL> alter database mount;
alter database mount
ERROR at line 1:
ORA-01100: database already mounted
SQL> alter system switch logfile;
alter system switch logfile
ERROR at line 1:
ORA-01109: database not open
SQL> ALTER DATABASE OPEN;
ALTER DATABASE OPEN
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
WE want to change the status in v$log table from Current to ACTIVE and UNUSED to INACTIVE.
How can we do that?
Can anyone help us?
Regards
Srini

Hi ,
WE have tried those but in vain..
Please find the error logs
SQL> alter system switch logfile;
alter system switch logfile
ERROR at line 1:
ORA-01109: database not open
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/alcatel/oracle/oradata/SNM/system01.dbf'
SQL> ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/alcatel/oracle/oradata/SNM/system01.dbf'SP2-0734: unknown command beginning "ORA-01194:..." - rest of line ignored.
SQL> ^C
SQL> recover database until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/alcatel/oracle/oradata/SNM/system01.dbf'
SQL> recover database until cancel using backup controlfile;
ORA-00279: change 179433372 generated at 11/20/2010 18:00:10 needed for thread
1
ORA-00289: suggestion : /alcatel/oracle/admin/SNM/arch/arch_1_635_666206692.arc
ORA-00280: change 179433372 for thread 1 is in sequence #635
Srini

Need to drop a current redo log on a Standby

Oracle 11.2.0.2
I have 3 redo logs on a newly created Standby database.
SQL> SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;
GROUP# ARC STATUS
1 YES UNUSED
3 NO CURRENT
2 YES UNUSED
The redo log in Group 3 needs to be dropped and recreated. How can I force a log switch on a Standby in mount mode?
SQL> alter database drop logfile group 3;
alter database drop logfile group 3
ERROR at line 1:
ORA-01623: log 3 is current log for instance ufms216 (thread 1) - cannot drop
ORA-00312: online log 3 thread 1: '/path/redo03.dbf'
SQL> alter system switch logfile;
alter system switch logfile
ERROR at line 1:
ORA-01109: database not open
Please help !!!
Thanks!
Dave

SAME ERROR/SITUATION
SQL> startup mount
ORACLE instance started.
Total System Global Area 1.2527E+10 bytes
Fixed Size 2231240 bytes
Variable Size 3657434168 bytes
Database Buffers 8858370048 bytes
Redo Buffers 8691712 bytes
Database mounted.
SQL> SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;
GROUP# ARC STATUS
1 YES UNUSED
3 NO CURRENT
2 YES UNUSED
SQL> alter database drop logfile group 3;
alter database drop logfile group 3
ERROR at line 1:
ORA-01623: log 3 is current log for instance ufms216 (thread 1) - cannot drop
ORA-00312: online log 3 thread 1: '/a0253/d01/oradata/ufms216/redo03.dbf'
SQL> alter system switch logfile;
alter system switch logfile
ERROR at line 1:
ORA-01109: database not open
SQL> alter database recover managed standby database cancel;
alter database recover managed standby database cancel
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
SQL>
HELP!

How to recover from corrupt redo log file in non-archived 10g db

Hello Friends,
I don't know much about recovering databases. I have a 10.2.0.2 database with corrupt redo file and I am getting following error on startup. (db is non archived and no backup) Thanks very much for any help.
Database mounted.
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 6464 change 9979452011066 time 06/27/2009
15:46:47
ORA-00312: online log 1 thread 1: '/dbfiles/data_files/log3.dbf'
====
SQL> select Group#,members,status from v$log;
GROUP# MEMBERS STATUS
1 1 CURRENT
3 1 UNUSED
2 1 INACTIVE
==
I have tried this so far but no luck
I have tried following commands but no help.
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;
Database altered.
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-01139: RESETLOGS option only valid after an incomplete database recovery
SQL> alter database open;
alter database open
ERROR at line 1:
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 6464 change 9979452011066 time 06/27/2009
15:46:47
ORA-00312: online log 1 thread 1: '/dbfiles/data_files/log3.dbf'

user652965 wrote:
Thanks very much for your help guys. I appreciate it. unfortunately none of these commands worked for me. I kept getting error on clearing logs that redo log is needed to perform recovery so it can't be cleared. So I ended up restoring from earlier snapshot of my db volume. Database is now open.
Thanks again for your input.And now, as a follow-up, at a minimum you should make sure that all redo log groups have at least 3 members. Then, if you lose a single redo log file, all you have to do is shutdown the db and copy one of the good members (of the same group as the lost member) over the lost member.
And as an additional follow-up, if you value your data you will run in archivelog mode and take regular backups of the database and archivelogs. If you fail to do this you are saying that your data is not worth saving.

Get ORA-00368: checksum error in redo log block

Hi all,
I get an error ORA-00368: checksum error in redo log block when connecting to database and here is the error:
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 430757 change 1236507302 time 11/12/2009
09:55:35
ORA-00312: online log 4 thread 1: '/oradata02/tchad/redo4.log'
Note that we are in noarchive log mode.
Could you help on how to recover my database please or a doc if there is interesting somewhere.
Thank you
Lucienot

Hi I don't have redo log duplex and here are the things i've done:
1.     shutdown abort
2.     ALTER DATABASE CLEAR UNARCHIVED LOGFILE '/oradata/.../redo3.log';
3.     startup nomount;
4.     alter database mount;
5.     ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 4;
SQL> SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;
GROUP# ARC STATUS
3 NO ACTIVE
4 NO CURRENT
5 NO UNUSED
SQL> alter system switch logfile;
alter system switch logfile
ERROR at line 1:
ORA-01109: database not open
SQL> alter database open;
alter database open
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oradata00/tchad/system01.dbf'
Thanks

Redo log file corupted, database not getting open

I am Oracle Funda-1 student.
Have install standard Oracle 9I on Windows XP pro service pack 2.
I made some changes in sample table & given commit. So log buffer will flush to redo log file.
Then I open current redo log file from OS & selected all junk characters [select all] & deleted same. Save the file. Causing redo file size 0KB.
Then made more changes to table & issue commit. no errors ! every thing working file.
Even chked V$log & V$logfile.
Again I open current redo log file from OS & selected all junk characters [ select all ] & deleted same. Save the file. Causing redo file size 0KB.
Then issue manual log switch. Alter system switch logfile
I got disconnected from database & database was close.
When I reconnected & try to open database in normal mode. Gave error saying redolog_1.log is corrupted & needed for recovery.
Now not even allowing me clear redo group 1. with alter database clear logfile group 1. as database is not coming to open stage.
just able to mount the database. with error rdolog_1 corrupted.
Wasn't oracle suppose to be halted when very 1st time I corrupted redo log file.
Why it disconnected me & got close.
When then one use alter database clear logfile group 1.

I may try this ALTER DATABASE OPEN RESETLOGS;
As no backup & not multiplex.
Still looking for explanation why database got close down instead of getting halt.
I have found one more status in V$log, which is not given in Oracle university book or online document.
INVALIDATED
Which come as a result when oracle unable to switch to next on line group due to non availability of next group redo log physical file.
SQL> select group#,members,status from V$log;
GROUP# MEMBERS STATUS
1 1 INVALIDATED
2 1 INACTIVE
4 1 UNUSED
As matter of fact, it's only portion of a big
document which happen to cover what you are testing
in detail.
I would invest time to read the document to
understand how things work instead of getting dirty
quick answers.

Cant drop a current redo log

ORACLE 11.2.0.2
I have a corrupted redo log on a Physical Standby db. The corrupted file is the current log. I cant do an "alter system switch logfile" because the database is not writeable.
SQL> alter database open;
Database altered.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
Database altered.
SQL> SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;
GROUP# ARC STATUS
1 YES UNUSED
2 YES UNUSED
3 NO CURRENT
SQL>
SQL> alter system switch logfile;
alter system switch logfile
ERROR at line 1:
ORA-16000: database open for read-only access
How can I drop log file #3? The database is currently a physical, if I convert ti to a logical, then the dp would be writeable. Would this work? Any other ideas??

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ps.htm
8.3.5 Adding or Dropping Online Redo Log Files
Changing the size and number of the online redo log files is sometimes done to tune the database. You can add or drop online redo log file groups or members to the primary database without affecting the standby database. Similarly, you can drop log file groups or members from the primary database without affecting your standby database. However, these changes do affect the performance of the standby database after switchover.
Caution:
Whenever you add an online redo log file to the primary database, you should add corresponding online and standby redo log files to the standby database.
For example, if the primary database has 10 online redo log files and the standby database has 2, and then you switch over to the standby database so that it functions as the new primary database, the new primary database is forced to archive more frequently than the original primary database.
Consequently, when you add or drop an online redo log file at the primary site, it is important that you synchronize the changes in the standby database by following these steps:
If Redo Apply is running, you must cancel Redo Apply before you can change the log files.
If the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO, change the value to MANUAL.
Add or drop an online redo log file:
To add an online redo log file, use a SQL statement such as this:
SQL> ALTER DATABASE ADD LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log' SIZE 100M;
To drop an online redo log file, use a SQL statement such as this:
SQL> ALTER DATABASE DROP LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log';
Repeat the statement you used in Step 3 on each standby database.
Restore the STANDBY_FILE_MANAGEMENT initialization parameter and the Redo Apply options to their original states.

Redo Log Resize

Hi Experts
i need to resize my online redo log size. at present its size 100Mb. can you plz guide me and give me the steps how i can accomplish this activity successfully
my DB Version is 10g(10.2.0.3) and O/S is RHEL AS 4.6
regards,

To changing size of online logfiles you need drop that and create with new size.But there you can not drop current and active log group.To avoiding this you can use alter system switch logfile and alter system checkpoint .Following example you will see that.
C:\Documents and Settings\Administrator>set ORACLE_SID=TEST
C:\Documents and Settings\Administrator>sqlplus "/as sysdba"
SQL*Plus: Release 10.2.0.1.0 - Production on Thu Jul 29 16:42:04 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> select group||' - '||member from v$logfile;
select group||' - '||member from v$logfile
ERROR at line 1:
ORA-00936: missing expression
SQL> select group#||' - '||member from v$logfile;
GROUP#||'-'||MEMBER
1 - D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO01.LOG
3 - D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO03.LOG
2 - D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO02.LOG
SQL> desc v$log;
Name                                      Null?    Type
GROUP#                                             NUMBER
THREAD#                                            NUMBER
SEQUENCE#                                          NUMBER
BYTES                                              NUMBER
MEMBERS                                            NUMBER
ARCHIVED                                           VARCHAR2(3)
STATUS                                             VARCHAR2(16)
FIRST_CHANGE#                                      NUMBER
FIRST_TIME                                         DATE
SQL> select group#||' - '||status from v$log;
GROUP#||'-'||STATUS
1 - INACTIVE
2 - INACTIVE
3 - CURRENT
SQL> alter database drop logfile group 1;
Database altered.
SQL> select group#||' - '||status from v$log;
GROUP#||'-'||STATUS
2 - INACTIVE
3 - CURRENT
SQL> alter database add logfile group 1 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\R
EDO_01.LOG' size 50M;
Database altered.
SQL> select group#||' - '||status from v$log;
GROUP#||'-'||STATUS
1 - UNUSED
2 - INACTIVE
3 - CURRENT
SQL> alter database drop logfile group 2;
Database altered.
SQL> alter database add logfile group 2 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\R
EDO_02.LOG' size 50M;
Database altered.
SQL> select group#||' - '||status from v$log;
GROUP#||'-'||STATUS
1 - UNUSED
2 - UNUSED
3 - CURRENT
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
SQL> select group#||' - '||status from v$log;
GROUP#||'-'||STATUS
1 - ACTIVE
2 - CURRENT
3 - ACTIVE
SQL> alter system checkpoint;
System altered.
SQL> select group#||' - '||status from v$log;
GROUP#||'-'||STATUS
1 - INACTIVE
2 - CURRENT
3 - INACTIVE
SQL> alter database drop logfile group 3;
Database altered.
SQL> alter database add logfile group 3 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\R
EDO_03.LOG' size 50M;
Database altered.
SQL>

Redo Log Switch 결과...

환경 : 8.1.7.3.0 (no archive log 모드)
log_checkpoint_timeout = 0
log_checkpoint_interval = 999999999
redo log size = 200M
현재 check point는 log switch 상태에서만 가능하도록 설정된 것 같습니다.
거래량이 적어서 그런지 log switch는 30시간 주기입니다.
제가 실행한 것은 아래 4번째 로그가 current일때
alter system checkpoint를 하고 조금 있다가..
alter system switch logfile를 하여 1번째가 current가 된 상황입니다.
3/16일 14시 까지도 계속 active상태입니다...
1. 문제가 생긴건지요??? 도움부탁합니다...
2. no archive log mode에서도 switch 주기를 줄이는 것이 복구에 도움이 되나요...?
===========================================
STATUS , FIRST_CHANGE#,FIRST_TIME
CURRENT , 8846777646687,2007-03-15 16:57:55
INACTIVE, 8846777587798,2007-03-14 10:34:40
INACTIVE, 8846777609448,2007-03-14 17:17:38
ACTIVE , 8846777643690,2007-03-15 16:01:22

no archivemode에서 정상복구를 바라는 것인지요?
잘못된 정책이란 생각이 듭니다.
no archive mode에서 v$log의 first_change# 중에 가장 작은 것
이 v$recover_file의 change# 보다 크거나 같다면 복구불능입니다.
배치작업이라도 있어서 log switch가 한번의 cycle을 돌게 되면 이전
백업으로는 복구불능입니다. archive mode로 지금 바로 바꾸시지요..
log_checkpoint_timeout은 checkpoint에 대한 timeout 시간값을
지정하는 것입니다.
LOG_CHECKPOINT_INTERVAL specifies the frequency of checkpoints in terms of the number of redo log file blocks that can exist between an incremental checkpoint and the last block written to the redo log. This number refers to physical operating system blocks, not database blocks.
checkpoint는 아시는 바와 같이 데이터파일과
리두로그 컨트롤파일의 SCN을 일치시키는 것입니다. 주요한 것은
DBWR프로세스가 데이터파일에 write를 하겠구요.
물론 checkpoint와 인스턴스 복구는 관련이 있습니다. checkpoint timeout을
적당히주면 instance recovery에서 좀 더 빠르게 instance 복구후 DB가
open되겠습니다. 만약 설정하신대로 하신다면 DB를 abort로
내리고 open하게 되면
instance recovery시에 더 많은 시간이 필요하겠습니다.
게다가 트랜잭션으로 인한 log switch하는 시간이 30시간보다
작다면 timeout을 준들 영향을 주지 않겠지요. redo log가 꽉
차게 되면 log switch를 자동으로 하게 되는데 log switch를
하기전에 checkpoint를 주게 되어 있으니까요.
그런데 checkpoint와 물리적/논리적 복구와는 다른 개념입니다.
checkpoint는 위에서 말씀드린 instance recovery와 관련이 있고
물리적/논리적 복구에서는 archive file이 떨어져 있는가 current redo log가
존재하는가에 따라서 복구가능여부를 결정되는 것이지요..
그리고 ACTIVE 상태라는 것은 문서상의 정의에서는 archive mode일 경우
archiving이 되는 중일 경우, 그리고 이 상태는 complete recovery시에 redo log
적용시 필요한 정보가 있다는 것입니다.
no archive mode에서 복구정책을 적용 하겠다는 것은 위험한 발상인 것 같습니다.
물론 DSS시스템의 경우에는 이미 정책을 no archive mode로
만들어두고 주말마다 offline backup을 하기도 합니다.
하지만 DSS에서는 하루에 300번 이상의 log switch가 일어나는
경우가 있을 정도이니 아무리 백업이 되어 있다 한들 완전복구는
불능이겠지요. offline backup을 했을 때까지만 복구가 됩니다.
$LOG
This view contains log file information from the control files.
Column Datatype Description
GROUP#
NUMBER
Log group number
THREAD#
NUMBER
Log thread number
SEQUENCE#
NUMBER
Log sequence number
BYTES
NUMBER
Size of the log (in bytes)
MEMBERS
NUMBER
Number of members in the log group
ARCHIVED
VARCHAR2(3)
Archive status (YES |NO)
STATUS
VARCHAR2(16)
Log status:
UNUSED - Online redo log has never been written to. This is the state of a redo log that was just added, or just after a RESETLOGS, when it is not the current redo log.
CURRENT - Current redo log. This implies that the redo log is active. The redo log could be open or closed.
ACTIVE - Log is active but is not the current log. It is needed for crash recovery. It may be in use for block recovery. It might or might not be archived.
CLEARING - Log is being re-created as an empty log after an ALTER DATABASE CLEAR LOGFILE statement. After the log is cleared, the status changes to UNUSED.
CLEARING_CURRENT - Current log is being cleared of a closed thread. The log can stay in this status if there is some failure in the switch such as an I/O error writing the new log header.
INACTIVE - Log is no longer needed for instance recovery. It may be in use for media recovery. It might or might not be archived.
no archive mode에서도 복구하는 여러가지 방법들이 있기는 합니다.
예를들어 current redo log가 깨졌을 때에 recovery 방법이라던지
등등이 문서에 있긴하지요. 하지만 no archivemode에서 백업을 붓고
복구하는 방법은 찾아보기 힘드실 것입니다. 위에서도 말씀드렸듯이
no archive mode에서
v$recover_file의 CHANGE# > v$logl의 minimum FIRST_CHANGE# 이면 데이터파일은 복구가능합니다.
그러나 CHANGE# <= minimum FIRST_CHANGE# 이면 복구 불가능합니
다. 그러니 백업을 붓고 복구를 하는 방법에 대한 문서는 거의
찾기 힘듭니다. advance 방법에 대한 문서에서만 adjust_scn을 쓴다던지 하는 등이 나와있을 뿐입니다.
글 수정:
민천사(민연홍)
아무래도 졸면서 썼나봅니다.;;
interval과 timeout은 엄연히 다른데요. 왜 timeout과 interval을
혼동했는지..;;
LOG_CHECKPOINT_INTERVAL specifies the frequency of checkpoints in terms of the number of redo log file blocks that can exist between an incremental checkpoint and the last block written to the redo log. This number refers to physical operating system blocks, not database blocks.
LOG_CHECKPOINT_TIMEOUT specifies (in seconds) the amount of time that has passed since the incremental checkpoint at the position where the last write to the redo log (sometimes called the tail of the log) occurred. This parameter also signifies that no buffer will remain dirty (in the cache) for more than integer seconds.

Increse of redo log size

Hi,
Please help me to increase the redo log size.
As i am in DB - oracle 10G and OS - Suse linux 10SP2
SQL> SELECT * FROM v$log;
    GROUP#    THREAD# SEQUENCE#      BYTES    MEMBERS ARC STATUS
FIRST_CHANGE# FIRST_TIME
         1          1        358 157286400          2 YES INACTIVE
   2972903289 28-NOV-11
         2          1        359 157286400          2 YES INACTIVE
   2972957401 28-NOV-11
         3          1        357 157286400          2 YES INACTIVE
   2972839164 27-NOV-11
    GROUP#    THREAD# SEQUENCE#      BYTES    MEMBERS ARC STATUS
FIRST_CHANGE# FIRST_TIME
         4          1        360 157286400          2 NO CURRENT
   2973005629 29-NOV-11
SQL> SELECT * FROM v$logfile;
    GROUP# STATUS TYPE
MEMBER
IS_
         4         ONLINE
/oracle/JID/origlogB/log_g14m1.dbf
NO
         4         ONLINE
/oracle/JID/mirrlogB/log_g14m2.dbf
NO
    GROUP# STATUS TYPE
MEMBER
IS_
         3         ONLINE
/oracle/JID/origlogA/log_g13m1.dbf
NO
         3         ONLINE
/oracle/JID/mirrlogA/log_g13m2.dbf
    GROUP# STATUS TYPE
MEMBER
IS_
NO
         2         ONLINE
/oracle/JID/origlogB/log_g12m1.dbf
NO
         2         ONLINE
    GROUP# STATUS TYPE
MEMBER
IS_
/oracle/JID/mirrlogB/log_g12m2.dbf
NO
         1         ONLINE
/oracle/JID/origlogA/log_g11m1.dbf
NO
    GROUP# STATUS TYPE
MEMBER
IS_
         1         ONLINE
/oracle/JID/mirrlogA/log_g11m2.dbf
NO
8 rows selected.
Please help me how to execute for the above query.
Thanks,
Hariharan

Hello
Complete step:
Step 1 SQL> select a.group#, a.member, b.bytes/1024/1024 mb from v$logfile a, v$log b where a.group# = b.group#;
This query will show current group with redo log members and their size.
Step 2 Make the last redo log CURRENT one
To find which group is current at this moment use following query
SQL> select group#, status from v$log;
GROUP#         STATUS
1                    CURRENT
2                    INACTIVE
3                    INACTIVE
4                    INACTIVE
Now as you can see that the first group is marked as current but we need to make group 4 as current. So force group 4 to become current one by switching log file. To switch log file use following query.
SQL> alter system switch logfile;
GROUP#         STATUS
1                     INACTIVE
2                    CURRENT
3                    INACTIVE
4                  INACTIVE
SQL> alter system switch logfile;
GROUP#        STATUS
1                     INACTIVE
2                     INACTIVE
3                     INACTIVE
4                    CURRENT
Step 3 Drop the first online redo log
After making the last online redo log file the CURRENT one, drop the first online redo log:
SQL> alter database drop logfile group 1;
Database altered.
Note:
Be aware that if you are going to drop a logfile group, it cannot be the current logfile group. However, where attempting to drop the logfile group resulted in the following error as a result of the logfile group having an active status:
SQL> ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE DROP LOGFILE GROUP 1
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of instance ORA920 (thread 1)
ORA-00312: online log 1 thread 1: ''
Easy problem to resolve. Simply perform a checkpoint on the database:
SQL> ALTER SYSTEM CHECKPOINT GLOBAL;
System altered.
SQL> ALTER DATABASE DROP LOGFILE GROUP 1;
Database altered.
Step 4 You need to re-create dropped online redo log group with different size. Use the following query to achieve this.
SQL> alter database add logfile group 1 ('<path>/origlogA/log_g11m1.dbf','<path>/mirrlogA/log_g11m2.dbf') size 200M reuse;
Database altered.
Step 5 Force another log switch
After re-creating the online redo log group, force a log switch. The online redo log group just created should become the "CURRENT" group:
SQL> select group#, status from v$log;
GROUP#         STATUS
1                     UNUSED
2                     INACTIVE
3                     INACTIVE
4                    CURRENT
SQL> alter system switch logfile;
SQL> select group#, status from v$log;
GROUP#         STATUS
1                      CURRENT
2                      INACTIVE
3                      ACTIVE
Step 6 # Loop back to Step 3 until all logs are rebuilt
After re-creating an online redo log group, continue to re-create (or resize) all online redo log groups until all of them are rebuilt.
Regards,
Rajan

Emergency: cannot start database because redo logs have been deleted

Hi. Ok, so the redo logs are deleted and I don't have a backup. Fine, whatever. I am trying to just start my database and start the logging from scratch.
ORA-00320: cannot read file header from log 1 of thread 1
ORA-00312: online log 1 thread 1: '/u01/oradata/orcl/redo01.log'
ORA-27069: attempt to do I/O beyond the range of the file
Here's what my log files look like:
select group#, thread#, status from v$log;
GROUP# THREAD# STATUS
1 1 ACTIVE
4 1 UNUSED
3 1 UNUSED
2 1 CURRENT
I have group 3 and 4 just sitting there. I would love to switch logging from group 1 to group 4 (which I just created) so I can drop the corrupted group 1 but when I try:
SQL> alter system switch logfile;
alter system switch logfile
ERROR at line 1:
ORA-01109: database not open
Of course the database is not open because I can't get it started. So, I'm in kind of a catch 22.

I think you need to restore your database. http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/osadvsce.htm#CACFFJFB says:
>
Losing an Active Online Redo Log Group
If the database is still running and the lost active redo log is not the current log, then issue the ALTER SYSTEM CHECKPOINT statement. If the operation is successful, then the active redo log becomes inactive, and you can follow the procedure in "Losing an Inactive Online Redo Log Group". If the operation is unsuccessful, or if your database has halted, then perform one of procedures in this section, depending on the archiving mode.
The current log is the one LGWR is currently writing to. If a LGWR I/O operation fails, then LGWR terminates and the instance fails. In this case, you must restore a backup, perform incomplete recovery, and open the database with the RESETLOGS option.

How do I manually archive 1 redo log at a time?

The database is configured in archive mode, but automatic archiving is turned off.
For both Oracle 901 and 920 on Windows, when I try to manually archive a single redo log, the database
archives as many logs as it can up to the log just before the current log:
For example:
SQL> select * from v$log order by sequence#;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
1 1 14 104857600 1 NO INACTIVE 424246 19-JAN-05
2 1 15 104857600 1 NO INACTIVE 425087 28-MAR-05
3 1 16 104857600 1 NO INACTIVE 425088 28-MAR-05
4 1 17 512000 1 NO INACTIVE 425092 28-MAR-05
5 1 18 512000 1 NO INACTIVE 425100 28-MAR-05
6 1 19 512000 1 NO CURRENT 425102 28-MAR-05
6 rows selected.
SQL> alter system archive log next;
System altered.
SQL> select * from v$log order by sequence#;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
1 1 14 104857600 1 YES INACTIVE 424246 19-JAN-05
2 1 15 104857600 1 YES INACTIVE 425087 28-MAR-05
3 1 16 104857600 1 YES INACTIVE 425088 28-MAR-05
4 1 17 512000 1 YES INACTIVE 425092 28-MAR-05
5 1 18 512000 1 NO INACTIVE 425100 28-MAR-05
6 1 19 512000 1 NO CURRENT 425102 28-MAR-05
See - instead of only 1 log being archive, 4 of them were. Oracle behaves the same way if I use the "sequence" option:
SQL> select * from v$log order by sequence#;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
1 1 14 104857600 1 NO INACTIVE 424246 19-JAN-05
2 1 15 104857600 1 NO INACTIVE 425087 28-MAR-05
3 1 16 104857600 1 NO INACTIVE 425088 28-MAR-05
4 1 17 512000 1 NO INACTIVE 425092 28-MAR-05
5 1 18 512000 1 NO INACTIVE 425100 28-MAR-05
6 1 19 512000 1 NO CURRENT 425102 28-MAR-05
6 rows selected.
SQL> alter system archive log next;
System altered.
SQL> select * from v$log order by sequence#;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
1 1 14 104857600 1 YES INACTIVE 424246 19-JAN-05
2 1 15 104857600 1 YES INACTIVE 425087 28-MAR-05
3 1 16 104857600 1 YES INACTIVE 425088 28-MAR-05
4 1 17 512000 1 YES INACTIVE 425092 28-MAR-05
5 1 18 512000 1 NO INACTIVE 425100 28-MAR-05
6 1 19 512000 1 NO CURRENT 425102 28-MAR-05
Is there some default system configuration property telling Oracle to archive as many logs as it can?
Thanks,
DGR

Thanks Yoann (and Syed Jaffar Jaffar Hussain too),
but I don't have a problem finding the group to archive or executing the alter system archive log command.
My problem is that Oracle doesn't work as I expect it.
This comes from the Oracle 9.2 online doc:
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/statements_23a.htm#2053642
"Specify SEQUENCE to manually archive the online redo log file group identified by the log sequence number integer in the specified thread."
This implies that Oracle will only archive the log group identified by the log sequence number I specify in the alter system archive log sequence statement. However, Oracle is archiving almost all of the log groups (see my first post for an example).
This appears to be a bug, unless there is some other system parameter that is configured (by default) to allow Oracle to archive as many log groups as possible.
As to the reason why - it is an application requirement. The Oracle db must be in archive mode, automatic archiving must be disabled and the application must control online redo log archiving.
DGR

Unusable redo log

Similar Messages

Maybe you are looking for