1. About v $ db_object_cache
library objects displayed are cached in the library cache cache (shared pool) in. It provides more details than the dynamic performance table V $ LIBRARYCACHE, shared pool and looking
in terms of active objects more useful. These objects include tables, indexes, clusters, PL / SQL procedures and packaging, and triggers. In the statistics shared pool object level.
| Column Name | type of data | description |
| OWNER | VARCHAR2(64) | Object owner (if it is sql statement applications, this column values are generally empty) |
| NAME | VARCHAR2(1000) | Object Name (first 1000 characters sql statement or anonymous block / cursor) |
| DB_LINK | VARCHAR2(64) | If there is a database link name dblink |
| NAMESPACE | VARCHAR2(28) | Library cache object naming type: TABLE / PROCEDURE, BODY, TRIGGER, INDEX, CLUSTER, OBJECT |
| TYPE | VARCHAR2(28) | 对象类型 (for example, sequence, procedure, function, package, package body, trigger) |
| SHARABLE_MEM | NUMBER | Objects can occupy the shared memory size (unit: btyes) |
| LOADS | NUMBER | The number of times the memory of the object to be loaded. When an invalid object when this value will continue to increase. |
| EXECUTIONS | NUMBER | 无效的（Not used. See V$SQLAREA to see actual execution counts.） |
| LOCKS | NUMBER | This object is currently locked in the number of session |
| PINS | NUMBER | The current number of session execution of this object |
| KEPT | VARCHAR2(3) | Inform whether resident shared pool (yes / no) objects, this object depends on whether the use of PL / SQL procedure DBMS_SHARED_POOL.KEEP "hold" (permanently fixed in memory) |
| CHILD_LATCH | NUMBER | The number of child protection locks the object. |
2. parameters associated:
SHARED_POOL_SIZE shared pool size
size shared_pool_reserved_size reservation pool
3-associative view:
V $ LIBRARYCACHE This view object is described starting from the instance of the start set in the repository buffer pool
V $ LIBRARY_CACHE_MEMORY Displays information about memory allocated library cache Memory to
objects in Different Namespaces.
V $ OBJECT_DEPENDENCY can be determined by the currently loaded shared pool of packet, which processes a cursor or object dependency
V $ SUBCACHE library currently loaded into the lower buffer cached information
V $ SQL_SHARED_MEMORY
V $ SHARED_POOL_ADVICE shared pool size is recommended
V $ SGASTAT SGA details
DBA_KEEPSIZES
4. related packages:
DBMS_SHARED_POOL display shared pool size of the object, keeping or unkeeping objects to reduce memory fragmentation
5. Related script:
objpool.sql approach listed objects are ready to be loaded live PINNING.
Shared_pool_freelist.sql
6. The Related sql statement:
- forming generate pin live shared pool sql statement is not currently pin the object of living.
- v $ db_object_cache can often be loaded but not live pin package, functions, and procedures keep coming.
'.' select 'exec sys.DBMS_SHARED_POOL.keep ( ' || chr (39) || owner || || NAME || chr (39) || ',' || chr (39) || 'P' | | CHR (39) || ');' AS sql_to_run
from V $ DB_OBJECT_CACHE in the TYPE WHERE ( 'PACKAGE of', 'the FUNCTION', 'PROCEDURE') and loads> = 50 and Kept 'NO' and Executions> 50;
SQL_TO_RUN
- -------------------------------------------------- ----------
Exec sys.DBMS_SHARED_POOL.keep ( 'JXXXT.IN_GZ_LOGS', 'P');
sys.DBMS_SHARED_POOL.keep Exec ( 'JXXXT.IN_DX_GROUPSEND', 'P');
Exec sys.DBMS_SHARED_POOL.keep ( 'JXXXT.IN_JJ_LOGS', 'P');
Exec sys.DBMS_SHARED_POOL.keep ( 'JXXXT.IS_MOBILEPHONE', ' P ');
exec sys.DBMS_SHARED_POOL.keep (' JXXXT.IN_JA_LOGS ',' P ');
exec sys.DBMS_SHARED_POOL.keep (' JXXXT.IN_DX_SENDALLTEMP ',' P ');
performing exec sys.DBMS_SHARED_POOL.keep (' JXXXT.IN_GZ_LOGS ',' P '); an undefined may report errors
need to perform dbmspool.sql this script is $ ORACLE_HOME / rdbms / admin / sqlplus under at
- Show different types of objects shared pool.
- - show whether use dBMS_SHARED_POOL.KEEP () object-pin live.
COL of the type for A20
COL kept A4 for
the SELECT of the type, COUNT (*), kept, round (SUM (sharable_mem) / 1024,0) share_mem_kilo
from V$DB_OBJECT_CACHE where sharable_mem != 0 GROUP BY type, kept order by 3,4;
TYPE COUNT(*) KEPT SHARE_MEM_KILO
-------------------- ---------- ---- --------------
APP CONTEXT 1 NO 1
SEQUENCE 2 NO 3
NON-EXISTENT 3 NO 3
PIPE 5 NO 6
PUB_SUB 5 NO 8
TRIGGER 4 NO 14
FUNCTION 4 NO 21
SYNONYM 12 NO 56
VIEW 29 NO 66
TABLE 78 NO 161
PACKAGE BODY 11 NO 166
12 is NO 623 PACKAGE of
CURSOR 42270 NO 332 424
the INDEX YES. 4. 5
the CLUSTER 12 is YES. 6
TABLE 20 is YES 43 is
- find more loads of objects
COL A80 name for the trunc
the SELECT owner, sharable_mem, Kept, loads, the WHERE name from V $ DB_OBJECT_CACHE loads> 2 ORDER bY loads DESC;
see many objects (tables) is repeated a large number of loads, the load is repeatedly v $ db_object_cache list mostly because of insufficient cache, is extruded.
This caused most of the reason is because there is no bind variables, a large number of repeated loading caused by the same statement. But can not solve the fundamental problem by increasing share_pool
Solution:
1, modify the sql statement, use variables instead of constants (developed to complete)
2, can keep some of the frequently used small tables. dbms_shared_pool packets can be taken into account by the number and size of the loads of the table to keep those tables
- find out using a lot of memory objects using DBMS_SHARED_POOL.KEEP () perform live pin.
Owner the SELECT, name, sharable_mem, Kept the FROM V $ DB_OBJECT_CACHE
the WHERE sharable_mem> Kept the AND 102400 = 'NO' sharable_mem the ORDER BY DESC;
- object shared pool memory consumption required to find contiguous memory lookup in 8 described statement
COL name for A40
COL of the type for A30
the SELECT OWNER, nAME, the TYPE, SHARABLE_MEM from V $ DB_OBJECT_CACHE the WHERE SHARABLE_MEM> 10000
and of the type in ( 'PACKAGE', 'PACKAGE the BODY', 'FUNCTION', 'PROCEDURE') the Order by SHARABLE_MEM desc ;
- stable database to determine which object pin live operation.
SET 150 LINESIZE
COL oname for A40
COL owner for A15
COL the type A20 for
the SELECT owner name || || oname, substr (type, plates 1,12) '.' "Type", sharable_mem "Size", Executions, loads,
Kept the FROM V $ DB_OBJECT_CACHE of the type in the WHERE ( 'TRIGGER', 'PROCEDURE','PACKAGE BODY','PACKAGE')
Executions the AND> 0 the ORDER BY desc Executions, loads desc, sharable_mem desc;
-. The object is not listed in a large live pin
SET 150 LINESIZE
COL SZ for AlO
COL name for AlOO
COL keeped for A6
SELECT TO_CHAR (sharable_mem / 1024, '999999') sz_in_K, decode (Kept, 'Yes', 'Yes', '') keeped,
owner || ',' || name || LPAD ( '', 29 - (length (owner) + length (name ))) || '(' || || type ')' name,
null Extra, iscur 0 V from V $ DB_OBJECT_CACHE WHERE sharable_mem> 1024 * 1000;
- the process is not listed in a large live pin of the package and function
COL type for A25
COL name for A40
COL owner for A25
SELECT owner, name, type, round (SUM (sharable_mem / 1024),. 1) from V $ DB_OBJECT_CACHE sharable_mem_K WHERE Kept = 'NO'
and (type = 'PACKAGE' or type = 'FUNCTION' or type = 'PROCEDURE')
by owner Group, name, by type Order. 4;
7. The other
need to be pin into memory objects are: conventional large memory objects, such as standard, diutil packet; compiled common triggers; sequences.
It will be the best in the boot pin into memory (I think here you can write the appropriate boot trigger).
In this way, both when using the command alter system flush shared_pool, we can not speak of these object flush out.
DETAILED pin object into the memory using the method DBMS_SHARED_POOL.keep stored procedure. Unkeep methods can lift the pin state.
8.db_object_cache fragmentation and
fragmentation resulting in the shared pool although there are many small pieces can be used, but not large enough contiguous space, it is a common phenomenon in the shared pool.
The key is to eliminate shared pool error loading the object is about the size of the possible cause problems. Once you know the problems of PL / SQL, you
can start in the database (this time shared pool is completely continuous) This code will be fixed. This will ensure that when you call a large packet, it has a total of at
sharing pool, rather than a continuous search for debris in the shared pool (when using the system, these fragments may cease to exist).
Can query the V $ DB_OBJECT_CACHE view to determine the PL / SQL whether large and has not been identified as a "kept" mark. These future need to load
an object, can cause problems (because of their size and the need for continuous use up a lot of memory). By querying the V $ DB_OBJECT_CACHE table, you can
find that are not fixed, but required too much space and is likely to cause an object to potential problems.
