High Availability Overview

analysis. Change data capture quickly identifies and processes only the data that has changed, not entire tables, and makes the change data available for further use.

Change data capture does not depend on intermediate flat files to stage the data outside of the relational database. It captures the change data resulting from INSERT, UPDATE, and DELETE operations made to user tables. The change data is then stored in a database object called a change table, and the change data is made available to applications in a controlled way.

See Also: Oracle9i Data Warehousing Guide

High Availability Overview

Computing environments configured to provide nearly full-time availability are known as high availability systems. Such systems typically have redundant hardware and software that makes the system available despite failures. Well-designed high availability systems avoid having single points-of-failure. Any hardware or software component that can fail has a redundant component of the same type.

When failures occur, the failover process moves processing performed by the failed component to the backup component. This process remasters systemwide resources, recovers partial or failed transactions, and restores the system to normal, preferably within a matter of microseconds. The more transparent that failover is to users, the higher the availability of the system.

Oracle has a number of products and features that provide high availability. These include multiplexed redo log files, Recovery Manager (RMAN), Fast-Start Recovery, LogMiner, flashback query, partitioning, Transparent Application Failover, online reorganization, Oracle Replication, Oracle Data Guard and Standby Database, Real Application Clusters, and Oracle Real Application Clusters Guard. These can be used in various combinations to meet specific high availability needs.

1-60 Oracle9i Database Concepts

High Availability Overview

See Also:

Transparent Application Failover

Transparent Application Failover (TAF) enables an application user to automatically reconnect to a database if the connection fails. Active transactions roll back, but the new database connection, made by way of a different node, is identical to the original. This is true regardless of how the connection fails.

With Transparent Application Failover, a client notices no loss of connection as long as there is one instance left serving the application. The database administrator controls which applications run on which instances and also creates a failover order for each application.

Elements Affected by Transparent Application Failover

During normal client/server database operations, the client maintains a connection to the database so the client and server can communicate. If the server fails, so then does the connection. The next time the client tries to use the connection the client issues an error. At this point, the user must log in to the database again.

With Transparent Application Failover, however, Oracle automatically obtains a new connection to the database. This enables users to continue working as if the original connection had never failed.

There are several elements associated with active database connections. These include:

Client/Server database connections

Introduction to the Oracle Server 1-61

High Availability Overview

Transparent Application Failover automatically restores some of these elements. However, you might need to embed other elements in the application code to enable transparent application failover.

See Also:

Online Reorganization Architecture

Database administrators can perform a variety of online operations to table definitions, including online reorganization of heap-organized tables. This makes it possible to reorganize a table while users have full access to it.

This online architecture provides the following capabilities:

Any physical attribute of the table can be changed online. The table can be moved to a new location. The table can be partitioned. The table can be converted from one type of organization (such as a heap-organized) to another (such as index-organized).

Many logical attributes can also be changed. Column names, types, and sizes can be changed. Columns can be added, deleted, or merged. One restriction is that the primary key of the table cannot be modified.

Online creation and rebuilding of secondary indexes on index-organized tables (IOTs). Secondary indexes support efficient use of block hints (physical guesses). Invalid physical guesses can be repaired online.

Indexes can be created online and analyzed at the same time. Online fix-up of physical guess component of logical ROWIDs (used in secondary indexes and mapping table on index-organized tables) also can be used.

Fix the physical guess component of logical ROWIDs stored in secondary indexes on IOTs. This allows online repair of invalid physical guesses

1-62 Oracle9i Database Concepts

High Availability Overview

Data Guard Overview

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—corruptions, human errors, and disasters. If a failure occurs on the production (primary) database, you can failover to one of the standby databases to become the new primary database. In addition, planned downtime for maintenance can be reduced because you can quickly and easily move (switch over) production processing from the current primary database to a standby database, and then back again.

Note: To protect against unlogged direct writes in the primary database that cannot be propagated to the standby database, turn on FORCE LOGGING at the primary database before taking datafile backups for standby creation. Keep the database (or at least important tablespaces) in FORCE LOGGING mode as long as the standby database is active.

Data Guard Configurations

A 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 Network 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.

Data Guard Components

As application transactions make changes to the primary database, the changes are logged locally in redo logs, which are sent to the standby databases by log transport services and applied by log apply services.

Introduction to the Oracle Server 1-63

High Availability Overview

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 performing recovery (by applying logs), or open for reporting access. A physical standby database can be queried read-only when not performing 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.

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 ease maintenance.

1-64 Oracle9i Database Concepts