# ADG主库新建PDB备库无法同步故障分析

> 作者/来源: UCloud 运营管理员
> 发布时间: 2023-01-11T05:20:00.000Z
> 分类: 其他
> 标签: AI, 数据库
> 原文链接: http://117.50.162.249:3000/yun/articles/882

---

# ADG主库新建PDB备库无法同步故障分析

> 来源: https://www.ucloud.cn/yun/130041.html
> 作者: IT那活儿
> 发布日期: 发布于2023-01-11 13:20

ADG主库新建PDB备库无法同步故障分析

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_011.png)

仙女都在看

点点点，赞和在看都在这儿！

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_001.png)

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_015.png)

亲爱的小伙伴们，我们又见面了，这次给大家带来的是最近处理的一起Oracle19CADG主库新建PDB备库无法同步问题。

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_015.png)

先简单介绍下故障过程，某天突然一同事跑过来说：

“魏大湿，我在主库上新建PDB，备库没有同步，实时应用也自动宕掉了。”

“新建PDB之前，主备同步是好的吗？”

“是好的，在创建之前特意检查了实时应用，在主库创建测试表，备库立马就有了。”

“之前在这个库的主库上有创建过PDB没？”

“创建过，ADG同步一直都没问题。”

“。。。”

通过沟通知道了，这套CDB模式的19C，之前在主库上创建PDB，备库同步正常。但是最近的一次新建PDB，备库同步就宕掉了。于是接手去看下到底是啥原因？

查看主库的PDB如下，新建的PDB是con\_id：6的，状态都正常。

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_004.png)

备库新建PDB处于mount状态：

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_005.png)

查看主备库的v$datafile视图发现主库新建PDB的数据文件都存在，但是备库没有。

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_006.png)

查看备库alert日志报错如下：

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_007.png)

报错显示由于无法识别+DATADG1，导致MRP0进程宕掉。

通过asmcmd进入ASM中发现除了第一个system文件外，其他新建PDB的数据文件都没有生成，而且第一个文件从之前dbalert日志来看，是没有restore成功的。也就是损坏的，直接rm掉。结合日志及MOS。

通过日志初步判断触发Bug25350791，在MRPFails with ORA-1274 while Creating PDB on Standby (Doc ID2423108.1)文章中提到的workwround是被克隆的源PDB需要处于readonly模式且实时同步开启即可。但我们新建的PDB是从pdb$seed种子库克隆过来的，pdb$seed本来就处于readonly。

新建PDB命令如下：

------首先查出pdb$seed的系统数据文件路径，后进行克隆

CREATEPLUGGABLE DATABASE pdbtest ADMIN USER  pdbtest\_admin IDENTIFIED BYxxxxxx

storageunlimited

DEFAULTTABLESPACE TBS\_PDBPDB DATAFILE +DATADG1 SIZE 30g AUTOEXTEND OFF

FILE\_NAME\_CONVERT=(+DATADG1/RACDB/AB29857745280367E0532A3DE60/DATAFILE/system.292.1046608615,+DATADG1,

+DATADG1/RACDB/AB29857745280367E0532A3DE60/DATAFILE/sysaux.290.1046608619,+DATADG1,

+DATADG1/RACDB/AB29857745280367E0532A3DE60/DATAFILE/undotbs1.288.1046608621,+DATADG1,

+DATADG1/RACDB/AB29857745280367E0532A3DE60/TEMPFILE/temp.286.1046608621,+DATADG1);

我们目前尝试了各种方法去解决PDB同步的问题，例如把standby\_file\_management设置成手动，然后创建PDB命令填写详细路径等方式都均告失败。已开SR等待回复。

**看到这里我们先把同步恢复先，路还是要继续往前走的。以下是恢复的过程：**

**1、**在主库备份新建PDB及控制文件，并将其备份集scp至备库。

backuppluggable database  PDBTEST FORMAT  /bak/PDBTEST\_%U\_%T.bak;

alterdatabase create standby controlfile as /bak/standby.ctl;

**2、**记录备库的数据文件路径后，将备库所有节点实例全部shutdownimmediate，将其中一个节点实例启动至nomount，重建控制文件。

selectfile#,alter database rename file ||file#|| || to||name||; name\_str from v$datafile order by 1;

shutdownimmediate;

startupnomount;

RMAN>restore standby controlfile  from /bak/standby.ctl;

**3、**数据库启动至mount状态后，将备库文件管理设置成手动，将控制文件中的数据文件路径rename成步骤二备份的路径。(注：数据文件要通过file#一一对应)

alterdatabase mount;

altersystem set standby\_file\_management="manual" scope=both;

数据文件路径修改前：

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_008.png)

Rename命令如下：

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_009.png)

**4、**将注册备份集及归档日志,并restore新建的pdb，注意这里要restore2次，会自动在控制文件中注册新建数据文件，否则新建数据文件路径是错误的。

catalogstart with /bak noprompt;

restorepluggable database  PDBTEST;

restoredatafile 150,151,152,153;-------150,151,152,153为新建PDB数据文件的file#。

catalogstart with +ARCHIVEDG noprompt;

**5、**开始做recover，recover完成之后，开启实时应用即可。

recoverdatabase noredo;

截图：

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_010.png)

注：开启实时应用后，此时会发现备库alert日志中有logfile及tempfile路径错误的报错。这种报错是由于控制文件中redo及tempfile的路径错误导致，不用手动去修改。只要将备库所有节点实例启动至readonly，然后开启实时应用，在主库多切换几次归档即可解决。

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_011.png)

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_012.png)

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_015.png)

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_014.png)

![](https://ucloud-blog.cn-bj.ufileos.com/articles/130041/images/130041_015.png)

扫码关注我们