Oracle Database 11g： 面向 DBA 和开发人员的重要新特性 - PL/SQL 性能

PL/SQL 性能

通过研究代码内联、真正的原生编译以及简单整数的用例来了解如何提高代码性能。

Oracle Database 11g 引入了许多极有用的新特性用以提高 PL/SQL 代码的性能，但其中最引人注目的特性是原生编译和内部单元内联。

原生编译本身不是新特性，但无需任何前提条件（如安装 C 编译器）即可使用此特性却是一项新技术。（Oracle 将这个改进的性能称为“真正的原生编译”。）此外，新的数据类型 simple_integer 使得代码在原生编译下可以更好地执行。内部单元内联是一种优化技术，利用此技术，PL/SQL 代码在编译期间可以生成有效代码。

在本文中，您将看到这些新特性的相应用例。您还会了解这些用例在不同方案中的性能：执行原生编译时、使用简单整数时、内联程序时以及在各种组合方案中。

真正的原生编译

您可能会想起 Oracle9i 数据库第 2 版中引入的原生编译；与解释形式相比，使用原生编译时 PL/SQL 程序的执行速度要快得多。尽管有上述优点，但采用率却很低，这是因为许多系统管理员都不愿意在生产数据库服务器上安装所需的 C 编译器。另外，此类编译器还要求定义用于创建 O/S 中间文件的参数 plsql_native_library_dir。

在 Oracle Database 11g 中，无需在服务器上安装 C 编译器或设置参数即可执行原生编译。只需在创建或重新编译存储的代码之前设置一个会话参数即可：

alter session set plsql_code_type = native;
...  

compile the code here ...

原生编译所需时间比解释编译长，但由于目前在 Oracle Database 11g 中执行进程的速度非常快，因此影响不是很明显。您可能希望在常规开发周期中使用解释编译模式，而在开发结束时使用原生编译模式，这通常是一个很好的做法。

作为 11g 移植的一部分，我用关键任务应用程序中的实际代码（一个相当大的程序包，共 5,827 行代码）做了一个试验。我在现有的 10g 数据库和新的 11g 数据库上对该代码执行了原生编译，然后使用解释编译重复了相同的操作。执行这两编译时都将 plsql_optimize_level 设置为 2。我测量了每种方案的编译时间，如下所示（以秒为单位）。

	10g	11g
解释	1.66	1.64
原生	4.66	2.81

结果显而易见。执行解释编译时，完成时间非常接近。但是执行原生编译时，在 11g 下的编译时间大大缩短，约为 10g 下的 60%。因此，尽管在 11g 下执行原生编译时延长了编译时间，但仍然比 10g 下的原生编译快的多。

要了解哪些对象已使用 NATIVE 进行了编译，可以查看 USER_PLSQL_OBJECT_SETTINGS 视图：

SQL> select name, PLSQL_code_type
  2> from user_plsql_object_settings;

NAME                 PLSQL_CODE_TYPE
--------------------           ---------------
DO_CALC              NATIVE
PERFECT_TRIANGLES    NATIVE
PRIME_NUMBERS        NATIVE
PRIME_NUMBERS        NATIVE
SOME_MATH            INTERPRETED
TR_BOOKINGS_TRACK    INTERPRETED
TR_SALGRADE_COMP     INTERPRETED
UPD_INT              NATIVE

还有一个适用于所有对象的类似视图 DBA_PLSQL_OBJECT_SETTINGS。

新数据类型：简单整数

如果使用新的数据类型 simple_integer，则原生编译的优势更为明显。从技术上讲，它不是真正的数据类型，而是数据类型 pls_integer 的子类型。简单整数被定义为利用硬件运算而不是软件运算。将简单整数与真正的原生编译结合使用时，性能将显著提高。看了后面的试验，您就会明白其中的原委。

由于 simple_integer 是 pls_integer 的子类型，因此继承了如下属性：它是 32 位带符号整数，可以具有介于负 2,147,483,648 和 2,147,483,647 之间的整数值。但是，它与 pls_integer 之间存在以下不同点：simple_integer 不能为空，但允许溢出 — 当所分配的值超过最大值时，它将回绕而不返回错误。

从语法上讲，在可以使用 pls_integer 的任何位置均可使用此数据类型，但要仔细注意它们之间的差别；simple_integer 的其他属性可能导致它在某些情况下不适用。

在用 pls_integer 替代 simple_integer 之前，我们来看一些您应当了解的潜在问题：

• 此变量不能为空，因此，如果未将变量声明写成：

  num1    simple_integer:= 1;

• 而写成：

  num1    simple_integer;
  

• 则会收到编译错误：

  PLS-00218: a variable declared NOT NULL must have an initialization assignment
  

• 如果在程序内将变量设置为 NULL，如：

  num1 := NULL;
  

• 则会收到编译错误：

  PLS-00382: expression is of wrong type
  

• 请注意这些错误消息，它们看上去可能未表达出错误的确切本质。如果您的程序要求将某个变量设置为空，则不能将该变量定义为 simple_integer。
• 有关 simple_integer 的另一个要点涉及在超出最大值和最小值时回绕值。请记住，pls_integer 的最大正值为 2147483647。如果尝试存储一个较大值时将会发生什么？我们来看一个代码示例：

  declare
  v1 pls_integer := 2147483647;
  begin
  v1 := v1 + 1;
  dbms_output.put_line('v1='||v1);
  end;
  /
  

• 它将抛出一个错误：

  declare
  *
  ERROR at line 1:
  ORA-01426: numeric overflow
  ORA-06512: at line 4
  

• 该错误很明显，并且非常适当；您尝试超出数据类型允许的最大值。如果使用 simple_integer 而不是 pls_integer：

  declare
  v1 simple_integer := 2147483647;
  begin
  v1 := v1 + 1;
  dbms_output.put_line('v1='||v1);
  end;
  /
  

• 输出应如下所示：

  v1=-2147483648
  

• 请注意该值 (-2147483648)，它是 simple_integer 的最小值。当您增加到最大值 (2147483647) 时，该值只是回绕到初始值，这是 simple_integer 的一个特性。请注意此行为。

将真正的原生编译和简单整数结合使用

如您所见，不能随便在任意位置使用 simple_integer；使用之前必须仔细确定边界条件（尤其是值的潜在回绕）。此外，simple_integer 是针对原生编译设计的。在解释编译中，它们可能不会提供很大的性能改进（但也不会降低性能，您将在后面看到这一点）。在真正的原生模式下，simple_integer 的性能优势尤为突出。

实际上，大多数 PL/SQL 业务应用程序都主要是使用 SQL 开发的，因此这些应用程序不会通过原生编译获得显著的性能改进。在“前一个周期”中，我使用 PL/SQL 开发了一个数据库容量规划工具，其中包含许多数值计算和统计计算，代码超过几千行。执行原生编译时，此工具的性能得到了极大改进。简单整数当时不可用，否则会带来更大的性能优势。

内部单元内联

内部单元内联是指使用子例程代码的副本替换对该子例程的调用。通常，修改后的代码运行速度更快。在 Oracle Database 11g 中，PL/SQL 编译器能够确定应该复制（或内联）对哪个子例程的哪些调用并做出更改，从而提高性能。

通过示例可以对此进行很好地说明。下面的代码使用对帐户余额计算得到的利息更新名为 BALANCES 的表。代码遍历表的所有记录，计算利息，然后更新表的余额列。

create or replace procedure upd_int is
/* original version */
    l_rate_type     balances.rate_type%type;
    l_bal           balances.balance%type;
    l_accno         balances.accno%type;
    l_int_rate      number;
    procedure calc_int (
        p_bal in out balances.balance%type,
        p_rate  in number
    ) is
    begin
        if (p_rate >= 0) then
            p_bal := p_bal * (1+(p_rate/12/100));
        end if;
    end;
begin
    for ctr in 1..10000 loop
        l_accno := ctr;
        select balance, rate_type
        into l_bal, l_rate_type
        from balances
        where accno = l_accno;
        select decode(l_rate_type,
            'C', 1, 'S', 3, 'M', 5, 0)
        into l_int_rate
        from dual;
        for mth in 1..12 loop
            calc_int (l_bal, l_int_rate);
            update balances
            set balance = l_bal
            where accno = l_accno;
        end loop;
    end loop;
end;
/

由于所有记录类型的实际利息计算方法相同，因此我将该逻辑放在主过程内的一个单独过程 calc_int() 中。这样可以提高代码的可读性和可维护性，但效率很低。

然而，如果我编写 calc_int() 中所示的代码而不调用 calc_int()，则会创建一个速度较快的程序，如下所示：

create or replace procedure upd_int is
/* revised version */
    l_rate_type     balances.rate_type%type;
    l_bal           balances.balance%type;
    l_accno         balances.accno%type;
    l_int_rate      number;
begin
    for ctr in 1..10000 loop
        l_accno := ctr;
        select balance, rate_type
        into l_bal, l_rate_type
        from balances
        where accno = l_accno;
        select decode(l_rate_type,
            'C', 1, 'S', 3, 'M', 5, 0)
        into l_int_rate
        from dual;
        for mth in 1..12 loop
            -- this is the int calc routine
            if (l_int_rate >= 0) then
                l_bal := l_bal * (1+(l_int_rate/12/100));
            end if;
            update balances
            set balance = l_bal
            where accno = l_accno;
        end loop;
    end loop;
end;
/

修改后的代码与原始代码唯一的不同之处在于，用于计算利息的代码现在处于循环中，而不在过程 calc_int() 内。

请注意，新版本可能更快，但这不是很好的编码方法。用于计算利息的代码部分在月份循环的每次迭代时执行一次，然后针对每个帐号执行一次。由于重复执行该部分代码，因此将这部分代码单独放在一个过程 (calc_int) 中更合理，如上一版本的 upd_int 代码中所示。该方法可以使代码模块化，易于维护，且可读性极强，但效率较低。

那么，如何同时实现代码模块化和提高执行速度这两个互相冲突的目标呢？以模块化方式编写代码（像 upd_int 的第一个版本那样），然后让 PL/SQL 编译器对代码进行“优化”，使其看上去像代码的第二个版本，这种方法如何呢？

在 Oracle Database 11g 中可以执行此操作。只需使用较高的 PL/SQL 优化级别重新编译过程即可。完成此操作有两种方法：

• 设置会话级别参数并重新编译过程：

  SQL> alter session set plsql_optimize_level = 3;
  
  Session altered.
  

• 上述设置指示 PL/SQL 编译器重写代码以内联该代码。
• 使用 plsql 设置直接编译过程。

  SQL> alter procedure upd_int
    2  compile
    3  plsql_optimize_level = 3
    4  reuse settings;
  
  Procedure altered.
  

• 同一会话中编译的任何其他过程都不会受影响。当您要在同一会话中编译很多过程时，这是处理内联的一种较好的方法。还可以使用编译器指令 pragma。

create or replace procedure upd_int is
    l_rate_type     varchar2(1);
...
...
begin


pragma inline (calc_int, 'YES');
    for ctr in 1..10000 loop
...
...
end;

我添加了 pragma inline (calc_int, 'YES'); 行以便让编译器内联该过程。同样，您也可以在此处使用“NO”，以通知编译器不内联此过程，即使将 plsql_optimizer_level 设置为 3 时也是如此。

此内联过程可以使代码执行速度更快。性能改进的程度自然根据编译器可能执行内联的程度而有所不同。在本文结尾，您将看到一个使用内联的示例代码，并会看到代码内联带来的性能改进。

编译时间

当然，此优化过程使得编译器的工作效率更高。但工作效率提高多少呢？

为了回答这个问题，我采用了前面提供的实际生活应用程序代码，并在不同的组合方案（内联/非内联和解释/原生）中对其进行了编译。下面是编译时间：

	内联	未内联
解释	1.70	1.64
原生	3.15	2.81

结果是显而易见的。使用内联选项执行编译时，在解释编译模式下编译时间略有增加（大约 4%）。执行原生编译时，编译时间也有所增加，但增幅较大，约为 12%。因此，您可能希望在开发周期中使用内联/解释选项编译应用程序，然后在最后阶段使用原生编译。使用内联特性似乎没有显著增加编译时间，因此开发周期时间不会受到很大影响。

现在有一个重要问题：既然您没有更改代码，如何确认代码被内联呢？可以通过设置会话变量完成该操作：

alter session set plsql_warnings = 'enable:all';

现在，当您重新创建过程之后：

SQL> @upd_int

SP2-0804: Procedure created with compilation warnings

请注意此时发出的警告消息。要查看警告消息，请使用以下命令：

SQL> show error
Errors for PROCEDURE UPD_INT:

LINE/COL ERROR
--------     -----------------------------------------------------------------
7/5      PLW-06006: uncalled procedure "CALC_INT" is removed.
28/13    PLW-06005: inlining of call of procedure 'CALC_INT' was done

请注意最后一行，它确认了过程 calc_int 确实已被内联。

如果您要了解哪些对象是以什么级别进行编译的，可以查询视图 USER_PLSQL_OBJECT_SETTINGS：

sql> select name, plsql_optimize_level
  2> from user_plsql_object_settings;

NAME                 PLSQL_OPTIMIZE_LEVEL
--------------------                     --------------------
DO_CALC                                 2
PERFECT_TRIANGLES                       2
TR_BOOKINGS_TRACK                       2
TR_SALGRADE_COMP                        2
UPD_INT                                 3
... and so on ...

还有一个适用于所有对象的类似视图：DBA_PLSQL_OBJECT_SETTINGS。

请记住，这是内部单元内联，只有单元内部的过程才被内联。单元外部的子例程不会被内联。

运行试验

现在通过一个可重复的试验来检验这些优点。您需要创建一个程序包的基础性版本，然后根据前面学过的概念修改变量数据类型和编译指令。

首先，创建欧几里德算法的一个实现，以算出两个数字的最大公约数。下面是 Wiki 页中的函数逻辑：

function gcd(a, b)
     if a = 0 return b
     while b ≠ 0
         if a > b
             a := a - b
         else
             b := b - a
     return a

我们将查看在这些修饰符的不同组合下执行此程序包所占用的 CPU 时间，并记录所用时间。因此，接下来创建一个用于存储 CPU 时间的表：

create table times(
  native        char(1) check (native    in ('Y', 'N')) enable,
  simple        char(1) check (simple    in ('Y', 'N')) enable,
  inlining      char(1) check (inlining  in ('Y', 'N')) enable,
  centiseconds  number not null,
  constraint times_pk primary key (simple, inlining, native))
/

共有三个列：原生、简单和内联，分别用于指定原生编译、简单整数和内联代码。列中的“Y”表示编译代码时使用了该特性。因此，下面的记录：

NATIVE SIMPLE INLINING CENTISECONDS
------    ------    --------           ------------
Y      N      N                 100

表示对程序执行了原生编译但未使用简单整数，未发生代码内联，并且此组合占用了 100 厘秒的 CPU 时间。

如果只使用一份程序包，请使用条件编译（在 Oracle 数据库 10g 第 2 版中引入）修改该程序包。下面是创建程序包的方法：

-- suppress these expected warnings:
--   inlining of call of procedure 'gcd' was done
--   uncalled procedure "gcd" is removed.
--   unreachable code
--   keyword "native" used as a defined name
alter session set plsql_warnings = 'enable:all, disable:06002, disable:06005, disable:06006, disable:06010'
/
alter session set plsql_ccflags = 'simple:false'
/
create package gcd_test is
  procedure time_it;
end gcd_test;
/
create package body gcd_test is
  $if $$simple $then
    subtype my_integer is simple_integer;
    simple constant times.simple%type := 'y';
  $else
    subtype my_integer is pls_integer not null;
    simple constant times.simple%type := 'n';
  $end

  function gcd(p1 in my_integer, p2 in my_integer) return my_integer is
    v1 my_integer := p1; v2 my_integer := p2;
  begin
    while v2 > 0 loop
      if v1 > v2 then
        v1 := v1 - v2;
      else
        v2 := v2 - v1;
      end if;
    end loop;
    return v1;
  end gcd;

  function exercise_gcd return number is
    -- expected value depends on no_of_iterations.
    expected_checksum my_integer := 74069926; -- 2475190;
    no_of_iterations constant my_integer := 5000; -- 1000;
    checksum my_integer := 0; 
    v my_integer := 0;
    t0 number; t1 number;
  begin
    for warmup in 1..2 loop
      checksum := 0;
      t0 := dbms_utility.get_cpu_time();

      for j in 1..no_of_iterations loop
        v := gcd(j, j);
        if v <> j then
          raise_application_error(-20000, 'logic error: gcd(j, j) <> j');
        end if;
        checksum := checksum + v;

        for k in (j + 1)..no_of_iterations loop
          v := gcd(j, k);
          if gcd(k, j) <> v then
            raise_application_error(-20000, 'logic error: gcd(j, k) <> gcd(k, j)');
          end if;
          checksum := checksum + v;
        end loop;
      end loop;

      if checksum <> expected_checksum then
        raise_application_error(-20000, 'checksum <> expected_checksum: '||checksum);
      end if;

      t1 := dbms_utility.get_cpu_time();
    end loop;
   return t1 - t0;
  end exercise_gcd;

  procedure time_it is
    inlining times.inlining%type;
    native times.native%type;
    centiseconds constant times.centiseconds%type := exercise_gcd();
  begin
    if lower($$plsql_code_type) = 'native' then
      native := 'y';
    else
      native := 'n';
    end if;

    if $$plsql_optimize_level = 3 then
      inlining := 'y';
    else
      inlining := 'n';
    end if;

    insert into times(native, simple, inlining, centiseconds)
      values(time_it.native, gcd_test.simple, time_it.inlining, time_it.centiseconds);
    commit;
  end time_it;
end gcd_test;
/
show errors

程序包有足够的行内注释，使代码具有自描述性，所以此处不作详细解释。概括来说，函数 GCD() 接受两个值，并返回这两个值的最大公约数。函数 exercise_gcd() 调用 GCD() 函数，并返回执行所占用的 CPU 时间，以厘秒表示。最后，公共过程 TIME_IT() 以相应的*度调用 EXERCISE_GCD() 函数，并向 TIMES 表中插入一条记录。

现在，您需要使用不同的修饰符调用打包过程几次，并记录每种情况下的 CPU 时间。可以通过在编译程序包之前更改条件编译变量来执行此操作：

truncate table times
/

-- Interpreted ---------------------------------------------
-- Simple:false
-- No Inlining
alter package GCD_Test compile body
  PLSQL_Code_Type = interpreted
  PLSQL_CCFlags = 'Simple:false'
  PLSQL_Optimize_Level = 2 /* no inlining */
  reuse settings
/
begin GCD_Test.Time_It(); end;
/

-- inlining
alter package GCD_Test compile body
  PLSQL_Code_Type = interpreted
  PLSQL_CCFlags = 'Simple:false'
  PLSQL_Optimize_Level = 3 /* inlined */
  reuse settings
/
begin GCD_Test.Time_It(); end;
/

-- Simple:true
-- no inlining
alter package GCD_Test compile body
  PLSQL_Code_Type = interpreted
  PLSQL_CCFlags = 'Simple:true'
  PLSQL_Optimize_Level = 2
  reuse settings
/
begin GCD_Test.Time_It(); end;
/

-- inlined
alter package GCD_Test compile body
  PLSQL_Code_Type = interpreted
  PLSQL_CCFlags = 'Simple:true'
  PLSQL_Optimize_Level = 3
  reuse settings
/
begin GCD_Test.Time_It(); end;
/

-- Native -------------------------------------------------
-- Simple:false
-- no inlining
alter package GCD_Test compile body
  PLSQL_Code_Type = native
  PLSQL_CCFlags = 'Simple:false'
  PLSQL_Optimize_Level = 2
  reuse settings
/
begin GCD_Test.Time_It(); end;
/

-- inlined
alter package GCD_Test compile body
  PLSQL_Code_Type = native
  PLSQL_CCFlags = 'Simple:false'
  PLSQL_Optimize_Level = 3
  reuse settings
/
begin GCD_Test.Time_It(); end;
/

-- Simple:true
-- no linlining
alter package GCD_Test compile body
  PLSQL_Code_Type = native
  PLSQL_CCFlags = 'Simple:true'
  PLSQL_Optimize_Level = 2
  reuse settings
/
begin GCD_Test.Time_It(); end;
/

-- inlined
alter package GCD_Test compile body
  PLSQL_Code_Type = native
  PLSQL_CCFlags = 'Simple:true'
  PLSQL_Optimize_Level = 3
  reuse settings
/
begin GCD_Test.Time_It(); end;
/

要查明上述每种方案中的性能改进程度，请使用以下代码：

spool timings.txt
<<b>>declare
  Interp_Pls_Integer_Noinline     Times.Centiseconds%type;
  Interp_Pls_Integer_Inline       Times.Centiseconds%type;
  Interp_Simple_Integer_Noinline  Times.Centiseconds%type;
  Interp_Simple_Integer_Inline    Times.Centiseconds%type;

  Native_Pls_Integer_Noinline     Times.Centiseconds%type;
  Native_Pls_Integer_Inline       Times.Centiseconds%type;
  Native_Simple_Integer_Noinline  Times.Centiseconds%type;
  Native_Simple_Integer_Inline    Times.Centiseconds%type;

  procedure Show_Caption(Caption in varchar2) is
  begin
    DBMS_Output.Put_Line(Chr(10)||Rpad('-', 60, '-')||Chr(10)||Chr(10)||Caption||Chr(10));
  end Show_Caption;

  procedure Show_Ratio(Var1 in varchar2, Var2 in varchar2, Ratio in number) is
  begin
    DBMS_Output.Put_Line(Rpad(Var1, 15)||'and '||Rpad(Var2, 14)||To_Char(Ratio, '99.99'));
  end Show_Ratio;
begin
  select  a.Centiseconds
  into    b.Interp_Pls_Integer_Noinline
  from    Times a
  where   a.Native = 'N' and a.Simple = 'N' and a.Inlining = 'N';

  select  a.Centiseconds
  into    b.Interp_Pls_Integer_Inline
  from    Times a
  where   a.Native = 'N' and a.Simple = 'N' and a.Inlining = 'Y';

  select  a.Centiseconds
  into    b.Interp_Simple_Integer_Noinline
  from    Times a
  where   a.Native = 'N' and a.Simple = 'Y' and a.Inlining = 'N';

  select  a.Centiseconds
  into    b.Interp_Simple_Integer_Inline
  from    Times a
  where   a.Native = 'N' and a.Simple = 'Y' and a.Inlining = 'Y';

  select  a.Centiseconds
  into    b.Native_Pls_Integer_Noinline
  from    Times a
  where   a.Native = 'Y' and a.Simple = 'N' and a.Inlining = 'N';

  select  a.Centiseconds
  into    b.Native_Pls_Integer_Inline
  from    Times a
  where   a.Native = 'Y' and a.Simple = 'N' and a.Inlining = 'Y';

  select  a.Centiseconds
  into    b.Native_Simple_Integer_Noinline
  from    Times a
  where   a.Native = 'Y' and a.Simple = 'Y' and a.Inlining = 'N';

  select  a.Centiseconds
  into    b.Native_Simple_Integer_Inline
  from    Times a
  where   a.Native = 'Y' and a.Simple = 'Y' and a.Inlining = 'Y';

  Show_Caption('Benefit of simple_integer');
  Show_Ratio('Interpreted',    'no inlining',    Interp_Pls_Integer_Noinline   / Interp_Simple_Integer_Noinline);
  Show_Ratio('Interpreted',    'inlining',       Interp_Pls_Integer_Inline     / Interp_Simple_Integer_Inline);
  Show_Ratio('Native',         'no inlining',    Native_Pls_Integer_Noinline   / Native_Simple_Integer_Noinline);
  Show_Ratio('Native',         'inlining',       Native_Pls_Integer_Inline     / Native_Simple_Integer_Inline);

  Show_Caption('Benefit of inlining');
  Show_Ratio('Interpreted',    'pls_integer',    Interp_Pls_Integer_Noinline    / Interp_Pls_Integer_Inline);
  Show_Ratio('Interpreted',    'simple_integer', Interp_Simple_Integer_Noinline / Interp_Simple_Integer_Inline);
  Show_Ratio('Native',         'pls_integer',    Native_Pls_Integer_Noinline    / Native_Pls_Integer_Inline);
  Show_Ratio('Native',         'simple_integer', Native_Simple_Integer_NoInline / Native_Simple_Integer_Inline);

  Show_Caption('Benefit of native');
  Show_Ratio('pls_integer',    'no inlining',    Interp_Pls_Integer_Noinline    / Native_Pls_Integer_Noinline);
  Show_Ratio('pls_integer',    'inlining',       Interp_Pls_Integer_Inline      / Native_Pls_Integer_Inline);
  Show_Ratio('simple_integer', 'no inlining',    Interp_Simple_Integer_Noinline / Native_Simple_Integer_Noinline);
  Show_Ratio('simple_integer', 'inlining',       Interp_Simple_Integer_Inline   / Native_Simple_Integer_Inline);

end b;
/
spool off

以下为输出内容。它显示了 CPU 时间与默认值之比：非内联、解释编译且使用 pls_integer。

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

Benefit of simple_integer

Interpreted    and no inlining     1.00
Interpreted    and inlining        1.00
Native         and no inlining     2.19
Native         and inlining        2.79

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

Benefit of inlining

Interpreted    and pls_integer     1.07
Interpreted    and simple_integer  1.07
Native         and pls_integer     1.16
Native         and simple_integer  1.48

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

Benefit of native

pls_integer    and no inlining     4.78
pls_integer    and inlining        5.18
simple_integer and no inlining    10.53
simple_integer and inlining       14.49

从上述输出可以看到，默认情况下执行所占用的 CPU 时间为使用内联和 simple_integer 的原生编译的 14.49 倍 — 无论用哪种标准来衡量，这都是非常显著的性能改进。

总结

现在您应该已经了解了这些新特性的功能和用途。总结：

• 从语法上讲，在可以使用 pls_integer 的任何位置都可以使用 simple_integer 数据类型，但要注意值的潜在回绕和非空要求。这意味着不能盲目地处处使用简单整数。如果应用程序不会意外超出最大值或低于最小值，则将简单整数与原生编译结合使用是一种很好的方法。
• 与原生编译结合使用时，simple_integer 的优势非常明显，而与解释编译结合使用时则不明显。请注意，即使与解释编译结合使用，simple_integer 也同样是有益无害的。
• 内联与原生编译结合使用时其优势也要比与解释编译结合使用时大得多。这一点更难解释。不严格地讲，接近普通编译后端的代码越紧凑，原生分支在域中执行智能优化（在解释分支中不可行）的机会越多。
• 当程序比较顺从时（即，不是使用 SQL 开发的，且不使用 Oracle 数字、日期等），原生编译的优势最明显。请注意，即使符合这些条件，性能改进的程度也会在很大的范围内变化。
• 在 Oracle Database 11g 中选择原生编译和内联是一件自然而然的事情。不选的唯一原因可能是编译时间较长（也许在早期的开发阶段确实如此）。
• 可以安全使用 simple_integer 的机会不是很多。但一旦出现这种机会，就应该牢牢抓住它。

Forward from http://www.oracle.com/technetwork/cn/articles/sql/11g-plsql-087990-zhs.html