• 确定使用数据库重放的优点
• 列出数据库重放所涉及的步骤
• 使用Enterprise Manager 记录和重放工作量
- 为什么使用数据库重放
• 系统更改(如硬件和软件升级)是不可避免的。
• 客户需要在实施更改前确定更改的全面影响。
• 大量的测试和验证可能会花费很多的时间和资金。
• 测试除了成本昂贵之外,成功率还很低:
– 许多问题未被检测到。
– 更改可能会对系统的可用性和性能产生负面影响。
• 成功率低的原因:
– 无法使用实际的生产工作量进行正确的测试,有许多问题未被
检测到。
• 数据库重放功能使你可以执行与实际情况相符合的测试。
为什么使用数据库重放?
大型业务关键应用程序不但复杂,而且负载模式和使用模式也相当多。与此同时,这些业
务系统要在响应时间、吞吐量、运行时间和可用性方面提供特定服务级别的保证。对系统
的任何更改(如升级数据库或修改配置)通常都需要进行全面的测试和验证,然后才能在
生产系统中实施这些更改。在移到生产系统之前为了保证安全,数据库管理员(DBA) 需
要让测试系统承受与生产环境中的工作量很近似的工作量。DBA 使用一种有效的方式分
析系统级更改对整体SQL 性能的影响也很有益处,因为这样便可以在生产之前对更改执
行任何必要的优化。
- 数据库重放
• 在测试环境中重新创建实际的生产数据库工作量。
• 在生产中实施更改之前,确定和分析潜在的不稳定性。
• 捕获生产中的工作量:
– 捕获带有实际负载和并发度的完整生产工作量
– 将捕获的工作量移到测试系统
• 在测试中重放工作量:
– 在测试系统中进行所需的更改
– 重放带有生产负载和并发度的工作量
– 采用提交顺序
• 分析和报告:
– 错误
– 数据差异
– 性能差异
数据库重放
针对之前列出的挑战,Oracle Database 11 g 提供了具体的解决方案。
通过数据库重放,在将实际的工作量放到生产系统之前,可以在测试系统上重放实际工作
量,从而测试系统更改的影响。记录数据库服务器在一段有代表性的时段(例如高峰期
间)内的生产工作量(包括事务处理并发度和相关性)。此记录数据用于在经过适当配置
的测试系统上重放工作量。通过在测试系统中使数据库服务器承受与生产工作量几乎相同
的工作量,可以在数据库更改获得整体成功方面获得高度的信心。
- 系统体系结构:捕获
系统体系结构:捕获
图中展示了一个正在进行记录的系统。应始终记录生产系统中某个“你所关注的”期
间内的工作量。一般情况下,可通过重放记录来确定升级到新版本的RDBMS 服务器是否
安全。在系统中运行生产工作量时,内置到RDBMS 中的一种特殊记录基础结构可以记录
有关所有外部客户机请求的数据。外部请求包括所有SQL 查询、PL/SQL 块、PL/SQL 远
程过程调用、DML 语句、DDL 语句、对象导航请求或Oracle Call Interface (OCI) 调用。
在记录过程中,后台作业以及通常情况下的所有内部客户机将继续工作,不会被记录。最
终结果是一份工作量记录,其中包含重放工作量所必需的全部信息;RDBMS 可通过外部
请求来查看这些信息。
记录基础结构只会对记录系统造成最低的性能开销(额外的CPU 、内存和输出/ 输出)。
但是,应计划配备额外的磁盘空间用于记录实际工作量。
RAC 说明:RAC 环境中的实例可以访问公用数据库文件。但是,它们不需要共享公用的
通用文件系统。在这样的环境中,工作量记录会在记录过程中写入各个实例的文件系统。
为了进行处理和重放,需要将工作量记录的所有部分手动复制到单个目录中。
- 系统体系结构:处理工作量
系统体系结构:处理工作量
处理工作量捕获数据,创建特定于新工作量重放的元数据文件,这是重放指定工作量捕获
所必需的。仅创建新文件,而不对工作量捕获过程中创建的任何文件进行修改。因此,可
以对相同的捕获目录多次运行预处理(例如,过程遇到意外错误或被取消时)。
在此阶段中,将重新映射外部客户机连接。可以修改会影响重放结果的所有重放参数。
注:因为处理工作量捕获的成本可能相对较高,所以最好的做法是在生产数据库系统以外
的某个系统中执行该操作。
- 系统体系结构:重放
系统体系结构:重放
在重放系统中重放工作量之前,务必执行以下操作:
1. 在测试系统中还原重放数据库,以便与工作量捕获开始时的捕获数据库匹配。
2. 根据需要更改测试系统(如执行升级等)。
3. 将工作量复制到测试系统。
一个名为“重放驱动程序”的特殊应用程序将使用工作量记录,向在其中重放工作量的
RDBMS 发送请求。该 RDBMS 通常是一个测试系统。假定重放系统的数据库适合于重放
已记录的工作量。不会重放内部RDBMS 客户机。重放驱动程序是一种特殊客户机,它使
用工作量记录并向测试系统发送相应的请求,其行为与记录工作量过程中使用的客户机在
发送外部请求时的行为相同(参见前面的示例)。使用其行为与RDBMS 的唯一外部客户
机相同的特殊驱动程序,可以记录和重放客户机不可知的基础结构。
重放驱动程序包含一个或多个连接到重放系统的客户机,并且可以根据工作量捕获发送请
求。重放驱动程序可以根据网络带宽、CPU 和内存容量,在所有重放客户机之间均匀分
配工作量捕获流。
- 更改前生产系统
更改前生产系统
数据库重放侧重于记录和重放RDBMS 所承受的工作量。因此,记录工作量的操作是在
图中所示的位置完成的。在软件堆栈中的RDBMS 上进行记录可实现此级别以下的所
有项目交换,并可使用记录和重放功能测试新的设置。
在重放工作量时,RDBMS 将执行记录过程中发现的操作。也就是说,RDBMS 代码在重
放阶段的行为方式与记录阶段的行为方式非常相似。这是通过重新创建所有外部客户机对
RDBMS 的请求实现的。外部客户机请求包括了 RDBMS 的所有可能的外部客户机发出的
请求。
- 支持的工作量
• 支持的工作量:
– 包含几乎所有类型的绑定的所有SQL(DML、DDL、
PL/SQL)
– 完整的LOB 功能(基于游标和直接OCI)
– 本地事务处理
– 登录和注销
– 会话切换
– 有限的PL/SQL RPC
• 限制:
– 直接路径加载、导入/导出
– 基于OCI 的对象导航(ADT) 和REF 绑定
– 流、非基于PL/SQL 的AQ
– 分布式事务处理、远程描述/提交操作
– 闪回(数据库和查询)
– 共享服务器
支持的工作量
以上显示了支持的和不支持的数据库操作。
注:也会捕获基于 SQL 的XML 操作。系统仅捕获显式的SQL 语句(客户机发布的SQL
语句)。不会捕获数据库本身生成的隐式调用。例如,审计是隐式的,类似后台进程活动
是隐式的。
- 捕获注意事项
计划:
• 为捕获的工作量(二进制文件)留出足够的磁盘空间
• 数据库重新启动:
– 确保重放与实际情况相符的唯一方式
— 启动限制
— 捕获将取消限制
– 可能不是必需的(取决于工作量)
• 还原数据库以进行重放的一种方式:
– 物理还原(提供顺序/时间)
– 逻辑还原应用程序数据
– 闪回/ 快照备用
• 可以指定过滤器来捕获部分工作量
• SYSDBA 或SYSOPER权限和相应的OS 权限
开销:
• TPCC 的性能开销为4.5%
• 内存开销:每个会话64 KB
• 磁盘空间
捕获注意事项
在工作量记录的计划阶段要执行以下任务:
• 检查数据库备份策略,确保在记录开始时数据库可被还原为StartSCN 。
• 计划捕获期间:根据应用情况和峰值期间选择捕获期间。可以使用现有的可管理性功
能,如自动工作量资料档案库(AWR) 和活动会话历史记录(ASH) ,根据工作量历史
记录选择一个恰当的期间。应谨慎计划捕获的开始时间,因为建议的操作是在捕获开
始前关闭并重新启动数据库。
• 指定工作量捕获数据的位置。必须设置用于存储工作量捕获数据的目录。应提供充足
的磁盘空间,因为磁盘空间不足时记录会停止。但是,在停止之前捕获的所有内容仍
可用于重放。
• 定义捕获过滤器,过滤掉不捕获的用户会话。可以指定记录过滤器以跳过不应捕获的
会话。
• 数据库重放功能没有引入任何新的权限或用户角色。记录用户和重放用户必须具有
SYSDBA 权限或SYSOPER权限。这是因为仅具备SYSOPER权限或SYSDBA 权限的
用户才可以启动或关闭开始记录的数据库。还应分配正确的操作系统(OS) 权限,以
便用户能够访问记录、重放目录以及操作这些目录下的文件。
- 重放注意事项
• 预处理捕获的工作量:
– 一次性的操作
– 在与重放时使用版本相同的 DB 版本上
– 如果版本匹配,可在任何位置(生产系统、测试系统或
其它系统)执行
• 还原数据库,然后执行更改:
– 升级
– 方案更改
– OS 更改
– 硬件更改
– 添加实例
重放注意事项
预处理阶段是必需的针对指定数据库版本的一次性操作。创建了必需的元数据以后,可以
按需要多次重放工作量。
必须还原重放数据库,以便与工作量捕获开始时的捕获数据库匹配。成功的重放取决于应
用程序事务处理,该事务处理要访问与捕获系统上的数据相同的应用程序数据。可以选择
使用时间点恢复、闪回和导入/ 导出来还原应用程序数据。
- 重放注意事项
• 管理外部交互
– 重新映射用于工作量的连接字符串:
— 一对一:用于简单的实例对实例重新映射
— 多对一:使用负载平衡器(如单节点对RAC)