THE PRAGMA KEYWORD

A PRAGMA IS GENERALLY A LINE OF SOURCE CODE PRESCRIBING AN ACTION YOU WANT THE
COMPILER TO TAKE. ITS LIKE AN OPTION THAT YOU GIVE THE COMPILER.
IT CAN RESULT IN DIFFERENT RUNTIME BEHAVIOUR FOR THE PROGRAM BUT IT DOESN'T GET
TRANSLATED DIRECTLY INTO BYTECODE.

PLSQL HAS A PRAGMA KEYWORD WITH THE FOLLOWING SYNTAX:

PRAGMA instruction_to_compiler;

PLSQL OFFERS SEVERAL PRAGMAS:

1) AUTONOMOUS_TRANSACTION:

THE PRAGMA INSTRUCTS THE PLSQL COMPILER TO ESTABLISH A PLSQL BLOCK AS AUTONOMOUS OR
INDEPENDENT. FOR THE PURPOSES OF THE AUTONOMOUS TRANSACTION, A PLSQL BLOCK CAN BE
ANY OF THE FOLLOWING:

--> TOP LEVEL ( BUT NOT NESTED ) ANONYMOUS PLSQL BLOCKS.

--> FUNCTIONS AND PROCEDURES, DEFINED EITHER IN A PACKAGE OR AS STANDALONE
PROGRAMS.
--> METHODS ( FUNCIONS AND PROCEDURES ) OF AN OBJECT TYPE.
--> DATABASE TRIGGERS.

PRAGMA AUTONOMOUS_TRANSACTION;

YOU CAN PUT THE AUTONOMOUS TRANSACTION PRAGMA ANYWHERE IN THE DECLARATION SECTION
OF YOUR PL/SQL BLOCK.

AN AUTONOMOUS TRANSACTION STARTS WITH THE FIRST SQL STATEMENT OF THE PL/SQL BLOCK
AND ENDS WITH A COMMIT. IT STARTS WITHIN THE CONTEXT OF AN ANOTHER TRANSACTION
CALLED PARENT TRANSACTION AND INDEPENDENT OF IT (PARENT TRANSACTION).TO MAKE A
TRANSACTION AUTONOMOUS U HAVE TO DECLARE PRAGMA AUTONOMOUS_TRANSACTION AT THE
BEGINNING.

THE MAIN ADVANTAGE OF USING PRAGMA AUTONOMOUS_TRANSACTION IS THAT WEATHER THE

TRANSACTION MADE BY THE PARENT MAY BE ROLLED BACK DUE TO SOME ERROR, THE AUTONOMOUS
TRANSACTION HAS NO EFFECT ON IT. SUPPOSE IF THERE IS ANY ERROR IN AUTONOMOUS
TRANSACTION � THEN >>>> WHAT HAPPEN? ? ? DON�T WORRY***** IT WILL SAVE ALL THE
TRANSACTIONS JUST BEFORE THE ERROR OCCURRED. ONLY THE LAST TRANSACTION THAT HAS
ERROR WILL BE ROLLED BACK ONLY IF THERE IS NO ERROR HANDLER.

HERE ARE SOME SPECIFIC IDEAS:

1) LOGGING MECHANISM

ON THE ONE HAND, YOU NEED TO LOG AN ERROR TO YOUR DATABASE LOG TABLE. ON THE OTHER
HAND, YOU NEED TO ROLL BACK YOUR CORE TRANSACTION BECAUSE OF THE ERROR. AND YOU
DON�T WANT TO ROLL BACK OVER OTHER LOG ENTRIES. WHAT�S A PERSON TO DO? GO
AUTONOMOUS!THIS IS PROBABLY THE MOST COMMON MOTIVATION FOR PL/SQL DEVELOPERS TO USE
AUTONOMOUS TRANSACTIONS AND IS EXPLORED AT THE END OF THIS SECTION.

2) PERFORM COMMITS AND ROLLBACKS IN YOUR DATABASE TRIGGERS

IF YOU DEFINE A TRIGGER AS AN AUTONOMOUS TRANSACTION, THEN YOU CAN COMMIT AND/OR
ROLL BACK IN THAT TRIGGER, WITHOUT AFFECTING THE TRANSACTION THAT FIRED THE
TRIGGER. WHY IS THIS VALUABLE? YOU MAY WANT TO TAKE AN ACTION IN THE DATABASE
TRIGGER THAT IS NOT AFFECTED BY THE ULTIMATE DISPOSITION OF THE TRANSACTION THAT
CAUSED THE TRIGGER TO FIRE. FOR EXAMPLE, SUPPOSE THAT YOU WANT TO KEEP TRACK OF
EACH ACTION AGAINST A TABLE, WHETHER OR NOT THE ACTION COMPLETED. YOU MIGHT EVEN
WANT TO BE ABLE TO DETECT WHICH ACTIONS FAILED.

3) AVOID MUTATING TABLE TRIGGER ERRORS FOR QUERIES

MUTATING TABLE TRIGGER ERRORS OCCUR WHEN A ROW-LEVEL TRIGGER ATTEMPTS TO READ FROM
OR WRITE TO THE TABLE FROM WHICH IT WAS FIRED. IF, HOWEVER, YOU MAKE YOUR TRIGGER
AN AUTONOMOUS TRANSACTION BY ADDING THE PRAGMA AUTONOMOUS_TRANSACTION STATEMENT AND
COMMITTING INSIDE THE BODY OF THE TRIGGER, THEN YOU WILL BE ABLE TO QUERY THE
CONTENTS OF THE FIRING TABLE�BUT YOU CAN ONLY SEE ALREADY COMMITTED CHANGES TO THE
TABLE. IN OTHER WORDS, YOU WILL NOT SEE ANY CHANGES MADE TO THE TABLE THAT CAUSED
THE FIRING OF THE TRIGGER. IN ADDITION, YOU WILL STILL NOT BE ALLOWED TO MODIFY THE
CONTENTS OF THE TABLE.

2) EXCEPTION_INIT

ITS A PRAGMA WHICH IS USED TO ASSOCIATE USER DEFINED EXCEPTION WITH ORACLE DEFINED
ERROR NUMBER.

PRAGMA EXCEPTION_INIT (unexpected_data,-01422);

HERE IN THE FOLLOWING EXAMPLE:

UNEXPECTED_DATA - USER DEFINED EXCEPTION

-01422 - SYSTEM DEFINED ERROR CODE,IN GENERAL WE GET THIS TYPE OF ERROR CODE IN A
SITUATION LIKE OUR SELECT STATEMENT RETRIEVES ROWS MORE THAN THE CAPACITY OF
MEMORY VARIABLE DECLARED IN DECLARATIVE SECTION.
EXAMPLE

DECLARE
v_employeeid EMPLOYEES.EMPLOYEE_ID%TYPE;
unexpected_data EXCEPTION;
PRAGMA EXCEPTION_INIT (unexpected_data,-01422);
BEGIN
SELECT employee_id INTO v_employeeid FROM employees WHERE employee_id BETWEEN
101 AND 123;
EXCEPTION
WHEN unexpected_data
THEN
DBMS_OUTPUT.PUT_LINE ('SELECT STATEMENT IS RETRIVING ROWS MORE THAN THE
CAPABILITY OF MEMORY VARIABLE,KINDLY DECLARE CURSOR IN DECLARATIVE SECTION');
END;

3) RESTRICT_REFERENCES

PRAGMA RESTRICT_REFERENCES IS A COMPILER DIRECTIVE. IT MAKES SURE THAT THE FUNCTION

MAINTAINS THE PURITY RULES AND CODE IN FUCTION CREATION SATISFY THE PURITY RULES.
THERE ARE 4 VALUES FOR IT.

WNDS
RNDS
WNPS
RNPS
PRAGMA RESTRICT_REFERENCES USES TO CONTROL THE SIDE EFFECTS OF PL/SQL SUBPROGRAMS.
EVERY PL/SQL SUBPROGRAMS MUST FOLLOW SOME RULES IN TERMS OF TRANSACTION CONTROL AND
SECURITY.

SYNTAX :-

CREATE OR REPLACE PACKAGE PKG_SALARY

IS
FUNCTION GET_EMP_SALARY(P_EMPNO INTEGER) RETURN NUMBER;
PRAGMA RESTRICT_REFERENCES(GET_EMP_SALARY, RNDS, RNPS, WNDS, WNPS);
END PKG_SALARY;

RNDS � READ NO DATABASE STATE. ASSERTS THAT THE FUNCTION NOT TO READ OR QUERY
TABLES
RNPS � READ NO PACKAGE STATE. ASSERTS THAT THE FUNCTION NOT TO READ OR REFERENCE
PACKAGE VARIABLES
WNDS � WRITE NO DATABASE STATE. ASSERTS THAT THE FUNCTION NOT MODIFY DATABASE
TABLES
WNPS � WRITE NO PACKAGE STATE. ASSERTS THAT THE FUNCTION NOT MODIFY PACKAGE
VARIABLES
TRUST � ASSERTS THAT THE FUNCTION CAN BE TRUSTED NOT TO VIOLATE ONE OR MORE RULES.
USED ONLY WHEN C OR JAVA ROUTINES ARE CALLED FROM PL/SQL.

EXPLANATION :-

IN THE ABOVE EXAMPLE FUNCTION GET_EMP_SALARY IS ASSOCIATED WITH PRAGMA

RESTRICT_REFERENCES. ORACLE CONVEYING THE COMPILER TO FOLLOW FOUR RULES WNDS, WNPS,
RNDS, RNPS. WHEN THE PACKAGE BODY COMPILES AND FIND ANY RULES WHICH VIOLATES ANY OF
THE RULES (RNDS, RNPS, WNDS, WNPS, TRUST) IT WILL RAISE A COMPILATION ERROR. NOTE
THAT IF THERE IS A PRAGMA DERIVATIVE AND VIOLATES ANY RULES IT WILL NOT RAISE ANY
COMPILER ERROR AND IT MIGHT RAISE RUN TIME ERROR.

CONSIDER THE BELOW EXAMPLES

1) FUNCTION TO RAISE EMPLOYEE SALARY

CREATE OR REPLACE PACKAGE PKG_SALARY

IS
FUNCTION GET_EMP_SALARY(P_EMPNO INTEGER) RETURN NUMBER;
END PKG_SALARY;
/

CREATE OR REPLACE PACKAGE BODY PKG_SALARY

IS
FUNCTION GET_EMP_SALARY(P_EMPNO INTEGER) RETURN NUMBER
IS
N_SAL NUMBER;
BEGIN
UPDATE EMP SET SALARY = SALARY + SALARY * 0.1 WHERE EMPNO = P_EMPNO
RETURNING SALARY INTO N_SAL;
COMMIT;
RETURN N_SAL;
END GET_EMP_SALARY;
END PKG_SALARY;
/

COMPILING��..

SQL> ../PKG_SALARY.SQL;
PACKAGE CREATED.
PACKAGE BODY CREATED.
EXECUTING���

SQL> SELECT PKG_SALARY.GET_EMP_SALARY(10) FROM DUAL;

SELECT PKG_SALARY.GET_EMP_SALARY(10) FROM DUAL
*
ERROR AT LINE 1:
ORA-14551: CANNOT PERFORM A DML OPERATION INSIDE A QUERY

SO PACKAGE SPECIFICATION AND BODY COMPILED PROPERLY BUT UNABLE TO USE IT AS IT

RAISE ERROR WHILE EXECUTING.

2) FUNCTION TO RAISE EMPLOYEE SALARY � WITH PRAGMA RESTRICT_REFERENCES

CREATE OR REPLACE PACKAGE PKG_SALARY

IS
FUNCTION GET_EMP_SALARY(P_EMPNO INTEGER) RETURN NUMBER;
PRAGMA RESTRICT_REFERENCES(GET_EMP_SALARY, WNDS);
END PKG_SALARY;
/

CREATE OR REPLACE PACKAGE BODY PKG_SALARY

IS
FUNCTION GET_EMP_SALARY(P_EMPNO INTEGER) RETURN NUMBER
IS
N_SAL NUMBER;
BEGIN
UPDATE EMP SET SALARY = SALARY + SALARY * 0.1 WHERE EMPNO = P_EMPNO
RETURNING SALARY INTO N_SAL;
COMMIT;
RETURN N_SAL;
END GET_EMP_SALARY;
END PKG_SALARY;
/

COMPILING��..

SQL> ../PKG_SALARY.SQL;
PACKAGE CREATED.

WARNING: PACKAGE BODY CREATED WITH COMPILATION ERRORS.

SQL> SHOW ERR

ERRORS FOR PACKAGE BODY PKG_SALARY:
LINE/COL ERROR
��� ����������������������
4/1 PLS-00452: SUBPROGRAM �GET_EMP_SALARY� VIOLATES ITS ASSOCIATED PRAGMA

WHEN WE USE PRAGMA RESTRICT_REFERENCES IT RAISES A COMPILER ERROR WHICH HELPS

DEVELOPER TO RE-WRITE HIS CODE. GENERALLY PRAGMA RESTRICT_REFERENCES ARE USED WITH
FUNCTIONS.

NOTE:-

DEFAULT KEY WORD APPLIES PRAGMA RESTRICT_REFERENCES TO ALL OF THE SUB PROGRAMS IN
SIDE THE PACKAGE SEE BELOW EXAMPLE

CREATE OR REPLACE PACKAGE PKG_SALARY

IS
FUNCTION GET_EMP_SALARY(P_EMPNO INTEGER) RETURN NUMBER;
FUNCTION GET_EMP_NAME(P_EMPNO INTEGER) RETURN VARCHAR2;
PRAGMA RESTRICT_REFERENCES(DEFAULT, WNDS);
END PKG_SALARY;
/
PACKAGE CREATED.

NOTE:- NORMALLY FUNCTIONS ARE NOT CREATED FOR DML RELATED PROCESSES AND PRAGMA
RESTRICT_REFERENCES ARE NOT NECESSARY.

4) SERIALLY_REUSABLE

THE SERIALLY_REUSABLE PRAGMA SPECIFIES THAT THE PACKAGE STATE IS NEEDED FOR ONLY
ONE CALL TO THE SERVER (FOR EXAMPLE, AN OCI CALL TO THE DATABASE OR A STORED
PROCEDURE INVOCATION THROUGH A DATABASE LINK). AFTER THIS CALL, THE STORAGE FOR THE
PACKAGE VARIABLES CAN BE REUSED, REDUCING THE MEMORY OVERHEAD FOR LONG-RUNNING
SESSIONS.

THIS PRAGMA IS APPROPRIATE FOR PACKAGES THAT DECLARE LARGE TEMPORARY WORK AREAS
THAT ARE USED ONCE IN THE SAME SESSION.

THE SERIALLY_REUSABLE PRAGMA CAN APPEAR IN THE DECLARE_SECTION OF THE SPECIFICATION

OF A BODILESS PACKAGE, OR IN BOTH THE SPECIFICATION AND BODY OF A PACKAGE, BUT NOT
IN ONLY THE BODY OF A PACKAGE.

THE STATE OF A SERIALLY REUSABLE PACKAGE PERSISTS ONLY FOR THE LIFETIME OF A CALL
TO THE SERVER. ON A SUBSEQUENT CALL TO THE SERVER, IF A REFERENCE IS MADE TO THE
SERIALLY REUSABLE PACKAGE, ORACLE CREATES A NEW INSTANTIATION (DESCRIBED BELOW) OF
THE SERIALLY REUSABLE PACKAGE AND INITIALIZES ALL THE GLOBAL VARIABLES TO NULL OR
TO THE DEFAULT VALUES PROVIDED. ANY CHANGES MADE TO THE SERIALLY REUSABLE PACKAGE
STATE IN THE PREVIOUS CALLS TO THE SERVER ARE NOT VISIBLE.

NOTE: CREATING A NEW INSTANTIATION OF A SERIALLY REUSABLE PACKAGE ON A CALL TO THE

SERVER DOES NOT NECESSARILY IMPLY THAT ORACLE ALLOCATES MEMORY OR CONFIGURES THE
INSTANTIATION OBJECT. ORACLE SIMPLY LOOKS FOR AN AVAILABLE INSTANTIATION WORK AREA
(WHICH IS ALLOCATED AND CONFIGURED) FOR THIS PACKAGE IN A LEAST-RECENTLY USED (LRU)
POOL IN SGA. AT THE END OF THE CALL TO THE SERVER THIS WORK AREA IS RETURNED BACK
TO THE LRU POOL. THE REASON FOR KEEPING THE POOL IN THE SGA IS THAT THE WORK AREA
CAN BE REUSED ACROSS USERS WHO HAVE REQUESTS FOR THE SAME PACKAGE.

WHY SERIALLY REUSABLE PACKAGES?

SINCE THE STATE OF A NON-REUSABLE PACKAGE PERSISTS FOR THE LIFETIME OF THE SESSION,
THIS LOCKS UP UGA MEMORY FOR THE WHOLE SESSION. IN APPLICATIONS SUCH AS ORACLE
OFFICE A LOG-ON SESSION CAN TYPICALLY EXIST FOR DAYS TOGETHER. APPLICATIONS OFTEN
NEED TO USE CERTAIN PACKAGES ONLY FOR CERTAIN LOCALIZED PERIODS IN THE SESSION AND
WOULD IDEALLY LIKE TO DE-INSTANTIATE THE PACKAGE STATE IN THE MIDDLE OF THE SESSION
ONCE THEY ARE DONE USING THE PACKAGE.

WITH SERIALLY_REUSABLE PACKAGES THE APPLICATION DEVELOPERS HAVE A WAY OF MODELLING

THEIR APPLICATIONS TO MANAGE THEIR MEMORY BETTER FOR SCALABILITY. PACKAGE STATE
THAT THEY CARE ABOUT ONLY FOR THE DURATION OF A CALL TO THE SERVER SHOULD BE
CAPTURED IN SERIALLY_REUSABLE PACKAGES.

EXAMINE THE PACKAGE WITH & WITHOUT SERIALLY_REUSABLE: CREATE TWO PACKAGES WITH &
WITHOUT SERIALLY_REUSABLE

SQL_11G> CREATE OR REPLACE PACKAGE WITHOUT_SERIALLY_REUSABLE_PKG AS

 2 V_WITHOUT_SR INT := 0;
3 END;
4 /
PACKAGE CREATED.

SQL_11G> CREATE OR REPLACE PACKAGE WITH_SERIALLY_REUSABLE_PKG AS

2 PRAGMA SERIALLY_REUSABLE;
3 V_WITH_SR INT := 0;
4 END;
5 /
PACKAGE CREATED.
NOW, LET US ASSIGN VALUES TO PACKAGED VARIABLES

SQL_11G> BEGIN
2 WITHOUT_SERIALLY_REUSABLE_PKG.V_WITHOUT_SR := 100;
3 WITH_SERIALLY_REUSABLE_PKG.V_WITH_SR := 100;
4 END;
5 /
PL/SQL PROCEDURE SUCCESSFULLY COMPLETED.

NOW, LET US DISPLAY THE VALUES OF PACKAGED VARIABLES

SQL_11G> BEGIN
2 DBMS_OUTPUT.PUT_LINE('WITHOUT_SERIALLY_REUSABLE_PKG.V_WITHOUT_SR VALUE IS -> '
|| WITHOUT_SERIALLY_REUSABLE_PKG.V_WITHOUT_SR );

3 DBMS_OUTPUT.PUT_LINE ('WITH_SERIALLY_REUSABLE_PKG.V_WITH_SR VALUES IS ->' ||

WITH_SERIALLY_REUSABLE_PKG.V_WITH_SR );
4 END;
5 /

WITHOUT_SERIALLY_REUSABLE_PKG.V_WITHOUT_SR VALUE IS -> 100

WITH_SERIALLY_REUSABLE_PKG.V_WITH_SR VALUES IS ->0

PL/SQL PROCEDURE SUCCESSFULLY COMPLETED.

WITH_SERIALLY_REUSABLE_PKG.V_WITH_SR IS SHOWING 0 BECAUSE THE PACKAGE IS MARKED AS

SERIALLY_REUSABLE WHICH RESETS THE PACKAGED VARIABLE GLOBAL VALUES TO DEFAULT
IMMEDIATELY AFTER ITS CALL.
NOW, CLUBBING ASSIGNMENT OF VARIABLES & DISPLAYING THE VALUES OF VARIABLES IN
SINGLE PLSQL BLOCK.

SQL_11G> BEGIN
2 WITHOUT_SERIALLY_REUSABLE_PKG.V_WITHOUT_SR := 100;
3 WITH_SERIALLY_REUSABLE_PKG.V_WITH_SR := 100;
4 DBMS_OUTPUT.PUT_LINE('WITHOUT_SERIALLY_REUSABLE_PKG.V_WITHOUT_SR VALUE IS ->
' || WITHOUT_SERIALLY_REUSABLE_PKG.V_WITHOUT_SR );
5 DBMS_OUTPUT.PUT_LINE ('WITH_SERIALLY_REUSABLE_PKG.V_WITH_SR VALUES IS ->' ||
WITH_SERIALLY_REUSABLE_PKG.V_WITH_SR );
6 END;
7 /

WITHOUT_SERIALLY_REUSABLE_PKG.V_WITHOUT_SR VALUE IS -> 100

WITH_SERIALLY_REUSABLE_PKG.V_WITH_SR VALUES IS ->0
PL/SQL PROCEDURE SUCCESSFULLY COMPLETED.

HERE ARE SOME THINGS TO KEEP IN MIND FOR SERIALIZED PACKAGES:

� THE GLOBAL MEMORY FOR SERIALIZED PACKAGES IS ALLOCATED IN THE SGA, NOT IN THE
USER�S UGA. THIS APPROACH ALLOWS THE PACKAGE WORK AREA TO BE REUSED. EACH TIME THE
PACKAGE IS REUSED, ITS PACKAGE-LEVEL VARIABLES ARE INITIALIZED TO THEIR DEFAULT
VALUES OR TO NULL, AND ITS INITIALIZATION SECTION IS RE-EXECUTED.

� THE MAXIMUM NUMBER OF WORK AREAS NEEDED FOR A SERIALIZED PACKAGE IS THE NUMBER OF
CONCURRENT USERS OF THAT PACKAGE. THE INCREASED USE OF SGA MEMORY IS OFFSET BY THE
DECREASED USE OF UGA OR PROGRAM MEMORY. FINALLY, THE DATABASE AGES OUT WORK AREAS
NOT IN USE IF IT NEEDS TO RECLAIM MEMORY FROM THE SGA FOR OTHER REQUESTS.

5) PRAGMA INLINE

WHEN YOU CALL SUBPROGRAM(PROCEDURE OR FUNCTION) IN YOUR CODE MULTIPLE TIME, IN

EVERY CALL IT WILL BE LOADED AGAIN SO IT WILL TAKE MORE TIME TO EXECUTE.
TO ENHANCE PREVIOUS DRAWBACK WE USE INLINE TO REPLACE THE SUBPROGRAM CALL WITH THE
COPY OF ALREADY CALLED SUBPROGRAM BEFORE.

PRAGMA INLINE DIRECTIVE IS NEW FEATURE PROVIDED SINCE ORACLE DATABASE 11G.
THE PRAGMA INLINE DIRECTIVE IS USED TO DETERMINE IF SUBPROGRAM CALL IS INLINE OR
NOT.

THE PRAGMA INLINE IS CONTROLLED BY PLSQL_OPTIMIZE_LEVEL PARAMETER VALUE

YOU CAN CHANGE PLSQL_OPTIMIZE_LEVEL BY ANY OF BELOW COMMANDS

ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL=2;

ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL=3;

PLSQL_OPTIMIZE_LEVEL:
Level 0: no compiler optimizations (PL/SQL compiled as is);
Level 1: high-level optimizations (such as moving constants out of loops);
Level 2: default level. Aggressive optimizations (such as rewriting cursor-for-
loops as array fetches) and in 11g, also inlining any subprograms that we
request with PRAGMA INLINE;
Level 3: most aggressive level: New in 11g, these will inline all subprograms where
possible (excluding those contained in built-in packages).

1-IF PLSQL_OPTIMIZE_LEVEL IS EQUAL TO 2, THEN THE INLINE IS DONE REGARDING PRAGMA

INLINE VALUE, IF PRAGMA INLINE VALUE IS YES, IT WILL BE INLINED OTHERWISE NOT
INLINED

2-IF PLSQL_OPTIMIZE_LEVEL IS EQUAL TO 3, THEN THE INLINE IS DONE WITH HIGH PRIORITY
REGARDING PRAGMA INLINE VALUE, IF PRAGMA INLINE VALUE IS YES, IT WILL BE INLINED
WITH HIGH PRIORITY OTHERWISE NOT INLINED

HOW TO USE PRAGMA INLINE

YOU CAN USE IT ANYWHERE IN YOUR CODE AND IT HAS BELOW SYNTAX

PRAGMA INLINE(SUBPROGRAM_NAME,'YES');
PRAGMA INLINE(SUBPROGRAM_NAME,'NO');

YOU CAN USE PRAGMA INLINE IN PRECEDENCE OF THE FOLLOWING STATEMENTS

1- ASSIGNMENT
2- CALL
3- CONDITIONAL
4- CASE
5- CONTINUE-WHEN
6- EXECUTE IMMEDIATE
7- EXIT-WHEN
8- LOOP
9- RETURN

DEMO
1- I WILL CREATE ANONYMOUS BLOCK FOR CALLING SUBPROGRAM WITHOUT USING PRAGMA INLINE
AND PRINT THE TIME USED TO EXECUTE THE CODE

DECLARE
LN$START_TIME NUMBER;
LN$END_TIME NUMBER;
LN$RESULT NUMBER;

FUNCTION ADD_FIVE (IN_NUMBER1 NUMBER)

RETURN NUMBER
IS
BEGIN
RETURN NVL (IN_NUMBER1, 0) + 5;
END;
BEGIN
LN$START_TIME := DBMS_UTILITY.GET_TIME;

FOR I IN 1 .. 10000000
LOOP
LN$RESULT := ADD_FIVE (I);
END LOOP;

LN$END_TIME := DBMS_UTILITY.GET_TIME;
DBMS_OUTPUT.
PUT_LINE ('TIME ELAPSED IS ' || TO_CHAR (LN$END_TIME - LN$START_TIME));
END;

THE OUTPUT IN DBMS OUTPUT CONSOLE

TIME ELAPSED IS 318

2- ADD PRAGMA INLINE TO MY PREVIOUS ANONYMOUS BLOCK.

DECLARE
LN$START_TIME NUMBER;
LN$END_TIME NUMBER;
LN$RESULT NUMBER;

FUNCTION ADD_FIVE (IN_NUMBER1 NUMBER)

RETURN NUMBER
IS
BEGIN
RETURN NVL (IN_NUMBER1, 0) + 5;
END;
BEGIN
LN$START_TIME := DBMS_UTILITY.GET_TIME;

FOR I IN 1 .. 10000000
LOOP
PRAGMA INLINE (ADD_FIVE, 'YES');
LN$RESULT := ADD_FIVE (I);
END LOOP;

LN$END_TIME := DBMS_UTILITY.GET_TIME;
DBMS_OUTPUT.
 PUT_LINE ('TIME ELAPSED IS ' || TO_CHAR (LN$END_TIME - LN$START_TIME));
END;

THE OUTPUT IN DBMS OUTPUT CONSOLE

TIME ELAPSED IS 160

I POSTED TIMER IN PLSQL AND SQL, YOU CAN USE IT FOR TRACKING TIMERS.

CONCLUSION
EXECUTING CALLING SUBPROGRAM WITH PRAGMA INLINE TAKES 160 AND WITHOUT IT TAKES 318,
SO USING PRAGMA INLINE PROVIDE US WITH HIGH PERFORMANCE.