RE: Question regarding db_file_scattered_read
- From: "Johnson, George" <GJohnson@xxxxxxx>
- To: 'Dennis Williams' <oracledba.williams@xxxxxxxxx>, "Johnson, George" <GJohnson@xxxxxxx>
- Date: Mon, 18 Jul 2005 16:30:22 +0100
I am chasing the high-parse-to-execution route at the moment. Seems
like there is an awful lot of un-shared SQL, so even if that isn't the major
problem, it might do as well to try to clean that up as well.
Like they say in all the best brit spy movies after the hero saves
the world again, "The reward is handshake from a few men in Whitehall and
the satisfaction of job well done."
-----Original Message-----
From: Dennis Williams [mailto:oracledba.williams@xxxxxxxxx]
Sent: 18 Jul 2005 14:41
To: GJohnson@xxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Question regarding db_file_scattered_read
George,
George, congratulations on thinking ahead, anticipating problems before
your users encounter them. Of course, you'll get no credit from management,
but such is the DBA's lot.
In Oracle terms, db_file_scattered_read usually equates to a full table
scan. Start looking for queries that are executing a full table scan.
Following Pareto's rule (80/20 principle), you probably have a few queries
that are doing a FTS on your largest tables. Tame them and your system
performance should look better.
Dennis Williams
On 7/18/05, Johnson, George <GJohnson@xxxxxxx> wrote:
>
>
>
> I have a DB on a Solaris box, the system that is almost at
> 100% utilisation, I'm not overly worried as no one is complaining,
> yet. I am simply trying to identify where the resources are being
> consumed, partly curiosity and partly in the hope of preventing a
> potential future problem.
>
> I have been over the wait stats and found that the system
> spends it's time, almost exclusively, making users wait on
> db_file_scattered_read, about 30% of their session time, in fact.
> However the OS reports hardly any I/O wait time, the system resources
> are being used up by user CPU. I believe the entire SGA is little too
> small, I am wondering if the scattered_read waits are a result of the
> SGA and/or buffer cache being too small or would a buffer cache that
> is too small, more likely result in buffer_busy_waits or have I got my
> thinking completely backside-about-face!? All the notes I can find
> relate db_file_scattered_read to an I/O performance problem, which
> from what I can tell from the OS, I don't seem to have.
>
> Any pointers in the direction I should start off in next,
> would be greatly appreciated.
>
> Rgds
>
>
>
>
> **********************************************************************
> ******
> This message contains confidential information and is intended only
> for the individual or entity named. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail.
> Please notify the sender immediately by e-mail if you have received
> this e-mail by mistake and delete this e-mail from your system.
> E-mail transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost, destroyed, arrive
> late or incomplete, or contain viruses. The sender therefore does not
> accept liability for any errors or omissions in the contents of this
> message which arise as a result of e-mail transmission.
> If verification is required please request a hard-copy version.
> This message is provided for informational purposes and should not
> be construed as an invitation or offer to buy or sell any securities or
> related financial instruments.
> GAM operates in many jurisdictions and is
> regulated or licensed in those jurisdictions as required.
>
****************************************************************************
>
****************************************************************************
This message contains confidential information and is intended only
for the individual or entity named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
This message is provided for informational purposes and should not
be construed as an invitation or offer to buy or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions as required.
****************************************************************************
--
//www.freelists.org/webpage/oracle-l
Other related posts:
