| Script Name |
Description |
s_all_ratios.sql |
THIS Script reports various performance ratios
|
s_sga.sql |
SGA usage
|
s_sga_buffer_pool.sql |
reports buffer pool from v$buffer_pool
|
s_sga_db_buffer.sql |
Displays Hit Ratio for DB_BUFFER
HIT RATIO should be > 90%
Refer to Metalink Doc ID: 33883.1
STATISTIC "cache hit ratio" - Reference Note
|
s_sga_dict_cache.sql |
Reports DATA_DICTIONARY_CACHE MISSES TO GETS RATIO
==================================================
sum(get_miss)
------------- < 15%
sum(get_reqs)
|
s_sga_high_sql.sql |
Reports expensive SQL from V$SQLAREA, V$SQLTEXT view
Joins to V$SQLTEXT using ADDRESS column
Prompts for number of DISK_READS and
PARSING_USER
|
s_sga_high_sql2.sql |
(uses PL/SQL block)
Reports expensive SQL from V$SQLAREA, V$SQLTEXT view
Joins to V$SQLTEXT using ADDRESS column
Prompts for number of DISK_READS and
PARSING_USER
|
s_sga_lib_cache.sql |
Reports LIBRARY_CACHE RELOADRATIO and GETHITRATIO.
1. RELOADRATION = shoul be low < 1
sum(reloads)
reloadratio = ------------ should be < 1
sum(pins)
2. GETHITRATIO = should be high (>90%)
|
s_sga_lib_cache_lock.sql |
Reports library cache locks. Many times in heavy development
environment PL/SQL code get`s compiled while someone else is
using it. This creates locks in library cache which can be
very hard to trace. I would typically check v$session_wait
to see if there are any waits for "enque", most of the time it`s
library cache lock especially when other locks are not present.
--
The next step would be to find out which package waiting
session was trying to compile or execute and run this script
supplying this package name. When you get the output of this
script you can kill sessions that are causing library cache lock.
|
s_sga_pined_plsql.sql |
Reports PINED PLSQL objects.
--
Will ask you if you want to KEEP these objects
if you say yes make sure you have this
package installed:
SYS.DBMS_SHARED_POOL.KEEP
You can install it by running DBMSPOOL.SQL as SYS.
|
s_user_sql.sql |
This script reports SQL TEXT from v$sqltext
|