Backup and Recovery - Expert Consolidation in Oracle Database 12c - page 383

Total System Global Area 1603411968 bytes
Fixed Size 2260920 bytes
Variable Size 452984904 bytes
Database Buffers 1140850688 bytes
Redo Buffers 7315456 bytes
starting full resync of recovery catalog
full resync complete
RMAN> select open_mode,log_mode,flashback_on from v$database;
OPEN_MODE LOG_MODE FLASHBACK_ON
-------------------- -------------- ------------------
MOUNTED ARCHIVELOG NO
This is one of the enhancements that put a large smile on the database administrator's face: nothing essential
since we could check in sqlplus before, but such a convenience that you do not want to miss this.
Enhanced over-the-network features
The over-the-network capabilities existed before Oracle 12c in the form of the “from active database” clause in RMAN,
but for a limited number of use cases. The duplication from the active database includes the copy of the source
database over the network.
This functionality has been enhanced in 12c in that the auxiliary instance can use existing backup sets on the
target database (host) to reduce the overhead of the network copy. If you would like to try this you should use the
using (compressed) backupset or section size clause and allocate at least as many auxiliary channels as you have
target channels.
Beginning with Oracle 12c you can also make use of backup sets created on the fly by the remote physical standby
database to restore or recover another database. Backupsets are transparently transferred over the network to the
destination host. But instead of using the “from active database” clause you use “from service” instead. The use of
a TNS service name obviously requires a corresponding service name definition in the TNS_ADMIN directory. The
main use case provided by the Oracle documentation is the recovery of a standby database using an incremental
backup. The ease of use is demonstrated by the following example, issued while connected to the standby database.
For this example to work the standby database CDB2 had media recovery stopped while the primary database—
CDB1—was instructed not to transport redo. While the standby was effectively on hold, the primary performed log
switches and a new tablespace “apress” has been created. The incremental backup is then initiated on the primary
which in this case is the auxiliary database. Although the same end result could be achieved with Oracle 11.2 as well, it
was a more complex process with room for error.
The first step is to connect to the databases in the correct way, that is, the standby database is your target while
the primary is the auxiliary instance:
[oracle@server1 ~]$ rman target sys@cdb2 auxiliary sys@cdb1
Recovery Manager: Release 12.1.0.1.0 - Production on Fri Sep 20 22:01:34 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.