High Availability and Backup Strategies in Software

Painting QR in Software High Availability and Backup Strategies

MAA best practices are published as a series of technical whitepapers and blue prints, and assist in deploying highly available Oracle-based applications and platforms that are capable of meeting and exceeding the business service-level requirements The MAA architecture covers all components of the technology stack, includes the hardware and the software, and addresses planned and unplanned downtime MAA provides a framework for high availability by incorporating redundancies into the components of the technology stack, and also by utilizing certain built-in high-availability features of the Oracle software For example, the Database Flashback feature enables you to recover from user errors such as an involuntary DROP TABLE statement by using a simple FLASHBACK TABLE command This cuts down the recovery time drastically, which otherwise would be needed for performing a point-in-time recovery using backups Figure 6-1 represents the MAA architecture using the Exadata Database Machine The Database Machine MAA architecture has identically sized Database Machines on the primary and standby sites The primary site contains a production database configured with Oracle Real Application Clusters (RAC) Oracle RAC provides protection from database server and

FIGURE 6-1

instance failures The standby site contains a physical standby database that is synchronized with the primary database by using Oracle Data Guard The Active Data Guard option enables the physical standby database to be open in a read-only state while the database is kept in sync with the primary database Active Data Guard enables you to offload read-only queries to the standby site and enhances the overall availability of the database by utilizing an otherwise idle standby site for reporting purposes The figure also depicts the use of Oracle database technologies such as Flashback, RMAN, and ASM for providing high availability during planned and unplanned downtime We ll next cover the Oracle high-availability features that address planned and unplanned downtime The intent is not to cover the complete set of MAA technologies, but only the topics that relate to the Exadata Database Machine and the common tasks that will be performed on the Machine The topics discussed in this section are listed here:

High availability with Oracle Data Guard Using Oracle GoldenGate with Database Machine Database Machine patches and upgrades Exadata Storage Server high availability Preventing data corruption

Oracle Data Guard is an integral component of MAA and the best-practice solution for ensuring high availability and disaster recovery of the Oracle database Data Guard provides an extensive set of features that enable you to recover from planned and unplanned downtime scenarios, such as recovering from data corruption, performing near-zero database upgrades, and conducting database migrations Data Guard provides the software to manage and maintain one or more standby databases that are configured as a replica of the primary database, and protects from data loss by building and maintaining redundant copies of the database When a data loss or a complete disaster occurs on the primary database, the copy of the data stored on the standby database can be used to repair the primary database Data Guard also provides protection from

6:

data corruptions by detecting and repairing corruptions automatically as they happen, using the uncorrupted copy on the standby database The Data Guard architecture consists of processes that capture and transport transactions occurring on the primary database and applying them on the standby databases Oracle redo generated on the primary site is used to transmit changes captured from the primary to the standby site(s), using a synchronous or asynchronous mechanism Once the redo is received by the standby site, it is applied on the standby databases using one of two possible methods: Redo Apply or SQL Apply The Redo Apply process uses the database media recovery process to apply the transactions to the standby databases Redo Apply maintains a block-for-block replica of the primary database, ensuring that the standby database is physically identical to the primary one in all respects The standby database that uses Redo Apply to sync up with the primary is called a physical standby The physical standby database can be open and made accessible for running read-only queries while the redo is being applied; this arrangement of the physical standby is called Active Data Guard The SQL Apply process mines the redo logs once they are received on the standby host, re-creates the SQL transactions as they occurred on the primary database, and then executes the SQL on the standby database The standby in this case is open for read-write activity, and contains the same logical information as the primary database However, the database has its own identity with possibly different physical structures The standby database that uses the SQL Apply as the synchronization method is called a logical standby NOTE The SQL Apply has some restrictions on the data types, objects, and SQL operations that it supports Refer to the Oracle Data Guard manuals for further details The MAA best practices dictate the use of Data Guard Redo Apply as the synchronization method for achieving the highest availability with the Database Machine MAA also proposes the use of Active Data Guard to enhance the overall availability of the database machine by utilizing the standby database for reporting and queries