Comments on: Event Histograms http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/ Just another Oracle weblog Mon, 20 May 2013 17:10:14 +0000 hourly 1 http://wordpress.com/ By: Measure oracle real-time I/O performance « bdt's oracle blog http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-51559 Tue, 20 Nov 2012 08:30:42 +0000 http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-51559 [...] You could get more detailed information thanks to the gv$event_histogram view (benefit of this view is described in this post). [...]

]]> By: Santhosh Nair http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-36097 Tue, 27 Apr 2010 18:30:37 +0000 http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-36097 An update on this on 11gR2

Now we have an additional column called last_update_time which is very useful info

santhosh

]]> By: Event Histograms - 2 « Oracle Scratchpad http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-31300 Mon, 16 Jun 2008 09:10:03 +0000 http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-31300 [...] Filed under: Statspack, Troubleshooting — Jonathan Lewis @ 8:38 pm UTC Jan 31,2007 In an earlier blog, I mentioned the 10g view v$event_histogram and described how useful it could [...]

]]> By: Jonathan Lewis http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-30949 Sat, 03 May 2008 10:06:50 +0000 http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-30949 David,
Thanks for the comment – amongst other things it’s brought to my attention that I didn’t answer Rita’s question in comment #2.

There is an example of this in the second posting about event histograms, where we see a large volume of data centred around the 8 m/s mark, and a second large volume of data with a much slower response time centred somewhere near the 1 second mark. This resolved into two different SANs with different performance patterns. That’s what I mean by a “double hump”.

]]> By: David Russell http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-30945 Sat, 03 May 2008 00:13:15 +0000 http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-30945 great google hit! I was really looking for information on column histograms; but, this was so much more interesting. With 64 different events, it reports a LOT of information. I’m only sorry I found it AFTER I rebooted the host yesterday. Had I only know :(

Thanks for posting!

]]> By: Jonathan Lewis http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-29534 Fri, 08 Feb 2008 17:18:32 +0000 http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-29534 Dude,
Correct – see http://jonathanlewis.wordpress.com/2007/01/31/event-histograms-2/

]]> By: Dude http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-29533 Fri, 08 Feb 2008 16:10:09 +0000 http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-29533 A Statspack report reports data from v$event_histogram while AWR does not on 10g.

]]> By: Rita http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-3160 Tue, 06 Feb 2007 04:22:56 +0000 http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-3160 Can you explain double-hump and triple-hump effect and how do they indicate a possible problem.
Thanks !

]]> By: David Aldridge http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-1452 Thu, 11 Jan 2007 15:20:58 +0000 http://jonathanlewis.wordpress.com/2007/01/10/event-histograms/#comment-1452 Yes, this is one of the best features of 10g. I always look for that “double-hump” in the histogram to indicate possible problems. Interpreting it is sometimes a tricky business of course.

I’ve seen a triple-hump effect on direct path reads, with the cause being too-high a default degree of parallelism on a generally quiet system. The low wait times were queries running as the only active session on the system, the middle one was normal operations, and the highest one being a system swamped with too many PQ processes leading to a drastic reduction in throughput.

]]>