Today we are going to look at the material on Data Guard and discuss the differences between Data Guard, Active Data Guard, and Golden Gate. We are going to look at what it takes to replicate from an on premise system to the cloud and from the cloud to an on premise system. It is important to know that you can also synchronize between two cloud instances but we will not cover this today.
If we look at the books that cover this topic they include
The home page for Data Guard provides links to white papers
The key concepts around Data Guard are the mechanisms for replication and how logs are shipped between systems. The basic foundation of Data Guard centers around replication of changes. When an insert or update is made to a table, this change is captured by the log writer and replicated to the standby system. If the replication mechanism is physical replication the data blocks changed are copied to the standby system. If the replication mechanism is logical replication the sql command is copied to the standby system and executed. Note that the select or read statements are not recorded and copied, only the commands that write to storage or update information in the database. By capturing the changes and shipping them to the standby system we can keep the two systems in synchronization. If a client is trying to execute a select statement on the primary database and the primary fails or goes offline, the select statement can be redirected to the standby for the answer. This results in seconds of delay rather than minutes to hours as is done with disk replication or recovery from a backup. How the replication is communicated to the standby system is also configurable. You can configure a write and release mechanism or a wait for commit mechanism. With the write and release mechanism, the logs are copied to the standby system and the primary system continues operation. With the wait for commit mechanism the primary stalls until the standby system commits the updates.
Significant improvements were made in 11g with the log writer service (LNS) and the redo apply service (RNS). The LNS has the ability to delay the shipping of the logs in the asynchronous update mode and can compress the logs. The RNS knows how the LNS is configured and can get decompress the logs and apply them as was done before. This delay allows for the LNS to look for network congestion and ship the logs when the network is not so overloaded. The compression allows the packet size to be smaller to reduce contention on the network and make the replication more efficient. It is important to note that you can have a single LNS writing to multiple RNS targets to allow for replication not in a one to one configuration but in a one to many configuration. It is also important to note that this technology is different from table cloning or data masking and redaction that we talked about earlier. The assumption is that there is a master copy of the data on the target system and we only ship changes between the systems when an update occurs on the primary.
The key difference between Data Guard and Active Data Guard is the state of the target database. With Data Guard, the database can not have any active sessions other than the RNS agent. You can not open the database for read only to do backups or analytics. Having an active sessions blocks the RNS agent from committing the changes into the database. Active Data Guard solves this problem. The RNS agent understands that there are active connections and can communicate changes to the active sessions if they are reading data from updated areas. A typical SQL connection uses buffering to minimize reads from the disk. Reads are done from an in memory buffer to speed up requests. The problem with reading data on a standby system is invalidation of these buffers. With Data Guard, there is no mechanism to invalidate buffers of sessions on other connections. With Active Data Guard, these mechanisms exist and updates are not only written to the disk but the cache for the other connections are updated.
Golden Gate is a more generic case of Active Data Guard. One of the limitations of Data Guard is that you must have the same chip set, operating system, and database version for replication. Translations are not done when changes are shipped from primary to standby. You can't for example replicate from a Sparc Server to an X86 server running the same version of the Oracle database. One uses little endian while the other uses big endian to store the bits on disk. Physical replication between these two systems would require a byte translation of every change. Data Guard does not support this but Golden Gate does. Golden Gate allows you to no only ship changes from one database instance to a different chip architecture but a different chip architecture on a different operating system running a different database. Golden Gate was originally crated to replicate between database engines so that you could collect data with SQL Server and replicate the data to an Oracle database or MySQL database so that you could do analytics on a different database engine than your data collection engine. With Golden Gate there is a concept similar to the LNS and RNS but the agents are more intelligent and promote the data type to a master view that can be translated into the target type. When we define an integer it might mean 32 bits on one system but 64 bits on another system. Golden Gate is configured to lead fill from 32 to 64 and truncate from 64 to 32 appropriately based on your use cases and configurations.
To replicate between two systems we basically need an open port from the primary system and the standby system to ship the logs. We also need a landing area to drop the change logs so that the RNS can pick up the changes and apply them. This prohibits Amazon RDS from enabling Data Guard, Active Data Guard, or Golden Gate since you do not have file system access. To run Data Guard in Amazon or Azure you need to deploy the Oracle database on a compute or IaaS instance and purchase the perpetual license with all of the options associated with the configuration. The beautiful thing about Data Guard is that it uses the standard port 1521 to communicate between the servers. There are special commands developed to configure and setup Data Guard that bridge between the two systems. As data is transmitted it is done over port 1521 and redirected to the RNS agent. We can either open up a network port in the cloud or create an ssh tunnel to communicate to our standby in the cloud. The communication works in both directions so we can flip which is primary and which is standby with a command or a push of a button with Enterprise Manager.
The important conversation to have about data protection is not necessarily do I have a copy of it somewhere else. We can do that with RMAN backups or file backups to replicate our data in a safe and secure location. The important conversation to have is how long can we survive without access to the data. If an outage will cost us thousands per minute, we need to look at more than file replication and go with parallel database availability. Data Guard provides this mechanism to keep an active database in another location (on premise or in the cloud) and provides for not only a disaster recovery solution but a way or offloading services from our primary production system. We can break the replication for a few hours and stop the redo apply on the standby while we do a backup. The logs will continue to be shipped just not applied. When the backup is finished we grind through the logs and apply the changes to the standby. We have a window of vulnerability but we have this while we are running backups on our primary system as well. We can now offload the backups to our standby system and let the primary continue to run as needed without interruption. In effect what this does is take all of the small changes that happen throughout the day and ship them to a secondary system so there is a trickle effect on performance. If we do an incremental backup at night we basically block the system while we ship all these changes all at once.
In summary, Data Guard is included with the High Performance Edition of the database and a free part of any on premise Enterprise Edition database. Active Data Guard is included with Extreme Performance Edition of the database and can be matched to synchronize an on premise or in cloud database that is also licensed to run Active Data Guard. There is a ton of reference material available on how Data Guard, Active Data Guard, and Golden Gate works. There are numerous tutorials and examples on how to configure and setup the service. It is important to know that you can use the cloud for this replication and a Dr to the Cloud whitepaper is available detailing how to do this.