由开发到生成环境
现在我们已经产生了一个单一的概要，我们需要将它传送到生产环境中。存储概要有很多特性可以帮助我们做到这一点。例如，我们可以将存储概要改名，由开发环境中导出，然后将它导入到生产系统中，首先在生产环境的一个测试分类中检验它，然后在将它转移到生产分类中。有用的命令是：
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，减少开销，并可让你更灵活地测试、管理和安装存储概要。
查看本文来源
京公网安备 11010802021500号