灵活使用ORACLE Real Application Testing (RAT)来减少测试人工的方法/实例介绍

前言

伴随着更新的性能问题

RAT 是什么？

可以执行时机业务中的workload相应的测试
- 对正式环境中的SQL进行Capture & Replay
- 9i / 10g 中获得的信息在 11g中重现
疑似客户端中可以再现高负荷状态
- 一次 Capture 中可以变化Transaction的时机等重新执行测试
Upgrade 以及Patch 应用等导致数据库变化，并可能会影响性能。

Real Application Testing
- 数据库中可以高效执行测试结构
- 可以在应用中不加工就可以减少人工
- 下述两个功能，合称为RAT
  - SQL Performance Analyzer (SPA)
    - 调查对性能的影响
  - Database Replay (DB Replay)
    - 应用的workload调查
      - 执行时间，SQL执行结果行数，错误内容

SPA 与 DB Replay 的差别

用途与功能

	SQL Performance Analyzer	Database Replay
该在怎样的情况下使用?	确认指定的重要的SQL相关的系统变更导致的性能影响的SQL单体测试	通过使用数据库服务器正式环境中的负荷，执行包含子系统在内的一概性测试时。
这些功能能做到什么？	在受到伴随着系统变更的SQL应答时间的变化之前进行确认	在测试系统中重现正式环境中的负荷
功能的目的是什么?	对SQL的应答时间的影响	评价系统中的吞吐量的影响程度
结构是什么?	执行储存在SQL Tuning Set 中的个别SQL语句，在系统变更中比较执行计划于实际执行时的统计值。	在正式环境中收集的负荷，包括同时执行性、时机、以及事务间的依赖性，一并再现。

SQL Performance Analyzer (SPA)

这里的图片是推测应用PATCH时的情况
更新时，比较/分析正式环境的STS以及测试环境中的SQL执行结果

Step 1. SQL 获得workload

SQL Performance Analyzer (SPA)

在SQL Tuning Set (STS) 中储存SQL workload
包含在STS中的数据

–SQL text

–Bind变量

–执行计划

–统计信息

对于现行的STS可以追究SQL
每隔一段时间，从cursor cache中手机信息，储存在STS中
储存在STS中的SQL可以过滤
但是，9i以及10gR1需要获得10046 trace以及对STS进行变更

Step 2. 执行变更前的SQL

为了比较环境变更后的测试，制成baseline
获得SQL的执行计划以及统计信息
串行执行SQL
一个一个执行SQL
不会执行DML / DDL (default)

–使用DBMS_SQLPA.EXECUTE_ANALYSIS_TASK procedure，将 EXECUTION_PARAMS 的 EXECUTE_FULLDML 参数更改为真就可以执行DML了 (执行SPA之后，就会被回滚)

可以不执行SQL，就可以获得执行计划

Step 3. 执行变更后的SQL

在测试环境中应用变更

–应用DB更新、补丁

–更新优化统计信息

–变更架构

–调优

应用变更后，重新执行同样的SQL

–收集执行计划以及统计信息

Step 4. 分析以及报告

比较被表示出来的项目

–执行时间

–CPU 时间

–读取buffer的块数

–读取disk的块数

–写入直接路径

–Parse时间

–优化成本

通过适用变更，表示出有影响的SQL。

–改善性能的SQL

–使得性能恶化的SQL

–对性能没有变更的SQL

利用SQL Tuning Advisor来对使得性能恶化的SQL进行调优

SPA 中需要考虑的问题

获得workload

–需要特别监视的workload以及推荐选择巅峰时的workload

测试环境

–使得正式环境以及测试环境都有相等分量的优化统计信息

–推荐应用变更完成前后都要刷新Buffer Cache

修正性能恶化

–使用SQL Tuning Advisor 以及 SQL Plan Baseline修正性能恶化

Database Replay (DB Replay)

获得正式环境的负荷直接在测试环境中再现

Step 1. workload的capture

从客户端中可以捕获所有request
(捕获文件)

–排除后台进程处理。

指定会话，可以排除/获得指定的workload

–在每个会话中都制成***.rec这个文件

–推荐排除SYS、SYSTEM、DBSNMP、EM、RMAN

指定捕获的执行时间
9.2.0.8 or 10g R2 以后可以捕获
RAC 环境中，捕获文件的保存地址中的共享文件以及本地文件都可以支持

Step 2. workload的预处理

事先准备

–将在正式环境中获得的捕获文件复制到测试环境中

–将数据配合正式环境中的捕获开始时点的内容

将捕获文件变更成可以replay的格式（replay文件）
※推荐在replay环境中执行
Replay文件可以多次执行
在RAC 环境中进行捕获时，将所有实例中生成的捕获文件汇集在同一为止，执行预处理

Step 3. workload的replay

重现正式环境中获得的workload的执行时间、并列度、commit顺序，然后replay
Replay客户端对DB服务器发送request
因为客户端会通过线程来执行，所以可以在一个进程中再现多个并列度。但是，负荷较大时，还是需要根据需要在多个进程中同时启动客户端（1个进程中最多50个会话）
11.2.0.3 + Patch:13947480 中可以进行Consolidated Database Replay (后述)
执行架构上的数据库整合的测试时可以用到的功能

(参考)replay选项

参数	说明	备注
Synchronization	这个参数决定workload replay时，所使用到的同步类型。用这个参数设定SCN时，所获得workload的commit顺序在replay中也可以保持global。获得时间SCN较小，仅限所有的操作都完成后，就会执行被replay的所有需求。这个参数在OBJECT_ID中设定时，基于获得时间SCN值以及数据库对象，使用精度更高的同步方法，就会计算被replay的call之间的依赖性。	设定为OFF时，因为无法保证commit执行顺序，正常来说一定会设定为SCN。
connect_time_ scale	从获得workload开始，用指定值变更变更连接会话的耗费时间。输入可以用百分比值来说明。 Workload的replay中，增加同时用户数或者减少同时用户数时可以使用。DEFAULT VALUE是100。	虽然比较依赖于评价，但如果仅仅在DB中评价Activity时，请考虑设定为0。
think_time_ scale	从同样的会话中可以变更两个连续的用户call之间的耗费时间。输入可以用百分比值来说明。 Workload的replay中，增加同时用户数或者减少同时用户数时可以使用。DEFAULT VALUE是100。	虽然比较依赖于评价，但如果仅仅在DB中评价Activity时，请考虑设定为0。
think_time_auto_correct	Replay中用户call完成时所耗费的时间，比在原本的获得中同样的用户call完成时间要长时，就会自动修正call之间的思考时间。通过DEFAULT的TRUE可以在replay获得较慢的情况下，缩短思考时间。	一般是应对设定为TRUE的情况。

Step 4. 分析以及报告

报告捕获时以及replay时的差异
性能差异
错误差异
- Replay时发生的新错误
- 捕获时发生过，但replay时没有发生的错误
- 捕获是发生过的replay时发生变异的错误
数据差异
执行replay之后，生成比较报告
- Workload replay report
- AWR 比较报告
- ASH 报告

灵活使用分析报告

开始时间以及终止时间，比较获得时以及replay时的处理时间，就可以查看整体性能是否恶化
可以确认是否出现错误

DB Replay中 需要考虑的问题

Capture 之前需要考虑的问题

–保存输出文件的存储容量

–CPU overhead

Capture 期间

–首先推荐执行1-2小时，之后我推荐渐渐延长时间

–特别是选择需要监视的workload以及巅峰时的workload

保证Capture 时数据的完整性

–为了提高Replay时的再现性，捕获之前我推荐先以 RESTRICT模式启动oracle数据库（捕获开始后一般会自动回到启动状态)

RAT 的总结

	SQL Performance Analyzer	Database Replay
应该在什么时候使用？	对于指定的重要SQL，确认是否存在由于系统变更产生性能影响的SQL单体测试	使用数据库服务器正式环境中的负荷，包含子系统，执行一概性测试的情况
这些功能能做什么?	在受到伴随着系统变更的SQL应答时间的变化的影响之前进行确认	在测试系统中重现正式环境的负荷
这些功能的目的是什么?	评价对于SQL的应答时间的影响度	评价系统中对于吞吐量的影响度
结构是怎样的?	执行储存在SQL Tuning Set 中的个别SQL语句之后，比较系统变更前后执行计划于执行时的统计值	再现正式环境中收集到的负荷、同时执行性、时机、以及事务间的依存性。