Oracle 12c中的PDB一下子让数据文件的格式复杂了一些,所以Data Guard就很有必要了,一旦出现问题,受损失的数据库是全局的。没想到在搭建Data Guard的时候还是碰到了一些小问题。
问题源自于一次PDB创建的时候,早些时候我在搭建好Data Guard后,主备库的日志应用都没有问题,过了几天,根据需求需要再添加一个PDB,导入一些数据供应用使用。按照要求创建了数据文件然后导入数据,但是查看备库的状态发现MRP异常停止了。
DG Broker检测的状态如下:
DGMGRL> show configuration;
Configuration - dg_testdb
Protection Mode: MaxPerformance
Members:
testdb - Primary database
s2testdb - Physical standby database
Error: ORA-16766: Redo Apply is stopped
Fast-Start Failover: DISABLED
Configuration Status:
ERROR (status updated 6 seconds ago)
DGMGRL>
备库的错误日志如下:
可以看到是备库没有对应的路径存在所以创建失败,但是错误特别之处在于有下面的错误信息:
Automatic Copy of Standby datafiles for create pdb failed with error - 65169. Files need to be copied manually
备库查看PDB的状态信息如下,TBILLMOB这个PDB出现了问题。
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 TCYMOB0 READ ONLY NO
4 MACTVDB READ ONLY NO
5 TBILLMOB MOUNTED
如果尝试切换容器,会抛出错误。
SQL> alter session set container=TBILLMOB;
ERROR:
ORA-65011: Pluggable database TBILLMOB does not exist.
这个错误查看了MetaLink也没有给出其他的建议,很明显和11g的处理方式有一些差别。无奈只能先修复问题,即从主库导出,备库还原恢复。
这个时候问题就来了,主库备份的时候怎么选择对应的数据文件,在哪个PDB中之类的。
使用RMAN来完成特定的备份,此处需要说明在12c中已经有了默认的新建系统用户sysbackup
rman target '"/ as sysbackup"'
查看schema的信息如下,原来是这么标记的。
因为这个新建的PDB数据文件完全没有同步过去,所以直接可以备份出来。
RMAN> backup format '/tmp/pdb_tbillmob.dmp' pluggable database tbillmob;
在备库上进行还原和恢复,假设备份集和控制文件在/tmp下。
RMAN> catalog start with '/tmp';
RMAN> restore pluggable database tbillmob from '/tmp/pdb_tbillmob.dmp';
Starting restore at 2016-10-25 11:32:18
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2838 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 10/25/2016 11:32:19
RMAN-06509: only SPFILE or control file can be restored from AUTOBACKUP
正确的方式是这样的。
RMAN> restore pluggable database tbillmob;
还原之后,开启日志应用即可。
SQL> recover managed standby database disconnect from session;
把备库打开
SQL> alter database open ;
尝试打开所有的PDB
SQL> alter pluggable database all open;
Pluggable database altered.
查看PDB的状态如下:
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 TCYMOB0 READ ONLY NO
4 MACTVDB READ ONLY NO
5 TBILLMOB READ ONLY NO
再次查看就主备关系就正常了。
DGMGRL> show configuration;
Configuration - dg_testdb
Protection Mode: MaxPerformance
Members:
testdb - Primary database
s2testdb - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 51 seconds ago)
DGMGRL>
而在这个基础上,我们进一步测试,主库PDB的目录下重新创建一个test目录,备库不存在,看看添加数据文件是否会成功。
mkdir -p /home/U01/app/oracle/oradata/testdb/pdb/tbillmob/test
SQL> alter tablespace users add datafile '/home/U01/app/oracle/oradata/testdb/pdb/tbillmob/test/users02.dbf'size 10M;
查看备库的信息如下:
当然我是在standby_file_management=auto的前提下操作的。如果是standby_file_management=manual还是存在一些差别。
问题源自于一次PDB创建的时候,早些时候我在搭建好Data Guard后,主备库的日志应用都没有问题,过了几天,根据需求需要再添加一个PDB,导入一些数据供应用使用。按照要求创建了数据文件然后导入数据,但是查看备库的状态发现MRP异常停止了。
DG Broker检测的状态如下:
DGMGRL> show configuration;
Configuration - dg_testdb
Protection Mode: MaxPerformance
Members:
testdb - Primary database
s2testdb - Physical standby database
Error: ORA-16766: Redo Apply is stopped
Fast-Start Failover: DISABLED
Configuration Status:
ERROR (status updated 6 seconds ago)
DGMGRL>
备库的错误日志如下:
可以看到是备库没有对应的路径存在所以创建失败,但是错误特别之处在于有下面的错误信息:
Automatic Copy of Standby datafiles for create pdb failed with error - 65169. Files need to be copied manually
备库查看PDB的状态信息如下,TBILLMOB这个PDB出现了问题。
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 TCYMOB0 READ ONLY NO
4 MACTVDB READ ONLY NO
5 TBILLMOB MOUNTED
如果尝试切换容器,会抛出错误。
SQL> alter session set container=TBILLMOB;
ERROR:
ORA-65011: Pluggable database TBILLMOB does not exist.
这个错误查看了MetaLink也没有给出其他的建议,很明显和11g的处理方式有一些差别。无奈只能先修复问题,即从主库导出,备库还原恢复。
这个时候问题就来了,主库备份的时候怎么选择对应的数据文件,在哪个PDB中之类的。
使用RMAN来完成特定的备份,此处需要说明在12c中已经有了默认的新建系统用户sysbackup
rman target '"/ as sysbackup"'
查看schema的信息如下,原来是这么标记的。
因为这个新建的PDB数据文件完全没有同步过去,所以直接可以备份出来。
RMAN> backup format '/tmp/pdb_tbillmob.dmp' pluggable database tbillmob;
在备库上进行还原和恢复,假设备份集和控制文件在/tmp下。
RMAN> catalog start with '/tmp';
RMAN> restore pluggable database tbillmob from '/tmp/pdb_tbillmob.dmp';
Starting restore at 2016-10-25 11:32:18
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2838 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 10/25/2016 11:32:19
RMAN-06509: only SPFILE or control file can be restored from AUTOBACKUP
正确的方式是这样的。
RMAN> restore pluggable database tbillmob;
还原之后,开启日志应用即可。
SQL> recover managed standby database disconnect from session;
把备库打开
SQL> alter database open ;
尝试打开所有的PDB
SQL> alter pluggable database all open;
Pluggable database altered.
查看PDB的状态如下:
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 TCYMOB0 READ ONLY NO
4 MACTVDB READ ONLY NO
5 TBILLMOB READ ONLY NO
再次查看就主备关系就正常了。
DGMGRL> show configuration;
Configuration - dg_testdb
Protection Mode: MaxPerformance
Members:
testdb - Primary database
s2testdb - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 51 seconds ago)
DGMGRL>
而在这个基础上,我们进一步测试,主库PDB的目录下重新创建一个test目录,备库不存在,看看添加数据文件是否会成功。
mkdir -p /home/U01/app/oracle/oradata/testdb/pdb/tbillmob/test
SQL> alter tablespace users add datafile '/home/U01/app/oracle/oradata/testdb/pdb/tbillmob/test/users02.dbf'size 10M;
查看备库的信息如下:
当然我是在standby_file_management=auto的前提下操作的。如果是standby_file_management=manual还是存在一些差别。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-2127103/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-2127103/