聊聊REDO APPLY的性能问题

这些天有点冷了,人也总想找借口偷懒。昨天因为要赶着提交pgconf 2021的演讲视频,所以早上就偷了下懒,没有动笔。一大早到了办公室后就发了个把小时呆,思考演讲PPT如何录制。还是有点小作用的,下午找了个会议室,一次性录制完成,一看时间,正好和组委会要求的30分钟相差不大。今早依然想习惯性的继续偷懒,看到微信公众号上有网友留言希望了解一些关于提高ADG RECOVERY吞吐量的知识。既然这么早坐在电脑前,茶也泡好了,那今天就聊聊关于ADG Media RECOVERY 性能相关的事情吧。

其实Oracle的ADG相关的资料,最好的莫过于ORACLE MAA系列资料中的一系列Best Pratices,即最佳实践系列。在ADG MEDIA RECOVERY性能方面,也有一份这样的文档:

聊聊REDO APPLY的性能问题

这篇文档里详细介绍了Oracle Redo Apply的一些相关的最佳实践,包括环境优化、参数配置、性能调优、延时分析等。

聊聊REDO APPLY的性能问题

如果你能够耐下心来认真阅读这不到10页的文字,就会有很大的收获。今天文章的最前面,我先介绍一下这篇文章中的一些建议。首先是STANDBY REDO LOG的大小建议。针对不同的REDO 量,对STANDBY REDO LOG的建议是不同的,其主要优化要点是减少日志切换。因为对于Oracle数据库来说,日志切换是十分高开销的操作。

上表列出了针对你的系统的高峰期的平均REDO产生频率,建议的REDO LOG文件的大小。这个大小是针对应用延时要求较高的环境的,可以尽可能让你的主库与STANDBY的延时处于毫秒级。在这份MAA中,还以重要提示的形势提示对于平均REDO量的采集一定要使用小时间间隔,AWR报告这种一小时平均值,可能会把PEEK TIME的值缩小数倍,是不适用的。

另外针对STANDBY REDO LOG GROUP的配置,也需要按照一个最佳的配置策略来进行配置。STANDBY REDO LOG大小要和生产库的REDO LOG完全一致,并且从性能考虑,STANDBY REDO LOG组绝对不能使用镜像,也就是每个组只能设置一个成员。对于STANDB BY REDO LOG GROUP的数量,针对每个实例(thread),STANDBY REDO LOG组的数量要比主库REDO LOG GROUP 的数量多一个。

如果我们要做准实时REDO APPLY,以支持应用系统读写分离业务的需求,那么STANDBY REDO LOG存储的位置的IO读写延时要和主库REDO LOG的存储相当,并且能够支持足够的读写IOPS。这一点对于减少APPLY LAG至关重要。因为为了节约投资,绝大多数的STANDBY 系统的存储都会使用性能略低的存储,这样就会导致在业务高峰时STANDBY的REDO APPLY延时过大。如果你的STANDBY 库的存储有多级分层,那么最好把STANDBY REDO LOG放到SSD盘上。

对于数据保护参数的设置,MAA建议为所有主数据库和备用数据库设置 DB_BLOCK_CHECKING=FULL 和 DB_LOST_WRITE_PROTECT=TYPICAL,以防止和检测物理块损坏和丢失写入。当然,如果你的备库的存储性能较差,那么在备库上设置 DB_BLOCK_CHECKING=MED可以减少高峰时的REDO APPLY LAG,虽然Oracle并不建议这么做。因为一旦出现逻辑坏块,那么可能会引发更大的LAG。另外,在备用数据库上将 DB_LOST_WRITE_PROTECT 参数设置为 TYPICAL,以便于检测 I/O 子系统中丢失的写操作。对于 OLTP应用负载,这个参数设置对重做应用的影响小于 5%。如果你确实需要进一步减少LAG的时候,这个参数的设置可以作为你最后的选择,当然牺牲的也是可靠性。

STANDBY DB上的REDO APPLY也是要使用DB CACHE的,因此DB CACHE的大小和DBWR的性能优化也十分重要。设置一个尽可能的DB CACHE,以及使用异步IO,调整好CHECKPOINT相关的参数对于REDO APPLY性能也影响很大。这方面的优化和主库上的相关优化策略类似,这里就不做过多的解释了。

对于REDO APPLY的性能,其主要和两方面因素有关,一方面是系统能够提供那个的资源(CPU,内存,IO等),另外一方面是主库负载的类型。第一个方面大家可以理解,REDO APPLY需要OS提供足够的资源,在ADG没有出现之前,REDO APPLY的服务器资源一直是十分充裕的,不过随着现在越来越多的客户把一些只读任务分流到ADG上,服务器资源竞争也是时常会出现的。前几天我介绍的哪个银行,在ADG服务器上的每秒逻辑读的高峰期复杂,甚至比主库上还要高5-6倍。这种情况下,业务负载和REDO APPLY往往会产生资源竞争,因此在分析REDO APPLY LAG的时候,也不要忽视这方面的因素。

第二个方面可能大家会有些疑问,不都是通过REDO去修改数据文件吗,为啥不同的应用应用负载会对REDO APPLY产生较大的影响呢?实际上也很好理解,对于OLTP负载,REDO APPLY可能会产生较为密集的小的随机读写IO,而对于批量写入的OLAP负载或者数据装载负载,其IO类型可能以顺序读写为主。如果IO子系统的性能卓越,这点差异可能还不会产生太大的不同,如果IO子系统的性能一般,这方面的差异就会被放大很多了。

从Oracle 12.2开始,Multi-Instance Redo Apply (MIRA)功能被引入了,可以在多个STANDBY实例上启用REDO APPLY,这对于需要尽可能低的REDO APPLY LAG的超大型系统是一个福音,大胆的启用MIRA,可以大大缓解高峰期的REDO APPLY LAG问题。

这是MAA上Oracle给出的一个OLTP工作负载的REDO APPLY的流量数据,当然这个测试环境是一个纯粹REDO APPLY的环境,并没有任何只读业务在上面运行,当系统中有大量只读业务的时候,这个数据可能会有较大的缩水。这个图也可以作为一个参考,用于我们评估自己系统的REDO APPLY的性能。大家要注意的是,除了第一个数据之外,其他的数据都是在EXADATA上产生的。这个图表可以作为一个理论极限的基线,而不能直接和我们的生产系统对比。

上图是批处理业务模式下的REDO APPLY负载,大家可以看出,批处理环境下,因为IO类型的不同,吞吐量有较大的提高。

最后要讨论的是并行恢复的并行度设置问题。REDO APPLY的并行度并不能通过RECOVERY_PARALLELISM参数设置来起作用,而是要在启动恢复的时候在ALTER DATABASE RECOVER MANAGED STANDBY DATABASE命令中指定。如果你不指定,那么系统自动会根据CPU_COUNT来设置并行恢复的并发度。如果你的服务器上只有并行恢复一个任务,没有承担只读操作的负载,那么这种自动指定并发度的影响还不会很大,因为你也不是特别关注是否在高峰期存在几分钟的LAG。而当你的系统作为准实时只读库来使用的时候,设置合理的并发度是否关键。

首先在你这个环境中不能把CPU的所有线程都设置为REDO APPLY,需要平衡你的SQL执行与REDO APPLY之间的资源,根据你的业务负载来适当减少REDO APPLY的并行度。

其次是,当你的STANDBY库的IO能力有限的时候,更多的REDO APPLY并行度并不能让你的恢复操作更快,REDO APPLY的并行度需要根据STANDBY数据库的IO能力来做合适的调整。


















聊聊REDO APPLY的性能问题》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/381.html