Oracle Database 19c New Feature => Propagate Restore Points from Primary to Standby site

With Oracle Database 19c, restore points which are created on primary database are automatically replicated on standby.

The restore points on standby are always normal restore points. It doesn't matter it is guaranteed or normal restore points on primary database.

There are 3 prerequisites for this feature:

1. The compatible parameter both on primary and standby database must be 19.0.0 or greater

2. The primary database must be open (not mounted) because of restored point replication is occured  through the redo logs. So, MRP process on standby needs to be running for replication.

3. There shouldn't be any existing restore point on standby database with same name.

Create a restore point on our 19c Primary database and see what is happening;

We created our restore point on primary. As you see there is a new column "REPLICATED" on "V$RESTORE_POINT" view and its value is "NO" on primary.


Let's check standby;

The name of the restore point on standby has suffix "PRIMARY" and "REPLICATED" column becomes "YES"

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>   

Dataguard => 12cR2 New Feature "Using DBCA to Create Physical Standby Database"

With 12cR2, you can create physical standby database by using DBCA utility. This new feature make the process easier and also automates some steps which you need to accomplish manually at earlier releases.

Restrictions:

• DBCA can create only single instance standby instance. If required, you can manually convert it to RAC database later.

• DBCA can only be used to create standby database for non-multitenant primary site.

• If you want to configure Dataguard Broker, you need to configure it manually too. 

• Primary database needs to be started via spfile.

Advantages:

• No need to create static listener (for duplicate method)

• It creates password file automatically

• No need to touch any RMAN utility explicitly

• No need to make entries for "tnsnames.ora" before dbca. You can use direct connection string.

• You can run additionals scripts after creation progress is finished by using -customScripts parameter.

The basic createDuplicateDB command has the following syntax:

dbca -createDuplicateDB 
    -gdbName global_database_name 
    -primaryDBConnectionString easy_connect_string_to_primary
    -sid database_system_identifier
    [-createAsStandby 
        [-dbUniqueName db_unique_name_for_standby]]
    [-customScripts scripts_list]

Example:

 dbca -silent -createDuplicateDB -gdbName PRMRY -primaryDBConnectionString 192.168.56.101:1521/PRMRY -sid STDBY -sysPassword ora123 -createAsStandby -dbUniqueName STDBY

You need to run the following command at standby site:

Dataguard => 12cR2 New Feature "Multiple Instance Redo Apply"

Starting in Oracle 12.2, we can run Redo Apply all or on some standby instances.
With this concept of multiple instance redo apply (MIRA), Redo Apply performance can scale as wide as the target RAC configuration allows.

This feature is crucial for Exadata and RAC customers with demanding high workloads on the primary database. For Active Data Guard customers, they can have real-time access to the data being churned on the primary database.

The ALTER DATABASE RECOVER MANAGED STANDBY DATABASE command, now accepts new INSTANCES [ ALL | integer] clause to start Redo Apply on multiple instances. The ALL option, starts redo apply on all the RAC standby instances that are in open or mount mode. All the instances must be in the same mounted or open mode; one instance cannot be in open mode (Active Data Guard or read-only mode) while others are in mounted mode. The integer option, specifies the number of RAC standby instances that will perform redo apply. We cannot specify which RAC instance(s) will perform the redo apply.

Starting redo apply on multiple instances has the following restrictions:
• In-Memory column store is not supported.
• Block Change tracking (BCT) is not supported.

With multi-node MRP, redo apply performance is now directly correlated to network bandwidth and latency between the primary and standby database environments

Dataguard

post for dataguard