Do we need to tune the wait event if total_timeouts column from v$system_event corresponding to that wait event is 0 or not increasing? Though the value in time_waited is high. The instance has been rebooted 3-4 days ago.
Printable View
Do we need to tune the wait event if total_timeouts column from v$system_event corresponding to that wait event is 0 or not increasing? Though the value in time_waited is high. The instance has been rebooted 3-4 days ago.
it depends on the wait event.
Any comments after having a look at this:
Don't be lazy and use the code tagsCode:Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
db file sequential read 15,425 0 121 8 2.1
direct path read 190,330 0 109 1 25.5
log file parallel write 13,674 0 34 2 1.8
log file sync 5,922 0 30 5 0.8
Why would I do that when you can post it properly with wrap code tags? :)Quote:
Originally Posted by mahajanakhil198
The avg wait time (ms) for the top events are 8, 1, 2, 5. When these numbers are not very high, should I need to worry about the events? No.
Did any user complaint about performance?
For an instance running for four days wait events suggest very little activity.
"db file scatered read" doesn't even show on your top wait events.
Is anybody complaining about performance? - if this is the case address the specific query user is complaining about.
Yes, there are complaints. All I am supposed to do is to find something wrong if it is there. I checked out the memory structures, etc. Everything seemed to be alright. I had a doubt about wait events. So just felt like asking it. I would collect more data on Monday and then share it.
And Yes, I wanted to represent the above output in the righteous manner but after so many attempts, I just couldn't find the right option. Thanks anyways!
1- Identify the top five complains - start for the ones bothering management.Quote:
Originally Posted by mahajanakhil198
2- Identify offending queries.
3- Fine tune offending queries.
4- Once offending queries are fixed document execution plan, cardinality of involved tables and, response time - tkprof-ed trace wouldn't hurt.
5- Go to #1