1818IP-服务器技术教程,云服务器评测推荐,服务器系统排错处理,环境搭建,攻击防护等

当前位置：首页 - 数据库 - 正文

君子好学，自强不息！

Oracle DataGuard GAP 修复手册

2022-11-27 | 数据库 | gtxyzz | 645°c
A+ A-

前言

DG GAP 顾名思义就是：DG不同步，当备库不能接受到一个或多个主库的归档日志文件时候，就发生了 GAP。

那么，如果遇到GAP如何修复呢?且听我细细道来~

一、介绍

DG GAP 主要分为以下两类情况：

1、主库归档日志存在，可以通过配置 Fetch Archive Log(FAL) 参数，自动解决归档 GAP。2、主库归档日志丢失，需要 人工干预 来修复。

不同 Oracle 版本的 GAP 修复方式也不尽相同，下面分别介绍不同版本的方式!

11G 的处理步骤：

a.在主库上创建一个备库的控制文件

b.以备库的当前SCN号为起点，在主库上做一个增量备份

c.将增量备份拷贝到备库上

d.使用新的控制文件将备库启动到mount状态

e.将增量备份注册到RMAN的catalog，取消备库的恢复应用，恢复增量备份

f.开启备库的恢复进程

12C 的新特性(RECOVER … FROM SERVICE)

18C 的新特性(RECOVER STANDBY DATABASE FROM SERVICE)

Oracle随着版本的升级，逐渐将步骤缩减，进行封装，18C之后可谓是达到了所谓的一键刷新，恢复DG同步。

二、实战

下面我们通过实验来进行演示如何修复：

  • 11G常规修复
  • 12C新特性(RECOVER … FROM SERVICE)修复
  • 18C新特性(RECOVER STANDBY DATABASE FROM SERVICE)修复

三、11G常规修复

首先，模拟备库断电，主库切几个最新的归档，然后手工删掉，重新开启DG同步。

备库停止DG同步进程：

sqlplus/assysdba
ALTERDATABASERECOVERMANAGEDSTANDBYDATABASECANCEL;
shutdownimmediate

主库切换多次归档：

sqlplus/assysdba
altersystemswitchlogfile;

主库删除最近几个归档日志：

rm1_34_1070147137.arc
rm1_33_1070147137.arc

备库开启同步进程：

startup
ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEUSINGCURRENTLOGFILEDISCONNECTFROMSESSION;

查看GAP：

sqlplus/assysdba
SELECT*FROMV$ARCHIVE_GAP;
THREAD#LOW_SEQUENCE#HIGH_SEQUENCE#
-------------------------------------
13234

SELECTmax(sequence#)fromv$archived_logwhereapplied='YES';
MAX(SEQUENCE#)
--------------
31

📢 注意： 当前DG数据库已存在GAP，GAP日志为：32—34。

a.在主库上创建一个备库的控制文件

alterdatabasecreatestandbycontrolfileas'/tmp/standby.ctl';

b.以备库的当前SCN号为起点，在主库上做一个增量备份备库查询当前 scn 号：

sqlplus/assysdba
selectto_char(current_scn)fromv$database;
TO_CHAR(CURRENT_SCN)
----------------------------------------
1086639

确认主备GAP期间是否新增数据文件：

sqlplus/assysdba
selectfile#fromv$datafilewherecreation_change#>=1086639;

主库根据备库scn号进行增量备份：

rmantarget/
run{
allocatechannelc1typedisk;
allocatechannelc2typedisk;
backupINCREMENTALfromscn1086639databaseformat'/tmp/incre_%U';
releasechannelc1;
releasechannelc2;
}

📢 注意： 如果存在新增数据文件，备库恢复时需要先restore新添加的数据文件。

c.将增量备份和控制文件拷贝到备库上主库拷贝增量备份和控制文件你至备库：

scpincre_0*oracle@orcl_stby:/home/oracle
scpstandby.ctloracle@orcl_stby:/home/oracle

📢 注意： 确认备库的磁盘空间是否足够存放。

d.使用新的控制文件将备库启动到mount状态备库关闭数据库实例，开启至nomount状态：

sqlplus/assysdba
shutdownimmediate
startupnomount

备库恢复新的控制文件：

rmantarget/
restorecontrolfilefrom'/home/oracle/standby.ctl';

备库开启到mount状态：

alterdatabasemount;

e.增量备份注册到RMAN的catalog，取消日志应用，恢复增量备份确认备库已关闭DG同步进程：

sqlplus/assysdba
ALTERDATABASERECOVERMANAGEDSTANDBYDATABASECANCEL;

备库rman注册增量备份文件：

rmantarget/
catalogstartwith'/home/oracle/';
YES

备库开启恢复增量备份：

recoverdatabasenoredo;

f.开启备库的恢复进程备库开启日志同步进程：

sqlplus/assysdba
alterdatabaseopenreadonly;
ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEUSINGCURRENTLOGFILEDISCONNECTFROMSESSION;

主库重新激活同步：

sqlplus/assysdba
ALTERSYSTEMSETLOG_ARCHIVE_DEST_STATE_2=defer;
ALTERSYSTEMSETLOG_ARCHIVE_DEST_STATE_2=enable;

查询是否存在GAP，确认主备是否同步：

sqlplus/assysdba
SELECT*FROMV$ARCHIVE_GAP;
SELECTmax(sequence#)fromv$archived_logwhereapplied='YES';
SELECTPROCESS,STATUS,THREAD#,SEQUENCE#,BLOCK#,BLOCKSFROMV$MANAGED_STANDBY;

至此，DG GAP已被修复，以上方式为常规修复方式，各个版本都通用。

四、12C新特性修复

首先，模拟备库断电，主库切几个最新的归档，然后手工删掉，重新开启DG同步。

模拟GAP期间，有数据文件添加的情况：

##主库添加数据文件
altertablespaceTESTadddatafile'/oradata/ORCL/test02.dbf'size100Mautoextendoff;

📢 注意： 当前DG数据库已存在GAP，GAP日志为：30—31 。

a.记录备库当前SCN号备库记录当前 scn 号：

sqlplus/assysdba
SELECTCURRENT_SCNFROMV$DATABASE;
CURRENT_SCN
-----------
2600487

b.使用recover standby using service恢复采用rman的新功能，recover standby using service，通过RMAN连接到target备库，然后用主库的service执行恢复备库命令。

语法：

RECOVER DATABASE FROM SERVICE < PRIMARY DB SERVICE NAME > NOREDO USING COMPRESSED BACKUPSET;

📢 注意： 确认主库的TNS已配置，这里的< PRIMARY DB SERVICE NAME >即 TNSNAME。

c.备库启动到nomount状态，恢复控制文件备库启动到nomount状态：

sqlplus/assysdba
shutdownimmediate
startupnomount

备库通过from service恢复控制文件：

rmantarget/
restorestandbycontrolfilefromserviceorcl;

备库开启到mount状态：

sqlplus/assysdba
alterdatabasemount;

d.备库恢复，修复GAP检查主备GAP期间是否添加数据文件：

sqlplus/assysdba
selectfile#fromv$datafilewherecreation_change#>=2600487;

FILE#
----------
13

restore 新添加的数据文件：

rmantarget/
run
{
SETNEWNAMEFORDATABASETO'/oradata/ORCL_STBY/%f_%U';
RESTOREDATAFILE13FROMSERVICEorcl;
}

由于主备的数据文件目录不一致，需要修改controlfile中数据文件位置：

rmantarget/
catalogstartwith'/oradata/ORCL_STBY';
YES
SWITCHDATABASETOCOPY;

将备库文件管理方式改为手动：

sqlplus/assysdba
altersystemsetstandby_file_management=MANUAL;

重命名 tempfile && logfile：

sqlplus/assysdba
##logfile
alterdatabaseclearlogfilegroup1;
alterdatabaseclearlogfilegroup2;
alterdatabaseclearlogfilegroup3;
alterdatabaseclearlogfilegroup4;
alterdatabaseclearlogfilegroup5;
alterdatabaseclearlogfilegroup6;
alterdatabaseclearlogfilegroup7;
alterdatabaserenamefile'/oradata/ORCL/redo03.log'to'/oradata/ORCL_STBY/redo03.log';
alterdatabaserenamefile'/oradata/ORCL/redo02.log'to'/oradata/ORCL_STBY/redo02.log';
alterdatabaserenamefile'/oradata/ORCL/redo01.log'to'/oradata/ORCL_STBY/redo01.log';
alterdatabaserenamefile'/oradata/ORCL/standby_redo04.log'to'/oradata/ORCL_STBY/standby_redo04.log';
alterdatabaserenamefile'/oradata/ORCL/standby_redo05.log'to'/oradata/ORCL_STBY/standby_redo05.log';
alterdatabaserenamefile'/oradata/ORCL/standby_redo06.log'to'/oradata/ORCL_STBY/standby_redo06.log';
alterdatabaserenamefile'/oradata/ORCL/standby_redo07.log'to'/oradata/ORCL_STBY/standby_redo07.log';
##tempfile
alterdatabaserenamefile'/oradata/ORCL/temp01.dbf'to'/oradata/ORCL_STBY/temp01.dbf';
alterdatabaserenamefile'/oradata/ORCL/pdbseed/temp012021-04-11_06-13-50-844-AM.dbf'to'/oradata/ORCL_STBY/pdbseed/temp012021-04-11_06-13-50-844-AM.dbf';
alterdatabaserenamefile'/oradata/ORCL/BFA6BEE45A1E3605E053AC01A8C0DD20/datafile/o1_mf_temp_j749f5fy_.dbf'to'/oradata/ORCL_STBY/BFA6BEE45A1E3605E053AC01A8C0DD20/datafile/o1_mf_temp_j749f5fy_.dbf';

备库重命名完后再改为自动：

sqlplus/assysdba
altersystemsetstandby_file_management=AUTO;

恢复主备GAP：

recoverdatabasefromserviceorclnoredousingcompressedbackupset;

📢 注意： 如果主备库文件目录不一致，则需要catalog切换控制文件中路径，否则报错：

e.开启备库日志应用，检查同步检查主备scn是否一致

sqlplus/assysdba
colHXFNMfora100
setline222
selectHXFILFile_num,substr(HXFNM,1,40)HXFNM,fhscnfromx$kcvfh;

主库切几次归档

sqlplus/assysdba
ALTERSYSTEMARCHIVELOGCURRENT;
ALTERSYSTEMSWITCHLOGFILE;

开启备库应用日志

sqlplus/assysdba
alterdatabaseopen;
alterpluggabledatabaseallopen;
ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEUSINGCURRENTLOGFILEDISCONNECTFROMSESSION;

查看备库同步是否正常

sqlplus/assysdba
setline222
colmemberfora60
selectt1.group#,t1.thread#,t1.bytes/1024/1024,t1.status,t2.memberfromgv$standby_logt1,gv$logfilet2wheret1.group#=t2.group#;

主库插入数据

sqlplustest/test@pdb01
insertintotestvalues(999);
commit;

备库查询是否实时同步

altersessionsetcontainer=pdb01;
select*fromtest.test;
ID
----------
1
2
999

至此，GAP已修复完成，可以发现，12C这个新特性，将一些步骤进行了省略和封装，进一步减少了我们的操作步骤，但是内部的原理仍然是一致的。

五、18C新特性恢复

18C 新特性是在 12C 的基础上，将 RECOVER STANDBY DATABASE 命令与 FROM SERVICE 子句一起使用，以通过对主数据库进行的更改来刷新物理备用数据库。备库可以直接在开启状态进行刷新。

语法：

RECOVER STANDBY DATABASE FROM SERVICE primary_db;

首先，模拟备库断电，主库切几个最新的归档，然后手工删掉，重新开启DG同步。

模拟GAP期间，有数据文件添加的情况：

##主库添加数据文件
altertablespaceTESTadddatafile'/oradata/ORCL/test02.dbf'size100Mautoextendoff;

📢 注意： 当前 DG 数据库已存在 GAP，GAP 日志为：69—70。

a、执行RECOVER STANDBY DATABASE FROM SERVICE刷新备库下面演示一下，如何使用一行命令在线修复DG GAP：

备库取消日志应用：

sqlplus/assysdba
ALTERDATABASERECOVERMANAGEDSTANDBYDATABASECANCEL;

备库执行修复命令，开始在线刷新备库：

rmantarget/
RMAN>RECOVERSTANDBYDATABASEFROMSERVICEorcl;

Startingrecoverat19-APR-21
usingtargetdatabasecontrolfileinsteadofrecoverycatalog
Oracleinstancestarted

TotalSystemGlobalArea3355441944bytes

FixedSize9141016bytes
VariableSize671088640bytes
DatabaseBuffers2667577344bytes
RedoBuffers7634944bytes

contentsofMemoryScript:
{
restorestandbycontrolfilefromservice'orcl';
alterdatabasemountstandbydatabase;
}
executingMemoryScript

Startingrestoreat19-APR-21
allocatedchannel:ORA_DISK_1
channelORA_DISK_1:SID=502devicetype=DISK

channelORA_DISK_1:startingdatafilebackupsetrestore
channelORA_DISK_1:usingnetworkbackupsetfromserviceorcl
channelORA_DISK_1:restoringcontrolfile
channelORA_DISK_1:restorecomplete,elapsedtime:00:00:02
outputfilename=/oradata/ORCL_STBY/control01.ctl
outputfilename=/oradata/ORCL_STBY/control02.ctl
Finishedrestoreat19-APR-21

releasedchannel:ORA_DISK_1
Statementprocessed
Executing:altersystemsetstandby_file_management=manual

contentsofMemoryScript:
{
setnewnamefortempfile1to
"/oradata/ORCL_STBY/temp01.dbf";
setnewnamefortempfile2to
"/oradata/ORCL_STBY/pdbseed/temp012021-04-11_06-13-50-844-AM.dbf";
setnewnamefortempfile3to
"/oradata/ORCL_STBY/BFA6BEE45A1E3605E053AC01A8C0DD20/datafile/o1_mf_temp_j749f5fy_.dbf";
switchtempfileall;
setnewnamefordatafile1to
"/oradata/ORCL_STBY/system01.dbf";
setnewnamefordatafile3to
"/oradata/ORCL_STBY/sysaux01.dbf";
setnewnamefordatafile4to
"/oradata/ORCL_STBY/undotbs01.dbf";
setnewnamefordatafile5to
"/oradata/ORCL_STBY/pdbseed/system01.dbf";
setnewnamefordatafile6to
"/oradata/ORCL_STBY/pdbseed/sysaux01.dbf";
setnewnamefordatafile7to
"/oradata/ORCL_STBY/users01.dbf";
setnewnamefordatafile8to
"/oradata/ORCL_STBY/pdbseed/undotbs01.dbf";
setnewnamefordatafile9to
"/oradata/ORCL_STBY/PDB01/o1_mf_system_j749f5d5_.dbf";
setnewnamefordatafile10to
"/oradata/ORCL_STBY/PDB01/o1_mf_sysaux_j749f5fw_.dbf";
setnewnamefordatafile11to
"/oradata/ORCL_STBY/PDB01/o1_mf_undotbs1_j749f5fx_.dbf";
setnewnamefordatafile12to
"/oradata/ORCL_STBY/test01.dbf";
setnewnamefordatafile14to
"/oradata/ORCL/test02.dbf";
restorefromservice'orcl'datafile
14;
catalogdatafilecopy"/oradata/ORCL_STBY/system01.dbf",
"/oradata/ORCL_STBY/sysaux01.dbf",
"/oradata/ORCL_STBY/undotbs01.dbf",
"/oradata/ORCL_STBY/pdbseed/system01.dbf",
"/oradata/ORCL_STBY/pdbseed/sysaux01.dbf",
"/oradata/ORCL_STBY/users01.dbf",
"/oradata/ORCL_STBY/pdbseed/undotbs01.dbf",
"/oradata/ORCL_STBY/PDB01/o1_mf_system_j749f5d5_.dbf",
"/oradata/ORCL_STBY/PDB01/o1_mf_sysaux_j749f5fw_.dbf",
"/oradata/ORCL_STBY/PDB01/o1_mf_undotbs1_j749f5fx_.dbf",
"/oradata/ORCL_STBY/test01.dbf",
"/oradata/ORCL/test02.dbf";
switchdatafileall;
}
executingMemoryScript

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

renamedtempfile1to/oradata/ORCL_STBY/temp01.dbfincontrolfile
renamedtempfile2to/oradata/ORCL_STBY/pdbseed/temp012021-04-11_06-13-50-844-AM.dbfincontrolfile
renamedtempfile3to/oradata/ORCL_STBY/BFA6BEE45A1E3605E053AC01A8C0DD20/datafile/o1_mf_temp_j749f5fy_.dbfincontrolfile

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

executingcommand:SETNEWNAME

Startingrestoreat19-APR-21
allocatedchannel:ORA_DISK_1
channelORA_DISK_1:SID=504devicetype=DISK

channelORA_DISK_1:startingdatafilebackupsetrestore
channelORA_DISK_1:usingnetworkbackupsetfromserviceorcl
channelORA_DISK_1:specifyingdatafile(s)torestorefrombackupset
channelORA_DISK_1:restoringdatafile00014to/oradata/ORCL/test02.dbf
channelORA_DISK_1:restorecomplete,elapsedtime:00:00:03
Finishedrestoreat19-APR-21

catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/system01.dbfRECID=4STAMP=1070263316
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/sysaux01.dbfRECID=5STAMP=1070263317
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/undotbs01.dbfRECID=6STAMP=1070263317
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/pdbseed/system01.dbfRECID=7STAMP=1070263317
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/pdbseed/sysaux01.dbfRECID=8STAMP=1070263318
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/users01.dbfRECID=9STAMP=1070263318
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/pdbseed/undotbs01.dbfRECID=10STAMP=1070263318
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/PDB01/o1_mf_system_j749f5d5_.dbfRECID=11STAMP=1070263318
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/PDB01/o1_mf_sysaux_j749f5fw_.dbfRECID=12STAMP=1070263318
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/PDB01/o1_mf_undotbs1_j749f5fx_.dbfRECID=13STAMP=1070263318
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL_STBY/test01.dbfRECID=14STAMP=1070263318
catalogeddatafilecopy
datafilecopyfilename=/oradata/ORCL/test02.dbfRECID=15STAMP=1070263318

datafile14switchedtodatafilecopy
inputdatafilecopyRECID=15STAMP=1070263318filename=/oradata/ORCL/test02.dbf
datafile1switchedtodatafilecopy
inputdatafilecopyRECID=4STAMP=1070263316filename=/oradata/ORCL_STBY/system01.dbf
datafile3switchedtodatafilecopy
inputdatafilecopyRECID=5STAMP=1070263317filename=/oradata/ORCL_STBY/sysaux01.dbf
datafile4switchedtodatafilecopy
inputdatafilecopyRECID=6STAMP=1070263317filename=/oradata/ORCL_STBY/undotbs01.dbf
datafile5switchedtodatafilecopy
inputdatafilecopyRECID=7STAMP=1070263317filename=/oradata/ORCL_STBY/pdbseed/system01.dbf
datafile6switchedtodatafilecopy
inputdatafilecopyRECID=8STAMP=1070263318filename=/oradata/ORCL_STBY/pdbseed/sysaux01.dbf
datafile7switchedtodatafilecopy
inputdatafilecopyRECID=9STAMP=1070263318filename=/oradata/ORCL_STBY/users01.dbf
datafile8switchedtodatafilecopy
inputdatafilecopyRECID=10STAMP=1070263318filename=/oradata/ORCL_STBY/pdbseed/undotbs01.dbf
datafile9switchedtodatafilecopy
inputdatafilecopyRECID=11STAMP=1070263318filename=/oradata/ORCL_STBY/PDB01/o1_mf_system_j749f5d5_.dbf
datafile10switchedtodatafilecopy
inputdatafilecopyRECID=12STAMP=1070263318filename=/oradata/ORCL_STBY/PDB01/o1_mf_sysaux_j749f5fw_.dbf
datafile11switchedtodatafilecopy
inputdatafilecopyRECID=13STAMP=1070263318filename=/oradata/ORCL_STBY/PDB01/o1_mf_undotbs1_j749f5fx_.dbf
datafile12switchedtodatafilecopy
inputdatafilecopyRECID=14STAMP=1070263318filename=/oradata/ORCL_STBY/test01.dbf
Executing:alterdatabaserenamefile'/oradata/ORCL/redo01.log'to'/oradata/ORCL_STBY/redo01.log'
Executing:alterdatabaserenamefile'/oradata/ORCL/redo02.log'to'/oradata/ORCL_STBY/redo02.log'
Executing:alterdatabaserenamefile'/oradata/ORCL/redo03.log'to'/oradata/ORCL_STBY/redo03.log'

contentsofMemoryScript:
{
recoverdatabasefromservice'orcl';
}
executingMemoryScript

Startingrecoverat19-APR-21
usingchannelORA_DISK_1
skippingdatafile5;alreadyrestoredtoSCN2155383
skippingdatafile6;alreadyrestoredtoSCN2155383
skippingdatafile8;alreadyrestoredtoSCN2155383
skippingdatafile14;alreadyrestoredtoSCN2658548
channelORA_DISK_1:startingincrementaldatafilebackupsetrestore
channelORA_DISK_1:usingnetworkbackupsetfromserviceorcl
destinationforrestoreofdatafile00001:/oradata/ORCL_STBY/system01.dbf
channelORA_DISK_1:restorecomplete,elapsedtime:00:00:01
channelORA_DISK_1:startingincrementaldatafilebackupsetrestore
channelORA_DISK_1:usingnetworkbackupsetfromserviceorcl
destinationforrestoreofdatafile00003:/oradata/ORCL_STBY/sysaux01.dbf
channelORA_DISK_1:restorecomplete,elapsedtime:00:00:01
channelORA_DISK_1:startingincrementaldatafilebackupsetrestore
channelORA_DISK_1:usingnetworkbackupsetfromserviceorcl
destinationforrestoreofdatafile00004:/oradata/ORCL_STBY/undotbs01.dbf
channelORA_DISK_1:restorecomplete,elapsedtime:00:00:01
channelORA_DISK_1:startingincrementaldatafilebackupsetrestore
channelORA_DISK_1:usingnetworkbackupsetfromserviceorcl
destinationforrestoreofdatafile00007:/oradata/ORCL_STBY/users01.dbf
channelORA_DISK_1:restorecomplete,elapsedtime:00:00:01
channelORA_DISK_1:startingincrementaldatafilebackupsetrestore
channelORA_DISK_1:usingnetworkbackupsetfromserviceorcl
destinationforrestoreofdatafile00009:/oradata/ORCL_STBY/PDB01/o1_mf_system_j749f5d5_.dbf
channelORA_DISK_1:restorecomplete,elapsedtime:00:00:01
channelORA_DISK_1:startingincrementaldatafilebackupsetrestore
channelORA_DISK_1:usingnetworkbackupsetfromserviceorcl
destinationforrestoreofdatafile00010:/oradata/ORCL_STBY/PDB01/o1_mf_sysaux_j749f5fw_.dbf
channelORA_DISK_1:restorecomplete,elapsedtime:00:00:01
channelORA_DISK_1:startingincrementaldatafilebackupsetrestore
channelORA_DISK_1:usingnetworkbackupsetfromserviceorcl
destinationforrestoreofdatafile00011:/oradata/ORCL_STBY/PDB01/o1_mf_undotbs1_j749f5fx_.dbf
channelORA_DISK_1:restorecomplete,elapsedtime:00:00:02
channelORA_DISK_1:startingincrementaldatafilebackupsetrestore
channelORA_DISK_1:usingnetworkbackupsetfromserviceorcl
destinationforrestoreofdatafile00012:/oradata/ORCL_STBY/test01.dbf
channelORA_DISK_1:restorecomplete,elapsedtime:00:00:01

startingmediarecovery

mediarecoverycomplete,elapsedtime:00:00:00
Finishedrecoverat19-APR-21
Executing:altersystemsetstandby_file_management=auto
Finishedrecoverat19-APR-21

方便大家查看，于是记录恢复全过程，通过以上执行过程，可以看到：

  • RECOVER STANDBY DATABASE命令重新启动备用实例。
  • 从主数据库刷新控制文件，并自动重命名数据文件，临时文件和联机日志。
  • 它可以还原添加到主数据库中的新数据文件，并还原到当前时间的备用数据库。

b.备库修改standby log路径发现刷新过后，备库redo log路径已修改，standby log路径未修改，因此手动修改。

查询备库的日志文件路径：

sqlplus/assysdba
SQL>selectmemberfromv$logfile;

MEMBER
--------------------------------------------------------------------------------
/oradata/ORCL_STBY/redo03.log
/oradata/ORCL_STBY/redo02.log
/oradata/ORCL_STBY/redo01.log
/oradata/ORCL/standby_redo04.log
/oradata/ORCL/standby_redo05.log
/oradata/ORCL/standby_redo06.log
/oradata/ORCL/standby_redo07.log

关闭备库文件自动管理：

sqlplus/assysdba
altersystemsetstandby_file_management=MANUAL;

清理standby log：

sqlplus/assysdba
alterdatabaseclearlogfilegroup4;
alterdatabaseclearlogfilegroup5;
alterdatabaseclearlogfilegroup6;
alterdatabaseclearlogfilegroup7;

修改standby log路径：

sqlplus/assysdba
alterdatabaserenamefile'/oradata/ORCL/standby_redo04.log'to'/oradata/ORCL_STBY/standby_redo04.log';
alterdatabaserenamefile'/oradata/ORCL/standby_redo05.log'to'/oradata/ORCL_STBY/standby_redo05.log';
alterdatabaserenamefile'/oradata/ORCL/standby_redo06.log'to'/oradata/ORCL_STBY/standby_redo06.log';
alterdatabaserenamefile'/oradata/ORCL/standby_redo07.log'to'/oradata/ORCL_STBY/standby_redo07.log';

修改完后打开备库文件自动管理：

sqlplus/assysdba
altersystemsetstandby_file_management=AUTO;

c.主库切日志，备库开启日志应用检查主备scn是否一致：

sqlplus/assysdba
colHXFNMfora100
setline222
selectHXFILFile_num,substr(HXFNM,1,40)HXFNM,fhscnfromx$kcvfh;

主库切几次归档：

sqlplus/assysdba
ALTERSYSTEMARCHIVELOGCURRENT;
ALTERSYSTEMSWITCHLOGFILE;

开启备库应用日志：

sqlplus/assysdba
alterdatabaseopen;
alterpluggabledatabaseallopen;
ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEUSINGCURRENTLOGFILEDISCONNECTFROMSESSION;

查看备库同步是否正常：

sqlplus/assysdba
setline222
colmemberfora60
selectt1.group#,t1.thread#,t1.bytes/1024/1024,t1.status,t2.memberfromgv$standby_logt1,gv$logfilet2wheret1.group#=t2.group#;

主库插入数据：

sqlplustest/test@pdb01
insertintotestvalues(999);
commit;

备库查询是否实时同步：

sqlplus/assysdba
altersessionsetcontainer=pdb01;
select*fromtest.test;
ID
----------
1
2
999

至此，18C的GAP也已修复，可以看到Oracle随着版本升级，越来越自动化的操作，意味着运维自动化的未来。

参考文档：

RESTORE/Recover from Service

Restoring and Recovering Files Over the Network(DG)

Restoring and Recovering Files Over the Network(RMAN)

Rolling Forward a Standby With One Command 18C

本文来源：1818IP

本文地址：https://www.1818ip.com/post/12024.html

免责声明：本文由用户上传，如有侵权请联系删除！

相关文章
标签：
上一篇

Oracle 12CR2 RAC 安装避坑宝典
下一篇

Oracle SQL Developer进一步提高开发效率

发表评论

必填

选填

选填

◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。


本站资源均来自原创及互联网，仅供学习与参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。


苏ICP备2022008563号-1

欢迎您关注我

扫码关注微信