Redo Log Writer Problem

Hello
What can I do, when Average redo log write time is 17'300ms (averaged over 30ms)?
I have only one redolog writer. Should I start more then one redolog writer? We have 3 Redolog Groups (64MB) and we work with oracle dataguard. Its Oracle 11.2 (Unix Solaris 10).
The system switch every 45 min the redogroup.
Thanks for your support...
Best regards...
Roger

Street wrote:
Hello
What can I do, when Average redo log write time is 17'300ms (averaged over 30ms)?
I have only one redolog writer. Should I start more then one redolog writer? We have 3 Redolog Groups (64MB) and we work with oracle dataguard. Its Oracle 11.2 (Unix Solaris 10).
The system switch every 45 min the redogroup.
Thanks for your support...
Best regards...
Roger
Why do you think that this time, 30ms is not good enough for your database ? Did you get any redo log related issues in the Statspack/AWR report?
There is only one LGWR possible, you can't have more than one LGWR.
Aman....

Similar Messages

Improving redo log writer performance

I have a database on RAC (2 nodes)
Oracle 10g
Linux 3
2 servers PowerEdge 2850
I'm tuning my database with "spotilght". I have alredy this alert
"The Average Redo Write Time alarm is activated when the time taken to write redo log entries exceeds a threshold. "
The serveres are not in RAID5.
How can I improve redo log writer performance?
Unlike most other Oracle write I/Os, Oracle sessions must wait for redo log writes to complete before they can continue processing.
Therefore, redo log devices should be placed on fast devices.
Most modern disks should be able to process a redo log write in less than 20 milliseconds, and often much lower.
To reduce redo write time see Improving redo log writer performance.
See Also:
Tuning Contention - Redo Log Files
Tuning Disk I/O - Archive Writer

Some comments on the section that was pulled from Wikipedia. There is some confusion in the market as their are different types of solid state disks with different pros and cons. The first major point is that the quote pulled from Wikipedia addresses issues with Flash hard disk drives. Flash disks are one type of solid state disk that would be a bad solution for redo acceleration (as I will attempt to describe below) they could be useful for accelerating read intensive applications. The type of solid state disk used for redo logs use DDR RAM as the storage media. You may decide to discount my advice because I work with one of these SSD manufacturers but I think if you do enough research you will see the point. There are many articles and many more customers who have used SSD to accelerate Oracle.
> Assuming that you are not CPU constrained,
moving the online redo to
high-speed solid-state disk can make a hugedifference.
Do you honestly think this is practical and usable
advice Don? There is HUGE price difference between
SSD and and normal hard disks. Never mind the
following disadvantages. Quoting
(http://en.wikipedia.org/wiki/Solid_state_disk):[
i]
# Price - As of early 2007, flash memory prices are
still considerably higher
per gigabyte than those of comparable conventional
hard drives - around $10
per GB compared to about $0.25 for mechanical
drives.Comment: Prices for DDR RAM base systems are actually higher than this with a typical list price around $1000 per GB. Your concern, however, is not price per capacity but price for performance. How many spindles will you have to spread your redo log across to get the performance that you need? How much impact are the redo logs having on your RAID cache effectiveness? Our system is obviously geared to the enterprise where Oracle is supporting mission critical databases where a hugh return can be made on accelerating Oracle.
Capacity - The capacity of SSDs tends to be
significantly smaller than the
capacity of HDDs.Comment: This statement is true. Per hard disk drive versus per individual solid state disk system you can typically get higher density of storage with a hard disk drive. However, if your goal is redo log acceleration, storage capacity is not your bottleneck. Write performance, however, can be. Keep in mind, just as with any storage media you can deploy an array of solid state disks that provide terabytes of capacity (with either DDR or flash).
Lower recoverability - After mechanical failure the
data is completely lost as
the cell is destroyed, while if normal HDD suffers
mechanical failure the data
is often recoverable using expert help.Comment: If you lose a hard drive for your redo log, the last thing you are likely to do is to have a disk restoration company partially restore your data. You ought to be getting data from your mirror or RAID to rebuild the failed disk. Similarly, with solid state disks (flash or DDR) we recommend host based mirroring to provide enterprise levels of reliability. In our experience, a DDR based solid state disk has a failure rate equal to the odds of losing two hard disk drives in a RAID set.
Vulnerability against certain types of effects,
including abrupt power loss
(especially DRAM based SSDs), magnetic fields and
electric/static charges
compared to normal HDDs (which store the data inside
a Faraday cage).Comment: This statement is all FUD. For example, our DDR RAM based systems have redundant power supplies, N+1 redundant batteries, four RAID protected "hard disk drives" for data backup. The memory is ECC protected and Chipkill protected.
Slower than conventional disks on sequential I/OComment: Most Flash drives, will be slower on sequential I/O than a hard disk drive (to really understand this you should know there are different kinds of flash memory that also impact flash performance.) DDR RAM based systems, however, offer enormous performance benefits versus hard disk or flash based systems for sequential or random writes. DDR RAM systems can handle over 400,000 random write I/O's per second (the number is slightly higher for sequential access). We would be happy to share with you some Oracle ORION benchmark data to make the point. For redo logs on a heavily transactional system, the latency of the redo log storage can be the ultimate limit on the database.
Limited write cycles. Typical Flash storage will
typically wear out after
100,000-300,000 write cycles, while high endurance
Flash storage is often
marketed with endurance of 1-5 million write cycles
(many log files, file
allocation tables, and other commonly used parts of
the file system exceed
this over the lifetime of a computer). Special file
systems or firmware
designs can mitigate this problem by spreading
writes over the entire device,
rather than rewriting files in place.
Comment: This statement is mostly accurate but refers only to flash drives. DDR RAM based systems, such as those Don's books refer to, do not have this limitation.
>
Looking at many of your postings to Oracle Forums
thus far Don, it seems to me that you are less
interested in providing actual practical help, and
more interested in self-promotion - of your company
and the Oracle books produced by it.
.. and that is not a very nice approach when people
post real problems wanting real world practical
advice and suggestions.Comment: Contact us and we will see if we can prove to you that Don, and any number of other reputable Oracle consultants, recommend using DDR based solid state disk to solve redo log performance issues. In fact, if it looks like your system can see a serious performance increase, we would be happy to put you on our evaluation program to try it out so that you can do it at no cost from us.

Standby DB real time redo log apply problem

Hi all,
I am using Oracle 10g to create physical standby db. In the standby
db, normal archived log apply does not have problem, but when I try to
use redo log real time apply and issue command
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
it shows:
ERROR at line 1:
ORA-38500: USING CURRENT LOGFILE option not available without stand
What is the problem??
Thanks a lot !
Steven

Note:3633226.8 from Metalink states:
Setting a standby's RealTimeApply property to ON when there are no standby
redo logs on the standby or the standby is not in SYNC transport, will
seemingly succeed. However, the apply engine will not start. The DRC log
will report an error like ORA-38500. In this case, add standby redo logs
and set the log transport mode for the standby to be SYNC and set the
standby state to ONLINE.
Workaround:
Add Standby Redo Logs on the standby and set the following broker properties
on the standby:
LogXptMode to SYNC and reset RealTimeApply to ON.
Then set the standby state to ONLINE.
HTH

To where does the LGWR write information in redo log buffer ?

Suppose my online redo logfiles are based on filesystems .I want to know to where the LGWR writes information in redo log buffer ? Just write to filesystem buffer or directly write to disk ? And the same case is associated with the DBWR and the datafiles are based on filesystems too ?

It depends on the filesytem. Normally there is also a filesystem buffer too, which is where LGWR would write.Yes but a redo log write must always be a physical write.
From http://asktom.oracle.com/pls/ask/f?p=4950:8:15501909858937747903::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:618260965466
Tom, I was thinking of a scenario that sometimes scares me...
**From a database perspective** -- theoretically -- when data is commited it
inevitably goes to the redo log files on disk.
However, there are other layers between the database and the hardware. I mean,
the commited data doesn't go "directly" to disk, because you have "intermediate"
structures like i/o buffers, filesystem buffers, etc.
1) What if you have commited and the redo data has not yet "made it" to the redo
log. In the middle of the way -- while this data is still in the OS cache -- the
OS crashes. So, I think, Oracle is believing the commited data got to the redo
logs -- but is hasn't in fact **from an OS perspective**. It just "disapeared"
while in the OS cache. So redo would be unsusable. Is it a possible scenario ?
the data does go to disk. We (on all os's) use forced IO to ensure this. We
open files for example with O_SYNC -- the os does not return "completed io"
until the data is on disk.
It may not bypass the intermediate caches and such -- but -- it will get written
to disk when we ask it to.
1) that'll not happen. from an os perspective, it did get to disk
Message was edited by:
Pierre Forstmann

Redo log wait

Dear All,
We are usinf ecc5 ans the databse oacle 9i on wondows 2003I have notice that the
Redo log wait S has been suddenly increase in number   690
Please suggest what si the problem and to solve it.
Data buffer
Size              kb      1,261,568
Quality            %           96.2
Reads                 4,234,462,711
Physical reads          160,350,516
          writes           3,160,751
Buffer busy waits         1,117,697
Buffer wait time   s          3,507
Shared Pool
Size              kb        507,904
DD-Cache quality   %           84.3
SQL Area getratio %           95.6
         pinratio %           98.8
      reloads/pins %         0.0297
Log buffer
Size              kb          1,176
Entries                  11,757,027
Allocation retries              722
Alloc fault rate   %            0.0
*Redo log wait      s            690*
Log files (in use)            8( 8)
Calls
User calls               41,615,763
     commits                367,243
     rollbacks                7,890
Recursive calls         100,067,593
Parses                    7,822,590
User/Recursive calls            0.4
Reads / User calls            101.8
Time statistics
Busy wait time     s        697,392
CPU time           s         42,505
Time/User call    ms             18
Sessions busy      %           9.26
CPU usage          %           4.51
CPU count                         2
Redo logging
Writes                    1,035,582
OS-Blocks written        14,276,056
Latching time      s              1
Sessions busy      %           9.26
CPU usage          %           4.51
CPU count                         2
Redo logging
Writes                    1,035,582
OS-Blocks written        14,276,056
Latching time      s              1
Write time         s            806
Mb written                    6,574
Table scans & fetches
Short table scans           607,891
Long table scans             32,468
Fetch by rowid        1,620,054,083
   by continued row         761,131
Sorts
Memory                    3,046,669
Disk                             32
Rows sorted             446,593,854
Regards,
Shiva

Hi Stefan,
As per the doc you have suggest. The details are as following.
In the day there is only 24 log switch , but in hour there is no more than 10 to 15 as per doc ,so ti is very less.
The DD-Cache quality   %           84.1 is less
The elapsed time since start
Elapsed since start (s)       540,731
Log buffer
Size              kb          1,176
Entries                  13,449,901
Allocation retries              767
Alloc fault rate   %            0.0
*Redo log wait      s            696*
   Log files (in use)            8( 8)
Check DB Wait times
TCode ST04->Detail Analysis Menu->Wait Events
Statistics on total waits for an event
Elapsed time:             985 s
since reset at 09:34:06
Type   Client   Sessions      Busy wait            Total wait           Busy wait
                            time (ms)    time (ms)            time (%)
USER   User          40            1,028,710           17,594,230        5.85
BACK   ARC0           1                2,640            1,264,410        0.21
BACK   ARC1           1                  540            1,020,400        0.05
BACK   CKPT           1                  950              987,490        0.10
BACK   DBW0           1                  130              983,920        0.01
BACK   LGWR           1                  160              986,430        0.02
BACK   PMON           1                    0              987,000        0.00
BACK   RECO           1                   10            1,800,010        0.00
BACK   SMON           1                3,820            1,179,410        0.32
Disk based sorts
Sorts
Memory                    3,443,693
Disk                             41
Rows sorted             921,591,847
Check DB Shared Pool Quality
Shared Pool
Size              kb        507,904
DD-Cache quality   %           84.1
SQL Area getratio %           95.6
pinratio %                           98.8
      reloads/pins %         0.0278
V$LOGHIST
THREAD#   SEQUENCE#   FIRST_CHANGE#   FIRST_TIME            SWITCH_CHANGE#
1         31612       381284375       2008/11/13 00:01:29   381293843
1         31613       381293843       2008/11/13 00:12:12   381305142
1         31614       381305142       2008/11/13 03:32:39   381338724
1         31615       381338724       2008/11/13 06:29:21   381362057
1         31616       381362057       2008/11/13 07:00:39   381371178
1         31617       381371178       2008/11/13 07:13:01   381457916
1         31618       381457916       2008/11/13 09:26:17   381469012
1         31619       381469012       2008/11/13 10:27:19   381478636
1         31620       381478636       2008/11/13 10:59:54   381488508
1         31621       381488508       2008/11/13 11:38:33   381498759
1         31622       381498759       2008/11/13 12:05:14   381506545
1         31623       381506545       2008/11/13 12:33:48   381513732
1         31624       381513732       2008/11/13 13:08:10   381521338
1         31625       381521338       2008/11/13 13:50:15   381531371
1         31626       381531371       2008/11/13 14:38:36   381540689
1         31627       381540689       2008/11/13 15:02:19   381549493
1         31628       381549493       2008/11/13 15:43:39   381556307
1         31629       381556307       2008/11/13 16:07:47   381564737
1         31630       381564737       2008/11/13 16:39:45   381571786
1         31631       381571786       2008/11/13 17:07:07   381579026
1         31632       381579026       2008/11/13 17:37:26   381588121
1         31633       381588121       2008/11/13 18:28:58   381595963
1         31634       381595963       2008/11/13 20:00:41   381602469
1         31635       381602469       2008/11/13 22:23:20   381612866
1         31636       381612866       2008/11/14 00:01:28   381622652
1         31637       381622652       2008/11/14 00:09:52   381634720
1         31638       381634720       2008/11/14 03:32:00   381688156
1         31639       381688156       2008/11/14 07:00:30   381703441
14.11.2008         Log File information from control file                                10:01:32
Group     Thread    Sequence   Size         Nr of     Archive          First           Time 1st SCN
Nr        Nr        Nr         (bytes)      Members        Status      Change Nr       in log
1         1         31638      52428800     2         YES INACTIVE    381634720       2008/11/14 03:32:00
2         1         31639      52428800     2         YES INACTIVE    381688156       2008/11/14 07:00:30
3         1         31641      52428800     2         NO   CURRENT     381783353       2008/11/14 09:50:09
4         1         31640      52428800     2         YES ACTIVE      381703441       2008/11/14 07:15:07
Regards,

Redo Log - Storage Consideration

I have one question about redo Log storage guidelines, that i red in one article on metalink
In that article recommended place redo log on raid device level 1 (*Mirroring*),
and NOT recommended place it on raid 10 or 5
If you know - explain detailed please, why it is so?
Scientia potentia est

I haven't seen a raid 0, raid 1, or raid 5 filesystem in the last 5 years. Most companies now use SAN or NAS.
That is not entirely true is it Robert. Most default SAN installation are set up as Raid5 and are presented to the users as filesystem mounts.
I agree entirely re the benefits of using ASM
The reason why redo logs are recommended to be on Raid1 (1+0, 10) and not Raid5 is that redo logs write differently to all other oracle datafiles as they are written sequentially by the LGWR process. Raid5 involves writing parity data to another disk and therefore adds additional writes to what can already be a very intensive single-streamed process
John
www.jhdba.wordpress.com

질문-Redo LOG 와 RollBack Segment 와의 상관관계에 대해서

Redo LOG 와 RollBack Segment 와의 상관관계 및 기능에 대해서 정확하게 알고 싶은데여?

저도 이부분에 대해서 한참 고민을 해봤고..
작년인가에.. 미국 오라클 본사에 있는 아는 분하고..
한국 오라클에서 십여년간 일하신 분에게도 여쭈어 보았는데..;;;
오라클은 SCN기반이고, redo log 와 rollback segment가 모두
scn기반으로 움직인다는 것의 상관관계를 빼고는 전혀 두개는
서로 연관성이 없다고 합니다.
redo log는 DB가 비정상종료되었을 경우에, commit을 했으나
데이터파일에 적용하지 못한 데이터에 대해서 rollforward를 수행하고,
또한 DB에 대한 변경사항대해서 저장만 하는 기능을 할 뿐 redo를
가지고 rollback을 하지는 않습니다. 즉 redo는 말 그대로 REDO
다시쓰기(재실행) 이지요. commit했으나 데이터파일에 쓰지 않은 데이터를
다시쓰기(재실행)하는 기능입니다.
그렇다면.. rollback segment는 commit하지 않은 데이터에 대해서
rollback을 하는 기능을 가집니다. rollforward와는 전혀 관계가
없겠죠..
이 두가지 작용을 통해서 DB에서 트랜잭션의 rollforward, rollback을
수행하나 그것은 SCN을 기반으로 작동 될 뿐 서로 어떤 연관성은
가지고 있지 않다고 합니다.
글 수정:
민천사 (민연홍)
그렇다면 대량 트랜잭션이 일어나고 redo log에 write하는 데이터와
undo에 쓰는 데이터는 관련성이 없을까요? 이 때 redo log는 트랜잭션에
대한 복구를 위한 로그를 남기는 역할 일 뿐이지 undo와 관련성을
가지지 않습니다. 관련성을 따지자면 "redo는 undo로 복제되는 실 데이터(변경전 데이터)에
대해서 복구로그를 쌓는다"는 것이됩니다. 차후에 트랜잭션 rollback
은 redo를 참조하는 것이 아니라 undo만을 참조하고, rollback하는
과정의 로그를 redo에 기록하는 것일 뿐입니다.

Problem while archiving the redo Log

Hi all,
I m having few issues in my server...
I get the following error in the alert log of oracle..
There are many errors
1) No space left on device
2) ARC0: I/O error 19502 archiving log 1 to
'/oracle/admin/SNM/arch/arch_1_393_668727286.arc'
ARCH: Archival stopped, error occurred. Will continue retrying
3) ORA-16014: log 1 sequence# 393 not archive*d, no available destinations*
Also please find the v$log file query
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
FIRST_CHANGE# FIRST_TIM
1 1 405 1073741824 1 NO CURRENT
60275455 20-OCT-09
2 1 403 1073741824 1 NO INACTIVE
59987366 19-OCT-09
3 1 404 1073741824 1 NO INACTIVE
60125083 20-OCT-09
Also the diskspace is almost 97%.
Can anyone let me know whether archival of redo log files is causing the issue here?
If so if i stop the archival of logs ,will it solve the problem?
Can anyone help me on this?
Mon Oct 19 09:54:39 2009
Errors in file /oracle/admin/SNM/bdump/snm_arc0_23831.trc:
ORA-19502: write error on file
"/oracle/admin/SNM/arch/arch_1_393_668727286.arc", blockno
577537 (blocksize=512)
ORA-27063: number of bytes read/written is incorrect
SVR4 Error: 28: No space left on device
Additional information: -1
Additional information: 1048576
ORA-19502: write error on file
"/oracle/admin/SNM/arch/arch_1_393_668727286.arc", blockno
559105 (blocksize=512)
Mon Oct 19 09:54:39 2009
Errors in file /oracle/admin/SNM/bdump/snm_arc0_23831.trc:
ORA-19502: write error on file
"/oracle/admin/SNM/arch/arch_1_393_668727286.arc", blockno
577537 (blocksize=512)
ORA-27063: number of bytes read/written is incorrect
SVR4 Error: 28: No space left on device
Additional information: -1
Additional information: 1048576
ORA-19502: write error on file
*"/oracle/admin/SNM/arch/arch_1_393_668727286.arc", blockno*
*559105 (blocksize=512)*
ARC0: I/O error 19502 archiving log 1 to
'/oracle/admin/SNM/arch/arch_1_393_668727286.arc'
ARCH: Archival stopped, error occurred. Will continue retrying
Mon Oct 19 09:54:40 2009
ORACLE Instance SNM - Archival Error
Mon Oct 19 09:54:40 2009
ORA-16038: log 1 sequence# 393 cannot be archived
ORA-19502: write error on file "", blockno (blocksize=)
ORA-00312: online log 1 thread 1: '/oracle/oradata/SNM/redo01.log'
Mon Oct 19 09:54:40 2009
Errors in file /oracle/admin/SNM/bdump/snm_arc0_23831.trc:
ORA-16038: log 1 sequence# 393 cannot be archived
ORA-19502: write error on file "", blockno (blocksize=)
ORA-00312: online log 1 thread 1: '/oracle/oradata/SNM/redo01.log'
Mon Oct 19 09:54:40 2009
ARCH: Archival stopped, error occurred. Will continue retrying
Mon Oct 19 09:54:40 2009
ORACLE Instance SNM - Archival Error
Mon Oct 19 09:54:40 2009
ORA-16014: log 1 sequence# 393 not archived, no available destinations
ORA-00312: online log 1 thread 1: '/oracle/oradata/SNM/redo01.log'
Mon Oct 19 09:54:40 2009
Errors in file /oracle/admin/SNM/bdump/snm_arc1_23833.trc:
ORA-16014: log 1 sequence# 393 not archive*d, no available destinations*
ORA-00312: online log 1 thread 1: '/oracle/oradata/SNM/redo01.log'
Mon Oct 19 10:00:16 2009
ARC0: Encountered disk I/O error 19502
Mon Oct 19 10:00:16 2009
ARC0: Closing local archive destination LOG_ARCHIVE_DEST_1:
'/oracle/admin/SNM/arch/arch_1_393_668727286.arc' (error
19502)
(SNM)

yes it is the production server.
Also the arch folder contains 2 GB file - arc file....
Does disable of archival will solve the issue?
I am try to clear the space or move to some other location..But the thing is my application files is of 3 to 4 GB.remaining thing is of dbf files.
6564 drwxr-x--- 2 oracle oinstall 512 Oct 21 2008 .
6563 drwxr-x--- 3 oracle oinstall 512 Oct 21 2008 ..
6568 -rw-r----- 1 oracle oinstall 7061504 Sep 30 11:58 control01.ctl
6569 -rw-r----- 1 oracle oinstall 7061504 Sep 30 11:58 control02.ctl
6570 -rw-r----- 1 oracle oinstall 7061504 Sep 30 11:58 control03.ctl
9283 -rw-r----- 1 oracle oinstall 5128192 Sep 30 10:21 mfxpima.dbf
6600 -rw-r----- 1 oracle oinstall 17179877376 Sep 30 11:50 muse0.dbf
6572 -rw-r----- 1 oracle oinstall 1073742336 Sep 30 08:10 redo01.log
6573 -rw-r----- 1 oracle oinstall 1073742336 Sep 30 10:16 redo02.log
6574 -rw-r----- 1 oracle oinstall 1073742336 Sep 30 11:58 redo03.log
6578 -rw-r----- 1 oracle oinstall 19293806592 Sep 30 11:58 sysaux01.dbf
6576 -rw-r----- 1 oracle oinstall 1698701312 Sep 30 11:56 system01.dbf
6579 -rw-r----- 1 oracle oinstall 2147491840 Sep 30 11:04 temp01.dbf
6577 -rw-r----- 1 oracle oinstall 4084211712 Sep 30 11:58 undotbs01.dbf
6580 -rw-r----- 1 oracle oinstall 5251072 Sep 30 10:21 users01.dbf
What as to be done....in this case....
Help me out...
I have no other option ....
SRinivasan

Urgent Help - Redo Log problem

Hi,
I have an implementation of Oracle 9i. Presently I have got 3 redo log groups with 2 members each. There are lot of updation and insertion of records going on with few tables. When the load increases the DB lands in a hang state and in the Log I get this message
Thread 1 cannot allocate new log, sequence 234
All online logs needed archiving
Current log# 1 seq# 233 mem# 0: D:\ORACLE\ORADATA\ORCL\REDO01.LOG
Current log# 1 seq# 233 mem# 1: D:\ORACLE\ORADATA\ORCL\REDO04.LOG
Can any one help me in solving this problem. I tried to Switch the log files but as they already are waiting for archiving so no use.
Any help on this will be highly helpfull to me as I am in Live environment.
Arvind

The way the log groups work is.
Log Writer(lgwr) starts writing to group 1. When group 1 fills up, it switches to group 2. When lgwr starts writing to group 2, the Archiver (arc) wakes up and starts writing group 1 to the archive file. When group 2 fills up lgwr start writing group 3 and arc archives group 2 once it has finished writing group 1. When group 3 fills up, lgwr starts writing to group 1 again, assuming that arc has finished writing group 1 to the archive.
In your case, it appears that arc is still writing group 1 when lgwr wants to use it again, so the database stalls until arc is finished writing group 1.
Fundamentally you have two choices. You can increase the size of each file in each log group, so they will fill up less often. However, this will also make arc take longer to archive the group. If you can gain enough time based on slower filling to offset the slower writing you should be ok.
The other option is to add a few more groups of the same size as the existing groups. This will give lgwr more groups to use before needing to start re-using earlier groups.
Typically, in our systems we run between 4 and 6 64M log groups and never see these hangs.
HTH
John

Where RFS exactly write redo data ? ( archived redo log or standby redo log ) ?

Good Morning to all ;
I am getting bit confused from oracle official link . REF_LINK : Log Apply Services
Redo data transmitted from the primary database is received by the RFS on the standby system ,
where the RFS process writes the redo data to either archived redo log files or standby redo log files.
In standby site , does rfs write redo data in any one file or both ?
Thanks in advance ..

Hi GTS,
GTS (DBA) wrote:
Primary & standby log file size should be same - this is okay.
1) what are trying to disclose about largest & smallest here ? - You are confusing.
Read: http://docs.oracle.com/cd/E11882_01/server.112/e25608/log_transport.htm#SBYDB4752
"Each standby redo log file must be at least as large as the largest redo log file in the redo log of the redo source database. For administrative ease, Oracle recommends that all redo log files in the redo log at the redo source database and the standby redo log at a redo transport destination be of the same size."
GTS (DBA) wrote:
2) what abt group members ? should be same as primary or need to add some members additionally. ?
Data Guard best practice for performance, is to create one member per each group in standby DB. on standby DB, one member per group is reasonable enough. why? to avoid write penalty; writing to more than one log files at the standby DB.
SCENARIO 1: if in your source primary DB you have 2 log member per group, in standby DB you can have 1 member per group, additionally create an extra group.
primary
standby
Member per group
2
1
Number of log group
4
5
SCENARIO 2: you can also have this scenario 2 but i will not encourage it
primary
standby
Member per group
2
2
Number of log group
4
5
GTS (DBA) wrote:
All standby redo logs of the correct size have not yet been archived.
- at this situation , can we force on standby site ? any possibilities ?
you can not force it , just size your standby redo files correctly and make sure you don not have network failure that will cause redo gap.
hope there is clarity now
Tobi

Physical standby database standby redo log problem

Hello
We have a physical standby database , I've created some standby redo log files but my problem is that they aren't used,
their status in v$stanby_log view is UNASSIGNED
and I see this message (ORA-16086: standby database does not contain available standby log files) in primary database alert_log file
while when I run "alter system switch logfile" in the primary database it transfer redo logs to the physsical standby database
and archive log file will be created in standby database
I've even recreated the standby redo log files and I added new ones to them but the problem wasn't solved
Do you know what is problem ?
elect group#,THREAD#,BYTES,STATUS from V$STANDBY_LOG;
group#     THREAD#      BYTES       STATUS
1                   0                   524288000                   UNASSIGNED
2                   0                   524288000                   UNASSIGNED
3                   0                   524288000                   UNASSIGNED
8                   0                   524288000                   UNASSIGNED
9                   0                   524288000                   UNASSIGNED
10                   0                   524288000                   UNASSIGNED
select group#,THREAD#,BYTES,MEMBERS,STATUS from v$log;
group#                    THREAD#                    BYTES                    MEMBERS                    STATUS
4                   1                   524288000                   2                   CLEARING
7                   1                   524288000                   2                   CLEARING_CURRENT
6                   1                   524288000                   2                   CLEARING
5                   1                   524288000                   2                   CLEARING
thanks

Hello Anurag
Thank you for your reply
I have found some issue in the standby database alert_log too , in the standby database alert_log it has been written:
RFS[782]: Assigned to RFS process 3919
RFS[782]: Identified database type as 'physical standby'
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
RFS[782]: No standby redo logfiles selected (reason:6)
Sun Jan 31 13:59:43 2010
Errors in file /u01/app/oracle/admin/tehrep/udump/tehrep_rfs_3919.trc:
ORA-16086: standby database does not contain available standby log files
Sun Jan 31 13:59:48 2010
RFS[781]: Archived Log: '/disks/sda/tehrep/archivelogs/1_6516_670414641.dbf'
Sun Jan 31 13:59:50 2010
and the context "/u01/app/oracle/admin/tehrep/udump/tehrep_rfs_3919.trc" is below :
+/u01/app/oracle/admin/tehrep/udump/tehrep_rfs_3919.trc+
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name:    Linux
Node name:      linserver2.com
Release:        2.6.9-42.ELsmp
Version:        #1 SMP Wed Jul 12 23:27:17 EDT 2006
Machine:        i686
Instance name: tehrep
Redo thread mounted by this instance: 1
Oracle process number: 58
Unix process pid: 3919, image: [email protected]
*** SERVICE NAME:() 2010-01-31 13:59:43.865
*** SESSION ID:(109.1225) 2010-01-31 13:59:43.865
KCRRFLAS
KCRRSNPS
No space in recovery area for active standby redo logs
The primary database is operating in MAXIMUM PROTECTION
or MAXIMUM AVAILABILITY mode, and the standby database
does not contain adequate disk space in the recovery area
to safely archive the contents of the standby redo logfiles.
ORA-16086: standby database does not contain available standby log files
when I saw this line "No space in recovery area for active standby redo logs" I thought that STANDBY_ARCHIVE_DEST parameter points where that there is no enough space , but when I consider I found out that points a directory on disk a "sda" that has enough space , I don't know what that means
by the way, at below I've written a section of the primary database alert_log context and "lgwr" trace file around Sun Jan 31 13:30:34 2010
alert_log :
ORA-16086: standby database does not contain available standby log files
Sun Jan 31 13:30:34 2010
LGWR: Failed to archive log 7 thread 1 sequence 6512 (16086)
Thread 1 advanced to log sequence 6512
Current log# 7 seq# 6512 mem# 0: /disks/sdb/tehrep/redo71.log
Current log# 7 seq# 6512 mem# 1: /disks/sdd/tehrep/redo72.log
LNSc started with pid=53, OS id=11451
Sun Jan 31 13:36:34 2010
Errors in file /u01/app/oracle/admin/tehrep/bdump/tehrep_lgwr_3692.trc:
ORA-16086: standby database does not contain available standby log files
Sun Jan 31 13:36:34 2010
LGWR: Failed to archive log 5 thread 1 sequence 6513 (16086)
Thread 1 advanced to log sequence 6513
Current log# 5 seq# 6513 mem# 0: /disks/sdb/tehrep/redo51.log
Current log# 5 seq# 6513 mem# 1: /disks/sdd/tehrep/redo52.log
*/u01/app/oracle/admin/tehrep/bdump/tehrep_lgwr_3692.trc file :*
Error 16086 creating standby archive log file at host '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=linserver2.com
+)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=tehrep_XPT.com)(INSTANCE_NAME=tehrep)(SERVER=dedicated)))'+
*** 2010-01-31 13:30:34.712 60679 kcrr.c
LGWR: Attempting destination LOG_ARCHIVE_DEST_3 network reconnect (16086)
*** 2010-01-31 13:30:34.712 60679 kcrr.c
LGWR: Destination LOG_ARCHIVE_DEST_3 network reconnect abandoned
ORA-16086: standby database does not contain available standby log files
*** 2010-01-31 13:30:34.712 60679 kcrr.c
LGWR: Error 16086 creating archivelog file '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=linserver2.com)(PORT=1521
+)))(CONNECT_DATA=(SERVICE_NAME=tehrep_XPT.com)(INSTANCE_NAME=tehrep)(SERVER=dedicated)))'+
*** 2010-01-31 13:30:34.712 58941 kcrr.c
kcrrfail: dest:3 err:16086 force:0 blast:1
Receiving message from LNSc
*** 2010-01-31 13:30:34.718 55444 kcrr.c
Making upidhs request to LNSc (ocis 0x0xb648db48). Begin time is <01/31/2010 13:30:30> and NET_TIMEOUT <180> seconds
NetServer pid:11196
*** 2010-01-31 13:30:38.718 55616 kcrr.c
upidhs done status 0
*** 2010-01-31 13:36:31.062
LGWR: Archivelog for thread 1 sequence 6513 will NOT be compressed
*** 2010-01-31 13:36:31.062 53681 kcrr.c
+Initializing NetServer[LNSc] for dest=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=linserver2.com)(PORT=1521)))(CO+
NNECT_DATA=(SERVICE_NAME=tehrep_XPT.com)(INSTANCE_NAME=tehrep)(SERVER=dedicated))) mode SYNC
LNSc is not running anymore.
New SYNC LNSc needs to be started
Waiting for subscriber count on LGWR-LNSc channel to go to zero
Subscriber count went to zero - time now is <01/31/2010 13:36:31>
Starting LNSc ...
Waiting for LNSc to initialize itself
*** 2010-01-31 13:36:34.116 53972 kcrr.c
+Netserver LNSc [pid 11451] for mode SYNC has been initialized+
Performing a channel reset to ignore previous responses
+Successfully started LNSc [pid 11451] for dest (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=linserver2.com)(PORT=1+
+521)))(CONNECT_DATA=(SERVICE_NAME=tehrep_XPT.com)(INSTANCE_NAME=tehrep)(SERVER=dedicated))) mode SYNC ocis=0x0xb648db48+
*** 2010-01-31 13:36:34.116 54475 kcrr.c
+Making upiahm request to LNSc [pid 11451]: Begin Time is <01/31/2010 13:36:31>. NET_TIMEOUT = <180> seconds+
Waiting for LNSc to respond to upiahm
*** 2010-01-31 13:36:34.266 54639 kcrr.c
upiahm connect done status is 0
Receiving message from LNSc
Receiving message from LNSc
Destination LOG_ARCHIVE_DEST_3 is in STANDBY RESYNCHRONIZATION mode
Receiving message from LNSc

Problem with Whole Database Online+Redo log Backup

Dear Marcus Sir,
I am facing while taking "Whole Database Online+Redo log Backup" through DB13 T-Code.
Below is the "Problem part of the Backup log", however if you need I will send you full log.
Hope you will find out problem soon
#FILE..... /oracle/ANP/sapdata2/sr3_8/sr3.data8
#SAVED.... sr3.data8 ANPB260810/12
BR0280I BRBACKUP time stamp: 2010-08-27 11.03.22
BR0063I 9 of 51 files processed - 19400.070 MB of 135986.469 MB done
BR0204I Percentage done: 14.27%, estimated end time: 11:47
BR0001I *******___________________________________________
BR0202I Saving /oracle/ANP/sapdata2/sr3_9/sr3.data9
BR0203I to /dev/rmt0.1 ...
BR0278E Command output of 'LANG=C dd obs=1024K bs=1024K if=/oracle/ANP/sapdata2/sr3_9/sr3.data9 of=/dev/rmt0.1':
dd read error: I/O error
462+0 records in
462+0 records out
BR0280I BRBACKUP time stamp: 2010-08-27 11.03.36
BR0279E Return code from 'LANG=C dd obs=1024K bs=1024K if=/oracle/ANP/sapdata2/sr3_9/sr3.data9 of=/dev/rmt0.1': 2
BR0222E Copying /oracle/ANP/sapdata2/sr3_9/sr3.data9 to/from /dev/rmt0.1 failed due to previous errors
BR0280I BRBACKUP time stamp: 2010-08-27 11.03.41
BR0317I 'Alter tablespace PSAPSR3 end backup' successful
BR0056I End of database backup: bedziydp.ant 2010-08-27 11.03.36
BR0280I BRBACKUP time stamp: 2010-08-27 11.03.41
BR0054I BRBACKUP terminated with errors
Warm Regards
Ahsan

Hi,
since you are getting a read error, it might as well be, that your datafile is defective.
Try the same dd-command to /dev/null, to see if it is possible to read the entire file.
First make sure that your null-device is existing, otherwise you might face a root-fs full problem.
dd obs=1024K bs=1024K if=/oracle/ANP/sapdata2/sr3_9/sr3.data9 of=/dev/null
or try a dbverify on it, which would also read the entire file and do a checksum test.
brbackup -c -u / -m /oracle/ANP/sapdata2/sr3_9/sr3.data9 -t online -w only_dbv
Good luck
Volker

Checksum problem in redo log file.

hi,
I hv a checksum problem in my redo log file.
Details.
1. I m unable to open the database but able to mount it.
2. Error says checksum error in current redolog group 2, so can't recover thread 1.
3. Error in group 2 which is active group.
In Mount stage ...
4. I Can't switch group as database is not open.
5. I . can't drop as group is active/current.
6. I can't clear logfile as thread 1 is not recovered.
7. I . can't recover through " Recover Database" command
Pls help,
Thanks in adv.
Rup

Try out these steps provided below, this would make your problem gone.
sql > shutdown immediate ;
sql > startup mount ;
sql > recover database until cance ;
sql > alter database open resetlogs ;
make sure to take database backup
hare krishna
Alok

How does LGWR write redo log files, I am puzzled!

The document says:
The LGWR concurrently writes the same information to all online redo log files in a group.
my undestandint of the sentence is following for example
group a includes file(a1, a2)
group b includes file(b1, b2)
LGWR write file sequence: write a1, a2 concurrently; afterwards write b1, b2 concurrently.
my question is following:
1、 my understanding is right?
2、 if my understanding is right, I think that separate log file in a group should save in different disk. if not, it cann't guarantee correctly recovery.
my opinion is right?
thanks everyone!

Hi,
>>That is multplexing...you should always have members of a log file in more than 1 disk
Exactly. You can keep multiple copies of the online redo log file to safeguard against damage to these files. When multiplexing online redo log files, LGWR concurrently writes the same redo log information to multiple identical online redo log files, thereby eliminating a single point of redo log failure. In addition, when multiplexing redo log files, it is preferable to keep the members of a group on different disks, so that one disk failure will not affect the continuing operation of the database. If LGWR can write to at least one member of the group, database operation proceeds as normal.
Cheers
Legatti

Upon commit, lgwr writes to redo logs but dbwr does not write to datafiles

Guys,
Upon issuing a commit statement, in which scenarios, the lgwr only writes to redo logs but the dbwr does not at all write to the datafiles?
Thanx.

The default behaviour is - on Commit, the lgwr writes to the redo logs immediately, but it may not get immediately written to the datafiles by the dbwr, but sooner or later it would (based on certain conditions). The only situation, which I can think of, when dbwr may not be able to write is datafiles is when the databases crashes, after the commit and before the DBWR could write to the datafiles.
Not sure, what you are exactly looking for, but hope this helps.
Thanks
Chandra Pabba

Redo Log Writer Problem

Similar Messages

Maybe you are looking for