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

前言

  • 伴随着更新的性能问题

sqltuning1

 

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)

spa1

  • 这里的图片是推测应用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进行变更

spa2

Step 2. 执行变更前的SQL

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

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

  • 可以不执行SQL,就可以获得执行计划

 

spa3

Step 3. 执行变更后的SQL

  • 在测试环境中应用变更

–应用DB更新、补丁

–更新优化统计信息

–变更架构

–调优

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

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

spa4

 

Step 4. 分析以及报告

  • 比较被表示出来的项目

–执行时间

–CPU 时间

–读取buffer的块数

–读取disk的块数

–写入直接路径

–Parse时间

–优化成本

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

–改善性能的SQL

–使得性能恶化的SQL

–对性能没有变更的SQL

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

spa5

SPA 中需要考虑的问题

  • 获得workload

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

  • 测试环境

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

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

  • 修正性能恶化

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

 

Database Replay (DB Replay)

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

 

db replay1

Step 1. workloadcapture

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

–排除后台进程处理。

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

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

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

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

 

db replay2

Step 2. workload的预处理

  • 事先准备

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

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

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

db replay3

Step 3. workloadreplay

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

db replay4

 

(参考)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 replay5

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语句之后,比较系统变更前后执行计划于执行时的统计值 再现正式环境中收集到的负荷、同时执行性、时机、以及事务间的依存性。

 

 

RAT 的总结 

减少人工的要点

RAT1

 

RAT 的 Best Practice

RAT 灵活使用顺序 (Best Practice)

rat2

rat_spa1

rat_spa2

rat_dbreplay

灵活使用RAT 的经过

 

  • 将实例数据库迁移到下次的基线中

–11g R2 中,为了更新而使用RAT

–大部分数据库都是 Oracle Database 9i R2

–Infrastructure team表示想尽可能多执行测试

  • 「要全部人工进行性能测试是不现实的」
  • 「对实例整体做迁移预测也是有限度的」
  • 「为了尽可能节约成本,会尽可能framework话以及将重复劳动最小化」

ratz1

基于客户业务的测试方法

ratz2

  • 夜晚处理batch之前,为了获得备份,暂时关闭系统,可以保证rest point
  • Batch 以及OLTP中执行其他测试

–Batch 处理中,执行数据的完整性测试以及性能测试

–OLTP中,构筑其他测试环境,仅仅执行性能验证

 

测试内容

  • Best Practice中,我推荐优先执行SPA ,但根据用户的期望,大多首先执行Capture / Replay
  • GoldenGate Veridata :迁移/复制时,做数据的整合性检查的产品
  • 利用自我制作的工具

–Oracle 9i Database R2 中因为无法获得DB time,所以无法比较各个SQL。对客户自身来说,利用SQL Trace 的Elapsed Time 执行性能比较

 

需求与功能的 Fit & Gap

客户的需求

1.总而言之,长时间进行捕获、
想对workload整体进行replay

2.正式数据库以及开发数据库中,想进行完整性测试本番

3.比较DB Replay 中各 SQL 的DB Time

产品机制 / Best Practice

1.从文件的容量以及正式环境的性能中,推荐首先执行的捕获用1-2小时

2.完整性测试可以通过restricted mode 来执行。但没有在正式环境中使用时,要使得数据完全一致就非常困难難

3.9i 中因为无法获得DB Time ,所以使用SQL trace的 Elapsed Time

 

比较DB time的单体SQL的性能

  • 为了比较性能恶化SQL以及改善性能的SQL,请通过AWR Report 的DB time 来判断之间的差距
  • SQL A 慢了5秒时,对业务整体的影响较大, 但SQL B慢了10秒的话,对整体的影响会较少
  • 重要的是掌握各个SQL的特征,指定改善计划

制成比较SQL Trace 的 Elapsed Time 的工具

–10g以后,因为可以比较 DB time了,就可以减少人工

 

应用补丁  需要在正式环境中应用 Patch

  • 请注意现有patch中的冲突

–大部分情况因为Sustaining Support / Extended Support 的Database较多,请注意这种情况

  • 详细内容请参考 Note:560977.1。
  • 这次的实例中执行的对策 (Oracle 9i Database R2 / Linux 64bit) ※2012年末時点

–仅限Linux 64 bit 的 Patch ,使用CPU中被合并的Patch:10087814

  • 其他时候是 one-off (Patch:9373986)

–应用上述 Patch时,需要升级9.2.0.8 的Opatch的版本

  • 应用Patch:6880880

–应用上述 Patch时,需要提高9.2.0.8的 OUI 的版本

  • 应用Patch:6640838

 

 

处理In-flight Transaction

 

  • start_capture 命令以及 finish_capture命令之间,虽然被捕获了,但是 start_capture时,执行中的事务无法捕获。

–这时因为仅仅记录发行SQL时的SQL语句的机制

  • 以SCN 为基础,需要明确分辨分歧点

in-flight transaction

被捕获的会话

in-flight transaction2

被捕获的会话

 

捕获PL/SQL时的操作

 

PL/SQL以及 stored procedure不会捕获一个个的SQL,而是仅仅捕获call

例) PL/SQL 中不包含称为时间的SQL时,捕获时以及replay时结果不同

捕获plsql

捕获PL/SQL时的操作

  • PL/SQL 以及stored procedure,不是一个个捕获SQL而是仅仅捕获CALL

捕获PLSQL时的操作

  • 9i的服务器,要比使用11g的服务器的I/O的性能更差,可以更新的行业就更少

捕获PLSQL 时的操作

 

PL/SQL 机制中需要注意的问题

  • 由于PL/SQL 的捕获机制,在如下所示,组合相应程序时,需要考虑对replay的影响
  • 用时间来控制的程序
  • 没有保障顺序性的程序

 

例) 「Batch A 终止数秒之后,流走Batch B 」这样的逻辑组合情况

 

PLSQL的 机制中需要注意的问题

 

比较Capture 时以及 default 时的CPU使用率

 

capture_cpu

比较Capture 时以及 default 时的CPU使用率

在同样环境中Capture & Replay 的验证结果

 

比较Capture 时以及 default 时的CPU使用率

Consolidated SQL Performance Analyzer

  • 将由各自的数据库获得的STS汇总到一个数据库中
  • 在整合环境中,可以SPA执行所有的workload

Consolidated SQL Performance Analyzer

Consolidated Database Replay

  • 可以在整合地址的环境中,对不同的数据库的Capture File 进行replay
  • 在以架构为单位进行整合时使用 (Server整合以及 OS整合时,使用一般的DB Replay)
  • 通过应用之间的可扩展性以及同时执行,可以识别问题,进行修复

 

consolidateddatabasereplay

  • 对于更新以及DB的各种变更,可以减少测试时的人工。
  • 不需要特别的架构,可以指定需要调优的SQL
  • SQL 单体性能测试以及重新workload时,较为有效

请一定要试一试使用 RAT!

(参考) GoldenGate Veridata

数据完整性检查

 

  • Veridata Server

–数据比较引擎、Veridata task总结

–比较数据,生成报告、确认out-of-sync数据

  • Veridata Web

–Rich Client /WebBrowserBase的GUI

–将要比较的job的object,以及设定规则

–参考报告以及out-of-sync数据

  • Veridata Agent

–获得数据

  • Veridata Repository

–保存设定信息的数据库

  • Veridata Command Line Interface

–GoldenGate Server的命令行客户端

 

ggveridata

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号