I am that specific customer for whom that bug was opened. If you need more information on this then let me know. This issue is still being worked on by the group which wrote 9idataguard and the problem is not diagnosed yet.
What we noticed was that some archiver-rfs transfer processes become extremely slow in sending data while others were ok. So I implemented a job which runs every 10 minutes, looks for archvielog transfers which have taken more than 25 minutes. Kills those processes and then rfs spawns new processes which work just fine. We are using 3 log archive dests 1) local 2) local standby 3) DR standby 2000 miles away. We generate more than 300GB archive logs/day I do not receive messages that I send to the list, can someone help me out with this problem. Thanks Shaleen ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Tuesday, November 26, 2002 3:44 PM > I see there has already been a lot of discussion on this topic. I would like to throw out one more possibility. It could be related to bug 2564886. If you read the bug on metalink, it probably won't make any sense because it is written for a specific customer. However, I have a similar problem and Oracle has classified my tar as related to this bug. Basically, if you use more than one log_arch_dest occasionally one of the archive process will just take forever. You didn't mention if you were using that parameter or if you are using a standby database so it may not apply to you. While oracle is working on this bug, we have disabled the second log_arch_dest and we have a script to manually check every minute and copy the archive logs to the other destination. This has helped us. Maybe it can help you to. > > We are on Sun Solaris 7 with 9.2.0.1 but the bug goes back to 9.0.1.3 so it probably applies to 9.2.0.2 also. > > HTH, > John > > >>> [EMAIL PROTECTED] 11/26/02 10:00AM >>> > We are on 9.2.0.2, Solaris 8 on Sunfire 3800 with 16 GB memory and 128 MB > on a hardware-controlled, mirrored RAID5 StorEdge T-3 Array. > > Periodically throughout the day the LGWR background process clocks 20+ > minutes of CPU time while actual CPU usage is quite low. I ran a statspack > report and for a 45-minute period that included the slow LGWR process. > > The top 5 timed events in my 45-minute report are: > > CPU time 1,295 60.41 > db file sequential read 392,516 341 15.91 > db file scattered read 70,245 168 7.85 > log file sync 26,916 133 6.22 > library cache pin 22 59 2.76 > > (Now that the top 5 is "timed" events, 3 spots almost always include CPU > and the db file reads, so I only get two other events, usually log file > sync, sometimes enqueue or latch free.) > > Statspack also shows the log file parallel write had 28,589 timeouts in > that 45 minute period--rather typical for us. > > I have session_cached_cursors set to 150. > > I am considering the following: > > 1. Removing my own redo log duplexing (mirroring) since redo logs are on > the mirrored, hardware-controlled RAID5 disk array. (I know, I know) > My sysadmin talked to the sun engineer yesterday and he said this is > "old school" thinking that redo logs should not be on RAID5. He said > because the RAID controller caches to memory all IO requests from > the CPUs, all physical writes to disk are done behind the scenes > (known as writebehind). He says the system is NOT waiting for IO. > > 2. Increasing redo log size (again). For the most part, log switches > average 2.5 per day, although there were 20 times in the last month of 3-7 > switches in a half hour. My logs are about 100 MB in 2 groups of 20 members > each. > > 3. Upping the session_cached_cursors to ? (in response to the library cache > pin event). > > Or is there a better option I'm overlooking? > > I would appreciate some advise on the best approach to resolve the slow > LGWR process, especially your thoughts on option 1. > > Thanks, > Debi > Deborah Lorraine, DBA > University of California, Davis > [EMAIL PROTECTED] > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Deborah Lorraine > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: John Carlson > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: orafaq INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
