Learning About Data Guard - Expert Consolidation in Oracle Database 12c - page 327

New Data Guard features in 12.1
As part of the new Oracle release there are some noteworthy changes to Data Guard as well. As with every new release
it is a good idea to check the Data Guard Concepts and Administration Guide as well as the Data Guard Broker
documentation for the section named “New features … in 12.1”. The following sections explain what is new and useful
from a Data Guard point of view with regards to consolidation and Database as a Service. In addition to the features
you can read about in the next section there are development related changes as well, mainly geared towards enabling
support for reporting applications to use sequences or temporary tables on the standby database. Although these new
features are great steps forward in terms of technology they will not be discussed here. Please bear in mind that some
of the new features require extra licenses on top of Enterprise Edition.
What will not be mentioned at this stage in the document is the support for Pluggable Databases. The remainder
of the next chapter will deal specifically with these in mind. Since Data Guard operates at the database level, not at the
PDB level, all operations shown below are executed at the CDB$ROOT level. It is not possible to limit the scope of redo
transport to a single Pluggable Database. Also note that non-Container Databases are out of the scope of this chapter.
Better separation of duties for log shipping
You read in the Linux installation chapter that Oracle has expanded roles available to users. A frequent complaint in
larger organizations was that Data Guard required the SYS account to transmit redo between the primary and standby
database. The security departments rightfully remarked that the SYS role was too powerful, and a less powerful role
should be used to transmit redo. With Oracle 12.1 this request has been implemented in the form of an initialization
parameter.
A database account which has been granted the SYSOPER privilege can be defined to ship redo from the primary
to the standby database. Interestingly at the time of this writing the SYSDG role did not allow you to ship redo to
the standby databases. When granting the SYSOPER to a user please do not forget to synchronize the password
files across all databases in the Data Guard configuration. You can easily check the contents of the file by querying
v$pwfile_users. Remember that the redo transport user needs to be a common user in the CDB.
Better support for cascaded destinations
A cascaded standby database receives redo indirectly from the primary database via an intermediate hop. Although
the ability to have cascaded standby databases allows the enterprise architect to develop interesting disaster recovery
solutions, the main reason for cascading is to offload the redo burden from the primary database. The more redo
destinations you define in the primary database the more work the host has to complete. Keep in mind that there has
to be a log shipping process for every standby database. If there are lots of standby databases to be supplied with redo
this can be a lot of extra work for the primary database and host.
Oracle 12.1 has improved support for cascading with physical standby databases. Consider a scenario as
shown in Figure 9-3 . Here a primary Redo arriving in data center B is cascaded to two standby databases in
data center C.