Interpreted vs.

Native compilation

- Sagar T.

Compilation
When PL/SQL is loaded into the server it is compiled to byte code before execution. Two methods :
Interpreted Native

Interpreted Compilation
Default compilation method Interpreted at run time With interpreted compilation, the PL/SQL statements in a PL/SQL program unit are compiled into an intermediate form, machinereadable code, which is stored in the database dictionary and interpreted at run time.

Interpreted Compilation process

PL/SQL is an interpreted language, but different than other interpreted languages (e.g. BASIC) where the code is processed statement by statement at run-time. PL/SQL code is compiled into Machine code (m-code) with a target virtual machine , socalled PVM - PLSQL Virtual Machine (like JAVA with Java Virtual Machine)

PVM
The PVM is implemented as a set of subroutines in the Oracle Executable, and scans the M-code at run-time. The scanning detects each successive OPCODE and its OPERANDS, then calls the subroutine that implements this OPCODE with actual arguments. This run-time scanning of M-code takes some resources, and this (only this) can be improved using PL/SQL NATIVE Compilation.

Native Compilation
Compiles into native code Stored in the SYSTEM tablespace Because the native code does not have to be interpreted at run time, it runs faster

Native code
In the native mode, a platform-specific dynamically linkable library (DDL) (similar to .dll in Windows or .so in Unix) is produced. This platform-specific DLL, at run time, calls exactly the same PVM subroutines with same arguments as would have been called by scanning the M-Code. In short, the performance improvement is due to the fact that the scanning effort has been moved from run time (when in interpreted mode) to compile time (when in native mode).

Native compilation Pre- 11g

Oracle 9i
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
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).

Native compilation Pre- 11g contd.

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

Native Compilation in 11g

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. natively compiled code is stored in database and not in any file system. Only one parameter, PLSQL_CODE_TYPE, is used to set the compilation mode switching.

Example
CREATE OR REPLACE CREATE OR REPLACE PROCEDURE PROCEDURE native_test(v_out OUT INTEGER ) interpreted_test(v_out AS OUT INTEGER ) AS BEGIN for i in 1 .. 5000000 loop BEGIN for i in 1 .. 5000000 loop v_out := i + i; end loop; v_out := i + i; END; end loop; / END; ALTER PROCEDURE native_test /
COMPILE PLSQL_CODE_TYPE = NATIVE

When to go for Interpreted mode?

In development environments Compiling the code faster

When to go for Native mode?

In production environments When the code is heavily PL/SQL based

Native Compilation Caveat

Used only for compute-intensive programs No major performance improvement for SQLintensive applications

 THANK YOU!