最近对10G的SQL Profiles做了一点学习。 个人理解SQL Profiles可以看作是SQL语句的统计信息。只是这个统计信息对特定SQL语句才能起作用，不对会语句的对象、其它语句产生影响。

使用SQL Profiles前要用SQL Tuning Advisor收集对语句的优化建议，再根据优化建议创建SQL Profiles。

SQL Profiles 使用也比较灵活，可以在会话级、系统级应用。

语句绑定SQL Profile后，测试了下SQL Profile与Bind Peeking的关系。测试发现，Bind Peeking的特性还是会起作用。这从另一方面说明SQL Profile与OUTLINE的不同：绑定OUTLINE后，执行计划是被固化的；绑定SQL Profile后，执行计划不是不变，而是优化器在执行该语句时，会参考SQL Profile中的信息。

常常需要从statspack中取一些数据做分析，比如找出SQL的执行次数、逻辑读等等做一些图表。这些数据都是累加的，所以需要找出两个时间点的差值，这时候 lag over分析函数就显得很有用了。

用登陆触发器实现用户名和IP的限制，要记录一些日志信息，带了insert、 commit之类的语句，测试时报了：

ORA-04092: cannot COMMIT in a trigger

不能在trigger中使用commit。

索引跳跃式扫描（INDEX SKIP SCAN），需要在CBO模式下才能起作用，当查询谓词中不带有前导列，且前导列唯一值较少时，才有可能用上该索引扫描方式。下面来看看INDEX SKIP SCAN 是如何扫描的：

查看执行计划：

查看执行计划：

本文主要通过设置10046事件及Tree Dump等方式，来观察索引扫描。

曾经写过一篇文章：对比前后执行计划，发现问题。当系统出现异常语句，在分析语句前，我常会先查查这个语句的历史执划信息，看看是否发生变化，何时发生了变化。如果发生了变化，就可以找出以前的执行计划，与当前的执行计划进行对比，看看有什么不同，是新建、删除了索引？是bind peeking的原因？还是表长时间没有分析？
之前的文章写的是9i的系统，可以使用statspace报告获得相关信息，现在总结下10G的，使用的是AWR报告中的信息，主要是查询以下三个视图：
DBA_HIST_SQL_PLAN、DBA_HIST_SQLSTAT、DBA_HIST_SNAPSHOT。