PINNING ORACLE APPLICATIONS OBJECTS INTO THE SHARED POOL

Pinning Oracle Applications Objects into the shared pool

Scope:
Oracle Applications DBAs who want to improve database performance by pinning packages into shared pool.

Why pinning objects into the shared pool?
Oracle Applications requires space in the ORACLE System Global Area (SGA) for stored packages and functions. If SGA space is fragmented, there may not be enough space to load a package or function. You should pre-allocate space in the SGA shared pool for packages, functions, and sequences by “pinning” them.

Pinning objects in the shared pool can provide a tremendous increase in database performance, if it is done correctly. Since pinned objects reside in the SQL and PL/PLSQL memory areas, they do not need to be loaded and parsed from the database, which saves considerable time.

What objects to be pinned into the shared pool?
Most performance improvement can be gained from pinning large, frequently used packages. Pinned objects are expensive in terms of memory space, since other not-pinned objects need this memory space, too. In general do not pin all objects or rarely used objects – this could even decrease database performance.

As a general rule, you should always pin the following packages which are owned by SYS:
(see Note 61623.1 SHARED POOL TUNING)

STANDARD
DBMS_STANDARD
DBMS_UTILITY
DBMS_DESCRIBE
DBMS_OUTPUT
and maybe other SYS packages that are often used (DBMS_LOCK, DBMS_ALERT, etc.).

The Applications objects that should be pinned are harder to identify and will vary from site to site, depending on what the users are doing. To identify good candidates for pinning, you need to know which objects are being executed the most. To do this, let the system run long enough to reach a steady state (several days to a week). Then initiate a SQL*Plus session as system (or sys or apps) and run the following script $AD_TOP/sql/ADXCKPIN.sql. This will spool object execution and reload statistics into the output file ADXCKPIN.lst.

Example output:

OBJECT TYPE SPACE(K) LOADS EXECS KEPT
———————————- ———— ——– —— ——- —-
APPS.FND_ATTACHMENT_UTIL_PKG PACKAGE 15.2 1 9 NO
APPS.FND_ATTACHMENT_UTIL_PKG PACKAGE BODY 13.7 1 8 NO
APPS.FND_CLIENT_INFO PACKAGE 2.7 1 206 NO
APPS.FND_CLIENT_INFO PACKAGE BODY 13.0 1 206 NO
APPS.FND_CONCURRENT PACKAGE 15.2 1 199 NO
APPS.FND_CONCURRENT PACKAGE BODY 24.2 1 197 NO

Another handy script:

SELECT substr(owner,1,10)||’.’||substr(name,1,35) “Object Name”,
‘ Type: ‘||substr(type,1,12)||
‘ size: ‘||sharable_mem ||
‘ execs: ‘||executions||
‘ loads: ‘||loads||
‘ Kept: ‘||kept
FROM v$db_object_cache
WHERE type in (‘TRIGGER’,’PROCEDURE’,’PACKAGE BODY’,’PACKAGE’)
AND executions > 0
ORDER BY executions desc,
loads desc,
sharable_mem desc;

Note: The Oracle8 documentation says that the column EXECUTIONS is “Not used. To see actual execution counts, see “V$SQLAREA” “. But it is still used in Oracle8.
Choose the objects with a high number of executions (EXECS) or very large (SPACE(K)), frequently used objects. If the decision is between two objects that have been executed the same number of times, then preference should be given to the larger object. From experience, very good results have been achieved with having pinned only about 10 packages.

How to pin object into shared pool?
The pl/sql scripts $AD_TOP/sql/ADXGNPIN.sql (packages, functions) and ADXSPPNS.sql (sequences) generate pinning scripts, which can be executed in Sql*Plus. Do not run them without having edited them, otherwise the scripts would try to pin all objects. Create your own script to pin the packages and pin them in a descending order according to their size.

The pl/sql command to pin a package (i.e. FNDCP_TMSRV) manually is:

SQL> execute dbms_shared_pool.keep(‘APPS.FNDCP_TMSRV’);

Note: The objects have to be pinned after each instance startup, and ideally immediately after the startup. Prior to Oracle 7.2 DBMS_SHARED_POOL.KEEP does not actually load all of the object to be KEPT into the shared pool. It is advisable to create a dummy procedure to execute each package to be KEPT. This dummy procedure can then be called after calling DBMS_SHARED_POOL.KEEP to ensure that the object is fully loaded. This is not a problem from 7.2 onwards.

Related Documents:
Note 62161.1 Systemwide Tuning using UTLESTAT Reports in Oracle7/8
Note 68307.1 STEPS TO RESOLVE APPLICATIONS LATCHING ISSUES

Sobre Alexandre Pires

ORACLE OCS Goldengate Specialist, OCE RAC 10g R2, OCP 12C, 11g, 10g , 9i e 8i - Mais de 25 anos de experiência na área de TI. Participei de projetos na G&P alocado na TOK STOK, EDINFOR alocado na TV CIDADE "NET", 3CON Alocado no PÃO DE AÇUCAR, DISCOVER alocado na VIVO, BANCO IBI e TIVIT, SPC BRASIL, UOLDIVEO alocado no CARREFOUR e atualmente na ORACLE ACS atendendo os seguintes projetos: VIVO, CLARO, TIM, CIELO, CAIXA SEGUROS, MAPFRE, PORTO SEGURO, SULAMERICA, BRADESCO SEGUROS, BANCO BRADESCO, BASA, SANTANDER, CNJ, TSE, ELETROPAULO, EDP, SKY, NATURA, ODEBRESHT, NISSEI, SICREDI, CELEPAR, TAM, TIVIT, IBM, SMILES, CELEPAR, SERPRO,OKI,BANCO PAN, etc
Esse post foi publicado em BUFFERS, ORACLE EBS, PLSQL SCRIPTS, PLSQL TUNING, SGA. Bookmark o link permanente.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s