Oracle Data guard Overview

Some things really need to be used constantly before they can be better remembered. Let's talk about data guard. I checked concepts several times, I can see Data guard related content on the Internet every other time. The concept in my mind has become blurred and there are still too few practices. Today, I simply wrote it into my blog, so that I don't have to go over the document in the future and it is convenient for you to read it.

 

Overview of Oracle Data guard

Oracle Data guard lets you maintain uptime automatically and transparently, despite failures and outages. oracle Data guard maintains up to nine standby databases, each of which is a real-time copy of the production database, to protect against all threats-Snapshot uptions, data failures, human errors, and disasters. if a failure occurs on the production (primary) database, then you can fail over to one of the standby databases to become the new primary database. in addition, planned downtime for maintenance can be partitioned, because you can quickly and easily move (switch over) production processing from the current primary database to a standby database, and then back again.

Fast-start failover provides the ability to automatically, quickly, and reliably fail over to a designated, synchronized standby database in the event of loss of the primary database, without requiring that you perform complex manual steps to invoke the Failover. this lets you maintain uptime transparently and increase the degree of high availability for system failures, data failures, and site outages, as well the robustness of disaster recovery.

 

Oracle Data guard deployments

 

An Oracle Data guard configuration is a collection of loosely connected systems, consisting of a single primary database and up to nine standby databases that can include a mix of both physical and logical standby databases. the databases in a data guard configuration can be connected by a LAN in the same data center, or-for maximum Disaster Protection-geographically dispersed over a WAN and connected by Oracle Net Services.

A Data guard configuration can be deployed for any database. this is possible because its use is transparent to applications; no application code changes are required to accommodate a standby database. moreover, data guard lets you tune the configuration to balance data protection levels and application performance impact; you can configure the protection mode to maximize data protection, maximize availability, or maximize performance.

As application transactions make changes to the primary database, the changes are logged locally in redo logs. for physical standby databases, the changes are applied to each physical standby database that is running in managed recovery mode. for logical standby databases, the changes are applied using SQL regenerated from the archived
Redo logs.

 

Physical standby Databases

 

A physical standby database is physically identical to the primary database. while the primary database is open and active, a physical standby database is either discovery Ming recovery (by applying logs), or open for reporting access. A physical standby database can be queried read only when not known recovery while the production database continues to ship redo data to the physical standby site.

 

Physical standby on disk database structures must be identical to the primary database on a block-for-block basis, because a recovery operation applies changes block-for-block using the physical rowid. the database schema, including indexes, must be the same, and the database cannot be opened (other than for read-only access ). if opened, the physical standby database will have different rowids, making continued recovery impossible.

 

Logical standby Databases

A logical standby database takes standard Oracle archived redo logs, transforms the redo records they contain into SQL transactions, and then applies them to an open standby database. although changes can be applied concurrently with end-user access, the tables being maintained through regenerated SQL Transactions allow read-only access to users of the logical standby database. because the database is open, it is physically different from the primary database. the database tables can have different indexes and physical characteristics from their primary database peers, but must maintain logical consistency from an application access perspective, to fulfill their role as a standby data source.

 

Oracle Data guard Broker

 

Oracle Data guard broker automates complex creation and maintenance tasks and provides dramatically enhanced monitoring, alert, and control mechanisms. It uses background agent processes that are integrated with the Oracle
Database Server and associated with each data guard site to provide a unified monitoring and management infrastructure for an entire data guard configuration. two user interfaces are provided to interact with the data guard configuration, a command-line interface (dgmgrl) and a graphical user interface called data guard manager.

Oracle Data guard manager, which is integrated with Oracle Enterprise Manager, provides wizards to help you easily create, manage, and monitor the configuration. this integration lets you take advantage of other enterprise manager features, such as to provide an event service for alerts, the Discovery Service for easier setup, and the job service to launch maintenance.

 

Data guard with RAC

RAC enables multiple independent servers that are linked by an interconnect to share access to an Oracle database, providing high availability, scalability, and redundancy during failures. RAC and data guard together provide
Benefits of both system-level, site-level, and data-level protection, resulting in high levels of availability and disaster recovery without loss of data:
■ RAC addresses system failures by providing rapid and automatic recovery from failures, such as node failures and instance crashes. It also provides increased scalability for applications.
■ Data Guard addresses site failures and data protection through transactionally consistent primary and standby databases that do not share disks, enabling recovery from site disasters and data during uption.

Specified different ubuntures using RAC and data guard are possible depending on the use of local and remote sites and the use of nodes and a combination of logical and physical standby databases.