Tuning the Database - Expert Oracle RAC Performance Diagnostics and Tuning - page 297

Continuing our look at the subsets of data found in the V$RESULT_CACHE_OBJECTS , the following output lists the
current space utilization of the results section for this operation:
Script: MVRACPDnTap_rcutil.sql
SELECT inst_id INT,
id,
TYPE,
block_count blkcnt,
column_count clmcnt,
scan_count,
row_count rcnt,
row_size_max rsm,
row_size_avg rsa,
space_overhead soh,
space_unused sun
FROM gv$result_cache_objects;
WHERE inst_id =&& instnum;
INT ID TYPE BLKCNT CLMCNT RCNT RSM RSA SOH SUN
---- --- ---------- ------- ------- ----- ----- ----- ----- -----
1 1 Dependency 1 0 0 0 0 0 0
1 0 Dependency 1 0 0 0 0 0 0
1 2 Result 7 5 300 27 26 536 35
Step 5
From the previous output discussed in Step 2 of the workshop, you noticed that .004% of the dynamic memory section
of the shared pool was utilized by this operation. The following query provides a detailed report:
SELECT *
FROM gv$sgastat
WHERE pool = 'shared pool'
AND NAME LIKE 'Result%'
AND inst_id = 1;
INST_ID POOL NAME BYTES
------- ------------ ---------------------------------- ----------
1 shared pool Result Cache: State Objs 2896
1 shared pool Result Cache 194216
1 shared pool Result Cache: Memory Mgr 200
1 shared pool Result Cache: 2088
1 shared pool Result Cache: Cache Mgr 5552
1 shared pool Result Cache: Bloom Fltr 2048
You now have an understanding of what happens with the result cache on instance one ( SSKY1 ). As observed, this
functionality has identical behavior as in the case of a single-instance implementation.
One of the great benefits of Oracle RAC is that multiple users can query against the same set of data from
multiple instances in the cluster. If a user were to execute the exact same query from either instance 2 ( SSKY2 ),
instance 3 ( SSKY3 ), or instance 4 ( SSKY4 ), as discussed earlier, depending on the volume of data being retrieved,