TUNING THE SYSTEM GLOBAL AREA:Memory for the shared pool, large pool, java pool, and buffer

cache is allocated in units of granules. The granule size is 4MB if the SGA size is less than 1GB. If the SGA size is greater than 1GB, the granule size changes to 16MB. The gran ule size is calculated and fixed when the instance starts up. The size does not change during the lifetime of the instance. The granule size that is currently being used for SGA can be viewed in the view V$SGA_DYNAMIC_COMPONENTS. The same granule size is used for all dynamic componen ts in the SGA. You can expand the total SGA size to a value equal to the SGA_MAX_SIZE parameter . If the SGA_MAX_SIZE is not set, you can decrease the size of one cache and rea llocate that memory to another cache if necessary. SGA_MAX_SIZE defaults to the aggregate setting of all the components. HOW TO OPTIMIZE THE DATA BUFFER CACHE:THE DATA BUFFERS ARE THE MEMORY STRUCTURES IN ORACLE THAT MAINTAIN THE MOST RECE NTLY USED ORACLE DATA BLOCKS. THE DATA BUFFERS ARE AGED OUT ON THE BASIS OF THE LEAST RECENTLY USED (LRU) ALGO RITHM. AS ORACLE SERVER CAN DIRECTLY ACCESS THE DATABLOCKS FROM THE BUFFER INSTEAD OF R EADING THEM FROM THE DISK , LESS I/O NEEDS TO BE PERFORMED AND THUS PERFORMANCE GETS IMPROVED. DATABASE BUFFER CACHE PERFORMANCE INFORMATION CAN BE OBTAINED FROM THE V$SYSSTAT VIEW. THE MOST IMPORTANT MEASURE OF DATABASE BUFFER PERFORMANCE IS THE " DATABASE BUFF ER HIT RATIO", WHICH MEASURES THE NUMBER OF TIMES ORACLE FOUND DATA BLOCKS IN THE MEMORY,INSTEA D OF HAVING TO READ THEM FROM THE DISK. SELECT ROUND(1-(SUM(DECODE(NAME,'physical reads',VALUE,0))/ (SUM(DECODE(NAME,'db block gets',VALUE,0))+ (SUM(DECODE(NAME,'consistent gets',value,0))))),2) "DATA BUFFER HIT RATIO" FROM V$SYSSTAT; OR SELECT 1-((a.value-(b.value))/d.value) "Cache Hit Ratio" from v$sysstat a, v$sysstat b, v$sysstat d where a.name='physical reads' and b.name='physical reads direct' and d.name='session logical reads'; NAME : Name of the buffer pool PHYSICAL READS : THIS IS THE NUMBER OF DISK BLOCK FETCH REQUESTS ISSUED BY ORACL E. DB BLOCK GETS : THIS IS THE NUMBER OF DATABASE BLOCK GETS WHICH ARE EITHER PHYSI CAL OR LOGICAL GENERALLY FOR UPDATE/DELETE/INSERT. CONSISTENT GETS : THIS IS THE NUMBER OF LOGICAL READS (THIS IS NUMBER OR READS F ROM THE BUFFER OR FROM DISK AND THE READ WAS FOR SELECT OPERATION, BUT ALSO COUL D BE A READ THAT ONLY USED THE CPU LIKE SELECT SYSDATE FROM DUAL;). PHYSICAL WRITES:- NUMBER OF PHYSICAL DISK WRITE REQUESTS FROM ORACLE. RECYCLE BUFFER POOL:-

An ad-hoc query that scans a large table can significantly degrade overall datab ase performance. A SQL operation on a large table may flush out frequently used data blocks from the buffer cache to store data blocks from the large table. Dur ing the peak time, ad-hoc queries that select data from large tables or from tab les that are rarely used should be avoided. If we cannot avoid such queries, we can limit the impact on the buffer cache by using RECYCLE buffer pool. Using RECYCLE pool, we can prevent a large table scan from flushing frequently u sed data blocks. "DB_RECYCLE_CACHE_SIZE=<SIZE>" IS THE PARAMETER WE HAVE TO SETUP IN INIT.ORA OR IN SPFILE OR DIRECTLY FOR CURRENT INSTANCE TO ALLOCATE THE REYCLE BUFFER POOL. The DBA must configure the table to use the RECYCLE POOL by specifying BUFFER_PO OL keyword in the CREATE TABLE or the ALTER TABLE statement. For example, you ca n assign a table to the recycle pool by using the following ALTER TABLE SQL stat ement. ALTER TABLE <TABLE NAME> STORAGE (BUFFER_POOL RECYCLE) KEEP BUFFER POOL:We can use KEEP pool to cache data blocks that are frequently used by the applic ation. Typically, this will be big enough to store data blocks that we want to a lways keep in memory. By storing data blocks in KEEP and RECYCLE pools you can s tore frequently used data blocks separately from the rarely used data blocks, an d control which data blocks are flushed from the buffer cache DB_KEEP_CACHE_SIZE = <size of KEEP pool> ALTER TABLE <TABLE NAME> STORAGE (BUFFER_POOL KEEP) TUNING THE SHARED POOL:THE LIBRARY CACHE MEMORY AREA CONTAINS THE SHARED SQL AND PL/SQL STATEMENTS. WHE N A USER SUBMITS A SQL OR PL/SQL STATEMENT TO THE DATABASE , THEN ORACLE PARSES IT INTO THE EXECUTABLE FORM BEFORE EXECUTING THE CODE.ORACLE TEMPORARILY STORES THE PARSED EXECUTABLE CODE IN THE LIBRARY CACHE, SO IF ANY USER ISSUES THE SAME SQL COMMAND AGAIN THEN ORACLE CAN SIMPLY USE THE CODE THAT IS ALREADY IN THE LIB RARY CACHE. ORACLE USES THE LRU ALGORITHM TO MAKE ROOM FOR NEWER SQL STATEMENTS. LIBRARY CACHE PERFORMANCE IS MEASURED IN TERMS OF THE RELATIVE NUMBER OF PINS AN D RELOADS. THE NUMBER OF PINS INDICATES THE NUMBER OF EXECUTIONS OF A SQL STATEMENT USING T HE PARSED SQL CODE IN THE MEMORY. WHEN A PARSED SQL STATEMENT CANNOT BE FOUND IN THE MEMORY (LIBRARY CACHE) THEN O RACLE HAS TO REPARSE THAT SQL AND IS KNOWN AS A RELOAD. A HIGH NUMBER OF RELOADS INDICATES SUB-OPTIMAL PERFORMANCE. THE LIBRARY CACHE PERFORMANCE IS MEASURED BY LIBRARY CACHE HIT RATIO WHICH IS THE RATIO OF PINS:RELOADS. THE V$LIBRARY CACHE VIEW CONTAINS THE STATISTICS FOR THE LIBRARY CACHE. SELECT SUM(PINS) "TOTAL PINS", SUM(RELOADS) "TOTAL RELOADS", ROUND((1-(SUM(RELOADS)/SUM(PINS))),2) "HIT RATIO"FROM V$LIBRARYCACHE; PINNING APPLICATION CODE:PINNING PREVENTS APPLICATIONS FROM BEING AGED OUT OF THE SHARED POOL. WHEN A CODE OBJECT LIKE A PROCEDURE OR TRIGGER IS CALLED THEN ORACLE READS THAT OBJECT FROM THE DISK AND STORES IT INTO THE SHARED POOL. AS LONG AS THE OBJECT I S EXISTING IN THE SHARED POOL THE SUBSEQUENT CALLS CAN USE THE SAME CODE FROM TH

E MEMORY RATHER THAN READING FROM THE DISK THIS MAKES ACCESS TO THE OBJECT FASTE R. WHEN ORACLE NEEDS TO READ FRESH OBJECTS INTO THE SHARED POOL AND IT CANNOT FIND CONTIGOUS FREE SPACE TO ACCOMODATE THE NEW OBJECTS THEN ORACLE MAY FLUSH OUT ONE OR MORE OLDER OBJECTS. OVER A TIME THE SHARED POOL MAY GET FRAGMENTED INTO FREE AND USED POCKETS. IF THE CODE OBJECT THAT IS BEING LOADED INTO THE SHARED POOL IS A LARGE CODE THEN A LARGE NUMBER OF SMALLER OBJECTS WILL HAVE TO BE FLUSHED O UT TO MAKE SPACE FOR THE LARGE OBJECT.THIS CAN SLOW THE PERFORMANCE OF CODE EXEC UTION. CODE CAN BE PINNED INTO THE SHARED POOL BY USING THE DBMS_SHARED_POOL PACKAGE. P INNING A LARGE , FREQUENTLY USED CODE INTO THE SHARED POOL AVOIDS FLUSHING OUT OF THAT CODE. PROPER USE OF PINNING INCREASES THE LIBRARY CACHE HIT RATIO. HOW TO IDENTIFY OBJECTS THAT MUST BE PINNED. SELECT OWNER, NAME, TYPE, TO_CHAR(SHARABLE_MEM/1024) "SIZE (K)", LOADS, EXECUTIONS EXECS, KEPT FROM V$DB_OBJECT_CACHE WHERE TYPE IN ('FUNCTION','PACKAGE','PACKAGE BODY','PROCEDURE') AND KEPT='NO' AN D OWNER='SCOTT' ORDER BY SHARABLE_MEM DESC; SQL> sho user USER is "SYS" SQL> DESC DBMS_SHARED_POOL ERROR: ORA-04043: object DBMS_SHARED_POOL does not exist SQL> @$ORACLE_HOME/rdbms/admin/dbmspool.sql Package created. Grant succeeded. View created. Package body created. SQL> GRANT EXECUTE ON DBMS_SHARED_POOL TO SCOTT; Grant succeeded. SQL> CONN SCOTT/TIGER Connected. SQL> CREATE OR REPLACE PROCEDURE P1 IS 2 BEGIN 3 DBMS_OUTPUT.PUT_LINE('ORACLE'); 4 END; 5 / Procedure created.

DBA CHECKS WHAT OBJECTS MUST BE PINNED CONN /AS SYSDBA SQL>SELECT OWNER, NAME, TYPE, TO_CHAR(SHARABLE_MEM/1024) "SIZE (K)", LOADS, EXECUTIONS EXECS, KEPT FROM V$DB_OBJECT_CACHE WHERE TYPE IN ('FUNCTION','PACKAGE','PACKAGE BODY','PROCEDURE') AND KEPT='NO' AN D OWNER='SCOTT' ORDER BY SHARABLE_MEM DESC; OWNER ---------------------------------------------------------------NAME -------------------------------------------------------------------------------TYPE SIZE (K) LOADS ---------------------------- ---------------------------------------- ---------EXECS KEP ---------- --SCOTT P1 PROCEDURE 12.3359375 1 2 NO sql> conn scott/tiger SQL> exec sys.dbms_shared_pool.keep('P1','P') PL/SQL procedure successfully completed. SQL> EXEC P1 PL/SQL procedure successfully completed. SQL> SET SERVEROUTPUT ON /SQL>EXEC P1 ORACLE PL/SQL procedure successfully completed. SQL> CONN /AS SYSDBA Connected. SQL> ed pin.sql SELECT OWNER, NAME, TYPE, TO_CHAR(SHARABLE_MEM/1024) "SIZE (K)", LOADS, EXECUTIONS EXECS, KEPT FROM V$DB_OBJECT_CACHE WHERE TYPE IN('FUNCTION','PACKAGE','PACKAGE BODY','PROCEDURE')

AND KEPT='YES' AND OWNER='SCOTT' ORDER BY SHARABLE_MEM DESC SQL> @pin.sql OWNER ---------------------------------------------------------------NAME -------------------------------------------------------------------------------TYPE SIZE (K) LOADS ---------------------------- ---------------------------------------- ---------EXECS KEP ---------- --SCOTT P1 PROCEDURE 12.3359375 3 2 YES SQL> TUNING DATA DICTIONARY CACHE:THE DATA DICTIONARY CACHE CONSISTS OF MEMORY BUFFERS THAT CACHE THE INFORMATION FROM THE DATA DICTIONARY. ORACLE USES THE DATA DICTIONARY INFORMATION TO MANAGE THE DATABASE OPERATIONS. IF ORACLE CAN READ THE DATA DICTIONARY INFORMATION IN T HE MEMORY FROM THE DDC , IT CAN AVOID READING FROM THE DISK. DDC IS ALSO KNOWN AS ROWCACHE. THE DDC PERFORMANCE STATS ARE FOUND IN THE V$ROWC ACHE VIEW. THE DDC PERFORMANCE CAN BE MEASURED BY CALCULATING THE DDC HIT RATIO, WHICH IS A RELATIVE MEASURE OF GETS AND GETMISSES WHERE GETMISSES IS THE NUMBER OF TIMES ORACLE HAD TO RETRIEVE INFORMATION FROM THE DATA DICTIONARY TABLES ON THE DISK BECAUSE IT HAD BEEN AGED OUT OF THE DATA DICTIONARY CACHE AND GETS IS T HE NUMBER OF TIMES ORACLE FOUND THE DATA IN THE DDC AND DID NOT HAVE TO READ FRO M THE DISK. SELECT ROUND((1-(SUM(GETMISSES)/SUM(GETS))),2) "DDC HIT RATIO" FROM V$ROWCACHE