During the introduction of Objects and Types in Oracle 8 release, PL/SQL was referred as procedural and object oriented language. While Oracle 9i and 10g were more concentrated on the sharpening of the object oriented model of Oracle, Oracle 11g aims at evolving PL/SQL from interpreted language to natively compiled language. In the tutorial, we shall see the changes made to achieve native compilation and its post application effects.
Interpreted to Native Compilation: A Tour
Native compilation of program units was first introduced in Oracle 9i release 1. Introduction of native compilation was taken as one of the revolutionary changes of 9i release. A PL/SQL source code could be natively compiled into machine code without seeking any efforts from an external Interpreter. With the help of C compiler, a C code source file was generated and linked to a shared library (DLL). During execution, Oracle executables made a call to the DLL whenever required.
Oracle 10g upgraded the native compilation feature by storing the compiled code in a database catalog. If the code is required, server used to load it from the catalog and not from the shared libraries (Native DLLs). Till 10g release, a third party compiler i.e. C compiler was used for the compilation of the source code and generating native DLLs.
Shared library management was identified as an overhead and an obvious performance bait at the server side. Database customers even raised issues on the Oracle credibility to rely on a third party compiler.
Native to Real Native Compilation
Oracle 11g renovated the native compilation by removing the third party compilation layer of program units and transforming the compilation process into a Real Native Compilation. Consequently, Oracle was able to win back its credibility among its customers and won the challenge by providing add-on benefits with the change, as listed below.
- Reduces complication of setting bunch of parameters
- No more dependency on C compiler. Saved licensing cost
- No file system required for DLL storage
- Compilation performance of program units enhanced by a decent fold of 2.5
- Hybrid advantage of first two, code execution improved by ~40%
- Improved scalability. It reduced contention within shared pool memory area by using PGA to create database catalog of shared code.
- Faster arithmetic operations, branching operations and no action operations
Prior to Oracle 11g, bunch of initialization parameters have to be maintained to configure native Compilation.
- plsql_native_make_utility to set the path of Make utility on db server
- plsql_native_make_file_name to set the file name for the make utility
- plsql_native_library_dir to set an existent path, where shared libraries would be stored
- plsql_native_library_subdir_count to set maximum libraries that can reside in the plsql_native_library_dir
- plsql_native_c_compiler and plsql_native_linker to specify full path of C compiler and linker on db server
- plsql_compiler_flags to set the compilation mode as NATIVE or INTERPRETED
Oracle 11g deprecated the above parameters by inducting a single parameter which was efficient enough to set the compilation mode switching. This is because in Oracle 11g, natively compiled code is stored in database and not in any file system.
PLSQL_CODE_TYPE: New Initialization Parameter
PLSQL_CODE_TYPE is the new parameter included in the spfile.ora file, which accepts two values.
1. INTERPRETED – The conventional compilation technique which used to convert the code in byte code format, an intermediate format. It is stored in the database dictionary and would be loaded using an interpreter at run time. This is default value of the parameter.
2. NATIVE – Support real native compilation of program units.
The parameter can be set at the System or Session level using ALTER [SYSTEM | SESSION] command.
ALTER SYSTEM SET PLSQL_CODE_TYPE = NATIVE
ALTER SESSION SET PLSQL_CODE_TYPE = NATIVE
Once the PLSQL_CODE_TYPE parameter is set, all the objects would be natively compiler from there on.
Program units, which were created and compiled in earlier versions of Oracle, can be natively recompiled at the by setting PLSQL_CODE_TYPE at object level.
ALTER [DATABASE Object] COMPILE PLSQL_CODE_TYPE = NATIVE
For example, a procedure P_INTERPRET was created in Oracle 9i and compiled in INTERPRETED mode. In Oracle 11g, it can be natively compiled as below.
SQL>ALTER PROCEDURE P_INTERPRET COMPILE PLSQL_CODE_NATIVE
Object level compilation settings can be queried from [USER | DBA | ALL]_PLSQL_OBJECT_SETTINGS dictionary views.
SQL>SELECT PLSQL_CODE_TYPE FROM ALL_PLSQL_OBJECT_SETTINGS WHERE NAME = ’P_INTERPRET’;
Another initialization parameter, which must be considered at low priority, is PLSQL_OPTIMIZE_LEVEL. It defines the scope of subprogram inlining for the optimizer. As per Oracle 11g enhancements, it can have 1, 2, and 3 as possible values. At the first optimization level (i.e. PLSQL_OPTIMIZE_LEVEL=1), Oracle server does not supports native compilation and this overrides the PLSQL_CODE_TYPE setting. For the optimal and commendable database performance, PLSQL_OPTIMIZE_LEVEL must hold the value 2.
Re-Compilation of Database Objects using Native Compilation in Oracle 11g
I will now describe the steps involved to upgrade the database to 11g, and re-compile the program units.
1. Set the PLSQL_CODE_TYPE
SQL>ALTER SYSTEM SET PLSQL_CODE_TYPE=NATIVE SCOPE=SPFILE;
2. Set the PLSQL_OPTIMIZE_LEVEL to 2 i.e. logical inlining of subprograms
SQL>ALTER SYSTEM SET PLSQL_OPTIMIZE_LEVEL=2 SCOPE=SPFILE;
3. Shutdown the Database
4. Startup the Database in UPGRADE mode
5. Execute the dbmsupgnv.sql script from the path @ORACLE_HOME/rdbms/admin/
6. Restart the Database
Vice-versa is also possible by setting the PLSQL_CODE_TYPE to INTERPRETED and executing dbmsupgin.sql from the same path.
Introduction of PL/SQL Data Type: SIMPLE_INTEGER
Oracle 11g introduces three new PL/SQL data type namely,
2. SIMPLE_FLOAT, and
While the SIMPLE_INTEGER evolved from the primitive data type family, SIMPLE_FLOAT and SIMPLE_DOUBLE are its float value counterparts. Value precision of SIMPLE_INTEGER ranges between –2,147,483,648 to 2,147,483,647.
The newly introduced data types are efficient as compared to their earlier counterparts; reason being the missing of NULL checks and Value overflow checks. The semantics of these data types are in close sync with the native compilation feature of oracle 11g hardware operations. They are more suited, more compatible for applications built on 11g release and yield better performance than PLS_INTEGER.
Limitations of Native Compilation
• Cannot speed up SQL execution
• Native compilation could not upgrade complex mathematical operations
About the author
Saurbh Gupta is working as Oracle R&D Consultant and Oracle 11g Advanced PL/SQL Certified Professional.