"[STANDBY] ExecuteThread" (some of threads happening to STANDBY)

Question

Hi,
I am using weblogic 9.2 version . Some of my threads are going into STANDBY mode , i think they are facing deadlock condtion.
After restarting the managed server with in some time some of the threads displaying as:
"[STANDBY] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'" waiting for lock weblogic.work.ExecuteThread@1485e8d WAITING
     java.lang.Object.wait(Native Method)
     java.lang.Object.wait(Object.java:474)
     weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:165)
     weblogic.work.ExecuteThread.run(ExecuteThread.java:186)
"[STANDBY] ExecuteThread: '29' for queue: 'weblogic.kernel.Default (self-tuning)'" waiting for lock weblogic.work.ExecuteThread@14d8300 WAITING
     java.lang.Object.wait(Native Method)
     java.lang.Object.wait(Object.java:474)
     weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:165)
     weblogic.work.ExecuteThread.run(ExecuteThread.java:186)
Anybody pls tell me why this problem is coming and please help me with the solution to get rid of above problem.
Thanks in Advance,
Krikar

Answer 1

OK, so all you logs are getting shipped and applied according to v$archived_log. That is good news.
Not sure you have a problem. IDLE or BUSY are the only two results of v$archive_processes (STATE). I would expect this when using Data Guard,
something is always busy.
v$archive_processes is generally used to see ARCH process is active or not. I assume your query was on the Primary side and even if you defer them, the ARCH will probably still be active. Will post and check mine.
After the check
I set LOG_ARCHIVE_MAX_PROCESSES=30 on my system and at this time of the day they are all idle even on the most used database. What is your LOG_ARCHIVE_MAX_PROCESSES setting?
Edited by: mseberg on Jan 11, 2011 4:18 AM
Run this query to determine how often log switches are occurring:
SELECT ROUND(AVG(1440 * (b.first_time - a.first_time)), 0) "Log switch
time - minutes"
FROM v$loghist a, v$log b
WHERE b.sequence# = a.sequence# + 1
AND a.sequence# = (SELECT MAX(sequence#) FROM v$loghist)
ORDER BY a.sequence#;
My gut instinct is your redo my be too small. You can change the redo size but you have no direct control over the ARCH process. This query returns 10 (minutes)
on my system. I'm thinking yours will be must lower.
MS
Edited by: mseberg on Jan 11, 2011 4:26 AM
Even later they as mostly idle with a decent load on them. My bet is you could bounce the server and they would return to BUSY. Still thinking log size, it make sense when you think about it, if all your redo were 1M instead of 100M the ARCH process would be very busy all the time.
Edited by: mseberg on Jan 11, 2011 7:32 AM