孤傲小二~阿沐

孤傲小二~阿沐

关注
发信
关注(28)粉丝(399)

Oracle的学习心得和知识总结（二十八）|Oracle数据库数据库回放功能之论文二翻译及学习

注：提前言明 本文借鉴了以下博主、书籍或网站的内容，其列表如下：

Oracle的学习心得和知识总结（二十八）|Oracle数据库数据库回放功能之论文二翻译及学习-LMLPHP

文章快速说明索引

学习目标：

目的：接下来这段时间我想做一些兼容Oracle数据库Real Application Testing (即：RAT)上的一些功能开发，本专栏这里主要是学习以及介绍Oracle数据库功能的使用场景、原理说明和注意事项等，基于PostgreSQL数据库的功能开发等之后 由新博客进行介绍和分享！

学习内容：（详见目录）

1、Oracle数据库数据库回放功能之论文二翻译及学习

学习时间：

2023年08月20日 14:35:35

学习产出：

1、Oracle数据库数据库回放功能之论文二翻译及学习
2、CSDN 技术博客 1篇

注：下面我们所有的学习环境是Centos7+PostgreSQL15.0+Oracle19c+MySQL5.7

postgres=# select version();
                                   version                                   
-----------------------------------------------------------------------------
 PostgreSQL 15.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.1.0, 64-bit
(1 row)

postgres=#

#-----------------------------------------------------------------------------#

SQL> select * from v$version; 

BANNER									    BANNER_FULL 								BANNER_LEGACY									CON_ID
--------------------------------------------------------------------------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- ----------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production	    Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production	Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production		     0
									    Version 19.3.0.0.0


SQL>
#-----------------------------------------------------------------------------#

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.7.19    |
+-----------+
1 row in set (0.06 sec)

mysql>

摘要

Oracle Database Replay 提供了一种通过在测试环境中重现真实用户工作负载来测试数据库系统更改的新方法。它有助于识别软件或硬件升级、补丁或数据库参数、模式或数据更改后的潜在问题。可以以最小的开销捕获生产数据库系统的任何有趣的工作负载周期。捕获的工作负载可用于驱动测试系统，同时保持实际生产工作负载的并发性和负载特性。重放不依赖于任何其他软件，包括应用程序本身。它可靠地重现捕获的工作负载，以支持早期诊断和故障排除。在本文中，我们讨论了重放结果的分析，并引入了新的比较周期报告，该报告有助于对捕获及其重放的变化进行详细的性能比较。我们在涉及 Siebel 金融应用程序升级的案例研究中展示了它的有用性，其中数据库重放可识别升级后的性能问题并帮助纠正这些问题。

类别和主题描述符

H.2.m [数据库管理]：杂项

一般条款

管理、测量、绩效、验证。

关键词

数据库、捕获、重放、测试

介绍

在大多数企业中，任务关键型业务功能严重依赖于数据库系统。不断变化的技术环境使得数据库系统的用户有必要部署最新的技术以保持竞争力。

维护现代技术基础设施的工作可能会发生变化，从将数据库升级到新版本，到更改底层硬件或操作系统。当这些变化应用于关键任务环境时，即使经过最严格的测试，也常常会导致非常破坏性的问题。

测试的最大挑战之一是能够无问题地实施对生产数据库系统的任何更改。数据库重放通过允许生产质量工作负载驱动测试系统并重复测试更改直到所有问题得到解决来解决这一挑战。

数据库重放

数据库重放[3]首次使使用真实生产工作负载进行数据库测试成为可能。首先，它允许捕获（记录）应用程序工作负载，同时对性能影响最小。捕获的工作负载包含捕获期间向数据库发出的所有请求以及所有并发和事务信息。然后，可以使用捕获的工作负载来测试测试系统中的更改，然后再将其实施到生产中。Database Replay的主要贡献在于它可以准确地重现测试系统上生产工作负载的并发和负载特征。因此，在使用实际工作负载进行测试后，数据库管理员可以确信在生产数据库中实施更改时不会出现意外的回归。

Database Replay 是 Oracle 数据库系统的一部分，不需要任何其他软件。这极大地简化了测试环境的设置。更重要的是，它消除了对任何其他软件（包括应用程序本身）的依赖。因此，数据库重放可以针对新的 Oracle 数据库版本测试应用程序业务功能的数据库部分。

在本文中，我们概述了分析重放结果的四步程序，并引入了有助于分析的新比较周期报告。该报告比较两个时段（捕获到任意重放或同一捕获的任意两次重放）。它报告主要配置更改、重放分歧、资源使用情况、最重要的更改 SQL 语句以及许多其他重要的性能指标。

我们在真实的数据库升级测试中演示了数据库重放的用法，其中我们捕获 Oracle/Siebel 在线应用程序大约 90 分钟，并在升级后的数据库上重放它。初始重放速度要慢得多，报告显示原因是 SQL 语句由于某种原因在数据库升级后选择了不同的执行计划，并且运行速度非常慢。调整性能不佳的 SQL 语句后，重放的性能变得与捕获的性能相似。更值得注意的是，现有的负载测试工具无法发现问题。

相关工作

现有的测试工具和方法都没有利用真正的生产级工作负载。Microsoft SQL Server [5]和 Quest Benchmark Factory 都具有基于 SQL 跟踪基础结构的捕获和不协调重放功能。然而，它们重放孤立的会话，而没有数据库范围的结果一致性机制。 也就是说，重放期间的事务以与捕获时间不同的数据库状态开始，并以不同的顺序执行更新。 另一个主要问题是，在实践中，由于开销较高，在整个数据库上启用 SQL 跟踪是不可行的。

LoadRunner 性能测试工具[4]通过记录用户与应用程序前端的交互来针对测试系统生成人工负载。生成的跟踪被参数化并用于模拟任意数量用户的负载。大多数时候，捕获的工作负载仅包含生产工作流程的一小部分，因为捕获不是来自真实用户。因此，生成的请求是随机的，并且可能并不总是在数据库中做有用的工作。此外，它使得仅 RDBMS 的测试变得麻烦，因为它需要中间层和应用程序。

[2] 中描述了另一种用于测试数据库应用程序的工作负载生成方法，该方法使用应用程序代码和数据库模式作为输入来生成应用程序的用户输入以及用于彻底测试应用程序和数据库的数据。生成的工作负载用于驱动应用程序，以尝试实现广泛的代码覆盖率。[1] 中的工作提出了一种查询感知方法来生成测试数据库。它强调了测试查询在测试数据库上执行时产生所需的间歇性和最终结果的重要性。然而，生成的工作负载是合成的，只能模拟部分生产工作负载。

数据库重放是对 Oracle SQL 性能分析器 (SPA)[6]（另一个 Oracle 测试功能）的补充。SPA 将正在运行的 RDBMS 的应用程序 SQL 语句以及性能和计划信息捕获到 SQL 调优集中。然后，它使用捕获的 SQL 调优集在测试环境中执行各个语句，以发现潜在的性能回归。SPA 的目标是对特定 SQL 语句进行单元测试，并且不会重现整个工作负载。本文的结构如下：

  • 首先介绍数据库重放的概念
  • 然后详细介绍了如何分析重放结果
  • 然后再介绍了案例研究
  • 最后是结论

数据库重放

在本节中，我们简要回顾一下数据库重放。[3]更详细地讨论了数据库重放架构和操作。

捕获

信息系统通常包含两个不同的环境：生产系统和测试系统。生产系统是企业的生命线，肩负着服务于企业信息技术需求的重任。没有在测试系统上进行广泛测试，任何更改都不应应用于任何实时生产系统。

对于Oracle客户来说，测试产品变更的理想工作负载是他们将要运行的实际生产工作负载。使用Database Replay，用户需要选择一个感兴趣的常规业务操作时间段，找到足够的磁盘空间来存储捕获并开始捕获工作负载。捕获的工作负载作为操作系统文件存储在用户指定的目录下。已采取措施尽量减少对生产系统的影响。我们的测试显示，在TPC-C基准测试上，事务吞吐量仅降低了4.5%。从应用程序的角度来看，数据库继续正常运行。即使在捕获错误或耗尽磁盘空间的情况下，生产系统也不会受到影响。

在工作负载捕获期间，RDBMS服务器进程生成一个文件(捕获文件)，其中包含来自一个或多个数据库会话的工作负载。数据库会话是用户在登录和注销之间的一组交互。每个会话由连续的服务请求或数据库调用组成，例如SQL查询、对表的更新、提交、从大对象(LOB)读取的OCI命令等。捕获文件是遵循自描述可扩展格式的二进制文件。捕获文件中的数据也是与平台无关的，因此可以在64位Linux操作系统上运行的Oracle数据库上捕获工作负载，然后在32位Windows系统上重放。此外，该格式允许向后兼容性，确保任何捕获都可以在Oracle数据库的任何未来版本上重放。

可以使用工作负载过滤器的定义对捕获进行微调。用户可以通过在会话属性、用户id和其他特定于工作负载的属性上设置过滤器，指定他们希望在捕获的工作负载中排除或包含工作负载的哪一部分。用户可以指定捕获工作负载的时间，也可以手动停止捕获。捕获完成后，用户可以将捕获的工作负载移动到测试系统，在那里可以开始真正的测试。

重放

生产工作负载的重放旨在对测试系统上的 RDBMS 进行压力，以确定其配置是否适合生产环境。一般来说，任何类型的测试都包含 4 个不同的阶段：

  1. 设置测试系统
  2. 定义和生成测试工作负载
  3. 运行工作负载
  4. 分析结果

使用数据库重放时，可以消除耗时的步骤 2，因为所选的工作负载（生产工作负载）是用于测试的最佳工作负载，并且已明确定义：从生产系统捕获的实际应用程序工作负载。

在重放之前，测试数据库需要恢复到逻辑上与捕获开始时相同的状态。Oracle 提供了 RMAN、Data Guard 和闪回技术等工具来完成此任务。重放之前要完成的最后一步是工作负载捕获的处理(指的是：预处理)。这将创建重放同步和运行时重新映射所需的必要元数据，并且只需完成一次。然后，可以根据需要多次重放已处理的工作负载。

通过将捕获的工作负载发送到测试系统来执行重放。为此，我们使用一个特殊的可执行文件（工作负载重放客户端）来读取捕获的工作负载，将其转换为适当的请求并将其提交到数据库。如图 1 所示，工作负载重放客户端本质上是捕获期间出现的原始数据库客户端的替代。所需的重放客户端和主机的数量由捕获的工作负载的最大并发数决定，并且可以使用提供的实用程序进行估计。重放开始后，每个客户端都会被分配一部分工作负载，所有重放客户端生成的聚合工作负载将准确模拟生产工作负载，从而实现高度真实的测试。

Oracle的学习心得和知识总结（二十八）|Oracle数据库数据库回放功能之论文二翻译及学习-LMLPHP

当重放正在进行时，数据库仍然可以正常访问。所有可用的性能监视工具都可用于在重放期间监视数据库，并且可以与 重放 并行执行额外的工作负载以进一步加载服务器。重放可以随时停止，也可以运行直至完成，直到消耗掉捕获的工作负载。重放完成后，RDBMS 会生成报告，帮助确定重放的质量并比较捕获和重放的关键点。当数据库状态在每次重放之前适当恢复时，还可以使用相同的捕获工作负载重复执行重放。

使用数据库重放进行测试

在本节中，我们首先回顾允许数据库重放准确再现记录的工作负载的设计原则。然后我们介绍一个四步过程来分析重放结果。最后，我们讨论如何使用比较期间报告来评估重放并衡量变更的影响。

重放设计原则

为了确保重放期间生成相同的工作负载，数据库重放的设计遵循以下关键原则：相同的用户调用、相同的连接模式和相同的事务语义。

同一用户调用

对于来自工作负载捕获的每个记录的数据库调用，重放都会构造一个新的调用，其行为就像记录的调用一样。也就是说，它在影响数据库状态、最终结果和服务器组件使用方面应该在功能上等效。

工作负载重放客户端主要完成对记录的数据库调用进行逆向工程并将其发送到服务器的工作。由于客户端在捕获过程中使用的每个功能（无论协议如何）都可以通过等效的 Oracle 调用接口 (OCI) 命令来提供，而服务器中没有任何差异，因此重放客户端只需要支持 OCI 协议即可驱动工作负载。重放客户端还进行系统数据重新映射以提供相同的功能。记录的调用可能包含与机器相关的系统数据，例如 ROWID、光标编号、LOB 定位器和序列号，这些数据需要在重放期间正确修改。

每个工作负载重放客户端都是一个多线程应用程序，它为每个工作负载捕获文件生成一个线程（重放线程）。重放线程读取捕获的工作负载文件并将数据转换为对数据库的服务调用。重放线程通过在两个连续调用之间适当地休眠来维护捕获的计时特性。因此，每个重放线程都可以以记录的请求速率从捕获文件再现工作负载。请注意，出于测试目的，提供重放选项来更改请求速率。

相同的连接模式

对于来自工作负载捕获的每个记录的数据库连接，重放通过执行记录的登录和注销操作来维护类似的数据库连接。在重放期间应观察到相同的连接模式。

在重放期间，可以使用一台或多台主机来驱动工作负载捕获。每台主机可以启动一个或多个重放客户端。每个重放客户端可以生成多个重放线程。该架构提供了高可扩展性，能够再现繁重的工作负载，而不受操作系统限制、客户端机器容量或网络带宽的影响。数据库重放还提供了工具来估计给定工作负载捕获所需的重放客户端和主机的数量。通过这样做，可以在重放期间观察到相同的连接模式。同样，提供重放选项来更改登录率以进行测试。

相同的事务语义

由于没有人可以假设数据库将按顺序服务并发请求，因此仅通过发出具有相同时序特征的相同工作负载来维护正确的数据依赖性是不够的。服务器中处理顺序的微小差异可能会导致整个工作负载出现分歧，从而无法产生准确的测试。

为了实现真实的测试，数据库重放会维护捕获期间观察到的事务语义。重放期间的 RDBMS 以这样的方式安排重放调用，以便每个重放调用都像捕获期间一样对相同的数据快照进行操作。这是通过强制执行捕获期间观察到的提交顺序来完成的：每个请求仅在重放适当的提交后才允许执行。

同步机制在重放期间协调传入调用以重现相同的并发性，同时确保数据库状态不会偏离原始状态。与在数据库系统外部实施的解决方案相比，开销最小化。

通过提供相同的事务语义，数据库重放将自己与其他测试工具区分开来。据我们所知，没有其他数据库系统支持此类测试。设计原则解释了为什么数据库重放能够更可靠地重现问题。同一捕获的两次重放将生成相同的工作负载，并且与原始工作负载具有相同的时序、并发性和事务特征。

重放分析程序

虽然数据库重放使重现工作负载捕获变得更加容易，但分析重放结果变得更具挑战性。重放可能会遇到新的错误、数据分歧、性能回归和其他问题。其中一些是显而易见的，并且是由重放系统的更改直接引起的。但仍有一些分歧是由这些变化间接引起的。它们可能看起来不可预测，需要详细分析才能了解这是否是一个新问题。在这里，我们建议采用四步程序来评估重放实验。它遵循自上而下的策略，从高层分析开始，进一步深入到具体的分歧。

第 1 步：评估重放了多少工作负载

重放可能不会完成，并且仅完成工作负载捕获的子集。显然，用户可以在重放期间随时停止重放。如果未正确规划或配置，重放也可能会失败。例如，如果重放客户端驱动过多的工作负载并达到底层操作系统的限制（例如每个进程的最大线程数或文件句柄数），则重放客户端将退出并导致重放被取消。为了避免此类问题，数据库重放提供了校准功能来指导重放客户端的部署。

接下来我们检查工作负载是否已在连接connection级别重放。如前所述，我们的重放尝试保持相同的连接模式。连接重放可能会遇到严重问题，例如捕获的用户帐户在重放系统中不可用并异常退出。它不会取消重放，但重放将丢失连接中的其余工作负载。如果记录的连接的重放未到达终点，则会将其报告为重放会话失败并包含在重放报告中。

第 2 步：评估已重放的次数是否符合预期

在步骤 1 中，检查重放期间已向数据库发送了多少工作负载。重放记录调用并不意味着它完成了与捕获相同的工作。第 2 步的重点是在功能方面对重放质量进行高级概述。也就是说，有多少工作负载已按预期重放。

重放跟踪每个数据库调用的结果并报告两种类型的分歧：错误分歧和数据分歧。错误分歧是在重放期间观察到的错误，而在捕获期间未观察到的错误，或者是与捕获期间不同的错误。当重放的调用影响的行数与捕获期间影响的行数不同时，就会出现数据分歧。

重放后，分歧调用的百分比是重放质量的良好指标。良好的重放通常具有最小的差异或没有差异。另一方面，大量的分歧调用可能意味着部分工作负载未正确重放。

有时，由于环境变化，重放会出现偏差。例如，如果链接不再有效，则使用数据库链接database links重放调用将失败。对于重放质量的判断可能会因这种重放差异而产生偏差。此时，客户还可以使用自己的脚本来查看重放结果。例如，在线购物系统可能会在捕获和重放后检查已处理订单的数量，以验证重放期间有多少用户工作负载成功。

第3步：分析性能回归

如果重放通过了前两个步骤，我们可以确信重放的工作负载代表了良好的测试。下一步是比较性能并发现潜在问题。性能分析主要基于自动工作负载存储库（AWR）。它是性能数据的持久存储。数据库每小时从内存视图中读取系统和性能数据，并将其存储为 AWR 快照。数据库重放还会在工作负载捕获或重放的开始和结束时自动拍摄 AWR 快照。因此每次捕获和重放都包含一组 AWR 快照。然后可以使用 Oracle 性能工具（例如 AWR 报告、活动会话历史记录报告和自动数据库诊断监视器 (ADDM) 报告）完成性能分析。

第4步：分析调用分歧
我们可以进一步分析调用分歧是否存在潜在问题。重放分歧可能表明部分工作负载在重放期间失败。由于应用更改后生产系统中可能会发生同样的故障，因此我们应该进一步缩小范围并分析重放报告中发现的差异数据。

比较 重放与重放

在上一节中，我们讨论了如何将重放与其捕获进行比较。但是，我们应该注意，即使重放是在与捕获相同的数据库中完成的，重放性能也可能与捕获性能不完全相同。重放的最高优先级是重现工作负载捕获的功能。性能可能会略有变化。例如，当重放gate某些数据库调用时，活动会话的数量可能会减少，以便可以维护相同的事务语义。由于重放环境与生产系统不同，一些重放差异是不可避免的。

测试更改的最可靠方法是比较两次重放。第一次重放将尝试尽可能地模仿捕获的系统，而不对系统进行任何更改。第二次重放将与第一次重放类似，同时应用单个更改作为测试变量。然后通过比较两个重放来精确测量变化的影响。正如我们之前讨论的，重放非常容易设置，并且可以可靠地重现更改的影响。

比较期间报告

生产工作负载的捕获和重放会产生大量 AWR 性能数据。对于没有经验的用户来说，比较数据并发现回归问题需要花费大量的时间和精力。我们引入了比较期间报告compare period report来帮助进行重放结果分析。它会比较并生成捕获到重放比较报告，或重放到重放的比较报告。

捕获-重放Capture-Replay报告将工作负载重放的性能与原始捕获系统的性能进行比较。主要包含以下六个部分：

  • 一般信息部分描述了实验设置。它包含有关数据库、AWR 和时间段的信息，以及重要参数、优化器相关参数和下划线underscore参数。它可以帮助用户验证重放是否是预期的实验

  • 重放差异部分描述了重放与捕获的差异。它包含分歧的调用百分比并报告总体分歧级别。有四种可能的分歧水平：

  • 主要性能统计部分通过比较数据库时间 [3]、CPU 时间和用户 I/O 等待时间对两个时期进行高级性能比较

  • 按数据库时间变化排名靠前的 SQL 部分比较了单个 SQL 语句从一个时期到另一个时期的性能变化

  • 硬件使用情况比较部分描述了系统上的一般 CPU 使用情况，并帮助评估它们是否受 CPU 限制

  • ADDM 比较部分提供了两个时间段的 ADDM 分析的比较，按影响的绝对差异排序。通过比较两个时期的 ADDM 结果，有助于发现一个时期存在但另一个时期不存在的问题，以及个体发现影响的变化。

而 Replay-Replay 报告比较了同一原始工作负载捕获的两次工作负载重放的性能。它与捕获重放报告具有相同的部分。主要区别在于重放分歧部分。如果在两次重放中发现相同的分歧记录，则在Replay-Replay报告中它不再是分歧。比较期间报告将用于调试我们以下案例研究中的问题。

案例分析

在本节中，我们通过案例研究演示数据库重放如何帮助数据库测试。

背景

该案例是 Oracle 内部性能和测试小组的一次数据库升级活动。目标应用程序是运行金融呼叫中心服务的 Siebel 应用程序。它在金融呼叫中心创建了新的账户、机会和订单。它还在合作伙伴经理应用程序中创建和分配服务请求。升级测试测量了 Siebel 工作负载相对于新 Oracle 数据库的性能。目标是发现问题并及时修复以发布最终版本。

在Database Replay推出之前，升级测试是通过以下方式完成的：测试人员首先安装较新的数据库版本。然后，他们通过从旧版本的数据库备份（Oracle Database 10gR2）升级数据库来设置数据库。该应用程序采用典型的三层架构。下一步是在单独的计算机上设置 Siebel 中间层和 Apache Web 服务器。环境搭建完毕后，使用LoadRunner[4]进行驱动测试。

工作负载捕获

当数据库重放可用时，测试小组开始使用数据库重放来减少测试工作。他们的测试计划是从应用程序经过充分测试的 Oracle 数据库企业版 11.1.0.7 数据库捕获工作负载，并对升级到 Oracle 数据库企业版 11.2beta 的数据库进行重放。今后我们将 Oracle 数据库的两个版本称为 11.1.0.7 数据库和 11.2beta 数据库。重放用于确定 11.2beta 数据库相对于 Siebel 数据库工作负载是否存在任何性能下降。

捕获是在运行 Red Hat Enterprise Linux 4 的四 CPU 计算机上完成的。部署了四个中间层来运行 Siebel 应用程序服务器和 Apache Web 服务器。在捕获过程中，工作负载运行了 700 个金融呼叫中心用户和 600 个合作伙伴经理用户 90 分钟。

通过重放调试 SQL 回归

工作负载捕获于 2008 年底完成。我们于 2009 年 3 月开始使用 11.2beta 数据库测试升级。为了使性能比较更加准确，所有重放都使用工作负载捕获中的相同主机。

由于我们需要运行多次重放以进行调试，因此我们决定打开存档日志记录并在数据库成功升级后立即创建一个还原点。目的是使重放数据库的设置变得容易。所需要做的就是在每次重放之前将数据库闪回到恢复点。

Oracle 11.2beta 数据库上的第一次重放花了近四个小时才完成了两小时的捕获。比较期间报告表明重放期间出现 SQL 回归。从 DB 时间变化的 Top SQL 来看，ID 为 44u0kwtwmd7h5 的 SQL 的 DB 时间从 90 秒增加到 10409 秒。在重放期间，产生了不同的执行计划，导致 SQL 执行速度明显变慢。由于每次重放时都会重现该问题，因此开发人员能够快速查明优化器中的问题。对于 LoadRunner，问题是间歇性的，并且很难重现，因为负载测试工具生成的工作负载在执行之间通常不一致。

为了解决这个问题，我们调整了回归 SQL 并导出了相应的 SQL 配置文件。然后我们将数据库闪回到还原点，导入 SQL 配置文件，并开始新的重放。如表 1 所示，回放 II 时回归消失，并且回放所花费的时间与捕获的时间几乎相同。

其他重放

我们重放了 11.1.0.7 数据库的工作负载，以验证它是否也具有相同的 SQL 回归。结果可以在表 1 的 Replay III 中找到。比较期报告显示，重放与捕获非常相似。因此我们知道 Oracle 11.1.0.7 数据库中不存在该问题。

我们还使用重放测试来检查其他更改的行为。存档注销重放用于测量存档日志记录的开销。如表 1 中的 Replay II 和 Replay IV 所示，两次运行的数据非常相似。归档所有联机重做日志时，预计用户 I/O 等待时间会增加。

概括

我们通过案例研究演示了数据库重放如何帮助数据库测试。数据库重放为 Siebel 等工作负载提供了更好的测试。在调试时可以轻松设置、重放、重现问题，并通过微小的更改来测量性能。

该案例研究可以轻松扩展以测试客户的关键业务工作负载。该测试可帮助客户检测测试环境中潜在的 SQL 回归或其他问题。如有必要，测试可以完全自动化。

结论

在当今快速发展的 IT 环境中，变化是不可避免的，但对于数据中心经理和管理员来说，这并不一定很困难。数据库重放使测试系统能够承受生产质量工作负载。变化的确切结果是可以肯定地预测的。可以高度自信地快速评估变化，并在生产系统受到负面影响之前采取纠正措施。据我们所知，没有其他数据库供应商提供接近真实测试的工具。

参考

[1] C. Binnig, D. Kossman, E. Lo, M.T. Özsu. QAGen: generating query-aware test databases. ACM SIGMOD international conference on Management of data 2007
[2] M. Emmi, R. Majumdar, K. Sen. Dynamic test input generation for database applications. International symposium on Software testing and analysis 2007.
[3] L. Galanis and etc. Oracle Database Replay. ACM SIGMOD international conference on Management of data 2008. 1159-1170.
[4] HP LoadRunner. http://www.hp.com.
[5] SQL Server Profiler, RDBMS Documentation, http://msdn.microsoft.com.
[6] K. Yagoub, P. Belknap, B. Dageville, K. Dias, S. Joshi, and H. Yu. Oracle’s SQL Performance Analyzer. IEEE Data Engineering Bulletin. March 2008 Vol. 31 No. 1

Oracle的学习心得和知识总结（二十八）|Oracle数据库数据库回放功能之论文二翻译及学习-LMLPHP

08-25 07:51
Powered by LMLPHP ©2024 孤傲小二~阿沐 0.007790