SQL Profile（第一篇）

SQL Profile是什么

SQL Profile是我非常喜欢的一个技术，通过它可以在不修改SQL语句的情况下，为SQL绑定任何需要的hint，与SQL代码是分离的，而且相对Baseline、outline来说，操作步骤简单，如果使用熟练可以在极短的时间内修正一个查询语句的执行计划，我已经在多个场合使用SQL Profile解决了数据库的性能问题。SQL Profile是ORACLE 10G出现的一个功能，SQL Profile在Oracle文档中被描述为作为SQL Tuning Advisor的一部分，只能通过SQL Tuning Advisor来使用，一般是通过运行SQL Tuning Advisor的JOB，JOB运行结束后可以查看SQL Tuning Advisor给出的优化建议，这些建议里可能会包含让DBA采用SQL Profile（hint的集合），作为ORACLE 10G后提供的新功能，DBA可以将SQL调优的工作交给SQL Tuning Advisor来做。正常情况下，一个SQL语句交给SQL 优化器后，优化器需要在非常短的时间内，给出解析结果，但是SQL Tuning Advisor却不同，它为了产生一个高效的执行计划，可能会花费很长的时间。进一步讲，它还会使用一些非常耗时的技术如Wath-If 分析，并加强对动态采样技术的利用来核实优化器的估计值。SQL Tuning Advisor的任务是分析SQL语句并建议如何使用一些方法来提高语句的性能，包括收集遗漏或过时的对象统计信息，创建新索引，改变SQL语句或者采用SQL Profile。按照官方的说法，SQL Profile只能通过SQL Tuning Advisor来使用，但是本节后面的几个章节都会使用手工创建SQL Profile的方式来告诉读者如何更快速的使用、创建SQL Profile，但是手工创建SQL Profile并不被ORACLE技术支持所支持。

简单来说SQL Profile是一个对象，包含了一系列的hint，这些hint包含了可以帮助优化器为一个特定的SQL语句找到高效执行计划的额外信息。这些hint包含执行环境，对象统计信息，和对查询优化器所作评估的修正信息，例如广为流传的OPT_ESTIMATE就是由SQL Profile所引入的hint，它主要的作用是设定对象统计信息、放大或缩小优化器的评估基数、修正表连接的基数，例如，select * from a where status='Inactive'，真实的返回基数为10000，但是由于统计信息的陈旧，导致优化器认为只返回100，因此通过OPT_ESTIMATE会纠正这一信息，例如通过OPT_ESTIMATE(@"SEL$1", TABLE, "A"@"SEL$1", SCALE_ROWS=100)来告诉优化器，对于表A经过谓词过滤后返回的基数为：优化器的评估基数再放大100倍，也就是优化器评估基数100，再乘以放大系数100，最终的基数为10000（注意OPT_ESTIMATE等hint的纠正信息并不会存储、更新到表、索引等对象的统计信息里）。从这里我们也可以看出，SQL Profile并不是真正的锁定执行计划，而只是告诉优化器一些更加真实的信息，让优化器根据真实的信息来得到更加合理的执行计划。因此，即使一个SQL使用了SQL Profile，优化器在选择执行计划的时候也具有很大的灵活性，随着数据的变化，时间的推移，这些修正因子可能也已经不再准确，因此可能会出现在某些使用了SQL Profile的SQL,刚开始这些SQL Profile工作的很好，但是不久就会产生一些问题。不过SQL Profile跟outline、Baseline一样都是基于存储一些hint来发挥作用的，SQL Profile虽然默认不会使用例如index、full等我们常见的hint，但是这些hint依然可以在SQL Profile里发挥作用。

SQL Profile在10G和11G默认是被打开的，可以通过设置参数SQLTUNE_CATEGORY为false来关闭SQL Profile。每个SQL Profile都被放置在一个特定的category中，可以在创建SQL Profile时指定category的值，如果不指定会被放在SQLTUNE_CATEGORY为defualt的category中。如果SQLTUNE_CATEGORY的值被设置为非default的值，那么只有SQL Profile的category的值为参数SQLTUNE_CATEGORY设置值的才会生效。利用这一特性来校验SQL Profile的性能是一种很好的方式，本章后面将会对这一技术进行详细说明。

n Note:SQL Profile可以为SQL语句添加任何hint，例如：bind_aware这个hint并不能通过SQL Baseline起作用，但是可以通过SQL Profile起作用。因为SQL Profile作为一种基于hint修正SQL执行计划的机制，做的比较傻瓜化，它仅仅是把hint应用到特定签名的SQL上，不会做其他校验，SQL Baseline不仅仅只是应用hint，还需要做plan_hash_value值的计算校验,因此对于bind_aware这种hint并不能对SQL Baseline起作用，因为这个hint会导致执行计划的不稳定性，而Baseline创建的时候是跟具体的plan_hash_value挂钩的，不能与这种具有不稳定性的hint挂钩。 n SQL Profile可以在DataGuard中使用，也就是说在主库创建SQL Profile后，备库可以自动使用到在主库上创建的SQL Profile，但是Baseline不能在DataGuard中使用。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22034023/viewspace-2154500/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22034023/viewspace-2154500/