做网站哪家服务器好,电子商务网站建设及维护,网站管理建设落实报告,wordpress付费主题分享目录结构 注#xff1a;提前言明 本文借鉴了以下博主、书籍或网站的内容#xff0c;其列表如下#xff1a; 1、参考书籍#xff1a;《Oracle Database SQL Language Reference》 2、参考书籍#xff1a;《PostgreSQL中文手册》 3、EDB Postgres Advanced Server User Gui… 目录结构
注提前言明 本文借鉴了以下博主、书籍或网站的内容其列表如下 1、参考书籍《Oracle Database SQL Language Reference》 2、参考书籍《PostgreSQL中文手册》 3、EDB Postgres Advanced Server User Guides点击前往 4、PostgreSQL数据库仓库链接点击前往 5、PostgreSQL中文社区点击前往 6、Oracle Real Application Testing 官网首页点击前往 7、Oracle 21C RAT Testing Guide点击前往 8、Oracle Database 19cReal Application Testing Overview点击前往 9、数据库回放白皮书 11g点击前往 10、论文四 原文Consistent Synchronization Schemes for Workload Replay 1、本文内容全部来源于开源社区 GitHub和以上博主的贡献本文也免费开源可能会存在问题评论区等待大佬们的指正 2、本文目的开源共享 抛砖引玉 一起学习 3、本文不提供任何资源 不存在任何交易 与任何组织和机构无关 4、大家可以根据需要自行 复制粘贴以及作为其他个人用途但是不允许转载 不允许商用 写作不易还请见谅 Oracle数据库数据库回放功能之论文四翻译及学习 文章快速说明索引摘要1. 介绍2. 一致的同步2.1 不一致的类型2.2 一致的同步方案2.3 一致方案的范围2.3.1 总排序2.3.2 基于提交依赖的排序2.3.3 基于对象依赖关系的排序2.3.4 基于碰撞依赖的排序2.3.5 使用更细粒度对象的研究 3. 高效实施3.1发现依赖关系3.2 实施细节 4 实验评价5. 相关工作6. 结论7. 引用 文章快速说明索引
学习目标
目的接下来这段时间我想做一些兼容Oracle数据库Real Application Testing (即RAT)上的一些功能开发本专栏这里主要是学习以及介绍Oracle数据库功能的使用场景、原理说明和注意事项等基于PostgreSQL数据库的功能开发等之后 由新博客进行介绍和分享 学习内容详见目录
1、Oracle数据库数据库回放功能之论文四翻译及学习 学习时间
2024年02月07日 09:54:26 学习产出
1、Oracle数据库数据库回放功能之论文四翻译及学习 2、CSDN 技术博客 1篇 注下面我们所有的学习环境是Centos7PostgreSQL15.0Oracle19cMySQL5.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 0Version 19.3.0.0.0SQL
#-----------------------------------------------------------------------------#mysql select version();
-----------
| version() |
-----------
| 5.7.19 |
-----------
1 row in set (0.06 sec)mysql摘要
Oracle Database Replay 最近在 Oracle 11g 中引入作为测试关系数据库系统的新颖工具 [9]。它包括记录生产系统中数据库服务器上运行的工作负载然后在测试系统中的数据库服务器上重放它。工作负载重放的一个关键功能是同步 synchronization它可以真实地再现真实的工作负载。它是一种对构成工作负载的重放请求 强制执行特定排序 的机制。与捕获的工作负载相比它会影响请求并发级别以及重放结果的一致性。在本文中我们定义了一致重放同步方案的类别并首次研究了它们涵盖的范围以及它们所呈现的权衡。我们将迄今为止提出的唯一方案 [9]在 Oracle 11g Release1 中实现的方案置于上述范围内并表明它是粗粒度的并且比必要的限制更多通常会强制独立调用之间的依赖关系。
通过强制执行不必要的等待它会降低可能的并发级别并降低性能。为了克服这些缺点我们确定了范围内的最佳方案它比同类产品的粒度更细并且在不同的权衡之间取得了适当的平衡它对重放的调用强制执行部分排序从而最大限度地减少所需的等待次数并最大化并发级别而不会影响重放结果的一致性。我们在 Oracle 11g 第 2 版中实施了这一新方案。我们的实验表明对于主要的工作负载类别它比现有方案能产生更好的质量重放。
1. 介绍
中国有句老话“好客不换店好店不换客”这表明即使是对运作良好的东西进行微小的修改通常也是有风险的。这句话所表达的常识体现在当涉及到大规模信息系统的变化时坚决不情愿。
虽然安全但这种保守和谨慎的做法阻碍了发展。需要进行更改以保持信息系统的最新性和竞争力因此需要进行广泛的测试以降低相关风险。通常更改首先在测试系统上实施并通过回归和压力测试进行验证。最后在成功结束所有测试后更改也会在生产系统上实施。测试的质量决定了将变更应用到生产系统后出现的问题的严重性和数量。执行大部分生产代码并在测试系统上产生实际负载的测试在为时已晚之前发现问题的成功率更高。
不幸的是生成适当的合成工作负载来测试大规模应用程序是一个非常困难的问题[10]。尝试使用手动编写或工具生成的脚本或模拟模型来模拟生产系统场景已被证明是不充分、耗时且基本上无效的[9]。理想的情况是让测试系统承受实际的生产工作负载。在数据库系统上重放真实的工作负载可以对大规模数据库应用程序进行此类测试。我们将使用术语 数据库重放 或 工作负载重放 来描述此类测试。 数据库重放最初是在 Oracle 11g [9] 中引入的。图 1 概述了其工作原理。生产系统中的数据库服务器上运行的真实工作负载出现在图的左侧以最小的开销记录最好是在高峰时段。记录的工作负载以下也称为捕获的工作负载随后在测试系统的数据库服务器上重放显示在图的右侧。重放这种真实的、通常很重且高度并发的工作负载对于测试目的具有巨大的潜力包括回归和压力测试、调试和容量规划。
捕获的工作负载存储在多个捕获文件中。一个捕获文件对应于在生产系统上捕获期间处于活动状态的单个数据库连接。它存储通过相应连接在数据库服务器上发出的调用列表 the list of calls。重放工作负载涉及启动足够数量的客户端进程这些进程读取适当的捕获文件并通过相应的连接在测试数据库服务器上发出记录的调用。目标是在重放期间重新创建与捕获期间相同数量的用户。
由于存在多个用户在数据库服务器上同时发出调用因此能够真实再现真实工作负载的数据库重放的一个关键功能是同步即对构成工作负载的重放调用强制执行特定排序的机制。所采用的同步方案强烈影响重放的以下重要属性
请求并发对来自不同重放客户端的特定调用强制排序不可避免地会导致等待。因此它影响并发性。结果一致性重放期间数据提交和查询的顺序决定了重放数据库中返回或更新的数据。因此重放的请求可能在完成的工作方面与捕获时的对应请求有所不同。
所有广泛使用的数据库管理系统DBMS都实现了一些并发控制机制来保证数据库的完整性[61317]。这些机制中的大多数包括两相锁定2PL及其变体都是基于可串行性理论构建的[6]。这种机制确保它们生成的调度是可序列化的即与由相同事务组成的串行调度等效(在串行计划中事务在时间上不会重叠)。如果两个调度的单独调用读取和写入的值相同则这两个调度是等效的。请注意等效schedule可以是任何串行schedule。
不采用重放同步方案只根据客户端的时间在重放期间简单地依赖并发控制机制来同步调用这允许高并发性类似于捕获期间的并发性但会导致不一致的结果即当调用争夺资源时结果不确定。换句话说调用分歧并且重放的工作负载看起来不再像捕获的工作负载因为重放调度相当于任意串行调度而不一定相当于捕获期间并发控制机制生成的调度。
另一方面如果用于重放同步的方案对捕获的调用施加总排序例如在捕获期间严格遵循这些调用的执行顺序则重放期间返回或影响的数据将是一致的即 与捕获期间相同但与实际捕获的工作负载相比工作负载的并发性将非常低因为重放的工作负载本质上是序列化的。
理想的同步方案必须位于这两个极端之间。它应该对调用强制执行一些部分排序以保证一致性同时还允许良好的并发潜力。请注意重放同步方案不执行传统的并发控制因为它的目标是重放一致性而不是数据库完整性。因此在本文的其余部分中我们将理所当然地认为 DBMS 实现了一些额外的并发控制机制 [6, 13,17]。此外我们将假设该机制提供快照隔离[6]这是几乎所有广泛使用的 DBMS 都支持的属性。
在之前的工作 [9] 中提出了一种实用的同步方案该方案对重放的请求强制执行部分排序从而允许合理的并发级别而不会出现数据分歧。在本文中我们的目标是形式化现有重放同步方案的特征发现新方案并提名最佳方案。下面我们总结了我们的主要贡献 一致方案的范围 ( Spectrum of consistent schemes)我们首次研究一致重放同步方案的范围。捕获和重放之间的结果一致性非常重要因为它允许我们验证重放的工作负载是否与捕获的工作负载执行相同的工作。 现有方案在频谱中的位置 (Position of existing scheme within the spectrum)我们找到了迄今为止提出的唯一用于重放同步 [9] 的方案在上述频谱中的位置并表明它是粗粒度的并且比必要的限制更多强制独立调用之间的依赖关系 。不必要的依赖关系可能会因等待时间增加而导致重放并发性降低。 高级方案的定义 ( Definition of an advanced scheme)当前的重放同步方案虽然在一些实际应用中足够但仍有改进的空间。在本文中我们提出了一种更细粒度的方案可以在不同的权衡之间取得适当的平衡。它生成一个强制执行部分排序的计划从而最大限度地减少来自不同客户端的调用之间所需的等待次数并最大限度地提高并发级别而不会影响重放一致性。我们的先进方案产生限制最少的调度该调度仍然与捕获期间并发控制机制产生的调度等效。正如我们下面所解释的它通过使用也在冲突可串行性理论中定义的一些类似的概念例如冲突依赖的概念和构造例如依赖图来实现这个目标[6]。 但是它将它们用于不同的目的确保重放一致性而不是事务可串行性 to ensure replay consistency rather than transaction serializability.。 高效实现 ( Efficient implementation)我们讨论了在数据库重放中有效实现一致同步方案的一些想法。我们的方法适用于已识别spectrum的所有方案而不仅仅是高级方案。 实验评估 (Experimental evaluation)我们在 Oracle 11g 第 2 版中实现了新方案。我们针对前一个方案对其进行了实验评估并展示了结果。
本文的其余部分组织如下在第 2 节中我们研究一致同步方案的范围。在第 3 节中我们描述了先进方案的有效实施。在第 4 节中我们介绍了实验评估的结果。在第 5 节中我们回顾了相关工作。最后我们在第 6 节中进行总结。
2. 一致的同步
例行测试任何更改 都涉及 在测试系统上 运行某种形式的应用程序工作负载 并 验证正确性和性能。在数据库重放中使用真实的工作负载因此可以通过比较两组结果来实现验证在测试系统上运行捕获的工作负载的结果和在生产系统上运行相同工作负载时记录的原始结果。
为了使这种比较有意义数据库重放必须保证重放工作负载的某些明确定义的行为否则无法基于使用真实工作负载的事实进行验证。我们使用术语 重放一致性 来描述这种定义明确的行为。定性地讲重放一致性意味着对数据库的每个重放请求必须执行与捕获期间相同的工作并操作相同的数据。只有这样才能比较捕获和重放的性能。
受到重放结果一致性重要性的启发在本节中我们研究重放期间可能发生的不一致类型并定义一致性重放同步方案的类别。然后我们确定这些方案涵盖的范围。最后根据该spectrum点的特性我们引入了一种用于工作负载重放的高级同步方案。
2.1 不一致的类型
让我们首先关注重放不一致的根源。它们也在其他地方进行过讨论[9]在这里我们对它们进行分类以帮助我们开发新的方法。首先我们必须假设捕获开始时的初始数据库状态与重放开始时的初始状态相同因为从任意状态开始实际上永远不会得到一致的结果。
该状态仅包括用户数据并且对布局、索引、模式或任何其他物理数据库特性没有任何假设。
通过使用 DBMS 的标准功能例如导出/导入或备份/恢复来满足此要求相当简单。
做出上述假设后我们可以根据相关结果的差异来源来识别两种类型的重放不一致系统性和随机性(systematic and random)。我们在下面定义它们并随后给出一些示例 系统不一致 (Systematic inconsistency)当两个 依赖于冲突(collision-dependent) 的调用之间的相对顺序发生变化时这种类型的不一致以可再现的方式出现。假设DBMS保证快照隔离[6]如果(a)至少其中一个调用通过提交一些更改修改了数据库的状态并且(b)两个调用都访问至少一个共同的数据库对象则两个调用是冲突相关的。为了简单起见除非另有说明否则我们可以认为数据库对象仅仅是一个数据库表因为我们关注的是关系数据库。对于更复杂的对象例如视图我们假设它们总是可以被分析到定义它们的基表。最后对于细粒度类型的数据库对象(例如块和行)需要更多的注意。我们将在2.3.5节详细介绍它们。 随机不一致(Random inconsistency)当调用取决于与运行时状态相关的某些值或条件时这种类型的不一致会以任意巧合的方式出现。通常导致随机不一致的调用是使用系统日期和时间的调用或生成并使用随机数的调用。 示例1系统不一致这里我们描述一个极端的、想象的情况仅供说明之用。假设一家拥有 1,000,000 名美国员工的大型公司遭受了重大金融危机的打击。想象一下公司财务主管执行如下所示的查询 Q1以了解有多少美国员工为该公司工作以及他们的平均工资是多少。假设 DBMS 在相当长的时间例如 1 秒后响应因为它评估超过一百万行的两个聚合函数计数和平均值并返回以下结果1,000,000, $60,000。基于这一结果公司首席执行官决定将除她本人之外的所有员工外包到印度。为此她执行查询 Q2。
Q1: select count(*), avg(salary) from emp where country‘USA’;
Q2: update emp set country‘India’ where country‘USA’ and job title‘CEO’;为了便于说明我们假设 Q2 自动提交其更改。在这种情况下我们可以很容易地看出 Q1 和 Q2 是冲突相关的因为 (a) Q2 通过更改表 emp 来修改数据库的状态并且 (b) 它们都访问相同的数据库对象表 emp。
此外假设数据库管理员正在计划对公司的系统进行更改例如升级 DBMS 版本但首先他想要测试其对由 Q1 和 Q2 组成的工作负载的影响。为此他在测试数据库上重放工作负载。重放期间执行 Q1 和 Q2 有两种可能的顺序Q1→Q2 和 Q2→Q1符号“→”表示 先行。回想一下第一个排序Q1→Q2是在捕获期间在生产系统上使用的。我们假设同步方案在重放期间选择第二个Q2→Q1。
Q2 执行后表 emp 只存储一行对应于一位美国员工即 CEO。在 Q2 之后执行 Q1 返回 1$600,000假设 $600,000 是 CEO 的工资。此结果与 Q1 之前的捕获期间的结果不同。此外在重放期间Q1 结果的计算变得微不足道因为聚合函数在单行上运行而不是像捕获期间那样在一百万行上运行。因此在重放期间考虑到 emp 上的一些适当索引Q1 的响应时间必须快几个数量级例如 0.01 秒。显然速度的提升不能归因于 DBMS 的升级。
总而言之对两个依赖于冲突的调用使用不同的顺序会在捕获和重放之间产生系统不一致。正如预期的那样结果不同。工作也不同因此重放性能不能用作测试的更改将对生产系统产生什么影响的指标。 示例2随机不一致想象一下示例1的公司在2010年的财务状况有所恢复因此10 月份雇用了 100,000 名新员工但 2010 年没有再雇用员工。当年 10 月份首席执行官执行了如下所示的第三季度以查看该月的新员工数量。在 Q3 中函数to_char 将日期转换为具有某种给定格式的字符串h_date 是表 emp 的一列用于存储员工的雇用日期sysdate 是返回系统日期的函数。假设Q3的结果为100,000其响应时间为0.5秒。
Q3: select count(*) from emp where to char(h date,‘mmyyyy’)to char(sysdate,‘mmyyyy’);下个月重放包含 Q3 的工作负载会产生与 Q3 不同的结果0因为 10 月之后没有新员工招聘。此外在这次重放期间Q3 的响应时间要快得多比如 0.01 秒因为聚合函数 count 对空行组进行操作。在这种情况下由于随机不一致而发生了分歧因为 Q3 的结果取决于运行时的状态在本例中为 sysdate 返回的日期。
2.2 一致的同步方案
在上一小节中研究了重放不一致的根源之后在本小节中我们定义了用于工作负载重放的一致性同步方案类别。
让我们首先关注系统性的不一致。显然它在重放期间的发生在很大程度上取决于所采用的同步方案因为系统不一致的根源是冲突相关调用的顺序发生变化。因此一致的重放同步方案的最低要求是确保冲突相关的调用始终以与捕获期间相同的顺序重放以防止系统不一致。请注意此顺序是由捕获期间在生产系统上运行的并发控制机制的调度所决定的。
现在让我们关注随机不一致。很容易观察到这种不一致是某些捕获的调用的类型所固有的这些调用取决于运行时的状态如上所述。由于它归因于这些调用的性质而不是它们的顺序因此同步无法解决相应的问题。为此目的需要一些与所采用的同步方案正交的附加机械。总之解决随机不一致问题就是关联和再现随机结果。
现有技术[9]通过捕获取决于生产系统的运行时状态的真实值例如调用Q3的sysdate的结果然后使用这些记录的值来替换回放期间基于测试系统的运行时间状态生成的值从而避免了这种情况。
在本文中我们将理所当然地认为随机不一致不存在因为我们的重点是同步方案并且与它们正交的技术可以很好地解决它。
根据上面的观察我们可以很容易地推断通过避免系统和随机不一致的工作负载重放遵循与捕获期间执行的调度相同的调度因为这样的重放保留了依赖于冲突的调用的相同顺序并消除了所有可能的分歧源。 在了解了一致同步方案应该如何表现之后我们给出了它们的正式定义。我们从一些在整篇论文中都会用到的符号开始
设S表示给定工作负载中所有调用的集合设a, b∈S是其中两个调用此外假设存在以下谓词如果在捕获期间a在b之前执行则precedes(a, b)返回true否则返回falseCommit (a)返回true如果通过提交一些更改来修改数据库状态否则返回falseAccess common object(a, b)如果a和b共同访问数据库对象则返回true否则返回falsemust wait(a, b)如果a必须等待b完成才能重放a则返回true否则返回false
最后让我们定义以下集合 显然以下关系对于这些集合成立
Spre⊇Scom⊇Scol, and Spre⊇Sobj⊇Scol为了解释我们的符号让我们举一些例子。假设某个捕获的会话 Y 包含五个调用Y1-Y5图 2。横轴表示时间因此在捕获期间Y1 在 Y2 之前执行Y2 在 Y3 之前执行依此类推。此外假设三种类型的调用选择、更新和提交分别用字母 S、U 和 C 表示。为了更好地区分提交调用和非提交调用我们对前者使用灰色例如 Y3对后者使用白色例如 Y1。每个调用都对一组对象进行操作由字母 S、U 或 C 后面的下标表示。例如Y1 从对象 2 选择一些结果Y2 更新对象 3而 Y3 提交对对象 3 的更改。
In our example, precedes(Y2, Y5), commit(Y3), and access common object(Y2, Y3) return true, but precedes(Y4,Y1), commit(Y1), and access common object(Y1, Y3) false. 最后各种集合的元素如下
S{Y1, Y2,Y3, Y4, Y5},Spre{(Y1, Y2), (Y1, Y3), (Y1, Y4), (Y1, Y5),(Y2, Y3), (Y2, Y4), (Y2, Y5), (Y3, Y4), (Y3, Y5), (Y4, Y5)}Scom{(Y1, Y3), (Y1, Y5), (Y2, Y3), (Y2, Y5), (Y3, Y4),(Y3, Y5), (Y4, Y5)}, Sobj{(Y1, Y4), (Y1, Y5), (Y2, Y3),(Y4, Y5)}Scol{(Y1, Y5), (Y2, Y3), (Y4, Y5)}使用我们的符号我们可以正式定义一致的重放同步方案如下所示。
定义一致性规则 consistency rule一个重放同步方案是一致的如果满足一致性规则
∀(a, b) ∈ S2((a, b) ∈ Scol ⇒ must wait(b, a)) 2.3 一致方案的范围
从概念上讲工作负载重放的一致性同步方案的主要工作如下给定一对调用(a, b)∈S2它必须决定其中一个是否必须等待另一个完成以保证一致性。
有三种可能的互斥决策
Decision 1: must wait(a, b)
Decision 2: must wait(b, a)
Decision 3: (¬must wait(a, b)) ∧ (¬must wait(b, a))如下所示根据做出上述决策的策略的严格或宽松程度我们可以将同步方案放置在一致方案范围内的相应位置。 图 3 直观地展示了该范围。当我们在其中从左向右移动时我们从更严格的计划转向更宽松的计划因此重放并发水平朝这个方向增加。最严格的方案左侧对构成工作负载的所有调用强制执行总排序。较宽松的方案会根据提交、对象或冲突依赖性强制执行某些部分排序。实际上部分排序意味着可以同时发出两个或多个调用而不必担心它们会在执行的工作类型方面相互影响。他们可能会争夺DBMS资源这是我们需要测试的方面之一。下面我们讨论频谱的不同点。
为了更好地解释范围内不同点之间的差异让我们扩展图 2 的运行示例并假设我们已捕获在生产系统上运行的三个并发会话即 X、Y 和 Z图 4a。然后图 4(b)-4(e) 显示了使用不同同步方案重放这些会话的示例。我们在下面提供更多详细信息。 2.3.1 总排序
在构成捕获的工作负载的所有调用中强制执行特定的总排序与捕获期间发生的排序完全相同是避免系统不一致的最直接方法。通过在重放期间保留所有调用的原始顺序基于全排序的同步方案保证它还保留冲突相关调用的顺序因此它是一致的。
形式上此类方案强制执行总排序规则
∀(a, b) ∈ S2((a, b) ∈ Spre ⇒ must wait(b, a)).
由于 Spre ⊇ Scol如果 (a, b) ∈ Scol则 (a, b) ∈ Spre。因此通过强制执行全排序规则此类同步方案也间接强制执行一致性规则。因此它是一致的。
在我们的运行示例中如果捕获的工作负载是图 4(a) 中的工作负载则基于全排序的同步方案可能会生成如图 4(b) 中所示的重放工作负载。如果我们比较这两个工作负载我们可以观察到尽管某些调用在重放期间发生了时间转移但它们的顺序仍然保持不变。
尽管一致但基于全序的同步方案对于重放并发来说限制太大。实际上由于在每对调用之间强制执行特定的顺序因此这是可能的最严格的方案。此属性解释了为什么它出现在图 3 频谱内的第一个位置左侧。例如在图 4(b) 的示例中调用 X2 由于某种原因在重放期间延迟执行。不幸的是基于全排序的同步方案必须将此延迟传播到所有后续调用以便保留指定的排序。因此即使调用 Z1、Y2 以及它们的所有后续调用其中大部分与 X2 是冲突无关的也必须等到 X2 完成。尽管这种同步方案保证了一致性但它不允许实现实际的并发性。它仅用于说明目的。 2.3.2 基于提交依赖的排序
在描述了最严格的极端情况基于全排序的方案之后让我们继续讨论更宽松的方案。强制执行某些部分排序的有前途的候选方案可以基于提交依赖性。该方案在 Oracle 11g 中可用并且已在其他地方提出过 [9]。利用任何一对非提交调用都不会依赖于冲突的特性基于提交依赖性的方案不会在非提交调用之间强制执行特定的顺序。另一方面如果至少有一个调用通过提交一些更改来修改数据库的状态它会在两个调用之间强制执行特定的顺序。
正式地此类的方案强制执行提交依赖规则
∀(a, b) ∈ S2((a, b) ∈ Scom ⇒ must wait(b, a)).
由于 Scom ⊇ Scol如果 (a, b) ∈ Scol则 (a, b) ∈ Scom。因此通过强制执行提交依赖规则此类同步方案也间接强制执行一致性规则。因此它属于一致方案的范围图 3。
在我们的运行示例中如果捕获的工作负载是图 4(a) 中的工作负载则基于提交依赖性强制排序的同步方案可能会生成如图 4© 中所示的重放工作负载。在此示例中我们可以观察到两个连续提交调用灰色圆圈之间的非提交调用白色圆圈之间没有特定的顺序。此属性允许更多的自由因此在提交调用之间的时间段内实现了更好的并发级别。例如在图 4© 中调用 X2 在重放期间再次延迟执行。
图 4(b) 中也发生了同样的情况。不同的是这一次Z1 不必等待因为它们都是非提交调用。因此Z1 和 X2 在重放期间已重新排序。由于它们是碰撞无关的因此这种重新排序不会损害一致性。请注意类似的重新排序出现在两个提交调用之间的多个非提交调用中。在图 4© 的示例中这包括调用 Y2 和 Z3以及 Y4 和 Z4。
据我们所知基于提交依赖性强制排序的同步方案是现有文献中迄今为止提出的唯一重放同步方案[9]。它可能比使用总排序的更松散这解释了为什么我们将它放在图3的第二个位置但它仍然比必要的更严格因为它在决定它们的排序时没有考虑到一对调用访问的数据。因此如果这些调用中至少有一个修改了数据库状态则它会在访问完全不相交的数据集的调用之间强制执行等待尽管此类调用是与冲突无关的。例如在图 4© 的示例中同步方案将在以下调用对之间强制执行等待因为至少其中一个调用提交了一些更改
must wait(Z2,X2), must wait(Z2, Y1), must wait(Z4, X3). 在此示例中上述调用是与冲突无关的。通过强制执行不必要的等待此类方案仍然可能会降低并发性和重放性能。
2.3.3 基于对象依赖关系的排序
遵循与基于提交依赖性的方案之一类似的一些逻辑基于对象依赖性的方案形成另一类方案其在构成捕获的工作负载的调用之间强制执行某些部分排序。他们利用的特性是其成员访问不相交的对象集的任何调用对都是冲突无关的。因此基于对象依赖性的方案从不强制执行此类调用对之间的特定顺序。另一方面如果这些调用至少访问一个共同的数据库对象它们会在两个调用之间强制执行特定的顺序。
正式地此类的方案强制执行对象依赖规则
∀(a, b) ∈ S2((a, b) ∈ Sobj ⇒ must wait(b, a)).
由于 Sobj ⊇ Scol如果 (a, b) ∈ Scol则 (a, b) ∈ Sobj 。因此通过强制执行对象依赖规则此类同步方案也间接强制执行一致性规则。因此它是一致的。
在我们的运行示例中如果捕获的工作负载是图 4(a) 中的工作负载则基于对象依赖性强制排序的同步方案可能会生成图 4(d) 中的重放工作负载。在此示例中我们可以观察到访问不相交的数据库对象集的调用之间没有特定的顺序。与全排序相比此属性允许更多的自由度因此可以实现更好的并发级别因为它避免了一些不必要的延迟。例如在重放期间图 4(d)虽然调用 Y1 和 X1 由于某种原因延迟开始但这种延迟并没有影响调用 Z1 和 Z2它们现在已成为第一个执行的调用。在重放期间可以将 Z1 和 Z2 与 X1 和 Y1 重新排序因为前一组调用访问对象 3而后一组调用分别访问对象 1 和 2。因此基于对象依赖的方案永远不会在它们之间强制等待。在我们的示例中对于其他冲突无关调用对例如 Z4 和 X3以及 Z3 和 Y3也可以进行类似的重新排序。
使用基于对象依赖的排序的同步方案可能比使用总排序的同步方案更宽松这解释了为什么我们将其放在频谱的右侧(图3)但它仍然比必要的更严格因为它在决定提交和非提交调用的排序时不区分它们。因此即使在非提交调用之间如果它们访问共同的对象它也会强制执行等待尽管它们是冲突无关的因此它会产生一些不必要的等待只读依赖项。例如在图 4(d) 中同步方案在以下调用对之间强制执行等待只是因为它们访问共同的对象must wait(X2,Y1)、must wait(Z3, X2)。上述调用是非提交的因此与冲突无关。通过强制执行不必要的等待此类方案仍然会降低并发性并降低重放性能。
当要比较基于提交依赖性的重放同步方案和基于对象依赖性的重放同步方案中哪一种更严格时答案取决于给定工作负载的属性。更详细地说哪一个更严格取决于相应集合的大小之间的关系即 |Scom| 和|Sobj|。集合包含的元素越多相应的同步方案必须执行的等待时间就越长因此就越严格。例如如果对于给定的工作负载 |Scom| |Sobj |那么基于提交依赖的方案对于该工作负载来说更加严格。根据观察在一般情况下我们无法知道两者之间哪个方案更严格在图3中我们将基于提交依赖关系强制排序的方案与基于对象依赖关系强制排序的方案放置在横轴上的相同坐标上。 2.3.4 基于碰撞依赖的排序
到目前为止我们提出的所有同步方案都比必要的更严格因为它们强制在冲突无关的调用对之间强制等待。基于冲突依赖的方案通过直接执行一致性规则第 2.2 节克服了这个缺点。
在我们的运行示例中如果捕获的工作负载是图 4(a) 中的工作负载则基于冲突依赖性强制排序的同步方案可能会生成图 4(e) 中的重放工作负载。在此示例中我们可以观察到调用 Y1捕获期间的第一个调用由于某种原因在重放期间延迟。然而在它之前已经执行了大量其他调用而无需等待它X1、X2、Z1、Z2 和 Z3。如果排序基于提交依赖性则 Z2 必须等待。如果排序基于对象依赖性则 X2 和 Z3 必须等待。然而此类方案不会遇到这些问题因为它强制要求最少的等待次数即仅在与冲突相关的调用之间强制执行。
前面的例子表明了松散方案的优点。实际上正如我们上面所示基于冲突依赖性对调用进行排序的方案是最宽松的方案这解释了为什么我们将其放置在图 3 的频谱中的最右侧位置。因此它比现有文献第 2.3.2 节中提出的方案更有希望因此也是我们选择的方案。我们在 Oracle 11g 第 2 版中实施了新方案作为现有方案的替代方案。 2.3.5 使用更细粒度对象的研究
在上一小节中我们提出了基于冲突依赖性强制排序的方案并认为它们是一致方案范围内最宽松的方案。此外在2.1节中我们提到为了简单起见我们认为数据库对象只是一个表。因此出现的问题是如果我们使用更细粒度的对象例如块或行我们是否可以设计出更宽松的方案。
直观上这种选择听起来很合理。考虑更细粒度的对象应该会减少依赖项的数量因此可以产生一种方案在调用之间强制执行更少的等待次数从而在重放期间实现更高级别的并发性。不幸的是这种直观上合理的方法在实践中行不通因为它可能会产生系统的不一致。我们用一个反例来证明这一点。
反例使用块或行假设我们在示例 1 和 2第 2.1 节中描述的是同一家公司。设其数据库包含一个表emp存储有关1,000,000名员工的信息对应于R1-R1,000,000的1,000,000行。此外考虑到在生产系统上表 emp 由 20,000 个块 B1-B20,000 组成。让每个块适合 50 行因此它们都已满。此外假设该公司收购了另一家同样拥有 1,000,000 名员工的公司。最后假设两个查询 Q4 和 Q5用 SQL 表示如下
Q4: select avg(salary) from emp;
Q5: insert into emp (select * from acquired emp);Q4 打印出所有员工的平均工资而 Q5 将被收购公司的员工插入到第一家公司的表 emp 中。为简单起见我们假设 Q5 自动提交其更改。在 Q5 之前执行 Q4 会聚合块 B1-B20,000 中的行 R1-R1,000,000。
此外Q5 在 emp 中插入 1,000,000 个新行例如 R1,000,001-R2,000,000。由于所有块 B1-B20,000 均已满因此新行将进入新分配的块例如 B20,001-B40,000。
如果我们考虑块级别的对象则 Q4 和 Q5 是冲突无关的因为它们访问不同的对象前者访问块 B1-B20,000而后者访问块 B20,001-B40,000。同样如果我们考虑行级别的对象则 Q4 和 Q5 再次是冲突无关的因为它们访问不同的对象前者访问行 R1-R1,000,000而后者访问 R1,000,001-R2,000,000。在这两种情况下基于冲突依赖性对调用进行排序的方案不会在重放期间强制这些调用之间等待。这会导致系统不一致因为如果在重放期间重新排序 Q4 和 Q5Q4 将聚合 2,000,000 行 (R1-R2,000,000)而不是在捕获期间聚合的 1,000,000 行。这种差异将影响第四季度的结果和表现。
显然基于块级或行级依赖的方案不能保证一般情况下的一致性。理论上识别查询之间重叠、动态确定其读取集以试图解决问题的解决方案是可能的。然而我们坚信由于其预期的高度复杂性它们在实际系统中并不实用。因此我们不再进一步调查它们。 3. 高效实施
Oracle Database Replay的第一个版本的体系结构已在之前的工作中进行了详细描述[9]。我们在第1节和图1中对其进行了简要总结。在本节中我们通过解释我们在该工具的第二个版本中实现的扩展来扩展原始出版物中的描述使其支持本文中提出的高级同步方案。
3.1发现依赖关系
Oracle Database Replay的工作原理如下给定数量的进程称为Replay客户机(图1)扫描捕获文件中记录的调用并通过请求执行这些调用的足够数量的连接向测试数据库服务器发送适当的并发请求。通过这样做重放客户端模拟捕获期间在生产系统上运行的应用程序和中间层。
为了确保重放结果的一致性在执行调用 a 之前测试数据库服务器首先根据所采用的同步方案识别 a 所依赖的所有其他调用并强制等待 a 直到所有调用都完成。由于工作负载通常包含大量调用因此动态搜索此类依赖项的计算成本可能非常昂贵。因此由于重放期间时间至关重要因此重放同步的有效实现需要以离线方式执行预处理算法该算法提前构建调用之间的依赖关系图G。
G 是有向无环图 (DAG)表示组成工作负载的调用之间的偏序。这些调用是 G 的顶点。根据所采用的同步方案如果 Must wait(b, a) 为真则有向边从顶点 a 开始并在顶点 b 结束。在我们的问题中使用依赖图类似于冲突可串行性理论中类似图的使用[6]。然而与后者不同的是我们的图在设计上是非循环的。此外我们用它来解决另一个问题重放一致性而不是事务可串行性。
算法 BuildDependencyGraph 以伪代码形式展示了我们高效的预处理算法该算法计算工作负载重放的依赖关系图。它的输入是包含捕获的工作负载的调用集 S。其输出是依赖图 G。
最初算法将 G 的顶点设置为 S第 1 行并将 G 的边初始化为空集第 2 行。然后它枚举S中潜在依赖的所有候选调用对以便识别G的边。为此它访问S中的每个调用a按照存储a的捕获文件的标识符cfa和捕获期间开始执行a的开始执行时间 ta (第3行)排序。然后它搜索a可能依赖的所有其他调用b。
上述 b 搜索的直接实现将详尽地枚举工作负载的所有可能调用。由于这些调用的数量通常非常大因此详尽的方法是不切实际的。为了克服这个缺点下面我们提出了一些属性基于这些属性我们的算法可以通过提前预测 同步方案不需要在特定的调用对上工作 来修剪其搜索空间。 属性 1避免在同一捕获文件 capture file 中搜索存储在特定捕获文件中的所有调用都是通过生产系统上的同一连接发送到数据库服务器的调用。通过同一连接进入数据库服务器的任何内容都应该以相同的方式重放。这种行为以更真实的方式模仿数据库所看到的生产工作负载。回想一下重放期间的调用重新排序试图在来自不同执行线程的请求之间实现更好的并发性而不是改变来自同一线程的调用的自然顺序因为后一种更改会修改重放期间用户的行为。因此尽管可能但不建议对存储在同一捕获文件中的调用进行重新排序。
基于此属性BuildDependencyGraph 不会搜索存储在同一捕获文件中的依赖调用因此对于每个调用 a它都会扫描每个捕获文件 cf第 4 行但会跳过存储 a 的文件 cfa第 5-7 行。 属性 2将搜索限制在一定范围内对于除 cfa 之外的每个文件 cf我们的算法都会扫描其中存储的调用第 12 行。正如我们下面所解释的它不是对整个文件执行耗时的扫描而是将搜索空间限制在特定的调用范围内。
令 ta 为捕获期间执行 a 的时间a.previous 为调用文件 cfa 中 a 的前一个调用如果 a 是 cfa 中的第一个调用则 a.previous 调用可以为 NULL。此外让 b0 和 b∞ 是我们的算法默认存在于 cf 中的两个人工调用假设 tb00 且 tb∞∞。他们分别扮演cf中第一个和最后一个调用的角色。它们不会重放而仅用于更轻松地处理边界情况如下所述。
此外令 RecallDependency第 9 行为返回 cf 中的调用例如 bmin的方法a.previous 调用必须等待该调用。如果存在这样的调用则它是唯一的基于下面的属性 3并且 BuildDependencyGraph 一定已经在之前的迭代中找到了它因为它处理按开始执行时间排序的调用第 3 行。否则如果 a.previous 调用为 NULL或者这样的调用不存在则 RecallDependency 返回 b0即上面定义的人工调用。
最后设 FindFirstCallAfterGivenTime第 10 行为返回 cf 中第一个调用例如 bmax的方法使得 ta tbmaxbmax 是 cf 中在 a 之后执行的第一个调用。如果这样的调用不存在则该方法返回 b∞。
根据前面的定义以下优先级成立bmin→a.previous_call→a→bmax。因此我们的算法第 12 行足以将 cf 中 a 需要等待的候选调用视为仅属于范围 (bmin, bmax) 的调用。请注意上述范围两侧都是开放的。因此不包含bmin和bmax即使bminb0、bmaxb∞也有效。 属性 3按相反时间顺序搜索并在第一个匹配处停止对于它生成的每个候选对例如 (a, b)BuildDependencyGraph 调用方法 ApplyRule第 13 行。根据它所采用的同步方案ApplyRule 结合了对 predicates 的某些适当子集的评估commit 和 access common object在第 2.2 节中定义。它返回一个决策可以是决策 1、2 或 3这三个选项已在第 2.3 节中定义指示各个调用 a 和 b 之间是否需要特定的排序。请注意ApplyRule 是我们算法中唯一依赖于特定同步方案的部分。除此之外我们的算法足够通用适用于我们在上一节中描述的所有一致同步方案。
如果ApplyRule返回Decision 1则调用a必须等待b因此算法在 G 的边中添加边 b→a第 16 行。我们认为在找到 ba 必须等待的 cf 中的调用之后我们的算法不需要继续搜索 cf 中 b 之前的 a 所依赖的其他调用a 将在所有这些之后间接执行因为它将在 b 之后显式执行并且根据属性 1所有这些都将在 b 之前执行。因此对其中任何一个强制执行显式等待都是多余的。此观察结果解释了属性 3基于该属性BuildDependencyGraph 按相反的启动执行时间顺序在 cf 中搜索并在找到第一个匹配项后停止搜索。BuildDependencyGraph 实现了反向启动执行时间顺序搜索如下所示它使用 cf 中位于 bmax 之前的调用来初始化 b第 11 行。这是具有最大启动执行时间的调用属于属性 2 定义的范围。
只要ApplyRule第13行返回决策3表明a和b是独立的算法就会向后迭代将cf中旧b之前的调用视为b的新值第22-24行。找到第一个匹配项第 15-18 行后算法将找到的标志设置为 TRUE。这会强制算法退出第 12 行的循环从而中断搜索。
到目前为止我们已经解释了当 ApplyRule 返回决策 1 或 3 时会发生什么。
决策 2 意味着调用 b 必须等待 a。在我们的设置中这样的结果是不可能的因为我们的算法访问的每个调用 b 都属于属性 2 定义的范围并且根据定义该范围内的所有调用必须在捕获期间在 a 之前执行。在决策 2 的不可能情况下第 19-21 行我们的算法为了完整性而引发错误。 属性 4修剪 G 中的边在枚举所有必需的调用对并构造图 G 后BuildDependencyGraph 最终调用方法 Reduce第 29 行。Reduce 修剪 G 中的一些冗余边。更详细地说它计算 G [5] 的传递约简它是 G 的子图具有最少的边数并表示与 G 相同的偏序。由于 G 是 DAG 它的传递约简是唯一的并且可以在线性时间内找到[14]。通过利用传递性的特性这种优化最大限度地减少了 G 中的边数从而减少了重放客户端必须强制执行的等待次数。 3.2 实施细节
现在让我们提供更多的实现细节主要关注我们在 Oracle Database Replay 第二版中必须进行的修改以使其支持基于冲突依赖的同步方案。下面我们分别研究每一步的执行。
捕获在捕获期间Oracle Database Replay 存储一致重放工作负载所需的一些元数据例如 SQL 文本、绑定值、计时信息和系统更改编号 (SCN)。(SCN 是一个顺序计数器精确识别 ORACLE 数据库中的某个时刻。SCN 通过提交进行推进) 最重要的是在新版本中它还存储调用访问的对象的标识符以及相应的访问类型读或写。额外的元数据使我们的算法能够根据一致性规则第 2.2 节决定两个调用是否冲突。请注意我们已经使用 DBMS 内核中的回调实现了工作负载记录因此所有必需的元数据都很容易获得。
出于性能原因Oracle Database Replay 在打开游标调用期间每个游标仅存储我们上面描述的附加元数据一次。为了避免不必要的冗余它不会在每次游标执行时一次又一次地显式存储它。相反在这种情况下它只存储光标编号这足以在后续步骤中需要时检索相关信息。
最后请注意工具存储的上述对象标识符始终引用基表即使与相应游标关联的 SQL 文本引用复杂视图也是如此。此属性保证 Oracle Database Replay 不会丢失任何依赖项。 预处理在预处理期间Oracle 数据库重放会生成许多线程每个线程都会解析许多捕获文件收集捕获期间存储的信息并使用重放步骤所需的元数据填充适当的结构和内部表。在新版本中它还填充了一个附加表
DEPENDENCIES(file_id, call_ctr, object id, RW, scn, pc_scn)该表为调用访问的每个对象存储一行。该信息对于识别同步期间的冲突是必要的。
列 file_id 保存存储给定调用的捕获文件的标识符call_ctr 是一个计数器用于标识捕获文件中给定调用的序列号对象 id 保存给定调用访问的对象的标识符RW 存储相应的访问类型scn 保存给定调用执行开始时数据库的 SCNpc_scn 保存 post-commit SCN即给定调用提交其更改后生成的新 SCN。如果给定的调用是非提交的则 pc_scn 就等于 scn
Oracle Database Replay 使用 DEPENDENCIES 中的原始数据来构建我们在上一小节中讨论的依赖图 G。为此我们在 PL/SQL 中实现了算法 BuildDependencyGraph第 3.1 节。在描述算法概要的伪代码中我们使用了时间的抽象概念来对调用进行排序并确定优先级。
我们的目的是使伪代码尽可能通用。但在我们的特定实现中我们使用call_ctr 作为捕获文件中调用排序的时间度量。此外我们使用 scn 和 pc_scn 来对不同捕获文件之间的调用进行排序。由于 SCN 是一个顺序计数器用于标识 ORACLE 数据库中的某个时刻因此它非常适合确定优先级。
总之我们的 PL/SQL 实现通过从 DEPENDENCIES 中选择适当的行来执行对存储在捕获文件BuildDependencyGraph第 3-4 行中的调用的扫描。它根据对象 id 和 RW 列中的相应值测试两个调用是否发生冲突第 13 行。每当它发现两个调用之间发生冲突时第 15-18 行它就会在另一个表 DEP_GRAPH(file_id, call_ctr, dep_file_id, dep_call_ctr) 中插入一个新行。DEP_GRAPH 实现了 G其中的一行表示两个调用之间的依赖关系。该对 (file_id, call_ctr ) 唯一标识第一个调用该调用存储在捕获文件中带有 id file_id 的位置 call_ctr 中。同样pair对 (dep_file_id, dep_call_ctr) 唯一标识第二个。 重放在重放期间数据库服务器可以访问表 DEP_GRAPH。因此它知道需要强制执行哪些依赖项。因此它会阻止需要等待其他调用的调用直到后者被执行。
我们实现不同同步方案的经验一种基于提交一种基于冲突依赖验证了我们的期望即实现前者需要更少的工作。对于该方案在服务器中维护一个中央 SCN 时钟存储重放期间已执行的调用中最大的 SCN足以有效地跟踪所有依赖关系而无需具体化 G。SCN-clock与模拟时钟类似它是由特定事件提前的。在重放的情况下这些事件是提交操作。因此在基于提交依赖的方案中服务器通过简单地阻止所有记录的SCN大于时钟当前值的新调用来强制一致性直到其他一些调用将时钟推进到它们的SCN或大于该值。有关更多详细信息请参阅其他地方[9]。权衡是显而易见的我们选择为 Oracle Database Replay 第一个版本实现更严格但更简单的方案并在第二个版本中实现高级方案。 4 实验评价
在第 2 节中我们研究了一致同步方案的范围并认为基于冲突依赖性强制排序的方案是最细粒度的方案因此期望最大限度地提高并发水平和相关的重放性能。我们在 Oracle 11g 第 2 版(Oracle 11g Release 2)中实现了这个新方案。为了验证我们的论点我们通过实验将其与现有文献 [9] 中提出的唯一对应方案即基于 提交依赖性commit dependency 强制排序的方案进行了比较。回想一下这个方案是在 Oracle 11g 中引入的。在本节中我们将介绍实验评估的结果。
请注意我们已将基于总排序或对象依赖性的评估方案排除在外。原因是这些方案的实际意义较小。正如我们在第 2.3.1 节中已经提到的前一种类型的方案不允许实际的并发性并且仅出于说明目的而提出。同样正如我们在第 2.3.3 节中所解释的后一种类型的方案在只读调用之间创建依赖关系。需要此属性来避免获取读取锁的 DBMS 中出现死锁。对死锁的解释超出了本文的范围。 硬件我们在两台运行 Linux 2.6.9 的机器上运行了我们的实验。机器 A 具有 4 GB 物理内存和 2 个 3 GHz Intel Xeon CPU每个 CPU 具有 6 MB 缓存大小。机器B更强大它拥有 32 GB 物理内存和 8 个 2.53 GHz Intel Xeon CPU每个 CPU 具有 8 MB 缓存大小。
工作负载场景我们尝试了不同的工作负载和各种捕获/重放场景。所有结果都是一致的。下面我们描述最具代表性的内容。由于篇幅限制我们省略了其余部分。
更详细地我们展示了与三个不同基准测试生成的工作负载相关的结果TPC-C [4]、Swingbench [11] 和真实应用程序 (RA)我们将在下面解释其特征
TPC-C 是数据库文献中广泛引用的基准。它描绘了一家批发供应商拥有多个地理分布的销售区和相关仓库。它以仓库数量作为输入参数。在我们的实验中我们将其设置为10这是一个常用的值。Swingbench 是一个旨在对数据库服务器进行压力测试的基准测试。它模拟来自同时下订单的客户的工作负载。我们已将 Swingbench 配置为生成 100 个并发会话。最后RA 是一个基准它使用我们正在合作的真实公司的应用程序生成的工作负载。该公司的代理商使用该应用程序根据考虑客户历史和个人资料的公式对不同服务进行报价。在我们的实验中我们使用了来自上述应用程序的 100 个并发会话。
请注意在为上述所有基准测试的输入参数选择值时我们的主要目标是在机器 A 上创建相当大但仍可管理的负载在捕获期间 CPU 平均繁忙 97%。
我们可以将我们使用的基准测试生成的工作负载分为两个不同的类别。RA 的工作负载以读取为主因为只有 3.3% 的调用是提交调用。TPC-C 和 Swingbench 的工作负载以提交为主因为它们包含的提交调用百分比分别达到 62% 和 36%。在 TPC-C 的情况下提交调用的百分比如此之高因为大多数更新调用都使用自动提交。
我们在此处介绍的实验中使用的主要场景如下我们首先捕获了上述三种工作负载的 32 分钟不同组合同时它们在机器 A 上运行的数据库服务器上执行。然后 我们在机器 B 上运行的数据库服务器上重放了捕获的工作负载。我们的场景模拟了非常常见的现实情况。应用程序正在中等规模的生产系统如机器 A上运行数据库管理员计划将其部署在功能更强大的机器如机器 B上。在实施升级之前管理员使用数据库重放来估计与升级相关的预期性能增益。
此外我们使用了三种不同的重放模式相同、快速和最快。我们用一个例子来解释它们的含义。想象一下两个连续的调用 a 和 b 存储在同一个捕获文件中这样 a→b。让 ta 和 tb 分别表示捕获期间执行 a 和 b 的时间。此外令 t’a 为重放期间执行 a 的时间da 为其执行的持续时间。然后对于每种模式b成为重放期间执行候选的时间t’b由以下公式给出
Same mode: t′b t′a max(tb − ta, da)fast mode: t′b t′a max((tb − ta)/2, da)fastest mode: t′b t′a da.第一个公式意味着在相同模式下重放会尝试在重放期间重现捕获期间观察到的相同调用速率同样在快速模式下重放会尝试使该速率加倍最后在最快模式下重放尝试以可能的最大速率一个接一个地重放所有调用即在连续调用之间不留任何间隙
请注意在前面的描述中我们已经强调了每种不同的模式都试图达到给定的速率。在实践中实现它取决于调用执行的持续时间以及由所采用的同步方案强制执行的任何额外等待。
结果分析首先我们提出了一组关于 读取 主导的工作负载由 RA 生成的工作负载的实验。我们使用两种不同的同步方案在三种不同的模式下重放捕获的工作负载。请注意这两种方案是一致的因此根据设计它们可以重现捕获的工作负载而不会出现任何数据或结果差异。
由于这两种模式产生相同的结果因此我们通过关注性能指标来比较它们图5显示了每次重放的运行时间图6显示了相应的吞吐量(即每秒的平均事务数)图7显示了提交调用在获得提交日志文件上的锁之前必须等待的总时间。 所有图形均包含三组每组两列。每组对应一种重放模式左侧为相同模式中间为快速模式右侧为最快模式。一对列对应于每种模式黑色列代表基于提交依赖的同步方案而白色列代表基于冲突依赖的同步方案。
从这些图表得出的主要结论是两种方案都能为读取主导的工作负载生成高质量的重放。回想一下机器 A 上的原始捕获持续时间为 32 分钟。图 5 表明两种方案都能够在相同模式下理想地同步重放因为它们实现了与捕获期间相同的调用速率并且也使重放在 32 分钟后完成。在其他两种模式下他们设法通过减少调用之间的时间来加快重放速度更好地利用机器 B 的额外计算能力。因此所用时间会减少图 5吞吐量会增加图 6。在相同和快速模式下两种方案表现得同样好但在最快模式下我们的新方案基于碰撞依赖的方案比现有方案性能提高了近 23%。这个结果表明,即使提交的数量是相对较小的特定工作负载collision-based同步仍然可以获得一些好处因为它执行更少的等待和管理增加并发的水平推动负载机器B高水平(平均CPU使用率达到47%而同样数量的计划根据提交的依赖是40%)揭示管理员升级机器的真正潜力。
至于提交等待时间图 7它们相当低因为提交数量很少并且提交日志文件上没有太多争用。基于提交依赖的方案的等待时间更短因为它以序列化的方式发出所有提交调用。请注意在这种情况下提交的发出是串行的但完成不是串行的因此仍然存在一些争论尽管规模较小。快速和最快模式下的等待时间会减少因为两种方案都在这些模式上强制执行更短的等待时间回想一下为不同模式计算 t′b 的公式。 为了更好地揭示我们新方案的潜力我们进一步尝试了以 提交 为主导的工作负载。为此我们将之前的工作负载与 TPC-C 和 Swingbench 生成的工作负载混合在一起。由此产生的工作量会更重并且以提交为主。图 8、图 9 和图 10 分别显示了以提交为主的工作负载的不同重放的运行时间、吞吐量和提交等待时间。 我们首先要指出的是基于提交依赖的方案无法有效地驱动以提交为主导的工作负载的重放。请注意每个图中所有黑柱的高度大致相同这表明即使在相同的模式下相应的方案也已经饱和。尽管单个请求从机器 B 的增强能力中获得了一些好处但通过平均保留资源的时间较短该方案无法提高并发级别以减少工作负载的运行时间。请注意在图 8 中基于提交依赖关系的方案的运行时间在所有模式下约为 38 分钟。这个时间甚至比捕获时间(32 分钟)还要长。
我们的新方案不会遇到同样的问题。它能够在相同模式下在大约 32 分钟内重放工作负载并成功在快速和最快模式下进一步加速工作负载提高并发水平并将吞吐量增加 40%图 9。通过这样做它生成更快、质量更好的重放因为它将机器B驱动到更高的负载水平(平均CPU使用率达到45%而基于提交依赖的方案的相同数字为35%)从而向管理员揭示了升级的真正潜力而不仅仅是总体资源消耗的改进。关于提交等待时间图 10我们可以观察到在这一系列实验中与图 7 中的相应时间相比它有所增加。
这是因为以提交为主的工作负载包含更多提交调用因此会在提交日志文件上产生更多争用。对于基于冲突依赖性的方案等待时间显着增加尤其是在最快模式下。这表明它同时发出许多提交调用这些调用是与冲突无关的。根据设计基于提交依赖的方案无法做到这一点。请注意随着队列中保留的提交调用数量的增加提交等待时间会迅速增加。这解释了图 10 中最快模式下白色柱的显着高度。
总体而言我们的结果验证了在重放以读取为主的工作负载时新方案的表现与现有方案相同或略好。此外在重放依赖于提交的工作负载时它的性能远远优于现有的。由于粒度更细它可以产生更好质量的重放在相同模式下更好地再现测试机器上的工作负载并在快速和最快模式下进一步加速。因此它导致更具代表性和更可靠的测试这一特性使其成为一致方案范围内的首选方案。 5. 相关工作
DBMS 中的并发控制和冲突可串行性的相关理论是与我们的工作相关的相当古老且经过充分研究的问题 [6,13,17]。该领域的算法使用了事务之间类似的依赖关系概念和类似的理论结构例如冲突依赖图。尽管存在上述相似之处但这两个问题有根本的不同。主要区别在于并发控制机制确保数据库完整性而重放同步方案则保证重放一致性。总之并发控制机制的任务是生成一个合法的调度来执行由竞争资源的事务组成的工作负载。如果调度保证数据库状态的完整性例如通过强制可串行化那么它就是合法的。另一方面重放同步机制不关注完整性因此它们遵循不同的约束。他们不必生成任何合法的计划而是必须生成与捕获期间在生产系统中实际执行的特定计划等效的计划。
另一个重要的区别是并发控制机制是动态工作的因为它们事先不知道整个工作负载而重放同步方案可以以离线方式发现所有依赖关系因为它们可以提前访问整个工作负载。因此如果在他们维护的依赖图中检测到循环前者可能必须回溯对于后者来说这种情况是不可能发生的。上述差异证明了工作负载重放需要不同同步方案的合理性。研究此类方案以及将已知理论应用于我们的新问题一直是本文的主要目的。
过去已经研究过记录和重放真实数据库工作负载并且一些商业工具已经提供了此处描述的一些功能。其中与我们的工作更接近的工具是Oracle Database Replay的第一个版本[9]。它在 Oracle 11g 中的实现使用一致的重放同步方案该方案根据提交依赖性对调用进行排序。正如本文所示该方案的限制比必要的多留下了很大的改进空间。在本文中我们的目标是首次研究所有一致重放同步方案的属性和权衡形式化其特征发现新方案并提名最佳方案我们已在 Oracle 11g 第 2 版中实现了这些方案。
同一类别的其他工具包括 Quest Benchmark Factory for Databases [1] 和 Microsoft SQL Server Profiler [3]依赖 SQL 跟踪来记录数据库工作负载。这些方法的问题在于SQL 跟踪在数据库服务器上增加了相当大的开销并且不包含实现一致同步方案所需的事务信息。因此他们的技术不适用于我们的问题。 iReplay 是用于数据库 QA、回归测试、性能测试等的下一代负载生成和分析工具。iReplay 被设计为真正的数据库重放允许组织捕获其生产 SQL 工作负载的真实图像然后重新创建该工作负载及其所有本机复杂性以便在测试环境中进行分析。这种方法有效地消除了生产流量和模拟测试条件之间的差距使组织能够更可靠地预测关键信息系统变化的影响同时降低相关风险。 此外还有另一个工具系列包括 iReplay [2]它在网络级别实现捕获和重放。在捕获过程中他们使用嗅探来记录进入 DBMS 的流量。在重放期间它们会再现相同的流量。此类工具的一个显着缺点是它们是在 DBMS 之外构建的因此它们只能依赖在其入口点观察到的计时信息。换句话说他们只知道请求何时到达 DBMS但无法访问有关该请求实际执行时间、它表现出的依赖关系、分配给它的 SCN 或它访问的对象的信息。因此在重放期间他们无法应用我们在本文中讨论的频谱的任何同步方案。他们能做的最好的事情就是按照与捕获期间相同的顺序发出相同的调用。显然这样的解决方案并不能保证在 DBMS 中执行期间保留相同的顺序。因此这些工具不能保证重放一致性而这一直是我们的主要关注点并且它们不属于本文的讨论范围。
最后其他几种算法会生成用于测试目的的合成数据或工作负载 [7,8,12,15,16]。不过他们都没有研究同步重放生成的工作负载的问题而这是我们的主要关注点。此外我们的方法适用于在真实系统上捕获的工作负载。预计真实工作负载比合成工作负载更能代表数据库测试。 6. 结论
在本文中我们首次对实际工作负载重放的一致同步方案进行了广泛的研究。我们定义了它们的类别确定了它们覆盖的范围并研究了该范围内各个点的属性和权衡。此外我们表明虽然在许多实际应用中足够但迄今为止提出的唯一一致的重放同步方案[9]是粗粒度的并且比必要的限制更多强制独立调用之间的依赖关系。
为了克服这个缺点我们确定了使用更细粒度的规则进行重放同步的理想方案。此外我们描述了新方案的有效实施并从理论上和实验上表明对于主要的工作负载类别它比现有方案产生更好的质量重放。 7. 引用
[1] Benchmark Factory for Databases. http://www.quest.com. [2] iReplay: Database Workload Capture and Replay. http://www.exact-solutions.com/products/ireplay. [3] SQL Server Profiler. http://msdn.microsoft.com. [4] Transaction Processing Performance Council. TPC-C benchmark. http://www.tpc.org/tpcc/. [5] A. V. Aho, M. R. Garey, and J. D. Ullman. The transitive reduction of a directed graph. SIAM J.Comput., 1(2):131–137, 1972. [6] P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987. [7] C. Binnig, D. Kossmann, E. Lo, and M. T. ¨ Ozsu. QAGen: generating query-aware test databases. In SIGMOD Conference, pages 341–352, 2007. [8] M. Emmi, R. Majumdar, and K. Sen. Dynamic test input generation for database applications. In ISSTA, pages 151–162, 2007. [9] L. Galanis, S. Buranawatanachoke, R. Colle, B. Dageville, K. Dias, J. Klein, S. Papadomanolakis, L. L. Tan, V. Venkataramani, Y. Wang, and G. Wood. Oracle database replay. In SIGMOD Conference, pages 1159–1170, 2008. [10] G. R. Ganger. Generating representative synthetic workloads: An unsolved problem. In Int. CMG Conference, pages 1263–1269, 1995. [11] D. Giles. Swingbench benchmark. http://www.dominicgiles.com/swingbench.html. [12] J. Gray, P. Sundaresan, S. Englert, K. Baclawski, and P. J. Weinberger. Quickly generating billion-record synthetic databases. In SIGMOD Conference, pages 243–252, 1994. [13] H. T. Kung and J. T. Robinson. On optimistic methods for concurrency control. ACM Trans. Database Syst., 6(2):213–226, 1981. [14] T.-H. Ma and J. Spinrad. Cycle-free partial orders and chordal comparability graphs. Order, 8(1):49–61, 1991. [15] M. Poess and J. M. Stephens. Generating thousand benchmark queries in seconds. In VLDB, pages 1045–1053, 2004. [16] D. R. Slutz. Massive stochastic testing of SQL. In VLDB, pages 618–622, 1998. [17] R. E. Stearns, P. M. L. II, and D. J. Rosenkrantz. Concurrency control for database systems. In FOCS, pages 19–32, 1976.
