16 Ocak 2019 Çarşamba

12c New Feature=> RESTORE AND RECOVER STANDBY DATABASE FROM NETWORK SERVICE

Oracle Database 12c New Feature: 

RESTORE AND RECOVER STANDBY DATABASE 
FROM NETWORK SERVICE  


It is always possible to loose archivelogs in our Prmiary-Standby Database configurations. When we loose even only one archivelog file, a gap would occur and the automatic recovery of our standby database stops.

We'd have several methods to resolve the gaps:

·                      Restore the archivelogs from backup and apply them manually
·                      Create incremental backup from primary and recover standby.


With the release of 12c, we have a new method to resolve the gaps; 

--->Restore&Recover from Network Service 


Steps:

1. Check the status:

SQL> SELECT distinct PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY order by process;
  

PROCESS   STATUS          THREAD#  SEQUENCE#
--------- ------------ ---------- ----------
ARCH      CLOSING               1         82
ARCH      CLOSING               1         89
ARCH      CONNECTED             0          0
MRP0      WAIT_FOR_GAP          1         86
RFS       IDLE                  0          0
RFS       IDLE                  1         90

6 rows selected.

SQL> 


2. Stop the recovery on standby

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> 


3. Recover the database over the network;

RMAN> recover database from service TWELVE;

Starting recover at 25-APR-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=249 device type=DISK
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service TWELVE
destination for restore of datafile 00001: /u01/app/oracle/oradata/TWELVE/system01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network bac
kup set from service TWELVE
destination for restore of datafile 00003: /u01/app/oracle/oradata/TWELVE/sysaux01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service TWELVE
destination for restore of datafile 00004: /u01/app/oracle/oradata/TWELVE/undotbs01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service TWELVE
destination for restore of datafile 00005: /u01/app/oracle/oradata/TWELVE/example01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service TWELVE
destination for restore of datafile 00006: /u01/app/oracle/oradata/TWELVE/users01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

starting media recovery

archived log for thread 1 with sequence 87 is already on disk as file /u01/app/oracle/product/12.1.0/dbhome_1/dbs/arch1_87_910395669.dbf
archived log for thread 1 with sequence 88 is already on disk as file /u01/app/oracle/product/12.1.0/dbhome_1/dbs/arch1_88_910395669.dbf
archived log for thread 1 with sequence 89 is already on disk as file /u01/app/oracle/product/12.1.0/dbhome_1/dbs/arch1_89_910395669.dbf
media recovery complete, elapsed time: 00:00:00
Finished recover at 25-APR-16

RMAN> 


4. Start the recovery Check the status again;

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

SQL> SELECT distinct PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY order by process;

PROCESS   STATUS          THREAD#  SEQUENCE#
--------- ------------ ---------- ----------
ARCH      CLOSING               1         82
ARCH      CLOSING               1         89
ARCH      CONNECTED             0          0
MRP0      WAIT_FOR_GAP          1         86
RFS       IDLE                  0          0
RFS       IDLE                  1         90

6 rows selected.

SQL> 

***As you see, standby is still waiting 86th archivelog because controlfile doesnt know the new SCN values of the datafiles yet. So, we need to restore the controlfile too.


5. Restore standby controlfile from network service

SQL> alter database recover managed standby database cancel;

Database altered.

SQL> shu immediate;
ORA-01109: database not open


Database dismounted.
ORACLE instance shut down.

SQL> startup nomount;
ORACLE instance started.

Total System Global Area  926941184 bytes
Fixed Size                  2930944 bytes
Variable Size             343934720 bytes
Database Buffers          574619648 bytes
Redo Buffers                5455872 bytes


SQL> 

[oracle@rent ~]$ rman target /

Recovery Manager: Release 12.1.0.2.0 - Production on Mon Apr 25 21:23:20 2016

Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.

connected to target database: TWELVE (not mounted)

RMAN>  restore standby controlfile from service TWELVE;

Starting restore at 25-APR-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=12 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service TWELVE
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/app/oracle/oradata/TWELVE/control01.ctl
output file name=/u01/app/oracle/oradata/TWELVE/control02.ctl
Finished restore at 25-APR-16

RMAN> alter database mount;

Statement processed
released channel: ORA_DISK_1

RMAN> alter database recover managed standby database using current logfile disconnect from session;

Statement processed



SQL> SELECT distinct PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY order by process;

PROCESS   STATUS          THREAD#  SEQUENCE#
--------- ------------ ---------- ----------
ARCH      CONNECTED             0          0
MRP0      APPLYING_LOG          1         90
RFS       IDLE                  0          0
RFS       IDLE                  1         90

SQL>   


Hiç yorum yok:

Yorum Gönder