解析Oracle 8i/9i的计划稳定性

由Oralce8.1开始，Oracle增加了一个新的特性就是Stored Outlines，或者称为Plan Stability（计划稳定性）。这个特性带来三个好处。首先，你可以优化开销很大的语句的处 理。第二，如果有一些语句Oracle需要花费长时间来优化（而不是执行），你可以节省时间并 且减少优化阶段的竞争。最后，它可以让你选择使用新的cursor_sharing参数而无需要担心因 　要知道如何使用存储概要才是最优的，我们首先运行一些极度没有效率的SQL的存储 　我们将看一下如何跟踪SQL语句，并且查看它当前在数据库中的执行计划，找出一些 提示来改进SQL语句的性能，然后再重新执行该SQL语句时，让Oracle使用我们的提示。 　在这个示例中，我们将创建一个用户，在该用户的模式中建一个表格，并且创建一个 存储过程访问该表格，我们将在这个存储过程上使用wrap工具，这样我们就不能通过反向方式 得到源代码。然后我们将通过该存储过程来调试SQL的执行。 　例子中我们将假定存储慨要已经在数据库创建的时候被自动安装。 　准备工作 　创建一个用户，他的权限有：create session, create table, create procedure, create any outline, and alter session。以该用户连接并且运行以下的脚本来创建一个表 　　create table so_demo ( 　　n1 number, 　　n2 number, 　　v1 varchar2(10) 　　) 　　; 　　insert into so_demo values (1,1,'One'); 　　create index sd_i1 on so_demo(n1); 　　create index sd_i2 on so_demo(n2); 　　analyze table so_demo compute statistics; 　接着需要编码来创建一个存储过程访问该表格。创建一个称为c_proc.sql的脚本，如 　　create or replace procedure get_value ( 　　i_n1 in number, 　　i_n2 in number, 　　io_v1 out varchar2 　　) 　　as 　　begin 　　select v1 　　into io_v1 　　from so_demo 　　where n1 = i_n1 　　and n2 = i_n2 　　; 　　end; 　　/ 　当然，也可以直接执行这个脚本来建立该过程--不过，为了更有效果，转到操作系统 　wrap iname=c_proc.sql 　响应是： 　Processing c_proc.sql to c_proc.plb 　这里不是通过执行c_proc.sql脚本来产生该过程，而是执行看不到源码的c_proc.plb 脚本，你将会发现在user_source的视图中找不到我们的SQL语句。这个应用的作用是什么？ 　现在我们已经产生了一个模拟的应用，我们就可以运行它，打开sql_trace，看看有 什么事情发生。我们将会发现这个SQL执行一个全表搜索来得到请求的数据。 　在这个测试中，全表检索或许是最有效的方式--不过让我们假定已经证明使用一个单 列的索引和and-equal选项才是最佳的执行路径时，我们可以怎样修改呢（无需在代码中加入 　通过存储概要，答案是简单的。要达到我下面所做的事情实际上有好几种方法，因此 不要认为这是唯一的做法。Oracle一直改进它的特性以方便使用，这里所讲的技术或许在未来 　你想该应用做什么？ 　要令Oracle如我们所想的那样运作，有三个阶段： 　. 启动一个新的session（连接），然后重新运行该过程，首先告诉Oracle我们要跟 踪将要运行的SQL语句和该SQL使用的路径。这里说的"路径"就是我们存储概要的第一个例子。 　. 为有问题的SQL语句创建更好的存储概要，然后用好的代替有问题的。 　. 启动一个新的session，并且告诉Oracle在看到匹配的SQL时，开始使用新的存储 概要，而不是使用通常的优化方法来执行；然后重新运行该过程。 　我们必须停止和启动新的session来确保pl/sql缓冲中的游标（cursors）并不是保持 打开的。存储概要只在一个游标被分析的时候产生和（或）应用，因此我们必须要确认以前存 　启动一个session并且执行以下的命令： 　　alter session set create_stored_outlines = demo; 　然后运行一小段匿名的代码块来执行该过程，例如： 　　declare 　　m_value varchar2(10); 　　begin 　　get_value(1, 1, m_value); 　　end; 　　/ 　然后停止收集执行的路径（否则以下你执行的一些SQL也会放到存储概要的表格中， 　alter session set create_stored_outlines = false; 　要看到这样做的结果，我们可以查询以下视图来看清Oracle为我们创建和存储的概要 　　select name, category, used, sql_text 　　from user_outines 　　where category = 'DEMO'; 　　NAME CATEGORY USED 　　------------------------------ ------------------------------ ------- 　　SQL_TEXT 　　------------------------------------------------------------------------------ 　　SYS_OUTLINE_020503165427311 DEMO UNUSED 　　SELECT V1 FROM SO_DEMO WHERE N1 = :b1 AND N2 = :b2 　　select name, stage, hint 　　from user_outline_hints 　　where name = ' SYS_OUTLINE_020503165427311'; 　　NAME STAGE HINT 　　------------------------------ ---------- ------------------------------ 　　SYS_OUTLINE_020503165427311 3 NO_EXPAND 　　SYS_OUTLINE_020503165427311 3 ORDERED 　　SYS_OUTLINE_020503165427311 3 NO_FACT(SO_DEMO) 　　SYS_OUTLINE_020503165427311 3 FULL(SO_DEMO) 　　SYS_OUTLINE_020503165427311 2 NOREWRITE 　　SYS_OUTLINE_020503165427311 1 NOREWRITE 　我们可以看到在demo的分类中只有一个存储概要，查看概要中的sql_text我们可以看 到与我们原来PL/SQL代码类似的、但又有点不同的语句。这是很重要的一点，因为Oracle仅在 存储的sql_text和将要执行的SQL非常相似的时候才会使用存储概要。实际上，在Oracle8i中 ，两个SQL语句要完全一样才可以，这也是存储概要的一个大问题。 　你可以由列表中看到存储概要中是一套hints用来描述Oracle如何执行（或者将要执 行）该SQL。这个计划使用一个全表搜索--即使是一个全表搜索这样的操作，Oracle使用大量 　要注意到存储概要通常都是属于一个分类的；在这里是demo分类，我们是通过alter session命令来指定的。如果在上面的命令中，我们使用true来代替demo，我们将在一个名字 　存储概要都有一个名字，该名字在整个数据库中都必须是唯一的。没有两个概要的名 字是相同的，即使是它们是由不同的用户产生。实际上，概要并不是由谁拥有的，它们仅有创 建者。如果你创建的一个存储概要和我以后执行的一个SQL语句匹配，Oracle将会应用你的 hints列表到我的语句--即使这些hints在我的模式中是无意义的。（这样我们就有完全不同 的选项来欺骗存储概要，不过这是另一篇文章的事情了）。你还可能注意到，当Oracle自动产 　继续处理我们那个有问题的SQL，我们判定如果使用一个 的hint，那么Oracle将会使用我们想要的执行路径，所以我们现在通过以 　　create or replace outline so_fix 　　for category demo on 　　select v1 　　from so_demo 　　where n1 = 1 　　and n2 = 2; 　这样就显式地在我们的demo分类中创建了一个名字为so_fix的存储概要。我们可以通 过name='SO_FIX'这个条件来重新查询user_outlines和user_outline_hints，查看一下存储 　　NAME CATEGORY USED 　　------------------------------ ------------------------------ --------- 　　SQL_TEXT 　　--------------------------------------------------------------------------- 　　SO_FIX DEMO UNUSED 　　select v1 　　from so_demo 　　where n1 = 1 　　and n2 = 2 　　NAME STAGE HINT 　　------------------------------ ---------- -------------------------------- 　　SO_FIX 3 NO_EXPAND 　　SO_FIX 3 ORDERED 　　SO_FIX 3 NO_FACT(SO_DEMO) 　　SO_FIX 3 AND_EQUAL(SO_DEMO SD_I1 SD_I2) 　　SO_FIX 2 NOREWRITE 　　SO_FIX 1 NOREWRITE 　　 　要注意到的是FULL(SO_DEMO)那一行已经被AND_EQUAL(SO_DEMO SD_I1 SD_I2)替换了 　现在我们必须将两个存储概要"替换"过来。我们想Oracle在看到以前的语句时使用新 的hint列表；要做到这一点，我们必须做一些欺骗。user_outlines和user_outline_hints视 图是由两个表格产生的(分别是ol$和ol$hints），它们由outln模式拥有，我们必须直接修改 这些表格；这意味着要使用outln连接数据库，并且使用一个有权限的帐号来更新表格。 　幸运的是，outln表格并没有任何引用的完整性限制。便利的是，ol$ (outlines)和 ol$hints (hints) 表格间的关系是由概要的名字定义的（存储在ol_name列中）。因此，仔 细检查名字，我们就可以通过交换ol$hints表上的名字交换存储概要的提示： 　　update outln.ol$hints 　　set ol_name = 　　decode( 　　ol_name, 　　'SO_FIX','SYS_OUTLINE_020503165427311', 　　'SYS_OUTLINE_020503165427311','SO_FIX' 　　) 　　where ol_name in ('SYS_OUTLINE_020503165427311','SO_FIX') 　　; 　对于这样做，你可能感到有点不习惯，特别是根据指南上的建议--不过这个更新在 Metalink（译者注：这是Oracle的一个技术支持站点）上是允许的。不过，你还需要做第二次 更新来确保和每个存储概要相联系的hints数目保持一致。如果你忽略了这一步，你将会发现 你的一些存储概要被损坏，或者在一个导出/导入中的处理中被破坏。 　　update outln.ol$ ol1 　　set hintcount = ( 　　select hintcount 　　from ol$ ol2 　　where ol2.ol_name in ('SYS_OUTLINE_020503165427311',' SO_FIX') 　　and ol2.ol_name != ol1.ol_name 　　) 　　where 　　ol1.ol_name in ('SYS_OUTLINE_020503165427311','SO_FIX') 　　; 　一旦完成上面的语句，你就可以发起一个新的连接，告诉它使用存储概要，重新运行 该过程然后退出；同样地，你可以使用sql_trace来确认Oracle确实是这样做的。要告诉 Oracle使用修改后的存储概要，你可以使用以下的命令： 　　alter session set use_stored_outline = demo; 　检查trace文件，你将会发现该SQL现在使用and_equal的路径（如果你使用tkprof来 处理和解释trace文件，你将会发现输出显示了两个矛盾的路径。第一个将展示使用的 and_equal路径，第二个将可能是一个全表搜索，这是因为在tkprof在跟踪的SQL上执行 　由开发到生成环境 　现在我们已经产生了一个单一的概要，我们需要将它传送到生产环境中。存储概要有 很多特性可以帮助我们做到这一点。例如，我们可以将存储概要改名，由开发环境中导出，然 后将它导入到生产系统中，首先在生产环境的一个测试分类中检验它，然后在将它转移到生产 　　alter outline SYS_OUTLINE_020503165427311 rename to AND_EQUAL_SAMPLE; 　　alter outline AND_EQUAL_SAMPLE change category to PROD_CAT; 　要将概要由一个开发系统导出到一个生产系统中，我们可以利用在一个导出的参数文 件中加入一个where语句，因此我们的导出参数文件可能是： 　　userid=outln/outln 　　tables=(ol$, ol$hints, ol$nodes) # ol$nodes exists in v9 only 　　file=so.dmp 　　consistent=y # very important 　　rows=yes 　　query='where ol_name = 'AND_EQUAL_SAMPLE'' 　Oracle 9的加强 　在使用存储概要时，还有许多其它的细节需要考虑，在Oracle8中，对于它们能够做 什么以及如何工作是有一些不便的限制的，不过其中许多的问题已经在Oracle 9中消除了。 　存储概要在Oracle8中使用的最大不足是它只可以在存储的文本和将要执行的文本要 完全一样才可以使用。在Oracle 9中，有一个"标准化"的处理可以消除这个匹配的限制；在对 比前，文本将会被转换为大写并且被除去空格。这样就提升了不同的SQL可以使用同一个存储 　调用多个存储块的复杂执行计划中还有一些问题。Oracle公司通过在Oracle 9中推出 了一个在outln模式中的ol$nodes表来解决。这样就可以帮助Oracle减少ol$hints中的hints 列表，并且可以在即将执行SQL的子区中正确地交叉应用它们。不过，由存储概要之间交换 hints的策略有一个副作用，因为ol$hints表还需要不同细节的文本长度和偏移。升级到 Oracle9时，将需要选用一些方法来管理存储概要，例如带有特别数据集合或者丢失索引的第 二个模式，或者是带有内置的hints的存储视图来替换文本中命名的表格。 　Oracle9的另一个特色是在管理存储概要时有更多的支持，包括初次推出了一个包来 让你直接编辑存储概要。更重要的是，还有一个选项可让你更安全地管理生产系统上的计划。 虽然没人喜欢在生产环境上做实验，不过在有些时候，只有生产系统才有正确的数据分布和卷 ，以让你决定某个SQL的最优执行路径。在Oracle9中，你可以创建一个outln表的私人拷贝， 并且将"public"的概要释放进去以作"私人的"实验，这样你就不用冒你的私人存储概要被终 端用户的代码看到的危险。我个人认为这是一个最后的手段，不过我可以想象到有时它是必须 的。更安全的是，如果你有一个full-scale UAT或者开发系统，可以使用这个特性自由地测试 　告诫 　这篇文章给你足够的信息作存储概要的实验；不过在应用该技术到一个生产系统上时 　首先--在Oracle8i中，outln（这是拥有存储概要的那些表格所在的模式）有一个默 认的密码，该帐号有一个非常危险的权限。你必须修改这个帐号的密码。在Oracle9i中，你将 　第二--保持存储概要的表格在system表空间中创建。在一个生产系统中，当你开始创 建存储概要时，你将会发现会使用system表空间中的很多空间。因此最好将这些表格移走，最 好是放到它们自己的表空间中。不幸的是，其中的一个表格含有long列，因此你将可能需要使 用exp/imp将这些表格移动到一个新的表空间中。 　第三--虽然存储概要对于解决严重的性能问题是很有用的，不过它也有一个开销。如 果激活了存储概要，那么Oracle在分析每个新的语句时都会检查是否存在一个相关的存储概要 。如果大量的语句都没有存储概要，那么你就需要平衡一下这个开销与你在很少拥有存储概要 语句上得到的性能提升，看是否值得这样处理。不过，这个问题只会在一个有着更严重性能问 　结论 　存储概要有着巨大的好处。当你不能修改源代码或者索引策略时，存储概要是令第三 　更进一步，如果你还需要面对将一个系统由基于规则切换到开销优先的问题，那么存 　如果你需要发挥存储概要的最大好处，那么Oracle9有一些加强可让它覆盖更多类的 SQL，减少开销，并可让你更灵活地测试、管理和安装存储概要。