闪回数据库的最佳实践和性能

适用于：

目的：

一些应用配置文件可能需要特别的调整或者额外的考虑当开启闪回数据库或者使用生成还原点的时候。这个笔记描述了闪回数据库的调整的最佳实践和特定应用案例的考虑因素。

范围和应用

该笔记是为正在使用或考虑使用闪回数据库或者生成还原点的数据库管理员准备的

闪回数据库是企业版10g的一个新特性可以用于快速的闪回数据库到一个时间点和传统的时间点恢复是相对应的，除了在时间点恢复使用外，闪回数据同时用于：

1．  Data Guard Fast-start failover，尽快恢复主数据库。

2．  11g Data Guard 快照备份（Note 443720.1 11g Using Snapshot Standby Database）当物理备用数据库转换成一个快照备用数据库，一个隐藏的保证还原点被创建，并且改还原点用于闪回一个快照备份到它原始的状态当它转换到一个物理备用数据库。

3．  数据库升级失败的回滚 — 使用闪回数据库而不是传统的降级程序，速度会快很多，只有当数据库已经升级并且没有应用数据发生改变，它才是可以实现的。

4．  利用瞬间逻辑备份库滚动升级物理备份库- 数据库的一部分滚动升级当物理备份被暂时的转换为逻辑备份，一个保证还原点在升级程序之前应在主数据库上被建立。这就是为什么数据库在升级之后可以被闪回并且转换回到物理备份。更多的详细信息请参看MAA paper "Rolling Database Upgrades for Physical Standby Databases using Transient Logical Standby 11g".

5．  RMAN - 闪回数据库综合了ORACLE 恢复管理器和使用后台恢复、前台恢复如果有需求。一个11g使用隐示恢复的例子，即当块介质恢复被执行的时候。

6．  手动恢复主库——如果Data Guard没有使用快速故障启动特性并且Data Guard故障不可避免，那么闪回数据库可以被用于手动的恢复故障的主库。这记录在DATA GUARD管理和概念指南。

7．  11g之前版本读写访问物理备份——在10.2你可以利用一个物理备份数据库来测试和其他用途需求读写访问备份库。当完成了测试的数据库可以闪回到一个物理备份用于容灾保护。这接近于11g的快照备份特性，但是不像11g的特性，当物理备份是open 读写的时候，重做是不接受的。更多的设置read-write详细信息可以在10.2快照备份中被闪回。

8．  恢复测试和训练系统。闪回另一个常见的用处就是闪回一个测试或培训库，在跑完测试或者培训之后回到初始的起点。

闪回数据库最佳实践和执行

闪回数据库最佳实践

* 了解你的基线，事先确定能够使用的闪回开销和评估开启闪回数据库的应用程序的工作量      

     影响。请参阅“分析性能的影响”。

*   确定闪回恢复区域空间足够用于装载数据库闪回日志。估算闪回恢复区的方法在10g   数据库备份和恢复基本指南或11g备份和恢复用户指南中有详细提到。一个常用的一般经验法则就是注意闪回日志产生的卷大小，它大概近似于重做日志产生的大小。例如，如果你打算把DB_FLASHBACK_RETENTION_TARGET 设置为24小时，并且如果数据库一天产生20GB的重做数据，根据一般经验应该分配20到30GB的磁盘空间给闪回日志。相同的法则可以应用于保证还原点。例如，如果数据库每天生成20GB重做数据，如果保证还原点保留一天的话，那么应该指派20到30GB。注意DB_FLASHBACK_RETENTION_TARGET只是一个目标并且没有保证你就一定能把数据库闪回到那么远。在一些情况下如果存在闪回恢复区域存在空间压力，那么最老的闪回日志将有可能被删除。更多的关于闪回区域删除法则说明请参照"11g Backup and Recovery User's Guide, Maintaining the Flash Recovery Area section. To guarantee a flashback point-in-time you must use guaranteed restore points.

* 企业管理器监控指标，"Recovery Area Free Space (%)" 在闪回恢复区域空间不足能主动报警

*  确保闪回恢复区有充分的I/O带宽。在自动负载信息库（AWR）里面经常可以看到等待事

     件的报告"FLASHBACK BUF FREE BY RVWR"  这就是由闪回带宽I/O不足引起的。

*  Set LOG_BUFFER 至少设置为8M以给予闪回数据库更多的缓冲内存空间。对于         

     11.1.0.7+数据库拥有超过4GB的SGA，你可能需要考虑将LOG_BUFFER设置为

*  按照介质恢复的最佳实践"Data Guard Redo Apply & Media Recovery" 最少设置

     PARALLEL_EXECUTION_MESSAGE_SIZE为8192.这将改善任何闪回操作的介质恢复。

*   如果你有一个备库，并且将其的 DB_FLASHBACK_RETENTION_TARGET 设置为与主库相同的值。那么当使用故障快速切换的时候，请确保备库的UNDO_RETENTION 与DB_FLASHBACK_RETENTION_TARGET参数至少设置为120，这样的话，即使出现长时间的停机，还原也是可以进行的。 在备库上，闪回边界并不会像主库一样，保证30分钟发布一次，也就是说，当在备库启用闪回功能时，DB_FLASHBACK_RETENTION_TARGET值至少要设定为120。既然前面提到主库与备库是一致的，那么也暗示着主库也必须做相同的设置（即：将同样主库的UNDO_RETENTION 与DB_FLASHBACK_RETENTION_TARGET参数至少设置为120）

*  同时参看10g数据库备份和恢复基础指南或者11g备份和恢复用户指南。

*  为了获得最佳性能当在一个数据库上启用闪回数据库，用LOB或者SecurefilesLOB

     数据类型，请使用CACHE设置。

*  RDBMS11.2不要求数据库处于挂载状态来闪回数据库。也就是说11.2再往后，它就

     不需要重启数据库到mount状态来闪回数据库了。

*  在11.2实际应用集群数据库可以采用一个新的优化，从而减少闪回数据库对性能的影响。请参阅补丁：:9184513获得更多的信息

*  要监视闪回数据库操作的进度，你可以查询V$SESSION_LONGOPS视图。一个查询监控进度的例子：

   如果需要获得更多的闪回数据库操作细节，那么可以将_flashback_verbose_info数据库参数设置为TRUE，它将在BACKGROUND_DUMP_DEST目录中产生详细的闪回数据库操作跟踪信息。

对性能影响的分析

当开启了闪回数据库或者使用保留还原点你应该遵循以下步骤开启闪回数据库的性能影响分析：

1、在工作量高峰期，在测试和生产中使用自动负载信息库获取性能基线。这是需要使用AWR的一个诊断包许可证，如果你没有，那么你也可以使用Statspack，参看Note 94224.1 "FAQ- Statspack Complete Reference".基线包含了一些性能数据，这些是来自于一个指定的时间段。即被保留下来用于比较相似负载情况的时间段。在创建一个固定的基线之前，仔细的考虑你选择作为基线的时间段，因为基线代表系统运行在最佳水平。这条基线（闪回数据库是关闭的）将用于评估闪回数据库对你的应用的影响。参照ORACLE性能调优指南第五章获取更多关于如何使用AWR获取基线的技术信息。注意如果你有任何大的周期性的批处理任务你也要获取他们的AWR快照。

2、打开闪回数据库在你的测试环境中或者如果你在11g版本RDMS并有一个物理备份库，那么你可以闪回数据库在你的物理备份上并转换它成为一个快照备份（这在10.2中也可以通过手动快照备份办到，但是在11g中没有被应用。参照Dell 10g Snapshot Standby）。Then when you run a workload against the snapshot standby it will be with flashback database logging enabled.

3、在工作量高峰期测试运行获得AWR快照。要在所有大工作量作业也是一样的做法。

     如果你在使用一个来自于生产的快照备份，then run a realistic workload against the snapshot standby,获得一样的AWR快照同无闪回性能基线相比较。

4、运行一个AWR的比较报告($ORACLE_HOME/rdbms/admin/awrddrpt.sql)来比较基线快照和闪回数据库快照。该报告每个统计、度量和等待事件将有一个"% Diff"列。检查区别并且评估影响是否是可以接受的。一般来说要关注redo生成的速率（redo大小）和每秒的事务数（TPS,事务报告）。如何你经常看到"FLASHBACK BUF FREE BY RVWR"等待事件那么这可能说明没有足够的磁盘子系统给闪回恢复区。你也看以使用非AWR指标诸如OLTP的应答事件和批处理的运行时间。

5、当在一个类生产测试环境执行闪回数据库，这应该是一个很好关于闪回数据库运行对生产的影响的指标，生产备份库是一个更准确的评估。如果可行的话，你应该在生产库上重复测试。

已知的高性能的影响因素

通常来说由于在主数据库上开启闪回数据库引起的OLTP类型的工作量开销一般会小于2%.

但是插入密集型LOB工作量和直接载入类型的工作量开销将产生高达30%的开销。

1、  对于插入密集型应用程序，开启数据库闪回的影响可能是不可接受的。以上的分析是通过每个事务物理读的影响和每秒重做数据生成的速率的观察得出的。

2、  在闪回数据库打开的情况下，插入密集型批处理作业可能会有30%的影响。

一般而言，RDBMS11.1.0.6版本提高了批处理性能当闪回数据库打开的时候。The performance impact was negligible once the DB_FLASHBACK_RETENTION_TARGET was met.但这个改进在RAC环境下不能支持。

3、  在11.1.0.7版本之前SQL*Loader并行直接路径装载会有一个持续的性能下降当闪回数据库开启的时候，这是发生了隐式的段压缩。这个问题在11.1.0.7中得到修正。

4、   截断表的插入密集型应用可以产生高的开销当闪回数据库打开的时候直到DB_FLASHBACK_RETENTION_TARGET时间过去。例如，如果DB_FLASHBACK_RETENTION_TARGET=240（4小时），而后截断表，在截断表的四个小时内，任何对该表的插入操作可能会产生大于20%的数据库性能损失。在这4小时的时期过去之后，这个性能影响将减少到低于2%。

5、   还可能存在这种情况在一个已经调整好的闪回恢复区，经常发生"FLASHBACK BUF FREE BY RVWR"等待事件。参看Bug 6168063.这个问题在RDBMS 11.1.0.7 和 10.2.0.4中得到修正。并且在. 10.2.0.3有适用于大多数平台的补丁可用。9032717

6、   如果使用ORACLE SecureFiles 那么请应用补丁9032717来避免间歇性的"FLASHBACK BUF FREE BY RVWR"等待事件高峰。

参考文献

显示相关信息

产品

关键词