In Data Guard, transfer of the changed data from the primary to standby database is
achieved by redo with no alternative. However, the apply process of the redo content to the
standby database may vary. The different methods on the apply process reveal different
type of standby databases.
There were two kinds of standby databases before Oracle database Version 11g, which
were: physical standby database and logical standby database. Within Version 11g we
should mention a third type of standby database which is snapshot standby. Let's look
at the properties of these standby database types.
Physical standby database
The Physical standby database is a block-based copy of the primary database. In a physical
standby environment, in addition to containing the same database objects and same data,
the primary and standby databases are identical on a block-for-block basis. Physical standby
databases use Redo Apply method to apply changes. Redo Apply uses Managed recovery
process (MRP) in order to manage application of the change in information on redo.
In Version 11g, a physical standby database can be accessible in read-only mode while Redo
Apply is working, which is called Active Data Guard. Using the Active Data Guard feature, we
can offload report jobs from the primary to physical standby database.
Logical standby database
Logical standby database is a feature introduced in Version 9iR2. In this configuration, redo
data is first converted into SQL statements and then applied to the standby database. This
process is called SQL Apply. This method makes it possible to access the standby database
permanently and allows read/write while the replication of data is active. Thus, you're also
able to create database objects on the standby database that don't exist on the primary
database. So a logical standby database can be used for many other purposes along with
high availability and disaster recovery.
Due to the basics of SQL Apply, a logical standby database will contain the same data as the
primary database but in a different structure on the disks.
One discouraging aspect of the logical standby database is the unsupported data types,
objects, and DDLs. The following data types are not supported to be replicated in a logical
standby environment:
BFILE
Collections (including VARRAYS and nested tables)
Multimedia data types (including Spatial, Image, and Oracle Text)
ROWID and UROWID
User-defined types
The logical standby database doesn't guarantee to contain all primary data because of the
unsupported data types, objects, and DDLs. Also, SQL Apply consumes more hardware
resources. Therefore, it certainly brings more performance issues and administrative
complexities than Redo Apply.
Snapshot standby database
Principally, a snapshot standby database is a special condition of a physical standby
database. Snapshot standby is a feature that is available with Oracle Database Version 11g.
When you convert a Physical standby database into a snapshot standby database, it becomes
accessible for read/write. You can run tests on this database and change the data. When
you're finished with the snapshot standby database, it's possible to reverse all the changes
made to the database and turn it back to a physical standby again.
An important point here is that a snapshot standby database can't run Redo Apply. Redo
transfer continues but standby is not able to apply redo.
Oracle Data Guard architecture
The main architecture of Oracle Data Guard 11gR2 includes a primary database, up to 30
standby databases, the redo transport services, (which automatically ship the redo log data
from the primary to standby server), and Apply Services (which applies the changes in redo
on the standby database).
Data Guard services
Redo transport services
In a primary database, when a user commits a transaction, the relevant redo data is written
into online redo logfiles from memory (Redo Log Buffer). After the online redo log group
becomes full it is archived into an archived redo logfile with a log switch. It's possible to
configure Data Guard sending the redo data to standby databases from the log buffer as the
transactions are committed (by LGWR process) or from the online redo logfiles when they're
being archived (by ARCn processes). Shipping
Here are the important properties of the log transport with the ARCH attribute:
Logs are sent by the ARCH process; the LNS process is not in use
Standby redo logs are not mandatory on the standby database
Data in the unarchived online redo log will be lost in a failover
=================
If LGWR is used for the redo transportation, it's possible to guarantee zero data loss failovers
by creating a Data Guard configuration in which the primary database waits for confirmation
from the standby database that redo has been received, before it informs that the commit
is completed. This configuration is called Synchronous redo transport (SYNC). However, this
may affect the performance of the primary database.
The following diagram shows the Data Guard configuration with LGWR and SYNC
transportation mode:
The following points explain the diagram in a better way:
LNS process
Acknowledgment needed from the standby database (RFS to LNS and LNS to LGWR)
to send COMMIT ACK to the database user
It's mandatory to use standby redo logs
Zero data loss in failover can be guaranteed with this configuration
There maybe slower response times on the primary database
The primary database stops giving service in a network disruption incident between
primary and standby
The other option is to use the Asynchronous redo transport (ASYNC) method, which avoids
the impact to primary database performance. In this method, the primary database never
waits for any acknowledgment from the standby database in order to complete the commit.
In the ASYNC redo transport method we have the performance gain; however, this method
does not guarantee zero data loss failovers because it does not guarantee all the committed
transactions being received by the standby database at any moment.
No comments:
Post a Comment