Practice 20 - Tuning The Shared Pool
Practice 20 - Tuning The Shared Pool
Practice 20
Practice Target
In this practice, you will perform the following:
• Simulate high parse issue then troubleshoot it
2. In the hosting PC, open a command prompt window and start Swingbench. Click on Start
Benchmark button.
D:
cd D:\swingbench\winbin
set PATH=D:\oracle\product\12.1.0\client_1\jdk\jre\bin;%PATH%
swingbench.bat
3. Start Putty and connect to srv1 as oracle. Then invoke SQL*Plus and login to ORADB as sysdba.
In the rest of this practice, this session will be referred to as admin window.
Note: Unless stated otherwise, all the steps in this practice should be run in the admin window.
sqlplus / as sysdba
set sqlprompt "ADMIN> "
5. Start two Putty sessions and connect to srv1 as oracle. In each session invoke SQL*Plus and
login to ORADB as soe. In this practice, those sessions are referred to as client windows.
sqlplus soe/soe@ORADB
set sqlprompt "CLIENT> "
6. In the two client sessions, run the following code to simulate high hard parsing issue.
The code runs endless loop that keeps executing queries with literals.
DECLARE
I NUMBER :=1;
N NUMBER ;
BEGIN
-- press CTL+C to stop the loop in SQL*Plus
WHILE (TRUE) LOOP
I := I + 1;
EXECUTE IMMEDIATE 'SELECT COUNT(*) FROM SOE.ORDERS WHERE ORDER_ID = ' ||
TO_CHAR(I)
INTO N ;
END LOOP;
END;
/
8. Run the following query script a few times to display the top events in the time model view.
Observer how the percentage of the hard parse time is steady incrementing.
@ $SD/time_model_pct.sql
9. Retrieve the top wait events at the database level. Re-run the query multiple times.
col EVENT format a40
col WAIT_CLASS format a11
SELECT EVENT, AVERAGE_WAIT,
TO_CHAR(ROUND(TIME_WAITED/100),'999,999,999') TIME_SECONDS, WAIT_CLASS
FROM V$SYSTEM_EVENT
WHERE TIME_WAITED>0 AND WAIT_CLASS<>'Idle'
ORDER BY TIME_WAITED DESC FETCH FIRST 10 ROWS ONLY;
10. Retrieve the top wait events for all the current sessions created by soe
The mutex 'cursor: pin S wait on X' is going up to the top wait event.
SELECT E.EVENT, E.WAIT_CLASS,
TO_CHAR(ROUND(SUM(E.TIME_WAITED)/100),'999,999,999') TIME_SECONDS
FROM V$SESSION_EVENT E, V$SESSION S
WHERE E.SID=S.SID AND ROUND(E.TIME_WAITED/100)>0
AND S.USERNAME='SOE' AND E.WAIT_CLASS <> 'Idle'
GROUP BY E.EVENT, E.WAIT_CLASS
ORDER BY TIME_SECONDS DESC FETCH FIRST 10 ROWS ONLY;
11. Display the amount of CPU processing consumed by all soe sessions in the last 10 minutes
grouped by minute.
Do not count the figure of the most recent minute because most likely it was not finished yet
when the query was executed.
SELECT TO_CHAR(SAMPLE_TIME,'HH24:MI') SMINUTE, COUNT(1) CPU
FROM V$ACTIVE_SESSION_HISTORY
WHERE USER_ID IN ( SELECT USER_ID FROM DBA_USERS WHERE USERNAME='SOE')
AND SESSION_STATE = 'ON CPU'
AND SAMPLE_TIME > SYSTIMESTAMP - INTERVAL '10' MINUTE
GROUP BY TO_CHAR(SAMPLE_TIME,'HH24:MI')
ORDER BY 1 DESC;
13. Open the generated file in the browser. Read the sections of the report to figure out the issue
from the report.
15. Generate an AWR report named as awr_shared_pool1.html for the last two created snapshots
@ ?/rdbms/admin/awrrpt.sql
host mv awr_shared_pool1.html /media/sf_extdisk
Note: Do not delete the generated HTML files. You will still need them in the next practice section.
20. Run the following query to display the library cache memory object sizes.
SELECT LC_NAMESPACE NAMES,
LC_INUSE_MEMORY_OBJECTS "OBJECTS",
LC_INUSE_MEMORY_SIZE "USED_MEM (MB)",
LC_FREEABLE_MEMORY_SIZE "FEEABLE MEM (MB)"
FROM V$LIBRARY_CACHE_MEMORY
ORDER BY LC_INUSE_MEMORY_OBJECTS DESC;
21. In the reports normal_oltp.html and awr_shared_pool1.html, study the section “Shared Pool
Advisory”.
o What is the optimal size proposed by each report?
o Which one should be considered?
22. Run the following query to find the optimal shared pool size from the Shared Pool Advisory view.
set lines 100
set pages 999
column c1 heading 'Pool |Size(M)'
column c2 heading 'Size|Factor'
column c3 heading 'Est|LC(M) '
column c4 heading 'Est LC|Mem. Obj.'
column c5 heading 'Est Time|Saved (sec)'
column c6 heading 'Est Parse|Saved Fctr'
column c7 heading 'Est|Object Hits' format 999,999,999
SELECT SHARED_POOL_SIZE_FOR_ESTIMATE C1,
SHARED_POOL_SIZE_FACTOR C2,
ESTD_LC_SIZE C3,
ESTD_LC_MEMORY_OBJECTS C4,
ESTD_LC_TIME_SAVED C5,
ESTD_LC_TIME_SAVED_FACTOR C6,
ESTD_LC_MEMORY_OBJECT_HITS C7
FROM V$SHARED_POOL_ADVICE ORDER BY 1;
In the following steps, you will raise the 'library cache pin' issue and perform the steps to detect it.
26. Start a fourth Putty session. Connect to srv1 as oracle, invoke SQL*Plus and connect to
ORADB as soe. In the rest of this practice, this session will be referred to as the monitored
session.
sqlplus soe/soe
set sqlprompt "CLIENT3> "
28. In the admin window, save the SID value returned from the preceding step into a substitution
variable.
define V_SID =<enter sid>
29. In the admin window, run the following query multiple times to display the top waiting events on
the soe sessions.
30. In the monitored session, compile the created function. The command will hang. Do not wait for
the command output. Go to the next step.
Note: If the statement could not take the lock, after some timeout, it returns the following error:
ORA-04021: timeout occurred while waiting to lock object
31. In the admin window, run the query again multiple times to display the top waiting events on
the soe sessions.
'library cache pin' came to the top of the waiting events and keeps incrementing.
32. In the admin window, obtain more details on what the monitoring session is waiting for.
The hang session is waiting for the event 'library cache pin'.
From obtaining the SQL statement, we know that we can obtain which object the session wants
to take its lock. But let’s try getting it from the P1RAW. With this particular wait event, the column
P1RAW is the "Handle Address" of the object.
set linesize 180
col P1TEXT format a15
col STATE format a10
SELECT EVENT, P1TEXT, P1, P1RAW, WAIT_TIME, STATE, WAIT_TIME_MICRO
FROM V$SESSION WHERE SID=&V_SID;
33. Execute the following query to get the object's owner and name:
col OWNER format a10
col OBJECT format a20
SELECT KGLNAOWN AS OWNER, KGLNAOBJ AS OBJECT
FROM SYS.X$KGLOB WHERE KGLHDADR='&Enter_P1RAW';
34. As a cleanup, cancel the executions in all the client sessions and drop the package.
DROP PACKAGE SOE.PCKORDERS;
Summary
• High parse rate is something that should always be avoided in the shared pool
• High parse rate leads to trigger the mutex 'cursor: pin S wait on X'
• Shared Pool Advisory can be used to determine the optimal shared pool size
• The optimal shared pool size should be determined when the system is running in normal
conditions
• High rate of the 'library cache pin' event should always be avoided in any system.
Investigation should be issued to learn the root cause.