10G redo log switchs with no activity

We have been testing 8i to 10G migrations and two things I have noticed that are different bwteeen the 2 databases are:
1) redo log switching occurring even though the database has no users and just sitting there. This is not happeniong in our 8i databases.
2) trace files of format instance_m001_ and instance_m000_ in ../bdump. Our 8i bdump's normally do not have trc files unless a problem occurs.
Is it normal for 10G to automatically switch redo logs with no activity and are these .trc files also normal? In general I get nervous with trc files. -quinn

Still haven't figured out the redo log switches, they seem to be slowing down, but the excess trace files are apparently cuased by a bug and can be fixed with Patch 3432729.

Similar Messages

Frequent redo log switches

Oracle 9.2.0.1 on W2k3 server. the redo log is switching every minute, even without any discernable database activity. It's in archive log mode and the redo logs are 100mb in size, so the archive logs are filling up my hard drive. I'm having a hard time figuring out why the redo logs are switching so often. there are 3 redo log groups. Thanks for any help you can give me.

If the redo logs are defined at 100M in size and the archived redo logs are 100M in size then the online redo logs are being filled. As suggested log miner is one way to determine what is happening.
Are the redo logs switching all the time or only during periods of peek activity? If the rapid log switches are only happening during certain time periods like 9:30 - 10:30 or the time correspond to the running of certain batch jobs then you should probably increase the size of your online redo logs.
If the archived redo logs are small then obvious something is forcing log switches prior to their filling. I would check the spfile setting for log_checkpoint_interval, log_checkpoint_timeout, and fast_start_mttr_target to be sure no one had made a mistake changing one of the values prior to running the log miner.
HTH -- Mark D Powell --

Digital Editions: The account you tried to log in with is activated on too many devices.

Digital Editions: The account you tried to log in with is activated on too many devices.
How do i reset it???
Chat does not run, my english is not got enough to call the hotline.
I didn*t find out how to contact adobe support by email :-(((
So, what can i do? Please help.
Otherwise, i can not read my ebooks any longer :-(((

The only people that I'm aware of who can reset your activation count is
the Adobe Help line that you call. And many of those people have to be
told that it is their job. This forum does not have the ability to forward
posts to Adobe technical support to get these kinds of problems resolved.
Trust in your English - or perhaps have a friend that speaks English better
do the talking.
I have to ask what you have been doing that used up all of the
activations. We need to fix the root of the problem.
=================

Redo log switch frequency

Hi all experts,
I have a 10.2.0.4 database. I want to find out how often redo log switch is happening in the database. Is there a query on some sys/system view that could show me that?
Thanks,

Hi,
You can check bellow mention query which will give you idea of log switch completion in your database.
select to_char(first_time,'YYYY-MON-DD') day,
to_char(sum(decode(to_char(first_time,'HH24'),'00',1,0)),'99') "00",
to_char(sum(decode(to_char(first_time,'HH24'),'01',1,0)),'99') "01",
to_char(sum(decode(to_char(first_time,'HH24'),'02',1,0)),'99') "02",
to_char(sum(decode(to_char(first_time,'HH24'),'03',1,0)),'99') "03",
to_char(sum(decode(to_char(first_time,'HH24'),'04',1,0)),'99') "04",
to_char(sum(decode(to_char(first_time,'HH24'),'05',1,0)),'99') "05",
to_char(sum(decode(to_char(first_time,'HH24'),'06',1,0)),'99') "06",
to_char(sum(decode(to_char(first_time,'HH24'),'07',1,0)),'99') "07",
to_char(sum(decode(to_char(first_time,'HH24'),'08',1,0)),'99') "08",
to_char(sum(decode(to_char(first_time,'HH24'),'09',1,0)),'99') "09",
to_char(sum(decode(to_char(first_time,'HH24'),'10',1,0)),'99') "10",
to_char(sum(decode(to_char(first_time,'HH24'),'11',1,0)),'99') "11",
to_char(sum(decode(to_char(first_time,'HH24'),'12',1,0)),'99') "12",
to_char(sum(decode(to_char(first_time,'HH24'),'13',1,0)),'99') "13",
to_char(sum(decode(to_char(first_time,'HH24'),'14',1,0)),'99') "14",
to_char(sum(decode(to_char(first_time,'HH24'),'15',1,0)),'99') "15",
to_char(sum(decode(to_char(first_time,'HH24'),'16',1,0)),'99') "16",
to_char(sum(decode(to_char(first_time,'HH24'),'17',1,0)),'99') "17",
to_char(sum(decode(to_char(first_time,'HH24'),'18',1,0)),'99') "18",
to_char(sum(decode(to_char(first_time,'HH24'),'19',1,0)),'99') "19",
to_char(sum(decode(to_char(first_time,'HH24'),'20',1,0)),'99') "20",
to_char(sum(decode(to_char(first_time,'HH24'),'21',1,0)),'99') "21",
to_char(sum(decode(to_char(first_time,'HH24'),'22',1,0)),'99') "22",
to_char(sum(decode(to_char(first_time,'HH24'),'23',1,0)),'99') "23"
from v$log_history group by to_char(first_time,'YYYY-MON-DD');
Hope this might help you.
Thanks,
Vishal Joshi
Oracle Apps DBA

Redo log switching

11gR2
Found out log switched every a few mins (2, 3 mins) at peak periods. I will make the recommendation for larger redo logs such that switches will be every 20 to 30 mins .
Wanted to know what would be negative side of large redo logs?

>
11gR2
Found out log switched every a few mins (2, 3 mins) at peak periods. I will make the recommendation for larger redo logs such that switches will be every 20 to 30 mins .
Wanted to know what would be negative side of large redo logs?
>
Patience, grasshopper!
If it ain't broke, don't fix it. So first make sure it is broken, or about to break.
Unless you have an emergency on your hands you don't want to implement a change like that without careful examination of your current log file usage and history.
You need to provide more information such as typical size of your log files, number of log groups, number of members in each group, log archive policy, etc.
1. How often do these 'peak periods' occur? Do they occur fewer than 5 or 6 times a day? Or dozens of times?
2. How long do they last? A few minutes? Or a few hours?
3. What is the typical, non-peak rate of switches? This is really your base-line that you need to compare things to.
4. What has the switch pattern been over the last few weeks or months?
5. What has the growth in DB activity benn over the last few weeks or months? What do expect over the next few months?
6. What is your goal in reducing the frequency of log switches?
Basic negative sides include longer time to archive each log file (the fewer logs in each group the more impact here) and the length of time to recover in the event you need to. With large log files there is more for Oracle to wade through to find the relevant data for restoring the DB to a given point in time.
Your suggestion of every 20 - 30 minutes means 2 to 3 times per hour. If you currently switch 10 or 12 times per hour you are making a very big change.
Although you don't want to 'tweak' the logs unnecessarily you also don't want to make such large changes.
Everything in moderation. If your current switch rate is 10 or 12 times per hour you may want to first cut this to maybe 1/2 to 1/3: that is, to 4 or 5 time per hour. It all depends on the answers to questions like I ask above. If you post the answers to know if will be helpful to anyone trying to advise you.

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.

Redo logs switches too frequent after migrating the db to different server

Dear Experts,
A couple of days back, we migrated our database (belonging to EBusiness Suite) to a different server, to get good performance benefit. The database is 10.2.0.4 and it was migrated from AIX 5.3 to Linux x86 64.
Users are happy with the performance, but I am getting below errors in the alert logs
a) Thread 1 cannot allocate new log, sequence 498
b) Private strand flush not complete
c) ORACLE Instance PROD - Can not allocate log, archival requiredOracle support is saying the issue is coming because of too frequent log switches. I am wondering how the log switches has become frequent in the new server. In the old server it was about 10 mins for every switch, now it is as frequent as 1 minute?
Any idea, what could be the reason behind this? Do you agree this issue is coming because frequent log switches?
Thanks
ARS

Kanchana Devasurendra wrote:
Hi ARS,
Please check the following item in your new database.
1. log_archive_max_processes Most properbly value set for this parameter is low ( may be it's set to 1.) Please increase up ( 4)I am curious to know what makes you think 4 is the right magic number for log_archive_max_processes - after all, he's only got one archive destination.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
A general reminder about "Forum Etiquette / Reward Points": http://forums.oracle.com/forums/ann.jspa?annID=718
If you never mark your questions as answered people will eventually decide that it's not worth trying to answer you because they will never know whether or not their answer has been of any use, or whether you even bothered to read it.
It is also important to mark answers that you thought helpful - again it lets other people know that you appreciate their help, but it also acts as a pointer for other people when they are researching the same question, moreover it means that when you mark a bad or wrong answer as helpful someone may be prompted to tell you (and the rest of the forum) what's so bad or wrong about the answer you found helpful.

Online redo log switching

Hello.
I have a question about online redo logs.
Assume that I have two small redo log groups in my database. I am processing a big batch load consisting of many inserts, but no checkpoing. The first redo log group gets full, it's switched to the second one. The second one gets full too and it need to be switched to the first. No commit until this time, so (I guess) the data has not been saved to datafiles.
Is that possible? Will the database hung ?
If not the first redo log group gets overwritten, doesn't it? What if, after the commit, the database crashes. I will not be able to restore the operations from the first redo group...?

Depends,
If you are running in archive log mode then when you fill the first redo log group it is copied to the archvielog destination, then when the second is filled its copied and we switch back to the first if the archiver hasn't completed you will get a short 'hang' whillst the archiver completes then the transaction will proceed.
if in no archivelog mode you will just switch back and forth between the two log files.
You may be confused because you think that the datablocks in the buffer cache and datafiles are not updated untill the transaction is completed this is not true, the assumption is that most transactions will be completed and commited for a usefull discussion of the concepts see.
Re: basic concepts

Créating new redo log group with dataguard

Hi,
is there an impact on the standby database if i create a new redo log group on the primary database?
Thanks

Hello,
No, there is no impact at all, it will be a completely independent operation, just be sure to replicate the operation on the Standby database - even if the standby_file_management parameter is set to 'AUTO' I don't believe that that (automatic file management) applies to redo logs, only data files.

Oracle 10g R2 Database Redo Log Files

I had 3 redo log files, each of size 50 MB. i added 3 more redo log files, each of size 250 MB.
Database is running in archive mode, files are generating with different sizes like 44 MB and 240 MB, i need to know is this harm for database or not?
to make all archive redo log files generation of equal size what should i do?
Please guide

Waheed,
When the redo log switch willbe happening,oracle would be asking archiver to log that into the archive file.So in case you have any parameters set to make the switch happen at certain time,depending on the activity of teh database,the archive file size may vary.There is no harm wit the different sizes of the files.What matters is the transaction informaiton contained in them not their size.
to make all archive redo log files generation of equal size what should i do?
As mentioned by Syed, you can make the switch happen at a defined interval which will not ensure but still will be a step to make the archive files of the same size.But I shall say you should bother more about making sure that the files are available rather than their size.
Aman....

Open database if an active online redo log is missing

Hi,
Sorry for the rather long post, but I specified all the steps I performed and couldn't make it shorter :-(
I need an advice on how to open the database if an active online redo log is missing.
For test purposes I intentionally performed a shutdown abort when the redo log group 1 was in active state and then renamed its only member (REDO01.LOG) so that the database couldn't perform crash recovery using it. Then upon startup I obviously got the message:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'H:\ORADATA\TESTDB\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.Ok, so I checked the state of the logs:
{noformat}
SQL>SELECT a.GROUP#, first_change#, SEQUENCE#, a.status, SUBSTR(b.MEMBER, 1, 40) MEMBER, b.status mem_status, a.archived
2    FROM v$log a, v$logfile b
3   WHERE a.GROUP# = b.GROUP#
4 ORDER BY a.GROUP#, b.MEMBER;
GROUP# FIRST_CHANGE# SEQUENCE# STATUS           MEMBER                         MEM_STA ARC
     1        592134         29 ACTIVE           H:\ORADATA\TESTDB\REDO01.LOG           YES
     2        592268         30 CURRENT          C:\ORADATA\TESTDB\REDO02.LOG           NO
     3        592129         28 ACTIVE           C:\ORADATA\TESTDB\REDO03.LOG           YES
{noformat}Since opening the database to perform a log switch and thus change the status of the redo log group 1 from ACTIVE to INACTIVE to recreate the member isn't possible, I performed database recovery.
SQL>recover database until cancel;
ORA-00279: change 592129 generated at 02/04/2009 10:31:15 needed for thread 1
ORA-00289: suggestion : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2009_02_04\O1_MF_1_28_%U_.ARC
ORA-00280: change 592129 for thread 1 is in sequence #28
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 592134 generated at 02/04/2009 10:31:28 needed for thread 1
ORA-00289: suggestion : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2009_02_04\O1_MF_1_29_%U_.ARC
ORA-00280: change 592134 for thread 1 is in sequence #29
ORA-00278: log file 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2009_02_04\O1_MF_1_28_4RLR3JS9_.ARC' no longer needed for this rec
overy
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2009_02_04\O1_MF_1_29_4RLR4MF3_.ARC'
ORA-00279: change 592268 generated at 02/04/2009 10:32:03 needed for thread 1
ORA-00289: suggestion : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2009_02_04\O1_MF_1_30_%U_.ARC
ORA-00280: change 592268 for thread 1 is in sequence #30
ORA-00278: log file 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2009_02_04\O1_MF_1_29_4RLR4MF3_.ARC' no longer needed for this rec
overy
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
'C:\ORADATA\TESTDB\REDO02.LOG'
Log applied.
Media recovery complete.
SQL>So for log sequence #28 I accepted the proposed archived redo log in the FRA, for sequence #29 (that's the online redo log that is missing!) I manually specified its archived copy, and for sequence #30 I specified the CURRENT online redo log. And as it seems the media recovery was successful.
Next I tried to open the database but again got the error:
SQL>alter database open noresetlogs;
alter database open noresetlogs
ERROR at line 1:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'H:\ORADATA\TESTDB\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.
The status of the log groups and its members is exactly as it was in the first query I wrote above, i.e. the redo log group 1 is still ACTIVE, so it's needed for crash recovery (which I had already done manually if I understand correctly how Oracle works!). I also checked if the datafiles are inconsistent (described in metalink doc id 1015544.102):
SQL>SELECT DISTINCT CHECKPOINT_CHANGE#, FUZZY FROM V$DATAFILE_HEADER;
CHECKPOINT_CHANGE# FUZ
            592269 NOSo, everything seems ok as far as datafile consistency is concerned.
My question is: how can I rename/drop/clear/whatever the member of redo log group 1 to open the database?
I tried to rename the log file member, to add another member to it, to open the database with resetlogs, to clear the logfile group 1, but all without success:
1)
SQL>alter database clear logfile group 1;
alter database clear logfile group 1
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of instance testdb (thread 1)
ORA-00312: online log 1 thread 1: 'H:\ORADATA\TESTDB\REDO01.LOG'
2)
SQL>alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-01139: RESETLOGS option only valid after an incomplete database recovery
3)
SQL>alter database rename file 'H:\ORADATA\TESTDB\REDO01.LOG' to 'C:\ORADATA\TESTDB\REDO01.LOG';
alter database rename file 'H:\ORADATA\TESTDB\REDO01.LOG' to 'C:\ORADATA\TESTDB\REDO01.LOG'
ERROR at line 1:
ORA-01511: error in renaming log/data files
ORA-01512: error renaming log file H:\ORADATA\TESTDB\REDO01.LOG - new file C:\ORADATA\TESTDB\REDO01.LOG not found
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.
4)
SQL>alter database add logfile member 'C:\ORADATA\TESTDB\REDO01.LOG' to group 1;
alter database add logfile member 'C:\ORADATA\TESTDB\REDO01.LOG' to group 1
ERROR at line 1:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'H:\ORADATA\TESTDB\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.Sorry again for the long post and thank you in advance for any suggestion.
Regards,
Jure

You could check if the recovery was complete by (re)creating the controlfile with the resetlogs option.
<CREATE CONTROLFILE REUSE DATABASE define_db_name RESETLOGS NOARCHIVELOG
...>Thanks for the hint. If possible, could you only check if the steps I'm going to perform are ok.
I did an "alter database backup controlfile to trace;" and then extracted the create controlfile definition part. So in essence I should run the following statements:
CREATE CONTROLFILE REUSE DATABASE "TESTDB" RESETLOGS ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
GROUP 1 'C:\ORADATA\TESTDB\REDO01.LOG' SIZE 20M,
GROUP 2 'C:\ORADATA\TESTDB\REDO02.LOG' SIZE 20M,
GROUP 3 'C:\ORADATA\TESTDB\REDO03.LOG' SIZE 20M
-- STANDBY LOGFILE
DATAFILE
'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TESTDB\SYSTEM01.DBF',
'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TESTDB\UNDOTBS01.DBF',
'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TESTDB\SYSAUX01.DBF',
'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TESTDB\USERS01.DBF'
CHARACTER SET EE8MSWIN1250
ALTER DATABASE OPEN RESETLOGS;
ALTER TABLESPACE TEMP ADD TEMPFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TESTDB\TEMP01.DBF' REUSE;Is that correct?
About the RMAN backups: Wouldn't a 'CATALOG RECOVERY AREA' populate the controlfile with backup information again (I'm not using a recovery catalog in this case)?
Thanks for the help!
Regards,
Jure

All redo log groups is active

Hello dear gurus!
After shutting database with option "abort"
we have unconsisten state of datafiles.
I ask to explain :
1) - does the ARCH background processes flash whole redo buffer into redolog ?
(In other words how reached consistency if all redo log groups was in active state before shutting down ?)
2) Where buffer contents in this case are dumped ?
Thanks and best regards,
Pavel
Edited by: Pavel on Jul 19, 2012 9:49 PM

Pavel wrote:
Hello dear gurus!
After shutting database with option "abort"
we have unconsisten state of datafiles.That's expected as checkpoint didn't happen. Issue a startup and instance recovery should take care of everything.
I ask to explain :
1) - does the ARCH background processes flash whole redo buffer into redolog ?ARCH process or LGWR? How does this relates to your current question?
(In other words how reached consistency if all redo log groups was in active state before shutting down ?)As I said, issue a startup of the instance and it should take care of the things.
2) Where buffer contents in this case are dumped ?Which case? Your questions are a bit fuzzy you see. Let's stick to one question at one time and follow it shall we?
Aman....

T is frequently switching the redo log files within 5min approx..

i am facing frequent switching of redo logs within 5minutes
can you please tell how to resolve
thanks for help

Hi,
I found this:
More frequent log switches may result in decreased performance. If your redo logs switches so faster Oracle will stop processing until the checkpoint completes successfully. Generally it is recommended to size your redo log file in a way that Oracle performs a log switch every 15 to 30 minutes.
A recommended approach is to
Query V$LOG view to determine the current size of the redo log members.
Record the number of log switches per hour.
Increase the log file size so that Oracle switches at the recommended rate of one switch per 15 to 30 minutes.
You can also check messages in the alert log in order to determine how fast Oracle is filling and switching logs. Suppose if your database redo log file size is set to 1MB. It means that Oracle switches the logs every 1 minute. So you will need to increase the size of redo log file to 30MB so that Oracle switches per 30 minutes.
It is also recommended to ensure that your online redo log files do not switch too often during high activity time. Instead in the period of high activity it should switch less while it should switch enough times during the time of low processing workloads. Many database administrators create PL/SQL programs to ensure that the logs switch every 15 to 30 minutes during times when activity is low.
Oracle ARCHIVE_LAG_TARGET can also be used to force a log switch after the specified amount of time elapses. The basic purpose of ARCHIVE_LAG_TARGET parameter is to control the amount of data that is lost and effectively increasing the availability of the standby database but many database administrators set ARCHIVE_LAG_TARGET parameter to make sure that the logs switch at regular intervals during lower activity time periods.
You should also keep in mind that how the size of the online redo log files will affect the instance recovery. Remember the lesser the checkpoints are taken; the longer will be the instance recovery duration. You can decrease the instance recovery time by appropriately setting the LOG_CHECKPOINT_TIMEOUT, LOG_CHECKPOINT_INTERVAL and FAST_START_MTTR_TARGET parameters.

When occurs crash recovery,why use active online redo log not archived log?

If current redo log had archived, but it's still 'ACTIVE'. As we all know, archived log is just an archived copy of the current redo log which is still 'ACTIVE', they have the same data. But why use active online redo log not archived log for crash recovery?(I think, if crash recovery can use archived log, then whether the online redo log is 'ACTIVE' or not, it can be overwritten)
Quote:
Re: v$log : How redo log file can have a status ACTIVE and be already archived?
Hemant K Chitale
If your instance crashes, Oracle attempts Instance Recovery -- reading from the Online Redo Logs. It doesn't need ArchiveLogs for Instance Recovery.
TanelPoder
Whether the log is already archived or not doesn't matter here, when the instance crashes, Oracle needs some blocks from that redolog. Archivelog is just an archived copy of the redolog, so you could use either the online or achive log for the recovery, it's the same data in there (Oracle reads the log/archivelog file header when it tries to use it for recovery and validates whether it contains the changes (RBA range) in it what it needs).

Aman.... wrote:
John,
Are you sure that the instance recovery (not the media recovery) would be using the archived redo logs? Since the only thing that would be lost is the isntance, there wouldn't be any archived redo log generated from the Current redo log and the previous archived redo logs, would be already checkpointed to the data file, IMHO archived redo logs won't participate in the instance recovery process. Yep, shall watch the video but tomorrow .
Regards
Aman....
That's what I said. Or meant to say. If Oracle used archivelogs for instance recovery, it would not be possible to recover in noarchive log mode. So recovery relies exclusively on the online log.
Sorry I wasted your time, I'll try to be less ambiguous in future

Can you spot any irregularities with this redo log configuration

DB version:10gR2
We were frequently getting 'log file sync' ranked 1 in TOP 5 wait events in AWR reports. So i looked at alert log.Can you spot any irregularities from below mentioned Redo log switching i got from the alert log?
Thu Nov 6 05:00:07 2008
Thread 1 advanced to log sequence 65790
Current log# 2 seq# 65790 mem# 0: /DLPRD/ora1/APP_MK/APP_MK_redo2a.log
Current log# 2 seq# 65790 mem# 1: /DLPRD/ora2/APP_MK/APP_MK_redo2b.log
Thu Nov 6 05:40:37 2008
Thread 1 advanced to log sequence 65791
Current log# 4 seq# 65791 mem# 0: /DLPRD/ora1/APP_MK/APP_MK_redo4a.log
Current log# 4 seq# 65791 mem# 1: /DLPRD/ora2/APP_MK/APP_MK_redo4b.log
Thu Nov 6 05:52:31 2008
Thread 1 advanced to log sequence 65792
Current log# 3 seq# 65792 mem# 0: /DLPRD/ora1/APP_MK/APP_MK_redo3a.log
Current log# 3 seq# 65792 mem# 1: /DLPRD/ora2/APP_MK/APP_MK_redo3b.log
Thu Nov 6 06:19:05 2008
Thread 1 advanced to log sequence 65793
Current log# 1 seq# 65793 mem# 0: /DLPRD/ora1/APP_MK/APP_MK_redo1a.log
Current log# 1 seq# 65793 mem# 1: /DLPRD/ora2/APP_MK/APP_MK_redo1b.log
Thu Nov 6 06:29:04 2008
Thread 1 advanced to log sequence 65794
Current log# 2 seq# 65794 mem# 0: /DLPRD/ora1/APP_MK/APP_MK_redo2a.log
Current log# 2 seq# 65794 mem# 1: /DLPRD/ora2/APP_MK/APP_MK_redo2b.log
Thu Nov 6 06:34:24 2008
Thread 1 advanced to log sequence 65795
Current log# 4 seq# 65795 mem# 0: /DLPRD/ora1/APP_MK/APP_MK_redo4a.log
Current log# 4 seq# 65795 mem# 1: /DLPRD/ora2/APP_MK/APP_MK_redo4b.log
Thu Nov 6 06:42:02 2008
Thread 1 advanced to log sequence 65796
Current log# 3 seq# 65796 mem# 0: /DLPRD/ora1/APP_MK/APP_MK_redo3a.log
Current log# 3 seq# 65796 mem# 1: /DLPRD/ora2/APP_MK/APP_MK_redo3b.log
Thu Nov 6 06:56:19 2008
Thread 1 advanced to log sequence 65797
Current log# 1 seq# 65797 mem# 0: /DLPRD/ora1/APP_MK/APP_MK_redo1a.log
Current log# 1 seq# 65797 mem# 1: /DLPRD/ora2/APP_MK/APP_MK_redo1b.log
Thu Nov 6 07:16:12 2008
Thread 1 advanced to log sequence 65798
Current log# 2 seq# 65798 mem# 0: /DLPRD/ora1/APP_MK/APP_MK_redo2a.log
Current log# 2 seq# 65798 mem# 1: /DLPRD/ora2/APP_MK/APP_MK_redo2b.log

Log file sync is usually a symptom of "over commiting", perhaps some batch job who commits after every row processed, see Note 34592.1 WAITEVENT: "log file sync" Reference Note for a complete reference.
HTH
Enrique

10G redo log switchs with no activity

Similar Messages

Maybe you are looking for