You are on page 1of 13

Oracle Database High-Availability Architecture

Choosing and implementing the architecture that best fits the availability requirements of a business can be a daunting task. This architecture must encompass appropriate redundancy, provide adequate protection from all types of outages, ensure consistent high performance and robust security, while being easy to deploy, manage, and scale. Needless to mention, this architecture should be driven by well-understood business requirements. Choosing and implementing high-availability architecture is covered in Oracle Database High Availability Overview. Before using the best practices presented in this book, your organization should have already chosen high-availability architecture for your database as described in Oracle Database High Availability Overview. If you have not already done so, then refer to that document to learn about the highavailability solutions that Oracle offers for Oracle

Oracle Database High-Availability Best Practices
To build, implement and maintain high-availability architecture, a business needs high-availability best practices that involve both technical and operational aspects of its IT systems and business processes. Such a set of best practices removes the complexity of designing a high-availability architecture, maximizes availability while using minimum system resources, reduces the implementation and maintenance costs of the high-availability systems in place, and makes it easy to duplicate the highavailability architecture in other areas of the business. An enterprise with a well-articulated set of highavailability best practices that encompass high-availability analysis frameworks, business drivers and system capabilities, will enjoy an improved operational resilience and enhanced business agility. Building, implementing, and maintaining a high-availability architecture for Oracle Database using highavailability best practices is the purpose of this book. By using the Oracle Database high-availability best practices described, you will be able to:

Reduce the implementation cost of an Oracle Database high-availability system by following detailed guidelines on configuring your database, storage, application failover, backup and recovery Avoid potential downtime by monitoring and maintaining your database using Oracle Grid Control Recover quickly from unscheduled outages caused by computer failure, storage failure, human error, or data corruption Eliminate or reduce downtime that might occur due to scheduled maintenance such as database patches or application upgrades




Oracle Maximum Availability Architecture
Oracle Maximum Availability Architecture (MAA) is an Oracle best practices blueprint based on proven Oracle high-availability technologies and recommendations. The high-availability best practices described in this book make up one of several components of MAA. MAA involves high-availability best practices for all Oracle products across the entire technology stack Oracle Database, Oracle Application Server, Oracle Applications, Oracle Collaboration Suite, and Oracle Grid Control. Some of the key features of MAA include:

Considers various business service level agreements (SLA) to make high-availability best practices as widely applicable as possible Leverages database grid servers and storage grid with low-cost storage to provide highly resilient, lower cost infrastructure Uses results from extensive performance impact studies for different configurations to ensure that the high-availability architecture is optimally configured to perform and scale to business needs Gives the ability to control the length of time to recover from an outage and the amount of acceptable data loss from a natural disaster Evolves with each Oracle version and is completely independent of hardware and operating system





Recovery Manager (RMAN)
About Recovery Manager (RMAN)
Recovery Manager (RMAN) is an Oracle utility that can back up, restore, and recover database files. The product is a feature of the Oracle database server and does not require separate installation. Recovery Manager is a client/server application that uses database server sessions to perform backup and recovery. It stores metadata about its operations in the control file of the target database and, optionally, in a recovery catalog schema in an Oracle database. You can invoke RMAN as a command-line executable from the operating system prompt or use some RMAN features through the Enterprise Manager GUI.

Why Use RMAN?
Most production database systems impose stringent requirements on backup and recovery. As a DBA in charge of backup and recovery, you must:
y y y y y

Manage the complexity of backup and recovery operations Minimize the possibility of human error Make backups scalable and reliable Utilize all available media hardware Make backups proportional to the size of transactional changes, not to the size of database Make recovery time proportional to the amount of data recovered


You have two basic methods for performing these backup and recovery tasks on an Oracle release 8.0 or higher database:

Using operating system commands to perform backup and restore operations, and SQL or SQL*Plus statements to perform recovery Using Recovery Manager for backup, restore, and recovery


The advantage of using RMAN is especially true if you use Oracle Managed Files. When you let Oracle name and manage your datafiles, control files, and online redo logs, the system becomes easier to use. On the other hand, it may be harder for you to keep track of the filenames of the

various database files because you have not named them yourself. RMAN users do not suffer from this problem because RMAN handles all record keeping. Comparison of RMAN Automated and User-Managed Procedures

Besides the obvious advantage of automation, RMAN provides a host of other useful features. Below chart compares some of the differences between the RMAN methodology and the traditional user-managed methodology.
Comparison between RMAN and User-Managed Methods

Recovery Manager Uses a media management API so that RMAN works seamlessly with third-party media management software. More than 20 vendors support the API. When backing up online files, RMAN rereads fractured data blocks to get a consistent read. You do not need to place online tablespaces in backup mode when performing backups.

User-Managed Method Does not have support of a published API.

Requires placing online tablespaces in backup mode before backing them up, and then taking the tablespaces out of this mode after the backup is complete. Serious database performance and manageability problems can occur if you neglect to take tablespaces out of backup mode after an online backup is complete. Backs up all blocks, not just the changed blocks. Does not allow you to recover a

Performs incremental backups, which back up only those data blocks that changed after a

Recovery Manager

User-Managed Method

previous backup. You can recover the database NOARCHIVELOG database. using incremental backups, which means that you can recover a NOARCHIVELOG database. However, you can only take incremental backups of a NOARCHIVELOG database after a consistent shutdown. Computes checksums for each block during a backup, and checks for corrupt blocks when backing up or restoring. Many of the integrity checks that are normally performed when executing SQL are also performed when backing up or restoring. Does not provide error checking.

Omits never-used blocks from datafile backups so Includes all data blocks, regardless of that only data blocks that have been written to whether they contain data. are included in a backup. Uses the repository to report on crucial information, including:
y y y

Does not include any reporting functionality.

Database schema at a specified time Which files need a backup Which files have not had a backup in a specified number of days Which backups can be deleted because they are redundant or cannot be used for recovery Current RMAN persistent settings Requires storage and maintenance of operating system-based scripts. Requires you to follow a complicated procedure when creating a test or standby database. Requires you to locate and test backups manually. Requires you to parallelize manually by determining which files you need to back up and then issuing operating system



Stores RMAN scripts in the recovery catalog. Allows you to easily create a duplicate of the production database for testing purposes, or easily create or back up a standby database. Performs checks to determine whether backups on disk or in the media catalog are still available. Performs automatic parallelization of backup and restore operations.

Recovery Manager

User-Managed Method commands in parallel.

Tests whether files can be backed up or restored without actually performing the backup or restore. Performs archived log failover automatically. If RMAN discovers a corrupt or missing log during a backup, then it considers all logs and log copies listed in the repository as alternative candidates for the backup.

Requires you to actually restore backup files before you can perform a trial recovery of the backups. Cannot failover to an alternative archived log if the backup encounters a problem.

Overview of the RMAN Environment
The RMAN environment consists of the utilities and databases that play a role in a backup and recovery strategy. A typical RMAN setup utilizes the following:
y y y y

RMAN executable Target database Recovery catalog database Media management software

Of these components, only the RMAN executable and target database are required. RMAN automatically stores its metadata in the target database control file, so the recovery catalog database is optional. Nevertheless, maintaining a recovery catalog is strongly encouraged. If you create a catalog on a separate machine, and if the production machine fails completely, then you have all the restore and recovery information you need in the catalog.

About the RMAN Executable
The RMAN executable is automatically included with the Oracle software installation. Its location is platform-specific and is typically located in the same place as the other Oracle executables. On Unix systems, for example, the RMAN executable is located in $ORACLE_HOME/bin. To start the executable, simply enter the filename on the command line. For example, on a UNIX system, enter:
% rman

About the Target Database
The target database is the database that RMAN is backing up, restoring, or recovering. You can use a single recovery catalog in conjunction with multiple target databases. For example, assume that your data center contains 10 databases of varying sizes. You can use a single recovery catalog located in a different data center to manage the metadata from all of these databases.

About the RMAN Repository
The RMAN repository is a set of metadata that RMAN uses to store information about the target database and its backup and recovery operations. Among other things, RMAN stores information about:
y y y y y

Backup sets and pieces Image copies (including archived redo logs) Proxy copies The target database schema Persistent configuration settings

You can access this metadata by issuing LIST, REPORT, and SHOW commands in the RMAN interface, or by using SELECT statements on the catalog views (only if you use a recovery catalog)

RMAN Lists and Reports

You can either create a recovery catalog in which to store the repository, or let RMAN store the repository exclusively in the target database control file. Below chart depicts RMAN using a recovery catalog. RMAN with Optional Recovery Catalog

Although RMAN can conduct all major backup and recovery operations using just the control file, note these advantages of using the catalog:

y y

Some RMAN commands and operations function only with a catalog. The recovery catalog retains historical backup information that can get overwritten in the control file. The recovery catalog stores information about backups from different incarnations of the database.


The recovery catalog is maintained solely by RMAN; the target database never accesses it directly. RMAN automatically propagates information about the database structure, archived redo logs, backup sets, and datafile copies into the recovery catalog from the target database's control file. You can also propagate this information to the catalog manually using the RESYNC CATALOG command.

About the RMAN Media Management Interface
To store backups on tape, RMAN requires a media manager. A media manager is a software program that loads, labels, and unloads sequential media such as tape drives used to back up and recover data. Below shows the architecture for a media manager integrated with Oracle. Architecture for MML Integrated with Oracle

The Oracle server session is the same type of server session used when a client such as SQL*Plus connects to the database. The media management library (MML) in above figure represents vendor-supplied media management software library that can interface with Oracle. Oracle calls MML software routines to back up and restore data files to and from media controlled by the media manager

Oracle Data Guard
What is Data Guard
The data guard means any DML, DDL, or DCL issued will affect both the databases. In other words you don't need to duplicate the database again and again; your databases are up to date at any point. Data guard can perform failovers and switchovers transparently without informing the client. Standby database and data guard are 2 different things, because standby database do not performs failovers and switchovers. The client will receive the error. Data Guard is one step forward then the standby database

Oracle Data Guard
Oracle Data Guard provides the management, monitoring, and automation software to create and maintain one or more standby databases to protect Oracle data from failures, disasters, human error, and data corruptions while providing high availability for mission critical applications Data Guard's loosely coupled architecture provides optimal data protection and availability:

Database changes are transmitted directly from memory, isolating the standby from I/O corruptions that occur at the primary. A standby database uses a different software code-path than the primary from firmware and software errors that impact the primary database. isolating it



Oracle corruption detection insures that data is logically and physically consistent before it is applied to a standby database. Data Guard detects silent corruptions caused by hardware errors (memory, cpu, disk, NIC) and data transfer faults, and prevents them from impacting the standby database. A standby database is used to perform planned maintenance in a rolling fashion, minimizing downtime and eliminating the risks inherent with introducing change to production environments.



Oracle Active Data Guard 11g extends basic Data Guard functionality by allowing read-only access to a physical standby database while continuously applying changes received from the primary database. This increases performance and return on investment by offloading ad-hoc

queries, Web-based access, reporting, and backups from the primary database while also providing disaster protection

Data Guard configuration
A Data Guard configuration consists of one production database and one or more standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located, provided they can communicate with each other. For example, you can have a standby database on the same system as the production database, along with two standby databases on other systems at remote locations. You can manage primary and standby databases using the SQL command-line interfaces or the Data Guard broker interfaces, including a command-line interface (DGMGRL) and a graphical user interface that is integrated in Oracle Enterprise Manager.

1. Primary Database
A Data Guard configuration contains one production database, also referred to as the primary database that functions in the primary role. This is the database that is accessed by most of your applications. The primary database can be either a single-instance Oracle database or an Oracle Real Application Clusters (RAC) database.

2. Standby Databases
A standby database is a transactionally consistent copy of the primary database. Using a backup copy of the primary database, you can create up to thirty standby databases and incorporate them in a Data Guard configuration. Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo to the standby database. Similar to a primary database, a standby database can be either a single-instance Oracle database or an Oracle RAC database. The types of standby databases are as follows:

Physical standby database

Provides a physically identical copy of the primary database, with on disk database structures that are identical to the primary database on a block-for-block basis. The database schemas, including indexes, are the same. A physical standby database is kept

synchronized with the primary database, through Redo Apply, which recovers the redo data received from the primary database and applies the redo to the physical standby database. As of Oracle Database 11g release 1 (11.1), a physical standby database can receive and apply redo while it is open for read-only access. A physical standby database can therefore be used concurrently for data protection and reporting.

Logical standby database It contains the same logical information as the production database, although the physical organization and structure of the data can be different. The logical standby database is kept synchronized with the primary database through SQL Apply, which transforms the data in the redo received from the primary database into SQL statements and then executes the SQL statements on the standby database. A logical standby database can be used for other business purposes in addition to disaster recovery requirements. This allows users to access a logical standby database for queries and reporting purposes at any time. Also, using a logical standby database, you can upgrade Oracle Database software and patch sets with almost no downtime. Thus, a logical standby database can be used concurrently for data protection, reporting, and database upgrades.


Snapshot Standby Database A snapshot standby database is a fully updatable standby database. Like a physical or logical standby database, a snapshot standby database receives and archives redo data from a primary database. Unlike a physical or logical standby database, a snapshot standby database does not apply the redo data that it receives. The redo data received by a snapshot standby database is not applied until the snapshot standby is converted back into a physical standby database, after first discarding any local updates made to the snapshot standby database. A snapshot standby database is best used in scenarios that require a temporary, updatable snapshot of a physical standby database. Note that because redo data received by a snapshot standby database is not applied until it is converted back into a physical standby, the time needed to recover from a primary database failure is directly proportional to the amount of redo data that needs to be applied.

3. Configuration Example
Below image shows a typical Data Guard configuration that contains a primary database that transmits redo data to a standby database. The standby database is remotely located from the primary database for disaster recovery and backup operations. You can

configure the standby database at the same location as the primary database. However, for disaster recovery purposes, Oracle recommends you configure standby databases at remote locations. Typical Data Guard Configuration

By: Amir Farooq (BI Analyst) - 911 Inbox Business Technologies