Comments on: Case Study: Statspack/AWR Latch Waits (Part 1) http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/ Jeremy Schneider Wed, 30 Nov 2011 21:26:13 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Case Study: Statspack/AWR Latch Waits (Part 2) : Ardent Performance Computing http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/#comment-471 Case Study: Statspack/AWR Latch Waits (Part 2) : Ardent Performance Computing Fri, 29 Jun 2007 16:21:56 +0000 http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/#comment-471 [...] during this 12 hour period is reading the enabled constraints from the dictionary. One person commented on Wednesday’s post that the numbers don’t seem to be consistent in that the system doesn’t query them much [...] [...] during this 12 hour period is reading the enabled constraints from the dictionary. One person commented on Wednesday’s post that the numbers don’t seem to be consistent in that the system doesn’t query them much [...]

]]> By: OraTransplant » Log Buffer #51: a Carnival of the Vanities for DBAs http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/#comment-470 OraTransplant » Log Buffer #51: a Carnival of the Vanities for DBAs Fri, 29 Jun 2007 16:01:25 +0000 http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/#comment-470 [...] sub latch wait events and finally Jeremy Schneider has a very interesting part 1 article about statspack and AWR latch waits. Hang around for the second part. Another DBA topic this week was a reminder to check your [...] [...] sub latch wait events and finally Jeremy Schneider has a very interesting part 1 article about statspack and AWR latch waits. Hang around for the second part. Another DBA topic this week was a reminder to check your [...]

]]> By: Hemant http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/#comment-466 Hemant Fri, 29 Jun 2007 15:26:19 +0000 http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/#comment-466 I would not expect that the latch waits have anything to do with "NetApp". Latch waits could be also be high if the server was starved of CPU and/or a very high rate of context-switching is occurring. As Jonathan says "I’ll have to tune in for the next installment on this". I would not expect that the latch waits have anything to do with “NetApp”. Latch waits could be also be high if the server was starved of CPU and/or a very high rate of context-switching is occurring. As Jonathan says “I’ll have to tune in for the next installment on this”.

]]> By: Gary http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/#comment-447 Gary Wed, 27 Jun 2007 23:05:24 +0000 http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/#comment-447 "insert into argument$" over 10,000 executions. "delete from source$" over 1,000 executions. Looks like they are creating and dropping a lot of PL/SQL. If it's development, I wonder if they've got something that is dropping/restoring database objects (maybe flashback database ?) to a 'production/testing-like' state. “insert into argument$” over 10,000 executions.
“delete from source$” over 1,000 executions.
Looks like they are creating and dropping a lot of PL/SQL.
If it’s development, I wonder if they’ve got something that is dropping/restoring database objects (maybe flashback database ?) to a ‘production/testing-like’ state.

]]> By: Jonathan Lewis http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/#comment-444 Jonathan Lewis Wed, 27 Jun 2007 19:21:55 +0000 http://www.ardentperf.com/2007/06/27/case-study-statspackawr-latch-waits-part-1/#comment-444 I'll have to tune in for the next installment on this. I don't like the 12hour range - too much opportunity for flattened averages, especially on a system that doesn't seem to be doing much. I think there's could be a lot of table truncating going on that is causing invalidation of SQL statements and pl/sql procedures. I think the problem may be made worse by the number of histograms in existence. The various statistics about constraints don't really seem to be consistent. You don't seem to query them much, don't have many, and yet work very hard when you need to see them. Maybe the root cause is in the history, with the con$ table or c_obj# cluster being smashed by lots of create/drop activity on objects and constraints. I’ll have to tune in for the next installment on this. I don’t like the 12hour range – too much opportunity for flattened averages, especially on a system that doesn’t seem to be doing much.

I think there’s could be a lot of table truncating going on that is causing invalidation of SQL statements and pl/sql procedures. I think the problem may be made worse by the number of histograms in existence.

The various statistics about constraints don’t really seem to be consistent. You don’t seem to query them much, don’t have many, and yet work very hard when you need to see them. Maybe the root cause is in the history, with the con$ table or c_obj# cluster being smashed by lots of create/drop activity on objects and constraints.

]]>