Oracle 11g中的Native PL/SQL程式碼編譯

realkid4發表於2013-11-21

 

Oracle環境中,PL/SQL是我們進行業務邏輯實現的最佳手段,同時也是和Oracle資料庫本身結合的最好的語言。使用好PL/SQL本身功能,可以大幅度提高我們的工作效率。

我們從最開始學習計算機和程式設計開始,就接觸到一個概念叫做“二進位制程式碼”。計算機可以直接進行二進位制程式碼的執行,就目前而言,二進位制是計算機執行速度最快的一種形式。其他的高階語言,如CC++,都是透過編譯Compile和連線Link過程,轉化為二進位制程式。

二進位制程式的特點是執行速度快。但是缺點也是明顯的,那就是針對一種物理機器型別(如CPU架構)、一種作業系統,二進位制執行程式的格式定義都是不同的。所以,針對每一種作業系統和物理平臺,理論上我們都需要進行一遍CompileLink過程,形成獨特的可執行程式。

中立語言,或者稱為中間語言的出現,結束了這樣的局面。這種代表性就是Java和諸多的指令碼語言,藉助一個“平臺相關”的虛擬機器軟體,我們可以讓相同的程式碼在不同平臺上執行。這也就是所謂的“一次編譯,多處執行”。

預設情況下,PL/SQL程式碼就是這樣的中間語言,也可以稱為解釋語言。在不同的平臺上,相同的程式碼在執行。相對於Native程式碼而言,解析程式碼的效能一直是人們關注的重要問題。將程式碼Native本地化,是人們經常提到的一種程式最佳化手段。

 

1PL/SQL語句Native

 

PL/SQL語句的Native化,是從Oracle9i引入的。最開始進行native的初衷就是效能,通常nativePL/SQL程式碼要比解釋形式(interpreted form)執行速度快。早期的native化是比較費力氣的,需要我們提供出本地的編譯器地址。

PL/SQL語句的native過程需要我們安裝額外的C編譯器,這個在一些生產環境下,還是有安全方面的顧慮的。

9i10g時代,資料庫中包括一個引數名為plsql_native_library_dir,用於指定本地的編譯器目錄位置。在11g中,這個引數被取消,進行程式碼native的過程也變得比較簡單起來。

11g中,Oracle是不需要伺服器上額外安裝C編譯器的。Oracle會直接將需要native化的PL/SQL程式碼轉化到伺服器上的shared libraryDDL)。由此,進行PL/SQL的本地編譯就變得很簡單,只需要一個開關裝置。這個就是Oracle引數plsql_code_type

在使用native PL/SQL的時候,我們一定注意使用記憶體物件的不同。Native PL/SQL程式碼對應的機器碼(machine code)在被調入資料庫catalog之前,是與PGA記憶體進行對映。而解釋程式碼(interpreted form code)則是和SGA進行對應。所以,在使用native code的時候,對SGA的消耗是減少的趨勢。

 

2、開關引數plsql_code_type

 

Oracle 11g開始,我們可以使用plsql_code_type來控制編譯器選擇開關。我們選擇Oracle11g進行實驗。

 

 

SQL> select * from v$version;

 

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production

PL/SQL Release 11.2.0.3.0 - Production

CORE        11.2.0.3.0         Production

 

TNS for Linux: Version 11.2.0.3.0 - Production

NLSRTL Version 11.2.0.3.0 – Production

 

 

相關引數

 

 

SQL> show parameter plsql_code

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

plsql_code_type                      string      INTERPRETED

 

 

預設情況下,Oracle是選擇解釋程式碼的形式進行編譯的。透過檢視user/all/dba_plsql_object_settings,我們是可以看到對應儲存程式碼物件使用的編譯形式的。

首先,我們使用預設方式進行儲存過程編譯。

 

 

SQL> create or replace procedure P_RECE_CALL_TEST is

  2  i number;

  3  c number;

  4  begin

  5    for i in 1..100 loop

  6        select count(*) into c from emp;

  7        dbms_output.put_line(to_char(c));

  8    end loop;

  9  end P_RECE_CALL_TEST;

 10  /

 

Procedure created

 

SQL> select name, plsql_code_type from user_plsql_object_settings;

 

NAME                           PLSQL_CODE_TYPE

------------------------------ --------------------

P_RECE_CALL_TEST               INTERPRETED

 

 

程式碼物件的plsql_code_type列顯示了物件的編譯形式。我們對於單獨的儲存過程,可以不透過引數修改,而是在compile過程中,直接指定編譯方式。這樣也是可以將程式碼編譯為native方式。

 

 

SQL> alter procedure p_rece_call_test compile plsql_code_type=native;

Procedure altered

 

SQL> select name, plsql_code_type from user_plsql_object_settings;

NAME                           PLSQL_CODE_TYPE

------------------------------ --------------------

P_RECE_CALL_TEST               NATIVE

 

 

配置引數plsql_code_type比較簡單,目前版本Oracle支援InterpretedNative兩個選項值。預設取值為Interpreted,表示將程式程式碼編譯為解析形式。另一個就是Native,表示編譯為原生程式碼。我們可以在session level進行靈活的配置。

 

 

SQL> alter session set plsql_code_type='native';

Session altered

 

SQL> alter procedure p_rece_call_test compile;

Procedure altered

 

SQL>  select name, plsql_code_type from user_plsql_object_settings;

 

NAME                           PLSQL_CODE_TYPE

------------------------------ --------------------

P_RECE_CALL_TEST               NATIVE

 

 

重新登入之後,可以將其編譯回解釋狀態。

 

 

SQL> conn scott/tiger@ora11g;

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.3.0

Connected as scott

 

SQL> alter procedure p_rece_call_test compile;

Procedure altered

 

SQL>  select name, plsql_code_type from user_plsql_object_settings;

NAME                           PLSQL_CODE_TYPE

------------------------------ --------------------

P_RECE_CALL_TEST               INTERPRETED

 

 

3、效能對比

 

PL/SQL本地化程式碼最大的好處和優勢就在於效能。特別是11g版本下,本地Native的優勢更加明顯。

我們選擇一個比較消耗資源的函式——斐波納妾數列計算第n項,採用遞迴的結構進行計算。

 

 

SQL> create or replace function fib(n number)

  2  return number

  3  is

  4  begin

  5    if (n<=2) then

  6       return n;

  7    else

  8       return fib(n-1)+fib(n-2);

  9    end if;

 10  end;

 11  /

 

Function created

 

SQL> select name, plsql_code_type from user_plsql_object_settings;

 

NAME                           PLSQL_CODE_TYPE

------------------------------ --------------------

FIB                            INTERPRETED

 

 

執行實驗前,清理shared_poolbuffer_cache

 

 

SQL> alter system flush shared_pool; 

System altered.

 

SQL> alter system flush buffer_cache;

System altered.

 

SQL> set timing on;

SQL> set serveroutput on;

SQL> declare

  2    n number;

  3  begin

  4    n := fib(40);

  5    dbms_output.put_line('Result is : '||n);

  6  end;

  7  /

 

Result is : 165580141

 

PL/SQL procedure successfully completed

 

Executed in 43.547 seconds

 

 

N=40時候,PL/SQL解釋形式程式碼執行時間43.55s計算出結果。下面我們看看Native化之後的情況。

 

 

SQL> alter function fib compile plsql_code_type=native;

Function altered

 

Executed in 0.219 seconds

 

SQL> select name, plsql_code_type from user_plsql_object_settings;

NAME                           PLSQL_CODE_TYPE

------------------------------ --------------------

FIB                            NATIVE

 

Executed in 0.078 seconds

 

 

第二次執行相同計算任務。

 

 

SQL> alter system flush shared_pool;

System altered.

 

SQL> alter system flush buffer_cache;

System altered.

 

SQL> set timing on;

SQL> set serveroutput on;

SQL> declare

  2    n number;

  3  begin

  4    n := fib(40);

  5    dbms_output.put_line('Result is : '||n);

  6  end;

  7  /

 

Result is : 165580141

 

PL/SQL procedure successfully completed

 

Executed in 25.734 seconds

 

 

第二次native執行情況,看出為25.73s完成計算。效能提升接近一半!

 

4、結論

 

我們在編寫pl/sql程式碼的時候,效能是一個非常重要的考量方式。Native程式化在一定程度上可以提高效率。不過應該看到,Native化程式是有條件的。Native PL/SQL節省的時間成本在PL/SQL引擎的層面,而SQL語句引擎方面不會有很大程度的提升。

所以,如果我們的程式碼中以流程、計算和迴圈判斷為主體,SQL語句相對較少,那麼使用Native化是比較“划算”的。反之,如果主要都是在進行SQL語句計算操作,即使我們將程式碼Native化,獲取到的優勢也比較少。

另一方面,Native化的程式在遷移、升級的時候,也許會有很多額外的問題和關注點。也是我們需要注意慎用的方面。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/17203031/viewspace-777265/,如需轉載,請註明出處,否則將追究法律責任。

相關文章