Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.tools -> Re: CPU Bottleneck

Re: CPU Bottleneck

From: Alex Filonov <afilonov_at_pro-ns.net>
Date: Tue, 22 May 2001 02:04:55 GMT
Message-ID: <3B09C944.FBA40633@pro-ns.net>

Jack wrote:

> Can you please tell me which of these statistics will tell me whether I have
> a CPU Bottleneck and which will tell me if I have a Disk bottleneck?
>
> Many thanks
>
> ---------------------------
> CR blocks created
> DBWR checkpoint buffers wri
> DBWR checkpoints
> DBWR transaction table writ
> DBWR undo block writes
> SQL*Net roundtrips to/from
> background checkpoints comp
> background checkpoints star
> background timeouts
> buffer is not pinned count
> buffer is pinned count
> bytes received via SQL*Net
> bytes sent via SQL*Net to c
> calls to get snapshot scn:
> calls to kcmgas
> calls to kcmgcs
> cleanouts and rollbacks - c
> cluster key scan block gets
> cluster key scans
> commit cleanout failures: c
> commit cleanout failures: c
> commit cleanouts
> commit cleanouts successful
> consistent changes
> consistent gets
> cursor authentications
> data blocks consistent read
> db block changes
> db block gets
> deferred (CURRENT) block cl
> enqueue releases
> enqueue requests
> execute count
> free buffer requested
> hot buffers moved to head o
> immediate (CR) block cleano
> immediate (CURRENT) block c
> index fast full scans (full
> leaf node splits
> logons cumulative
> logons current
> messages received
> messages sent
> no buffer to keep pinned co
> no work - consistent read g
> opened cursors cumulative
> opened cursors current
> parse count (hard)
> parse count (total)
> physical reads
> physical reads direct
> physical writes
> physical writes direct
> physical writes non checkpo
> recursive calls
> redo blocks written
> redo buffer allocation retr
> redo entries
> redo log space requests
> redo size
> redo synch writes
> redo wastage
> redo writes
> rollbacks only - consistent
> rows fetched via callback
> session logical reads
> session pga memory
> session pga memory max
> session uga memory
> session uga memory max
> sorts (disk)
> sorts (memory)
> sorts (rows)
> switch current to new buffe
> table fetch by rowid
> table fetch continued row
> table scan blocks gotten
> table scan rows gotten
> table scans (short tables)
> total file opens
> user calls
> user commits

You need to use OS statistics for that. Oracle doesn't know how much cpu and disk capacity your machine has. On HP-UX, you can use glance/gpm, there are similar tools on other UNIX OS. Received on Mon May 21 2001 - 21:04:55 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US