获取数据库整体的运行情况
步骤 1 （构造环境，对当前数据库进行各种操作）
sqlplus / as sysdba @ d: \mkdb . sql
步骤 2 （运行脚本，对当前数据库进行整体提取）
sqlplus / as sysdba @ spooldb.sql
步骤 3 （ 输 出对应日志文件，以供后续进行分析）
输出如下 5 个文件，其中 addm 是最近一小时文件， ash 是最近半小时文件，而 awr 文件
是最近一小时和最近 7 天的两个文件， spool 打头的文件输出数据库所有的相关信息。有了这
5 个文件，基本上数据库的情况可以了解得比较清晰。具体文件如下图所示：
其中 spool 打头的这个文件基本涵盖了你想获取的所有相关数据库信
息。如·数据库版本、数据库参数、主机参数、异常的表和索引信息（表分区有无异常、并行
度问题、索引是否失效、是否过大、是否为分区索引、索可｜类型、哪个歹l j 上有索引、索引过
多、组合索引的组合列过多、全局临时表的异常信息收集情况 ， 等等 ） 、日志切换情况、序列
情况、异常触发器、异常外键设置等。
获取 SQL 的各种详细信息
步骤 1 （构造环境，执行部分效率低下的 SQL)sqlplus / as sysdba @ d : \mksql . sql
步骤 2 （对当前的性能低下的 SQL 进行收集）
步骤 3 （对当前的性能低下的 SQL 进行收集）
我们获取到了这个 SOL 的详细执行计划和对应的表及索引信息，从而大大提升了效率，如下图所示
大家不要小看了这个一键获取 SQL 相关详细信息的威力。当你认为一条 SQL 有问题时，只
要获取到这些信息，根本就不需要进行任何与现场人员的交互动作，因为你要的东西都已经被
收集在一起了。让我们一起看看下面一个技术人员解决问题的一个思维片段。
这语句该如何优化，让我先瞧瞧这语旬的执行计划是啥？
哦，原来执行计划就在这里，太详细了！
奇怪，这里的执行计划不对啊，应该是要用索引啊，怎么会没有，难道是统计信息不准
确，还是说没建索引，还是说索 51 失效了？
咦，相关统计信息的收集是正常的，奇怪。我再看看，这列有索引吗？咦，是有，奇怪
了。哦，索 51 失效了，原来如此。看来我重建－下索引问题应该可以解决…·