In 11g, the DBMS_SHARED_POOL package has a couple of new procedures. One of them is the PURGE procedure which allows individual objects to be flushed from the shared pool. The create statement for this package can be found in the $ORACLE_HOME/rdbms/admin/dbmspool.sql script. I first ran across this about a year ago on Fairlie Rego’s Blog. The modification history shows that the PURGE procedure was written back in Aug, 2006 – so it’s been around for a while. The PURGE procedure can be used to dump objects from the shared pool including code (procedure/package/function), sequences, type definitions, triggers, and cursors (i.e. SQL statments). The ability to flush a single SQL statement is what caught my eye. Unfortunately, the option to purge cursors is not in the 11.1 documentation but it is documented (lightly) in the header of the package definition as you can see here.

rem $Header: dbmspool.sql 14-nov-2006.02:58:03 desinha Exp $
rem
Rem Copyright (c) 1991, 2006, Oracle. All rights reserved.
Rem NAME
Rem dbmspool.sql - dbms_shared_pool utility package.
Rem DESCRIPTION
Rem This package allows you to display the sizes of objects in the
Rem shared pool, and mark them for keeping or unkeeping in order to
Rem reduce memory fragmentation.
Rem RETURNS
Rem
Rem NOTES
Rem MODIFIED (MM/DD/YY)
Rem desinha 08/29/06 - Add purge
Rem rburns 05/07/06 - split for parallel
Rem mjungerm 06/15/99 - add java shared data object type
Rem ansriniv 04/13/98 - keep functionality for types
Rem gdoherty 06/05/97 - invoke prvtpool
Rem ansriniv 03/26/97 - provide keep/unkeep for sequences
Rem asurpur 04/09/96 - Dictionary Protection Implementation
Rem bhirano 12/23/94 - merge changes from branch 1.3.720.1
Rem adowning 02/23/94 - split into public/private files
Rem ajasuja 01/06/94 - merge changes from branch 1.1.312.1
Rem rkooi 04/20/93 - change psdkeep to psdkep
Rem ajasuja 11/05/93 - handle UNIX addresses
Rem rkooi 12/08/92 - Creation
create or replace package dbms_shared_pool is
------------
-- OVERVIEW
--
-- This package provides access to the shared pool. This is the
-- shared memory area where cursors and PL/SQL objects are stored.
----------------------------
-- PROCEDURES AND FUNCTIONS
--
procedure sizes(minsize number);
-- Show objects in the shared_pool that are larger than the specified
-- size. The name of the object is also given which can be used as
-- an argument to either the 'keep' or 'unkeep' calls below. You should
-- issue the SQLDBA or SQLPLUS 'set serveroutput on size xxxxx'
-- command prior to using this procedure so that the results will
-- be displayed.
-- Input arguments:
-- minsize
-- Size, in kilobytes, over which an object must be occupying in the
-- shared pool, in order for it to be displayed.
procedure keep(name varchar2, flag char DEFAULT 'P');
-- Keep an object in the shared pool. Once an object has been keeped in
-- the shared pool, it is not subject to aging out of the pool. This
-- may be useful for certain semi-frequently used large objects since
-- when large objects are brought into the shared pool, a larger
-- number of other objects (much more than the size of the object
-- being brought in, may need to be aged out in order to create a
-- contiguous area large enough.
-- WARNING: This procedure may not be supported in the future when
-- and if automatic mechanisms are implemented to make this
-- unnecessary.
-- Input arguments:
-- name
-- The name of the object to keep. There are two kinds of objects:
-- PL/SQL objects, triggers, sequences, types and Java objects,
-- which are specified by name, and
-- SQL cursor objects which are specified by a two-part number
-- (indicating a location in the shared pool). For example:
-- dbms_shared_pool.keep('scott.hispackage')
-- will keep package HISPACKAGE, owned by SCOTT. The names for
-- PL/SQL objects follows SQL rules for naming objects (i.e.,
-- delimited identifiers, multi-byte names, etc. are allowed).
-- A cursor can be keeped by
-- dbms_shared_pool.keep('0034CDFF, 20348871', 'C')
-- The complete hexadecimal address must be in the first 8 characters.
-- The value for this identifier is the concatenation of the
-- 'address' and 'hash_value' columns from the v$sqlarea view. This
-- is displayed by the 'sizes' call above.
-- Currently 'TABLE' and 'VIEW' objects may not be keeped.
-- flag
-- This is an optional parameter. If the parameter is not specified,
-- the package assumes that the first parameter is the name of a
-- package/procedure/function and will resolve the name. Otherwise,
-- the parameter is a character string indicating what kind of object
-- to keep the name identifies. The string is case insensitive.
-- The possible values and the kinds of objects they indicate are
-- given in the following table:
-- Value Kind of Object to keep
-- ----- ----------------------
-- P package/procedure/function
-- Q sequence
-- R trigger
-- T type
-- JS java source
-- JC java class
-- JR java resource
-- JD java shared data
-- C cursor
-- If and only if the first argument is a cursor address and hash-value,
-- the flag parameter should be set to 'C' (or 'c').
-- Exceptions:
-- An exception will raised if the named object cannot be found.
procedure unkeep(name varchar2, flag char DEFAULT 'P');
-- Unkeep the named object.
-- WARNING: This procedure may not be supported in the future when
-- and if automatic mechanisms are implemented to make this
-- unnecessary.
-- Input arguments:
-- name
-- The name of the object to unkeep. See description of the name
-- object for the 'keep' procedure.
-- flag
-- See description of the flag parameter for the 'keep' procedure.
-- Exceptions:
-- An exception will raised if the named object cannot be found.
procedure purge(name varchar2, flag char DEFAULT 'P', heaps number DEFAULT 1);
-- Purge the named object or particular heap(s) of the object.
-- Input arguments:
-- name
-- The name of the object to purge. See description of the name
-- object for the 'keep' procedure.
-- flag
-- See description of the flag parameter for the 'keep' procedure.
-- heaps
-- heaps to purge. e.g if heap 0 and heap 6 are to be purged.
-- 1=0 | 1=6 = hex 0x41 = decimal 65. so specify heaps=65.
-- Default is 1 i.e heap 0 which means the whole object will be purged.
-- Exceptions:
-- An exception will raised if the named object cannot be found.
procedure aborted_request_threshold(threshold_size number);
-- Set aborted request threshold for the shared pool.
-- Input arguments:
-- threshold_size
-- The size in bytes of a request which will not try to free unpinned
-- (not "unkeep-ed") memory within the shared pool. The range of
-- threshold_size is 5000 to ~2 GB inclusive.
-- Description:
-- Usually, if a request cannot be satisfied on the free list,
-- the RDBMS will try to reclaim memory by freeing objects from the
-- LRU list and checking periodically to see if the request can be
-- fulfilled. After finishing this step, the RDBMS has performed a near
-- equivalent of an 'alter system flush shared_pool'. As this impacts
-- all users on the system, this procedure "localizes" the impact to the
-- process failing to find a piece of shared pool memory of size
-- greater than thresh_hold size. This user will get the out of
-- memory error without attempting to search the LRU list.
-- Exceptions:
-- An exception will be raised if threshold is not in the valid range.
--

The interface to the PURGE procedure is a little screwy. You have to provide the SQL statement’s ADDRESS and HASH_VALUE from the v$sqlarea view, separated by a comma like so: ‘C18555B4,3891882158′. This seemed like a lot of bother so I wrote a little script that prompts for a sql_id and gets the address and hash_value for me and then calls the PURGE procedure. I called it flush_sql. Also the whole bit about flushing specific heaps didn’t make much sense to me, so the script just passes a value of 1 which appears to flush the whole statement including all the child cursors. Here’s an example:

29 Comments

I assume you mean the flush_sql.sql script. It is actually linked in the text in the post. I’m still experimenting with wrapping examples with that source code widget thing. Here’s the source in case you can’t get it the link to work.

[…] posted earlier about the ability to flush a single SQL statement out of the shared pool in 11g (also back ported to 10.2.0.4 with a bit …. If you are on an earlier release of Oracle though, you can accomplish the same thing by creating […]

[…] In 11g this is very easy as there is a built function (psuedo documented) to flush a single SQL statement from the shared pool (see my previous post – Flush A Single SQL Statement – for details). […]

I just realized that in some instances, the upgrade from 10.2.0.3 to 10.2.0.4 does not automatically create the DBMS_SHARED_POOL package. The file $ORACLE_HOME/rdbms/admin/dbmspool.sql should be there. But you may need to execute it manually to create the package. Like so:

Kerry – has anyone ever indicated that the pbod for dbms_shared_pool becomes invalidated with the 10.2.0.4.0 patch or 11g dbmspool.sql is loaded? I came upon your post during a production issue we are having with bad plans on peeked binds. This seems like the perfect solution if I could get it to work. I have recreated this both on HPUX and Linux.

No, I haven’t run into that problem. Sorry. The file that I executed was called called dbmspool.sql (the back ported version) not dbmspool11g.sql. Might try checking with support or the other “trick” way using the create outline, drop outline method I talked about here:

The script dbmspool11g.sql only creates the package specification, not the body, and it does invalidate the current package body because it doesn’t match the current spec. Look inside the script and you’ll find only a CREATE OR REPLACE PACKAGE … command; there will also be a .plb file in the same location which will create the package body to match the specification. The ?/rdbms/admin/dbmspool.sql script which Kerry used creates the package spec and calls the wrapped script to create the corresponding package body. All I see in your posted output is ‘Package created.'; there should also be the following messge:

“Package body created.”

for this to function correctly.

If you can’t find a corresponding .plb file for the dbmspool11g.sql script I suggest you run the listed dbmspool.sql script to get the spec and body created correctly.

Yes – dbms_shared_pool.keep is supposed to be able to pin individual SQL statements as well. Here’s a couple of scripts. The first one takes a sql_id and pins the statement. The second one shows all the pinned statements.

Have you encountered any issues with this in 11.2.0.1? Oracle seems to flush only the last child cursor, not the original one that parsed the query. The package body is there an valid and I’m not getting any errors out of the procedure.

No I have not run into that issue. But the dbms_shared_pool.purge procedure is very lightly documented. The last parameter is called HEAPS. I have used a value of 1 which seems to dump everything. It may be that there is something unusual about your particular cursor and that a different HEAPS value would cure. So you might try messing with that. Or it may be that the child cursor is still in use and thus preventing it from being flushed. This is probably more likely.

Hi Kerry,
will dbms_shared_pool.purge remove the sql even if its ‘active’ ? What happens when another session is running the same query while the purge is executed ? Does it still purge the sql from the cache ? or wait for the other query to finish ? or does NOT purge it at all ?

No it won’t flush active statements although it appears to mark them to be flushed when they become inactive (not sure where the bit is set for this as it doesn’t appear to be exposed in v$sql_shared_cursor in 11.2.0.3 even though there is PURGED_CURSOR flag in that view).

Hi Kerry
We have been using the script to flush sql_id in our shop. I thought if there is a extended version of this script that would allow to flush sql_id from local node for a different node (for example from node 1 flush the sql_id on node X). The reason is simple, we want to automate this and when someone slaps a sql profile on a sql_id we want to flush the sql_id on all RAC nodes to ensure the new plan is picked up across the board. Logging into different nodes to achieve this seems to be time inefficient. I am thinking of writing a shell script to achieve this, but wondering if there is one out there already.

I have not written such a script. Might be an interesting little project. You shouldn’t need to do this for SQL Profiles (or Patches or Baselines) though. When you create (or drop such an object) the cursors in other nodes should be invalidated, this may be version dependent but I haven’t had any issues with it in a long time. In fact, the last time I had such an issue was using Outlines in early 10g I think (or maybe it was 9i). Not that flushing/invalidating cursors across a large number of RAC nodes might not be usual for other purposes. One idea might be to create a SQL Patch (with a nonsensical hint text) and then drop it. This could be run from a single node and should invalidate cursors across the cluster, although it wouldn’t necessarily flush all children.

Thanks for sharing this and the scripts. Just a simple question, each time you call the script “find_sql” it asked for input “address” but I don’t see the parameter anywhere in the script. Would you explain a little bit?