Oracle DRM引发的一次数据库重启

IT那活儿 2024-04-09

347

点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！

背景描述

某天，某库两节点实例先后发生重启，实例重启前alter日志同时出现IPC Send timeout detected IPC超时。

版本信息：

操作系统：AIX 7100-04-07-1845(SP07)
数据库版本：oracle 11.2.0.4.0 两节点RAC

问题定位

2.1 日志分析

节点1 alert日志：

节点2 alert日志：

日志中DRM相关操作：

23:23:01分节点1、节点2同时出现IPC Send timeout detected IPC超时；
23:24:48节点2 LMS进程终止了自己的实例，随后节点1 在23:24:58由PMON进程终止了自己的实例；
数据库alert 首先出现IPC Send timeout，IPC超时，随后节点2被驱逐，节点1也终止自己的实例。

出现IPC Send timeout可能的原因：

在RAC中，数据库进程，例如LMON,LMD和LMS会不断地和其他实例的进程通信。LMD0负责管理enqueue,LMS进程负责管理数据块资源并传输数据块以支持Cache Fusion。

如果这些进程中的一个或者多个受阻、死循环或异常繁忙，则可能导致PC Send timeout（IPC发送超时）错误。--当时的相关进程都在做DRM操作，分析此次数据库重启为DRM特性导致。

lmon、lms 和 lmd 进程报告"IPC send timeout"错误的另一个原因是网络问题或服务器资源（CPU 和内存）问题。这些进程可能无法获得 CPU 运行调度或这些进程发送的网络数据包丢失。--主机CPU、内存资源当时并不繁忙。

2.2 DRM特性

DRM是Dynamic Remastering的缩写，PCM资源的主节点是资源第一次被访问的时候通过HASH算法决定的，除非有节点离开或者假如集群，否则PCM资源的主节点是不会发生改变的。DRM特性就是内存融合允许PCM资源的主节点根据资源在各个节点的访问情况动态调整。

对于DRM，我们需要了解以下概念：

主节点（Mater）
对于RAC系统,由于数据库同时存在多个实例，而且每个实例都会对资源(PCM 数据块,NON-PCM 各种锁资源)进行访问。也就是说GRD中的资源需要能够被多个实例同时访问,这就需要有存在一个协调者记录对应资源上的锁信息，并协调来自于多个实例的资源申请。
主节点(Master)就是用于保存资源的定义以及上面所有锁的信息，并负责协调资源申请节点。而Oracle主节点组织方式是集群中的每个节点都是资源的主节点，每个节点负责一部分资源。这种方式的优点是，工作负载被分配到各个节点，而主节点主出现问题时，资源重构的时间很短，不会影响系统的高可用性和性能。
当然，这种结构也会有些负面影响，例如：节点间的消息交互会变多，而且有些信息会被存放多份当一个资源第一次被访问的时候，Oracle会根据HASH算法计算出资源所对于的主节点，并将这个资源的定义信息,以及资源上所有的锁信息都保存在主节点上。但是这样做会使每一次访问都去访问主节点，从而增加实例间的信息交互量。

根据上面的描述，可以理解为：

在Oracle数据库中，无论多少个节点对于某个资源的操作，最多只会有3种节点参与：资源申请节点，资源主节点和资源持有者节点。如下图：

整个访问过程如下：

1）资源申请节点发送申请到主节点

2）资源主节点将对应的请求发送给资源持有节点

3）资源持有节点将本地持有的资源锁进行相应的改变，之后将资源发送给资源申请节点

4）资源申请节点获得了需要的资源，并通知资源的主节点更新资源的相关锁信息

说明：

上图当中的3种节点参与的资源申请过程，也是最复杂的过程。在实际应用当中，这种情况不会在每次申请资源时都发生。很多情况下，一个资源的操作只会涉及两个实例(例如：资源的申请节点和主节点在同一个节点，资源的主节点和持有者节点是同一个节点)，或者一个实例(三个节点都是同一个节点)， RAC里面偶尔看到的等待事件 gc ... 2-way gc ... 3-way,就是一个资源申请的过程涉及到3种节点或者两种节点的等待。

DRM的主要功能：

根据一段时间内（默认10分钟），每个实例，对某一个数据库对象的 (10gR1以数据文件为单位)的访问次数和方式，来决定数据库对象对应的buffer应该被mastering 到哪一个实例。

在指定时间内，如果某一个实例访问某个数据库对象次数高于其他实例一定倍数（默认50倍），则oracle 会把这个对象所有的buffer的master信息，转移到对应实例（注意：不是转移buffer）。

当然，转移的过程是渐进式的。当oracle 决定将一个buffer的master实例确定到本地实例后，会对这个buffer上加上affinity lock，来实现快速的访问。这也是我们经常提到的object affinity 的由来。

DRM过程：

Oracle停止所有在需要进行remastering的buffer上的操作。注意：DRM是渐进的，也就是说以windows为单位，每次对一部分的buffer 进行remastering 操作。
Lmon 通知所有实例，准备进行remastering。
在旧的master实例清除对应buffer的master信息。
将master信息传递给新的master实例。
在新的master实例构建资源的最新状态。
结束，并释放所有之前所有步骤占用的资源。

DRM 优点：

不需要reconfig，即能完成resource的remaster操作；
该特性的设计初衷是为了降低跨节点频繁访问需求，通过更改所访问资源的master node。

DRM的弊端：

在进程DRM操作的过程中，Oracle会将该资源的相关信息进行临时frozen，然后将该资源在其他节点进行unfrozen，然后更改资源的master节点。由于frozen的资源是GRD（Global Resource Directory）中的资源。在整个DRM的过程之中，访问该资源的进程都将被临时挂起。正因为如此，当系统出现DRM操作时，很可能导致系统或进程出现异常的。

DRM freeze 会导致资源短暂的不可用；
DRM freeze 可能会导致系统hang住。

2.3 优化建议

生产数据库建议关闭DRM（需要重启数据库）。

END

本文作者：袁钢(上海新炬中北团队）

本文来源：“IT那活儿”公众号

oracle系统 oracle oracle数据库数据库

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Oracle DRM引发的一次数据库重启

2.1 日志分析

2.2 DRM特性

2.3 优化建议

本文作者：袁钢(上海新炬中北团队）

本文来源：“IT那活儿”公众号

评论

相关阅读

Oracle DRM引发的一次数据库重启

2.1 日志分析

2.2 DRM特性

2.3 优化建议

本文作者：袁 钢(上海新炬中北团队）

本文来源：“IT那活儿”公众号

评论

相关阅读

本文作者：袁钢(上海新炬中北团队）