使用 InfoSphere Optim Query Capture and Replay 评估数据库迁移

捕获生产工作负载,在测试环境上重放它们,并分析流量比较报告

企业进行的迁移项目可能是复杂、昂贵和破坏性的。如果迁移团队没有配备有效的测试工具,那么他们可能需要花费几个月的时间来审查确定转换工作的优先级的代码,并准备模拟生产工作负载的脚本,这会浪费企业的宝贵资源。使用 InfoSphere® Optim™ Query Capture and Replay,组织可以安全地处理企业变更。利用 InfoSphere Optim Query Capture and Replay 的轻松捕获生产工作负载、在目标数据库上重放它们 (replay) 并生成比较报告的功能,数据团队可以系统地管理由于数据库升级而导致的棘手问题。

Martin Dizon, Optim/Guardium 专家, IBM

Martin Dizon 是 IBM 多伦多软件实验室的信息管理技术生态系统团队中的一名技术支持专家,为 IBM 的 Optim 和 Guardium 产品提供支持。他执行面向全球业务合作伙伴的演示、训练营和技能转移,帮助他们加快其 Optim/Guardium 项目,并确保他们取得成功。



Denis Kirichenko, Optim/Guardium 专家, IBM

Denis Kirichenko 是 IBM 在俄罗斯科技中心的 Optim 和 Guardium 技术生态系统团队中的一名软件工程师。他提供端到端的 InfoSphere Optim 和 Guardium 支持(范围包括从技能转让和演示/PoT/PoC 到产品的最佳实践),帮助加速合作伙伴的成功,并推进 InfoSphere Optim 和 InfoSphere Guardium 产品。



2012 年 10 月 22 日

免费下载:IBM® Data Studio V3.1 免费版或者 IBM® Optim® Database Administrator 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

今天,世界各地的企业依靠他们的任务关键型应用程序来促进创收。这些业务交付并维护可靠的、经过彻底测试的应用程序,以尽量减少应用程序故障造成的停机时间,这是至关重要的,因为停机时间可能会损害客户关系和业务的完整性。

由于出现数据或用户的增长、数据库升级或迁移,或硬件的重新配置等情况,会对企业应用程序或基础架构进行更改以便达到并超越竞争产品,此时,这种损害会特别明显。满足当前的客户期望,同时探索新的策略,如果执行得不正确的话,这会证明是代价昂贵且困难重重,结果还会导致失去业务、错过机会,甚至收入下降。

InfoSphere Optim Query Capture and Replay 目的是在业务对应用程序或基础架构作出变更时最大限度地减少可能出现的负面影响,其方法是在新应用程序正式可用前,有效地减少彻底测试新环境所需要的时间量,以及最大限度地提高新应用程序的质量。

注意

在本文中,InfoSphere Query Capture and Replay 被称为 Capture Replay

Capture Replay 可以通过实际的测试来降低成本并减少风险,使数据库专业人士可以在生产数据库上捕获 SQL 工作负载,并在测试数据库上重放这些真实的工作负载,以便模拟生产活动。具体而言,它能够捕获 SQL 命令、原始应用程序计时、执行顺序和性能指标,然后以不同的速度重放捕获的流量,以便进行容量和可扩展性测试。这就消除了对很耗费时间才能创建的脚本进行测试的需要。此外,生成报告,以便准确地分析环境变更所引起的影响种类,这对潜在的问题区域提供了进一步的洞察。

Optim Query Capture and Replay 架构

图 1 说明了由 Capture Replay 解决方案实现的基本架构。

图 1. Capture Replay 架构:Capture Replay Server 和 S-TAP Agent
该图显示了 Capture Replay 架构:Capture Replay Server 和 S-TAP Agent

Capture Replay 解决方案驻留在数据库服务器上,捕获传入和传出的流量,所以在实现它时不需要更改应用程序、数据库或基础架构。

Guardium

对于熟悉 InfoSphere Guardium 的人而言,Capture Replay Server 以 Guardium 平台为基础。

解决方案的第一个主要组件是 Query Capture Replay Server,它将安装 IBM InfoSphere Guardium 软件。您可以选择亲自在自己的服务器(符合 Guardium 的硬件和软件要求)上安装 Guardium 映像,或者购买已经安装和配置了 Guardium 的设备。Capture Replay Server 需要安装一个 Guardium 服务补丁,以实现最新的 Guardium 修复,还需要一个 Query Capture Replay 补丁,通过捕获/重放功能来更新它。

第二个重要组件是轻量级的 S-TAP 代理软件,它将被安装在要捕获 SQL 流量的两个数据库服务器上,以及想要重放已捕获流量的数据库服务器上。

S-TAP 代理的主要职责只是捕获在数据库服务器上的工作负载,同时实现从源数据库和目标数据库卸载 Capture Replay Server,这两个数据库稍后将用于分析(例如,比较报告)。它的影响很小,因为它不依赖于本地数据库的记录或跟踪,但仍然可以捕获 100% 的 SQL 负载。

Capture Replay Server 从您的捕获数据库服务器接收原始的数据库活动数据,并负责解析、评估和记录数据,这些数据将被用于在重放数据库上进行重放,以及生成报告供分析之用。用户通过 Capture Replay Server 的两个 Web 控制台 GUI 与之交互,在这两个 GUI 中,您可以指定捕获和重放选项,并查看高层次的和深入的工作负载比较报告:

  • Guardium Web Console:用于创建和配置异构数据库之间的捕获重放(例如,本文讨论的是 Oracle 到 DB2®)
  • Capture and Replay Web Console:用于创建和配置 DB2 数据库之间的捕获重放(如需了解更多信息,请访问 参考资料 中的 Information Center 链接)

捕获和重放场景

为了满足 SLA 的要求、满足客户的期望,并超越竞争对手的产品,企业必须能够适应用户和应用程序的事务性要求。Capture Replay 使组织能够安全地处理企业的变更。

图 2. 常见场景:数据库升级/迁移和硬件重新配置
该图显示了常见场景 - 数据库升级/迁移和硬件重新配置

随着数据或应用程序用户的数量增加,企业可能会发现自己不得不升级或重新配置硬件和数据库,以便使其应用程序维持可接受的性能水平。利用 Capture Replay,数据库管理员可以在当前的生产数据库服务器上捕获工作负载,并在数据库升级或硬件重新配置的过程中反复重放它。然后,您可以检查比较报告,其中包括有助于评估和比较数据库故障及响应时间的指标,以确保问题得到解决,并保持服务水平协议。

本文着重介绍数据库迁移的用例。将数据从一个数据库平台移动到另一个数据库平台,有可能会导致一些问题,比如由于不符合 SQL 标准而导致 SQL 语句失败。迁移通常比数据库升级更复杂,因为您在两个数据库供应商之间移动数据,而这两个供应商在很多技术方面都可能会有所不同。数据库管理员需要确保他们的应用程序的功能和性能不低于可接受的水平。

在迁移项目中使用 Capture Replay,DBA 可以:

  • 确定 “过时” 和 “热” 的 SQL 语句及数据库对象,以确定移植工作的优先级
  • 有效地评估迁移数据的初始硬件和存储需求
  • 通过详细的异常报告快速诊断 SQL 故障
  • 确定在迁移后的环境中缺失的数据集
  • 观察真实的响应时间,以确定性能问题

为了演示使用 Capture Replay 测试企业变更的业务价值,您将完成一个简单的数据库迁移场景。


数据库迁移

当执行数据库迁移时,可使用 Capture Replay 帮助验证迁移操作,并评估完成迁移过程所需要的进一步迁移工作。一旦创建了目标数据库环境,您就可以通过在目标数据库平台上重放生产工作负载,从而快速地查明迁移问题。虽然需要首先创建目标数据库对象,但 Capture Replay 最大限度地减少了迁移工作,它让您可以测试数据库层,而不必重新调整整个应用层来与新的测试数据库进行通信。

Capture Replay 比较功能让您可以识别失败的 SQL 语句、返回数据的不一致,以及由于新测试环境造成的性能问题。此外,重放/重放功能也可用于推进迁移过程,直到所有问题都得到解决,并且目标数据库系统达到期望的工作状态,并报告最少量的错误或不一致。

下面的场景展示了一个库存管理系统的迁移,该系统是一个使用 Oracle 作为其后端的 Web 应用程序。您将使用该应用程序在 Oracle 源数据库中产生流量,稍后这些流量将由在 DB2 for Linux®, UNIX®, and Windows® 目标数据库上的 Optim Query Capture and Replay 进行重放。

Capture Replay 数据库迁移工作流

完成迁移场景:

  1. 为相关的数据库流量捕获 Oracle 生产工作负载。
  2. 准备目标 DB2 迁移环境。应该使用运行工作负载所需的数据库对象和数据填充 DB2 数据库(例如,通过一个迁移工具来填充)。
  3. 在目标 DB2 迁移环境中重放已捕获的工作负载。
  4. 分析报告,识别迁移问题,并评估进一步的可能迁移工作。
  5. 执行数据库变更,解决所识别的迁移问题,并重复另一次工作负载重放,以验证变更。
图 3. Capture Replay 数据库迁移工作流
Capture Replay 数据库迁移工作流

验证先决条件

在可以开始该场景之前,您必须确保已安装和配置了 S-TAP 代理,使它可以正确地捕获流量,并将流量发送给 Capture Replay Server,以便在目标数据库上进行重放。这些工作都可以通过 Guardium Web Console 来完成。

  1. 注意

    S-TAP 代理是特定于 OS 的,而不是特定于数据库的。您只需要在每个数据库服务器上安装一个 S-TAP (无论在该服务器上存在多少种数据库)。在我们的场景中,我们的源数据库和目标数据库都安装在同一台服务器上,所以只需要安装一个 S-TAP。

    首先,确保源数据库和目标数据库服务器都安装了 Guardium S-TAP 代理。观察 S-TAP 状态,它应该已安装且处于活动状态。

    图 4. S-TAP 状态监视器
    S-TAP 状态监视器
  2. 确认已为 Oracle 和 DB2 数据库都创建并正确配置了检测引擎。
    图 5. 为 Oracle 和 DB2 数据库配置的检测引擎
    为 Oracle 和 DB2 数据库配置的检测引擎
  3. Guardium S-TAP 代理允许您监视与存在于其安装服务器上(受支持)的数据库相关的所有(本地和远程)流量。在我们的源数据库和目标数据库上的 S-TAP 通过创建一个策略捕获所有流量,不过滤任何种类的 IP、数据库、SQL 命令等。您需要指定一个 LOG FULL DETAILS 操作,必须使用它才能使捕获/重放特性正常工作。该操作不仅可以记录 SQL 语句,它也可以记录值。请注意,当您在目标数据库上运行一个重放时,您是在隐式执行一个捕获,所以其数据可用于未来的比较报告。

    图 6. Log Full Details 策略
    Log Full Details 策略
  4. 为了捕获语句执行之间的响应时间,并且记录受 SQL 语句影响的记录数量,您需要确保在常规 Inspection Engine Configuration (Administration Console > Configuration > Inspection Engines) 中分别选中了 Compute Avg Response Time 和 Log Records Affected 选项。此外,如果您打算在重放过程中使用 Auto Commit 选项,请确保选中 Default Mark Auto Commit 选项。
    图 7. 验证是否已正确配置检测引擎
    该图显示了验证是否已正确配置检测引擎
  5. 在这个阶段,S-TAP 代理将能够捕获所有的 Oracle 数据库流量,但稍后,您可以选择在目标数据库上重放哪些已捕获的流量。

迁移评估

在本文中,将通过一个简单的场景向您展示如何使用 Capture Replay 来分析目标数据库系统,在该系统中,已经在 DB2 环境中重新创建了 Oracle 数据库环境。该场景本身将主要关注解决与被迁移数据本身有关的迁移问题、在目标数据库环境中运行流量的性能,以及在 DB2 上重放任何不受支持的 SQL 语句。Capture Replay 的捕获/重放和重放/重放功能可以为分析提供报告,让您能够识别特定的移植问题,并帮助评估解决这些问题所需要的迁移工作。

场景目标

  1. 在目标系统上重新创建相关的数据库
  2. 捕获 Oracle 流量数据
  3. 暂存 Oracle 流量数据
  4. 在 DB2 上重放数据
  5. 比较和分析捕获/重放报告
  6. 识别若干种迁移问题:较差的性能和不兼容的 SQL
  7. 调优 DB2 数据库并修改暂存的数据,以修正不兼容的 SQL
  8. 在 DB2 上再次运行重放
  9. 验证迁移问题是否已得到解决

场景演练

  1. 注意

    您需要知道迁移到测试数据库的源数据库的快照状态时间,因为这对于在后续步骤中配置重放很重要。

    首先,您必须在您的测试环境中重新创建生产环境中相关的数据库,并迁移数据。在这个过程中,您可以使用多种迁移实用程序来进行协助,例如:

    • MEET DB2:Migration Enablement Evaluation Tool for DB2(即 MEET DB2)解析从 Oracle 数据库提取的 DDL 和 PL/SQL 代码,并报告支持的特性、不支持的特性,以及适合迁移工作的解决方案。
    • IBM Data Movement Tool:IBM Data Movement Tool 是一个简单而功能强大的工具,使来自 Oracle(或其他各种 DBMS)的应用程序可以在 IBM DB2 9.7 for Linux, UNIX, and Windows 上运行,其方法是连接到 Oracle 数据库,将数据库对象 DDL 提取到稍后可以被执行的文件,并生成负载脚本,将数据本身导入到 DB2。
    • Optim TDM:Optim Test Data Management Solution(简称为 Optim TDM)通过创建引用完整的合适大小 的测试数据库、轻松刷新与生产环境相近的测试环境、自动化测试比较,并屏蔽克隆的生产数据,从而加快迭代测试、控制成本,并确保测试环境的安全。
  2. 您必须通过使用 Web 应用程序在源数据库上生成流量。然后,S-TAP 代理将自动捕获此流量,并发送到 Capture Replay Server,在该服务器上,流量会被解析并存储,以便在另一个数据库上重放。
  3. 如前所述,您已经使用相关对象创建了自己的目标 DB2 数据库,这些对象与在 Oracle 数据库中发现的对象类似。创建过程可以手动完成,也可以包含迁移实用程序来帮助完成该过程。您应该使用 Capture Replay 执行迁移评估,它使您可以估计保证您的 DB2 数据库函数无差错需要完成的工作。通过在目标 DB2 数据库上重放 Oracle 流量,您可以识别有问题的对象,这些对象作为迁移过程的结果,需要得到进一步的关注。
  4. 接下来,您需要配置重放。这将确定在目标 DB2 数据库上重放已捕获 Oracle SQL 流的哪些部分。请记住,S-TAP 代理一直在捕获所有流量,包括来自其他数据库的流量。您需要把重点放在相关的已捕获数据上。这包括指定将用于重放的已捕获 SQL 流量的时间段,以及捕获流量的源数据库类型。

    使用 Replay Builder 配置一个新的重放,该工具位于 Capture/Replay > Configuration 选项卡下面。前四个参数是强制性的,其余的都是可选的。

    图 8. 通过 Replay Builder 创建 Replay Configuration
    该图显示了通过 Replay Builder 创建 Replay Configuration
    提示

    为了在迁移中有效地使用 Capture Replay,关键是要正确设置您的 Period start 参数。当使用 Capture Replay 重放生产工作负载时,源数据库和测试数据库必须处于类似的状态。此外,在迁移之前,S-TAP 代理必须已安装在您的源数据库和测试数据库服务器上,这样就可以监视流量并进行记录,以备后用。

    无论是使用一个完全备份迁移源数据库,还是通过其他方法迁移,您必须知道迁移到测试数据库的源数据库的 “快照” 状态的时间。这个时间是您的 Period start 参数设置,从该时间起,从源数据库捕获的任何流量数据都可以在测试数据库上安全地重放,因为测试数据库处于已验证状态,类似于您的源数据库的快照状态。

  5. 在任何选定流量能够在目标数据库上重放之前,在 Capture Replay Server 上需要一个暂存阶段。这将使您的重放配置定义与实际流量数据相关联。可以通过选择一个重放配置,单击 Stage 按钮,然后单击 start 来启动暂存流程。
    图 9. 暂存数据
    该图显示了暂存数据
  6. 暂存将重放配置添加到进程队列中,可在 Capture/Replay > Job Queue 选项卡下面监视它。您需要等待暂存进程达到 COMPLETED 状态。请记下暂存作业的进程 ID。
    图 10. 监视暂存进程的作业队列
    该图显示了监视暂存进程的作业队列
  7. 要在暂存作业完成后马上查看可用于重放的暂存数据,您可以在 Capture/Replay > Data Staging 选项卡下找到它。起初,您可能会注意到,将看到 “No Staging Data”。为了查看数据,您必须自定义报告。
    图 11. Data Staging 报告
    Data Staging 报告

    单击页面右上角的 Customize 按钮,自定义报告。

    图 12. 自定义 Data Staging 报告
    该图显示了自定义 Data Staging 报告
  8. 若您需要指定:只想查看与特定的重放配置 ("migration_replay") 关联的暂存数据 ("migration_replay"),可通过修改 configId 参数,将它更改为您之前在 Job Queue 中记下的 Process ID 来实现。可以单击底部的 Update 按钮,更新 Data Staging 报告。
    图 13. 更改 Data Stating 报告的 configId 参数
    该图显示了更改 Data Stating 报告的 configId 参数
  9. 该报告将更新为包含与重放配置关联的暂存数据。您将能够查看被执行和捕获的每个 SQL 语句的详细信息,如时间戳、数据库类型和执行它的服务器 IP 等,以及 SQL 语句的总数。
    图 14. 包含已捕获流量的 Data Staging 报告
    包含已捕获流量的 Data Staging 报告
  10. 现在,您已经验证了重放配置具有关联的流量,您可以在测试 DB2 数据库上重放它。通过返回到 Replay Builder,选择 Replay Configuration,并单击 Replay,您可以完成该操作。
    图 15. 通过 Replay Builder 重放
    通过 Replay Builder 重放
  11. 您需要配置 Replay Schedule Setup,然后单击 Apply。在这里,您可以指定与您希望在上面重放的数据源相关的参数,以及其他的选项,例如提交方法和重放的重复次数。一旦完成设置,您就可以单击 Run Once Now,在目标 DB2 数据库上开始重放暂存的 Oracle 流量。
    图 16. Replay Schedule 设置
    Replay Schedule 设置
    提示
    以下是在配置您的重放计划时要考虑的一些细节:
    Speed rate这个参数决定了您希望在目标数据库上重放已捕获流量的速度(例如,0 = 无延迟(SQL 将尽可能快地执行),1 = 相同的速度,10 = 比原始速度快 10 倍等)。
    Commit method这决定了在重放时如何将更改提交给数据库。Don't force 选项会检查您的 Inspection Configuration 设置(即,Default Mark Auto Commit 设置),以确定在重放时是否使用自动提交,Force auto commit 选项将在每个 SQL 语句之后提交,而 Force no auto commit 选项只在当其在已捕获流量中显式看到一个更改时才会提交。
    请注意,若 Speed rate 使用选项 “0”(无延迟)和/或 Commit Methods 设置为 Don't force,您可能会发现引用完整性约束失败所造成的错误,尤其是当您的流量包含使用不同会话的插入和更新语句时,因为事务可能无法以原来的顺序重放。建议您避免将 Speed rate 设置为选项 “0”,以及使用 Force auto commit 或 Force no auto commit 的提交方法。
  12. 再次转到 Capture/Replay > Job Queue 选项卡,查看重放的状态。一旦完成,您就可以单击 Capture/Replay > Capture/Replay List 选项卡,您在这里将能够生成有关已捕获和重放流量的不同报告。

    在此捕获/重放列表上,列出了一个记录。如 Name-From 和 Name-To 列所示,您可以验证该条记录是否与之前的捕获和重放作业(即,“migration_replay” 是已捕获流量,“replay_on_DB2” 是重放的流量)有关。为了生成捕获和重放流量之间的不同类型的比较报告,双击记录,并单击 Invoke

    图 17. 创建捕获/重放报告,比较流量
    该图显示了创建捕获/重放报告,比较流量
  13. 您将看到一个 GuardAPI 函数列表,在执行这些函数时,将生成详细的报告,比较捕获的和重放的流量。每个函数都会生成一种不同类型的报告。让我们先单击 queue_replay_object_agg_match_by_id 函数,看看它的情况。
    图 18. queue_replay_object_agg_match_by_id GuardAPI 函数
    该图显示了 queue_replay_object_agg_match_by_id GuardAPI 函数
  14. 注意

    使用 queue_replay_object_agg_match_by_id 函数,是因为您可以比较两个数据库之间的工作负载。预计会有一些白噪音,因为这种方法根据语句和对象名称进行 SQL 比较。如果您在比较相同数据库类型的工作负载,那么使用 queue_replay_agg_match_by_id 函数会更准确。

    调用此函数将生成 Workload Aggregate Match 报告。该报告聚集了来自捕获和重放流量的相似的 SQL 语句(基于 SQL 动词、对象和深度),并排比较它们,并为每个 SQL 语句提供统计数据。您应该从这个高层次的报告开始分析您的捕获/重放场景。保留默认参数,并单击 Invoke now,调用该函数。

    图 19. 调用 queue_replay_object_agg_match_by_id 函数
    该图显示了调用 queue_replay_object_agg_match_by_id 函数

    比较作业需要运行一段时间。在此期间内,您可以启动稍后要查看的另一份报告。

  15. 关闭所有弹出窗口,并返回到 Capture Replay (Guardium) 主界面。您可以再次双击 Capture/Replay、单击 Invoke,然后选择 queue_replay_match_by_id 函数,启动下一个比较作业。
    图 20. queue_replay _match_by_id GuardAPI 函数
    该图显示了 queue_replay_match_by_id GuardAPI 函数
  16. 注意

    如果有需要,您可以将特定的 SQL 语句分配给组 Replay - Include in Compare and Replay - Exclude from Compare,以便在比较过程中分别包括它们或排除它们,从而实现重点更突出的分析。

    调用此函数将生成 Workload Match 报告,它比之前的 Workload Aggregate Match 报告粒度更细、更详尽。此报告没有创建一个高层次的报告来总结相似的 SQL 语句之间的比较,而是比较了每一个单独的 SQL 语句。您可以保留默认的参数,但要将 includeGroup 参数更改为 Replay - Include in Compare,将 excludeGroup 参数更改为 Replay - Exclude from Compare。然后单击 Invoke now

    图 21. 调用 queue_replay_match_by_id 函数
    该图显示了调用 queue_replay_match_by_id 函数
  17. 现在,您已经触发了 Workload Aggregate Match 和 Workload Match 报告的创建,让我们来看看它们的状态。您需要关闭所有弹出窗口,返回主界面,进入 Job Queue。您将看到,最后运行的两个作业是通过调用 GuardAPI 函数 queue_replay_object_agg_match_by_idqueue_replay_match_by_id 启动的比较作业。Guardium Job Description 列将告诉您在捕获和重放的流量比较中有多少个 SQL 语句是匹配的和不匹配的。
    图 22. 监视 GuardAPI 函数作业的 Job Queue
    该图显示了监视 GuardAPI 函数作业的 Job Queue
  18. 由于这两个比较作业都已完成,您可以查看生成的报告。要查看它们,回到 Capture/Replay > Capture/Replay List 选项卡,双击 Capture/Replay 记录,并单击 View Workload Comparison
    图 23. Capture/Replay List - View Workload Comparison
    该图显示了 Capture/Replay List - View Workload Comparison
  19. 将会弹出一个窗口,说明数据编译已完成。单击 Take me there 直接转到这个特定的捕获/重放的 Workload Comparison。在这里,您将发现 GuardAPI 函数生成的其他报告。
    图 24. Workload Comparison 的数据编译进程
    该图显示了 Workload Comparison 的数据编译进程
  20. 您将被带到 Summary Comparison 报告。在这里,您可以分析有关捕获和重放流量的高层次详细信息和统计信息。您可以去看看一些作为示例的比较。让我们来看看平均执行时间的比较。

    注意

    Count From 和 Count To 条形分别代表捕获和重放流量的平均执行时间(您也将经常在其他比较报告中看到这样的命名约定)。Period(x 轴)表示捕获/重放发生的时间周期,以小时为单位。在此示例中,捕获/重放发生在第 “0” 个小时(第一个小时内)。

    在这里,您可以看到,在重放过程中,目标数据库的执行平均慢了大约 250ms。如果目标数据库的性能不符合您的 SLA 或不理想,则需要执行数据库调优和重新配置。通过使用这种高层次的条形图,您可以预计,为了在迁移的数据库上提高性能,需要进行进一步的工作。您必须在后面的步骤中执行一个简单的数据库调优任务,以提高性能。

    图 25. 比较 Avg Execution Time (ms)
    该图显示了比较 Avg Execution Time (ms)
  21. 注意

    对于任何条形图,您都可以双击它们,以查看图表中每个条形所表示的确切数字。

    现在,让我们来看看检索的总行数/受捕获和重放流量影响的总行数的比较。在这里,您可以看到,在目标数据库上的重放过程中,被检索的行数大约减少了 3000-4000。这可能意味着,并非所有数据都已从生产数据库迁移到测试数据库,或在测试环境上运行时,有若干个 SELECT SQL 语句失败。

    图 26. 比较检索的行数
    该图显示了比较检索的行数
  22. 如果您之前触发了一个从 GuardAPI 函数生成的报告,您将能够在左侧菜单面板上看到报告。现在,您可以通过单击 Workload Aggregate Match 报告,查看另一个高层次的总结报告。
    图 27. 查找 Workload Aggregate Match 报告
    该图显示了查找 Workload Aggregate Match 报告
  23. 在这里,您会看到相似的 SQL 语句组之间的比较。例如,下面的记录代表 SQL 动词为 SELECT、对象为 invent.locations,以及深度为 “0”(深度与嵌入式 SQL 有关 - 因为 SELECT 语句没有嵌入在另一个 SQL 语句内,其深度为 0)的所有 SQL 语句的组。
    图 28. 来自 Workload Aggregate Match 报告的一个记录
    该图显示了来自 Workload Aggregate Match 报告的一个记录
  24. 注意

    通过查看报告中的每个 SQL 语句行的背景颜色,您可以快速查看性能/一致性问题。查看手册,了解每种颜色代表的问题。

    观察一下,本报告中有许多性能和一致性指标。下面的记录表明,有 18 个 SQL 语句,它们选自 invent.services 表,并在您的 Oracle 和 DB2 数据库上执行。然而,在 DB2 上运行时,所有 18 个语句都失败(由 Compare-To Failures 显示)。这可能意味着,在测试数据库中的 invent.services 表可能有问题,或者 SQL 语句本身的语法/格式可能与 DB2 不兼容。同样的推断也适用于在 invent.services 表中更新记录的另一个 SQL 语句。

    图 29. SQL 语句无法在 DB2 上运行
    该图显示了 SQL 语句无法在 DB2 上运行

    如果看一下几个 SQL 比较记录的平均运行时,就可以清楚地看到,DB2 在重放过程中慢了几毫秒(由 Compare-To Avg Runtime 列显示),印证了您在 Summary Comparison 报告中所看到的。同样,这可能是由于不正确的数据库调优所造成的。

    图 30. 运行时较慢的 SQL 语句
    该图显示了运行时较慢的 SQL 语句

    从受影响的记录计数较低可以看出,在您的 DB2 测试数据库的 invent.locations 和 invent.owners 表中,您可能丢失了数据(由 Compare-To Avg Records Affected 列显示)。这证实了前面在分析 Summary Comparison 报告时所讨论的对不完整迁移的怀疑。

    图 31. 检索记录计数较低的 SQL 语句
    检索记录计数较低的 SQL 语句
  25. 您可以去看看细粒度版本的 Workload Aggregate Match 报告。在左侧,单击 Workload Match 报告即可看到。
    图 32. 查找 Workload Match 报告
    查找 Workload Match 报告
  26. 在这里,您会找到每个单独的 SQL 语句本身(而不是以分组形式比较它们)之间的性能和准确度统计的比较。您会注意到,它看起来与 Workload Aggregate Match 报告非常相似,只是列所代表的含义略有不同。您可以按照 SQL(而不是时间戳)对报告排序,以便观察与特定 SQL 语句(即,从 invent.services 表选择)有关的指标。让我们单击列名称 Compare-From FULL SQL,并查找记录。
    图 33. 从服务表中选择的 SQL 语句
    该图显示了从服务表中选择的 SQL 语句
  27. 注意

    在报告中有几个值表示特殊的问题,它们通常表示为负值(除非它们出现在显示差异的列中,如 Records Affected Difference)。特殊值 “-1” 表示执行 SQL 语句时的数据库错误,而值 “-2” 代表计数器过载,例如,执行的 SQL 语句所检索的行数超出 Capture Replay 的计数能力。

    如前所述,您已发现从 invent.services 表选择的 18 个 SQL 语句在 DB2 上运行失败。根据该报告,您可以通过查看 Compare-To Success 和 Compare-To Records Affected 列来验证该信息。您稍后会知道如何解决这个问题。

    图 34. SQL 语句无法在 DB2 上运行
    该图显示了 SQL 语句无法在 DB2 上运行
  28. 查看报告的其他部分,您将会发现还有另外一个 SQL 语句(通过更改一个特定项的现有值来更新 invent.services 表),在 DB2 上重放时,它似乎也会失败。同样,您可以通过查看 Compare-To Success 和 Compare-To Records Affected 列来验证这一点。您稍后会知道如何解决这个问题。
    图 35. 失败的 SQL 语句
    该图显示了失败的 SQL 语句
    图 36. 无法在 DB2 上运行的另一组 SQL 语句
    该图显示了无法在 DB2 上运行的另一组 SQL 语句
    提示
    类似于 Workload Aggregate Match 报告,Workload Match 报告显示了来自捕获和重放流量的每个单独的 SQL 语句的执行次数。这是一个强大的特性,可以帮助确定哪些 SQL 运行得最频繁和最少,这让您在转换工作中可以定位需要考虑的 “过时” 代码和 “热” 点。
  29. 此时,在该场景中,有三个问题需要解决:
    1. DB2 重放 Oracle 流量的性能较差
    2. 语句 SQL A 在 DB2 上重放时失败:

      SELECT count(*) FROM invent.services ORDER BY id DESC
    3. SQL 语句 SQL B 在 DB2 上重放时失败:

      UPDATE invent.services SET severity=<severity>, description=<description>,
      serviceOwner=<service_owner>,
      targetCloseDate=(TO_DATE(targetCloseDate) + <num_of_days>)
      WHERE id=<id>
  30. 为了在重放捕获的 Oracle 流量时提高 DB2 性能,您可以执行的任务之一是在所有表上执行 DB2 RUNSTATS 命令。这会更新有关表的特征以及任何关联索引的统计信息,从而使优化器可以确定更好的数据访问路径。打开 DB2 命令行界面并在表上执行 RUNSTATS。这也可以通过 IBM Data Studio 或 DB2 Control Center 的 GUI 来完成。
    图 37. RUNSTATS DB2 命令
    该图显示了 RUNSTATS DB2 命令
  31. 为了解决与这两个 SQL 语句相关的问题,让我们转到 Workload Exceptions 报告。您可以在 Workload Comparisons 选项卡的左侧找到该报告和其他报告。
    图 38. 查找 Workload Exceptions 报告
    该图显示了查找 Workload Exceptions 报告
  32. 在这里,您会看到,在我们的源 Oracle 数据库上捕获运行流量时并没有发现错误,但在测试的 DB2 数据库上重放相同的流量时,您会发现错误。

    图 39. 在捕获 Oracle 的过程中发生的异常
    该图显示了在捕获 Oracle 的过程中发生的异常
    图 40. 在 DB2 上重放的过程中发生的异常
    该图显示了在 DB2 上重放的过程中发生的异常

    单击列名称 SQL string that caused the Exception,在报告中按照 SQL 排序。在发现语句 SQL A 后,您可以看到,错误与 SQL 语句和 DB2 的不兼容有关,而与数据或数据库对象无关。

    图 41. SQL A 异常的解释
    SQL A 异常的解释

    要解决这个问题,您只需要在重放这些 SQL 语句时不使用 ORDER BY 子句。此外,在异常报告中找到语句 SQL B 后,您也可以看到存在与 DB2 的 SQL 兼容性问题。

    图 42. SQL B 异常的解释
    SQL B 异常的解释

    修复这个错误的方法是,在 DB2 上运行时为 TO_DATE() 函数提供一个格式字符串参数(若使用 Oracle,该函数并不需要显式定义一个格式字符串)。

  33. 现在,您已经确定了错误的原因,让我们继续看看 Data Staging 报告,可以在 Workload Comparisons 选项卡的左侧找到它。
    图 43. 查找 Data Staging 报告
    该图显示了查找 Data Staging 报告
  34. 在此报告中,您可以查看在源 Oracle 数据库上捕获,以及在目标 DB2 数据库上重放的每个独立的 SQL 语句。请注意,这和之前看到的是相同的 Data Staging 报告;只是通过界面的另一部分来访问它。在这里,您需要修改所捕获的不兼容的 SQL,那么当再次重放时,在上面识别的特定错误就不会再发生。单击 Full SQL 列,按照 SQL 排序,并查找 SQL A。
    图 44. 在 Data Staging 报告中查找 SQL A 语句
    该图显示了在 Data Staging 报告中查找 SQL A 语句
  35. 单击报告底部的 Invoke,并选择 modify_staging_data
    图 45. 调用 modify_staging_data GuardAPI 函数
    该图显示了调用 modify_staging_data GuardAPI 函数
  36. 在这里,您可以同时修改多个 SQL 语句。您只需要在左侧为与 SQL A 有关的每个记录选中一个复选框。

    图 46. 为 SQL A 语句选中复选框
    该图显示了为 SQL A 语句选中复选框

    然后,您必须用新的 SQL 语句填写 toSQL 列:SELECT count(*) FROM invent.services

    单击 Invoke now 并关闭出现的所有弹出窗口,返回主界面。

    图 47. 修改 SQL 语句
    该图显示了修改 SQL 语句

    刷新 Data Staging 报告后,您可以看到不兼容的 SQL A 语句已被正确地修改。

    图 48. Data Staging 报告中修改后的 SQL A 语句
    该图显示了 Data Staging 报告中修改后的 SQL A 语句
  37. 您需要再次修改暂存的数据,以便解决 SQL B 的不兼容问题。用于替换原语句的新 SQL 语句是:
    UPDATE invent.services SET severity=<severity>,description=<description>, 
    serviceOwner=<service_owner>,
    targetCloseDate=(TO_DATE(targetCloseDate + <num_of_days>,'YYYY-MM-DD HH24:MI:SS')) 
    WHERE id=<id>.
    图 49. Data Staging 报告中修改后的 SQL B 语句
    该图显示了 Data Staging 报告中修改后的 SQL B 语句
  38. 现在,您已经修改了暂存数据,并调优了 DB2 测试数据库,再次重放捕获的流量。返回到 Replay Builder,突出显示 Replay Configuration > migration_replay,然后单击 Replay
    图 50. 通过 Replay Builder 返回 Replay
    该图显示了通过 Replay Builder 返回 Replay
  39. 选择 Replay Schedule Setup > replay_on_DB2,单击 Run Once Now,然后在确认消息框中单击 OK

    图 51. 再次运行 Replay Schedule Setup
    该图显示了再次运行 Replay Schedule Setup

    注意

    您不需要使用 GuardAPI 函数生成额外的报告,比如这次的 Workload Aggregate Match 和 Workload Match,因为您将不会使用它们。

    返回到 Job Queue 并等待重放完成。一旦完成,单击 Capture/Replay > Replay/Replay List 选项卡。在这里,您将能够生成有关在两次重放之间进行比较的详细信息。在本例中,它将是在您的测试数据库上的第一次和第二次(在修改一些 SQL 语句并调优 DB2 数据库之后)重放之间的比较。双击 Replay/Replay 记录并单击 View Workload Comparison

    请注意,这就是您想要的记录,因为 Name-From 列代表您的第一次重放日程安排设置,而 Name-To 表示您的第二次重放日程安排设置。

    图 52. 在 Replay/Replay 列表选项卡中查看工作负载比较
    该图显示了在 Replay/Replay 列表选项卡中的工作负载比较
  40. 在数据编译完成后,单击 Take me there
    图 53. Workload Comparison 的数据编译进程
    该图显示了 Workload Comparison 的数据编译进程
  41. 您将被立即带到 Summary Comparison 报告。您会看到,在第二次重放期间,经过基本的数据库调优后,我们的 DB2 数据库性能已大幅提高。

    图 54. 比较 Avg Execution Time(提高的 DB2 性能)
    该图显示了比较 Avg Execution Time(提高的 DB2 性能)

    在您的第二次重放过程中,因为修改了捕获的 Oracle 流量中不兼容的 SQL 语句,失败的数量已大幅减少。

    图 55. 比较 SQL Failures(失败的数量减少)
    该图显示了比较 SQL Failures(失败的数量减少)
  42. 为了验证以前不兼容的 SQL 语句不会再造成任何错误,转到 Workload Exceptions 报告。
    图 56. 查找 Workload Exceptions 报告
    该图显示了查找 Workload Exceptions 报告
  43. 注意

    查看报告后,您可以看到所有流量中只有 3.5% 是由于 SQL 的不兼容性导致的失败(37 个错误与 1047 个 SQL 语句),因为大多数的失败只是同一个不兼容 SQL 语句的重复执行。

    在这里,您将发现,在您的测试 DB2 数据库上的第二次重放中只存在一个错误。该错误与在 Oracle 流量中捕获的一个过程有关,该过程最初在启动 Oracle SQL * Plus 界面进行调试时被调用。由于 DB2 没有此过程,在下次重放时可删除该 SQL,以便减少错误的数量。

    除此之外,其他所有先前的错误都已得到解决。您现在知道,需要在应用层对这些 SQL 语句进行修改,以防止在生产中发生相同类型的错误。

    图 57. Staged Data 修改之后的 Workload Exceptions 报告
    该图显示了 Staged Data 修改之后的 Workload exceptions 报告

    现在,您已经识别了性能和 SQL 兼容性问题,并解决了它们,从而完成了该场景。利用 Capture Replay 的 Capture/Replay 和 Replay/Replay 比较功能,以及 Summary Comparison、Workload Aggregate Match、Workload Match 和 Workload Exception 等报告,通过类似的方式,可以发现并解决其他迁移问题。


结束语

Capture Replay 让您可以正确地处理企业变更。通过利用其简单的捕获和重放功能,企业可以绕过创建脚本模拟生产工作负载这个艰苦的过程。凭借其强大的比较功能,企业可以迅速识别和解决这些变更所导致的问题。此外,在估计迁移项目的初始硬件和存储要求时,简单的工作负载捕获功能为专家提供了一个更加坚实的基础。Capture Replay 也可以与您现有的测试工具配合使用,为您的生产和测试数据提供更全面的分析。

能够轻松地捕获生产工作负载,并在测试环境中自定义重放,而无需破坏应用程序层本身,这是非常有价值的,在测试数据库升级、迁移和硬件配置时尤其如此。能够快速有效地映射生产环境,就可以在测试阶段实现迅速性。加速测试周期可以带来更快的产品交付,这反过来会转化为更高的企业收入。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=841826
ArticleTitle=使用 InfoSphere Optim Query Capture and Replay 评估数据库迁移
publish-date=10222012