ANBOB™

最近在跟客户沟通时，发现有些数据库厂家对外宣称，具备从oracle数据库迁移到目标国产库时，从源库到目标异构数据库真实负载重演能力，于是花了点时间研究一下，该功能原本在Oracle叫做ORACLE REAL APPLICATION TESTING （RAT）或其中的子Database replay, 相比另一功能SPA,是能重演生产库的真实业务到测试环境，国产库厂家是怎么做的呢？是真的可以RAT? 有没有什么风险呢？ 这里简单描述。

什么是ORACLE REAL APPLICATION TESTING （RAT）

Oracle Real Application Testing（简称 RAT）是 11g的一个重要的 feature, Real Application Testing 其实有两个功能子项:分别是 Database Replay 和 SPA（SQL Performance Analyzer）。利用 Oracle REAL APPLICATION TESTING以下简称RAT，可以从生产系统中捕获工作负载，然后在测试系统上重放这些工作负载，从而反映原始工作负载的精确计时、并发和事务特征。这使您能够在不影响生产系统的情况下测试系统更改的影响。

SPA 是用于捕捉生产数据库SQL或性能数据，传递到目标数据库重新执行，生成对比报告。

Database Replay，数据库回放顾名思义可以理解为一个录像机，录制生产库负载，离线传递到测试库或变更后的环境进行播放，从而进行对比生成分析报告。Database Replay分为四个阶段完成：录制、预处理、回放、结果分析和报告。

SPA和Database Replay区别简单的可以理解为，如果同时间段同 一个SQL在源库运行了10次，SPA对目标库是只跑1次判断兼容与性能，而Database Replay是按原顺序跑10次。

Database Replay 支持在运行 Oracle Database 10g R2和更高版本的系统上捕获工作负载。要在运行 Oracle 10g R2的系统上捕获工作负载，数据库版本必须为 10.2.0.4 或更高版本。工作负载replay仅在运行 Oracle Database 11g  R1和更高版本的系统上受支持。

另外在vldb 上有一篇oracle database replay的论文链接  https://www.vldb.org/pvldb/vol2/vldb09-588.pdf

这是一款强大的工具，无需应用团队参与即可测试实时性能, 模拟测试工作负载。通过RAT，您可以在不中断生产系统的情况下评估系统更改对工作负载的影响。它消除了多个团队参与测试过程的必要性，为进行性能测试提供了一种轻松快捷的方法。

什么是Workload Capture捕获？
启用Workload Capture工作负载捕获后，Oracle 数据库会仔细跟踪和归档所有外部客户端请求。这些记录以二进制文件（称为capture files文件）的形式存储在文件系统上。捕获功能作为用户进程上的轻量级跟踪实现，通过缓冲写入将特定于会话的信息记录到每个会话的单个 .rec 文件中。格式为 wcr_.rec，并附带一些元数据文件。每个捕获的会话都单独记录在各自的文件中。例如，如果捕获了 100 个会话，则将生成 100 个 wcr_.rec 文件，对于我们有的客户上万个会话，文件系统也有较大压力

用户可以指定这些捕获文件的存储位置。随着工作负载捕获的开始，每个外部数据库调用都记录在捕获文件中，其中包含 SQL 文本、绑定值和事务信息等关键详细信息。值得注意的是，后台活动和数据库计划程序作业不包括在此捕获过程中。生成的捕获文件与平台无关，可以很容易地传输到另一个系统以供后续重放。

相关对象dba_workload_captures ，dbms_workload_capture

Workload Capture影响

捕获期间对性能的影响取决于工作负载，并与从客户端传输的数据量相关，从客户端发送到服务器的数据越大，相关的开销就越高。通常，此开销受捕获期间执行的 SQL 语句数量的影响。wcr rec文件建议放在写入吞吐量的文件存储设备（存储故障案例1）。捕获所需的空间，AWR 报告监视SQL*Net* 传入网络流量：

Approx space required ==> 2 * Bytes received via SQL*Net from client (from AWR)

运行捕获的最佳时间, 建议选择峰值工作负载、完整业务周期或感兴趣的特定工作负载。但Capture已自动排除了后台进程如dbms_job, dbms_schedure 类的JOB，不支持SQL*Loader 等direct path 加载等条件限制.避免在 Oracle 数据库当前遇到 CPU 不足时启动捕获。

所需要的Licensing 授权

如果使用RAT 功能是需要Oracle的企业版lic + Oracle Real Application Testing 许可 和 Oracle 诊断包许可。 这也是一项不小的费用，如果基于此功能做二次开发，先不讨论是否需要经过Oracle的授权，就二次开发的是否允许商用？费用是有目标国产数据库软件厂家还是有源ORACLE数据库用户承担？都是个问题，在大陆内可能版权意识差一些，但是如果后期要“出海”还是要注意的。 因为之前遇到过国内的某数据库监控软件依赖AWR视图，在香港某客户实施时，发现监控页面多处空白，因为客户未购买其授权，并且非常重视版权，所以后果可想而知。但是随着数据库国产化转型，相信会逐渐增强并必须适应尊重软件正版化和知识产权。下图是Oracle 公开的2024年 授权单价:

oracle到国产库的RAT

目前了解了几个国产库的 RAT 方案，主要是利用 Oracle 自带的 RAT 中的 Workload Capture 功能。这些方案通常涉及对生成的二进制文件进行数据结构的破解和识别，然后生成自定义的文件格式。接下来，他们会编写 SQL 解析器，根据指定的规则（如 SQL 转换），在目标数据库上重新执行这些 SQL。最终，他们生成类似 RAT 的可读性报告，用于比对分析结果。所以破解Oracle 的WRC 的.rec文件就是关键。代码中发现存在A厂家引用B厂家代码的现象。

部分代码

// WcrParser represents a WCR parser. 
type WcrParser struct { 
    fileReader     WcrFileReader 
    listener       WcrParserListener 
    exceptionList []WcrParserException 
} 
// readFile reads and parses a WCR file. 
func (p *WcrParser) readFile(filePath string) error { 
    hasHandle := false 
    file, err := os.Open(filePath) 
    if err != nil { 
        return err 
    } 
    defer file.Close()

fi, err := file.Stat() 
if err != nil { 
    return err 
} 
if fi.Size() == 0 { 
    log.Printf("file %s is empty", filePath) 
    return nil 
} 
 
p.fileReader = &wcrFileReader{ 
    reader: bufio.NewReader(file), 
    filePath: filePath, 
} 

另一种做法是规避源库的风险，在Workload Capture捕捉录制过程，不依赖源库能力，如不使用oracle RAT，而是从网络中抓取tcp流量数据，分析其中的通信协议，从网络流量过滤SQL语句，如里支持多种数据库的网络通信协议，并且通过网络旁路监听流量的方式就可以真正做到对源库无影响，但是比较担心如何保证事务的高并发与事务顺序，同时记录事务SQL的持续执行时长是否准确？对于网络流量较大的业务库处理算力要求可能会比较大。

另外就国产数据库的类SPA功能实现就容易的多，从v$sql或AWR capture 明文SQL, 去目标数据库重演，生成报告提示兼容性，但是生成性能对比报告，应该也是需要Oracle 诊断包许可.

国产库的dbreplay应用负载回放

在Oracle中replay前有一个预处理，所需要的时间取决于：捕获的大小,文件数,CPU 类型和 I/O 吞吐量。 使用dbms_workload_replay.process_capture_remaining_time可以估算剩余时间。Oracle数据库通过重新创建所有捕获的外部客户端请求，使用生产系统的相同的时间顺序、并发性和事务依赖关系，在测试系统上执行工作负载捕获阶段记录的操作。Oracle提供了一个校准工具“wrc”来帮助确定特定工作负载所需的重放客户机的数量。因为整个工作负载都是重播的(包括DML和SQL查询)，所以重演系统中的数据在逻辑上应该尽可能与捕获系统中的数据相似。这将最大限度地减少重播分歧，并使重演分析更加可靠。

$ wrc mode=calibrate replaydir=/u01/app/oracle/db_replay_capture
...
Report for Workload in: /u01/app/oracle/db_replay_capture
-----------------------

Recommendation:
Consider using at least 1 clients divided among 1 CPU(s).

Workload Characteristics:
- max concurrency: 1 sessions
- total number of sessions: 3

Assumptions:
- 1 client process per 50 concurrent sessions
- 4 client process per CPU
- think time scale = 100
- connect time scale = 100
- synchronization = TRUE

注： 取自上面论文中的图片

国产数据库也会参考创建多个replay client, 但是重演的并发性、事务依赖性是否一致不得而知, 不过这可以自己在两端数据库跑不同的SQL, 验证最后的结果一致性。因为可能存在SQL转换失败、语法不支持、SQL执行效率(oracle有shared pool，可以共享SQL游标,达到1次解析多次执行，而其它库可能存在不同程度的SQL 解析效率影响)，影响“真实”应用负载重演的结果是否真实。有的客户就出现在oracle caputre 1小时负载，而在目标库5-6小时的dbreplay。希望结果的可靠度接近生产，不要成为一种形式。当然如果仅以该功能做为特性卖点宣传、亦或是提供客户的创新与专利的功绩、项目投标时的控标手段等目的，那技术将变得暗淡。

References
MOS 1536143.1  2980862.1 2930782.1

打赏

微信扫一扫，打赏作者吧～