【博客文章2024】RAC 19c磁盘硬件严重故障处置系列三：mgmtdb的恢复 Author： Bo Tang RAC 19c集群底层结构已经修复，详见这篇博客：https://www.botangdb.com/mytec/mytec_rac/202404/00900118.html。将通过本文和之后的两篇博客继续进行集群的恢复。下面红色标出的资源都需要恢复：
1. mgmtdb的问题以及mgmtdb在RAC集群中的作用： 由于mgmtdb的参数文件、控制文件和数据文件都在+data磁盘组上，所以这些文件也全部丢失，使得mgmtdb无法启动：
mgmtdb是带一个pdb的cdb数据库用来存储Cluster HealthMonitor (CHM/OS,ora.crf) 、Oracle Database QoS Management、Rapid Home Provisioning和其他的数据。它是一个单实例数据库，在Cluster启动的时候会启动mgmtdb，它的实例会在其中一个节点上运行(使用oclumon manage -get master查看在哪个实例上运行)。mgmtdb受clusterware管理。如果运行mgmtdb的节点宕机了，clusterware会自动把mgmgtdb转移到其他的节点上。 2. mgmtdb的cdb的创建： 在所有节点上停止ora.crf：
尝试删除mgmtdb实例：
根据提示在另一个节点运行：
反注册ora.mgmtdb资源：
创建mgmtdb的根容器数据库： 验证根容器的容器名，种子数据库的状态和数据文件： 3. mgmtdb的pdb的创建： 插件数据库的名字应该是cluster的名字，使用以下命令查看cluster的名字：
使用以下命令创建pdb。运行时会要求输入本地用户PDBADMIN的密码，设置并记住密码： 验证所有容器的容器名，插件数据库的状态和数据文件：
mgmtdb中的表： 4. mgmtca配置GIMR： 在所有节点上启动ora.crf： 由于GIMR没有配置，以下命令输出中的PDB name和PDB service都为空： 使用mgmtca来配置GIMR： GIMR如果配置成功，以下命令输出中的PDB name和PDB service不为空（12.2.0.1之前，PDB name和PDB service的值都是cluster的名字）： GIMR如果配置成功后，pdb的名字会被rename成GIMR_DSCREP_#形式，并多出6个数据文件： GIMR的路径：
查询GIMR的两个用户： 查看mgmtdb在哪个节点上运行：
|
GMT+8, 2024-4-7 23:21 , Processed in 0.034858 second(s), 21 queries .
