-
I ran the UTLBSTAT and selected the view v$rowcache. now, can someone please tell me what do these data represent? Thank you!!
SVRMGR> SELECT parameter, gets, getmisses
2> FROM v$rowcache;
PARAMETER GETS GETMISSES
-------------------------------- ---------- ----------
dc_free_extents 147 32
dc_used_extents 23 23
dc_segments 117 45
dc_tablespaces 106 3
dc_tablespace_quotas 0 0
dc_files 0 0
dc_users 76 8
dc_rollback_segments 126 4
dc_objects 558 109
dc_global_oids 0 0
dc_constraints 4 3
dc_object_ids 302 50
dc_synonyms 7 4
dc_sequences 3 2
dc_usernames 64 5
dc_database_links 0 0
dc_histogram_defs 8 4
...
I tried to make it easier to read, but it doesn't come out the way I wanted. Please bear with me. Tks.
-
From the Oracle doco...
"v$rowcache: This view displays statistics for data dictionary activity.
Each row contains statistics for one data dictionary cache. "
This view shows the information which can be used to calculate the hit ratios for each area of the data dictionary cache.
Here are some links to various doco on both dictionary cache and utlbstat/utlestat
Tuning memory allocation: Ch19 of Oracle doco :
http://technet.oracle.com/docs/produ...2/ch19_mem.htm
Utlbstat/Utlestat
http://www.adsinc.com/whitepapers/UtlestatReport.html
Rule of thumb bad hit ratios may be a symtom of either a
1) too small shared pool
2) frequently used stored procedure not pinned.
3) Too much parsing i.e lack of bind variables.
Have Fun
-
I would suggest u gather Aggregates instead of individual parameters from V$ROWCACHE.
SELECT SUM (GETS-GETMISSES)/SUM (GETS) * 100 AS HIT RATIO FROM V$ROWCACHE;
Hit ratio for dictionary cache should be 85% or higher.If its low, you need to address the problem. I suggest tuning the Library Cache first.
(PS: You should collect data only after your database has been running for quite sometime).
I dont think you need to run UTLBSTAT to gather data from V$ROWCACHE view. Utilities like UTLBSTAT (followed by UTLESTAT) collect data from these dynamic performance views.
