Comments on: Hit Ratios (4) http://jonathanlewis.wordpress.com/2007/09/26/hit-ratios-4/ Just another Oracle weblog Tue, 18 Jun 2013 04:32:58 +0000 hourly 1 http://wordpress.com/ By: CPU usage « Oracle Scratchpad http://jonathanlewis.wordpress.com/2007/09/26/hit-ratios-4/#comment-31032 Wed, 14 May 2008 06:30:34 +0000 http://jonathanlewis.wordpress.com/2007/09/26/hit-ratios-4/#comment-31032 [...] case is shown below. (It’s based on a simple script I wrote many years ago to demonstrate how pointless it was to depend on the buffer cache hit ratio as a source of meanigful information – subsequently hi-jacked by Connor McDonald for his [...]

]]> By: Jonathan Lewis http://jonathanlewis.wordpress.com/2007/09/26/hit-ratios-4/#comment-21734 Mon, 01 Oct 2007 10:35:14 +0000 http://jonathanlewis.wordpress.com/2007/09/26/hit-ratios-4/#comment-21734 Wolfgang, The original comment wasn’t about performance, or how to do performance analysis.

The OP simply wanted to understand why he could have a lot of db file sequential reads when his cache hit ratio was so “good” – and that’s what I wanted to explain.

]]> By: Wolfgang http://jonathanlewis.wordpress.com/2007/09/26/hit-ratios-4/#comment-21685 Sun, 30 Sep 2007 09:34:55 +0000 http://jonathanlewis.wordpress.com/2007/09/26/hit-ratios-4/#comment-21685 Well I think there are more “errors” in the above post.
The OP doesn’t mention what’s to slow and what will be “fast enough”.
My first approch would be to see a statspack report for about 15-20 minutes when the system is “too slow” and simply look at the top 5 sqls and top5 wait events (personally I perefere a statspack report over a awr report).
As the op said, that most of the reads are done with PK access, the reason might be slow disks or a bad configured san switch.
A simple 10046 trace would give as more information in the db file sequential read wait event.

]]>