检查自动统计信息的开启状态：
select client_name,status from dba_autotask_client;
确认自动统计信息的收集是关闭的，对于“auto optimizer stats collection”的状态应该是“DISABLED”。

附：关闭数据库的自动统计信息收集：

DG备库保持和主库同步，所以这些设置项也都是完全一样的。

主要就是在mount模式下切换数据到snapshot Standby模式再read write打开库，为之后测试做准备。下面是核心步骤：

关于其他细节可参考下面文章，主要是为“开启11gR2 DG的快照模式”，“后续还原成备库” 等操作提供参考：

进行SPA测试时，强烈建议在数据库中创建SPA测试专用用户，这样可以与其他用户区分开以及避免误操作。

备库从AWR中采集到SQL。
4.1 获取AWR快照的边界ID

我这里的结果是：

4.2 新建SQL Set
注意：以下的规范部分都是引用之前同事编写的SPA操作规范。

参考规范：

依据我的实验环境，真实的示例为：

4.3 转化AWR数据中的SQL，将其载入到SQL Set
从备库的AWR中提取SQL（这等同于主库历史的SQL）。
参考规范：

依据我的实验环境，真实的示例为：

4.4 打包SQL Set(可不做)
参考规范：

依据我的实验环境，真实的示例为：

说明：其实在我这里的测试场景下，这一步是不需要做的。因为备库的SQL Set可以直接在后面引用，不需要像SPA经典场景中，是从生产源环境打包导出来后，在测试环境再导入进去，再解包为SQL Set。

5.1 创建SPA分析任务
参考规范：

依据我的实验环境，真实的示例为：

5.2 获取变更前的SQL执行效率
参考规范：

依据我的实验环境，真实的示例为：

5.3 开启变更操作
变更内容：开启统计信息自动收集并确认已经成功收集了最新的统计信息。
这里首先需要开启统计信息自动收集，并可以把自动收集的窗口时间提前到现在，减少等待的时间。

查看窗口任务和有关统计信息自动收集的任务执行状态：

调整窗口任务的下一次执行时间：

更多有关调整窗口和自动任务的内容可参考文章：

5.4 变更后再次分析性能
测试运行SQL Tuning Set中的SQL语句，分析所有语句在收集统计信息之后的执行效率：
参考规范：

依据我的实验环境，真实的示例为：

5.5 变更前后性能对比
得到两次SQL Trail之后，可以对比两次Trial之间的SQL执行性能，可以从不同的维度对两次Trail中的所有SQL进行对比分析，主要关注的维度有：SQL执行时间，SQL执行的CPU时间，SQL执行的逻辑读。
参考规范：

依据我的实验环境，真实的示例为：

参考规范：

依据我的实验环境，真实的示例为：

这样就得到了各类的性能对比报告，以执行时间的全部报告为例，生成的报告概要头部类似这样：

当然，具体获取到的这些性能对比报告，针对那些有性能下降的SQL，还需要人工干预，评估如何优化处理那些性能下降的SQL。