On Sep 26, 1:41 am, Stefan Wetter <swet..._at_arcor.de> wrote:
> Hello NG!
>
> I'm pretty new to this theme. My task is, at the moment, to improve the
> performance of a database of one of our customers.
>
> I monitored the database-activity with the help of some tools and find
> pretty much DISK-IO (read). I think that should be lower. To the same
> time, the buffers are only filled half.
>
> I think i should find out, wich tables cause the physical reads (, to
> examine which process does need them to optimize the clients if necessary.
> If not, i would change the storage clauses of that tables to use another
> part of the buffers.)
>
> So, my question at this time is: how can i find out which tables (or
> maybe indexes) cause the disk-io?
>
> Thank you very much in advance!
> Stefan
- Read Concepts manual.
- Understand that most performance issues come from application
issues. For example, if some silly SQL reads an entire table to get a
few rows, you wil likely have a lot of unnecessary I/O that won't fill
up the SGA.
- Read the Performance manual.
- Understand the optimizer. It can only use the information it is
given. If the statistics it uses are wrong, non-existent, or skewed
in a manner the optimizer doesn't know about, it can choose a silly
plan for accessing the data. Sometimes a full table scan is not
silly.
- Understand what plans are and how to use them to understand 4.
- Understand what statspack (or other tools such as Jerome
mentioned) can tell you.
- Understand when, how and why to use tracing.
- Understand what waits are and how to evaluate them.
- Read and work through books and articles by Jonathan Lewis, Tom
Kyte, and Cary Milsap. (And I still like Lawson's book for the basic
how-to-dba implicit in your question, though it is out of date now).
- Understand why rules of thumb can be a bad idea for improving the
database of customers.
- Understand that tools based strictly on Oracle can be a bit
misleading from a systems standpoint, and systems tools can be
misleading from Oracle's viewpoint. Simply knowing you have a lot of
reads does not mean anything is wrong, after all, what is a database
going to be used for? A proper tuning methodology will figure out
what critical bottlenecks are, and what to do about them.
- Understand the basics. For example, if you have sequential writeintensive
archive writing interfering with random reads and writes for
undo and everything else, thrashing a SAN cache, you probably have a
configuration problem. If you have multiple users accessing data, you
need to understand how Oracle handles the issues involved.
- Create clear metrics for performance improvement.
- Read Concepts manual.
- Iterate.
Welcome to the group! See http://www.dbaoracle.net/readme-cdos.htm
jg
--
@home.com is bogus.
http://shop.lego.com/product/Default.aspx?p=10179&LangId=2057
Received on Wed Sep 26 2007 - 15:54:08 CDT