2 Oracle Database High Availability Features and Products

2.1.1 Fast-Start Fault Recovery

Oracle provides fast and predictable recovery from system faults and database failures. The Fast-Start Fault Recovery technology included in Oracle Database automatically bounds database recovery time upon startup by using its self-tuned checkpoint processing. This makes recovery time fast and predictable, and improves the ability to meet service level objectives. Oracle's Fast-Start Fault Recovery can reduce recovery time on a heavily-laden database from tens of minutes to a few seconds.

Fast-Start Fault Recovery features include:

• Predictable, bounded recovery from instance, database, and computer failures

• Database checkpointing is self-tuning to maintain desired recovery time objective

2.1.2 Oracle Real Application Clusters and Oracle Clusterware

Oracle Real Application Clusters (Oracle RAC) and Oracle Clusterware allow the Oracle Database to run any packaged or custom application across a set of clustered servers. This capability provides the highest levels of availability and the most flexible scalability. If a clustered server fails, Oracle Database continues running on the surviving servers. When more processing power is needed, you can add another server without interrupting access to data.

Oracle RAC enables multiple instances that are linked by an interconnect to share access to an Oracle database. In an Oracle RAC environment, the Oracle Database runs on two or more systems in a cluster while concurrently accessing a single shared database. The result is a single database system that spans multiple hardware systems. This enables Oracle RAC to provide high availability and redundancy during failures in the cluster. Oracle RAC accommodates all system types, from read-only data warehouse (DSS) systems to update-intensive online transaction processing (OLTP) systems.

Oracle Clusterware is software that, when installed on servers running the same operating system, enables the servers to be bound together to operate as if they are one server, and manages the availability of user applications and Oracle databases. Oracle Clusterware also provides all of the features required for cluster management, including node membership, group services, global resource management, and high availability functions:

• For high availability, you can place Oracle databases (single-instance or Oracle RAC databases), and user applications (Oracle and non Oracle) under the management and protection of Oracle Clusterware so that they restart on process failure or fail over to another node on node failure.

• For cluster management, Oracle Clusterware presents multiple independent servers as if they are a single-system image or one virtual server. This single virtual server is preserved across the cluster for all management operations, enabling administrators to perform installations, configurations, backups, upgrades, and monitoring functions once. Then, Oracle Clusterware automatically distributes the execution of these management functions to the appropriate nodes in the cluster.

Oracle Clusterware is a requirement for using Oracle RAC and it is the only clusterware that you need for most platforms on which Oracle RAC operates. Although the Oracle Database continues to support select third-party clusterware products on specified platforms, using Oracle Clusterware provides the benefit of dispensing with proprietary vendor clusterware and using an integrated software stack from Oracle that provides disk management with Oracle ASM to data management with the Oracle Database and Oracle RAC. In addition, Oracle Database features, such as Oracle Services, use the underlying Oracle Clusterware mechanisms to provide their capabilities.

Oracle Clusterware requires two clusterware components: a voting disk to record node membership information and the Oracle Cluster Registry (OCR) to record cluster configuration information. The voting disk and the OCR must reside on shared storage. The Oracle Clusterware requires that each node be connected to a private network by way of a private interconnect.

Together, Oracle RAC and Oracle Clusterware provide the following benefits:

• Ability to tolerate and quickly recover from computer and instance failures

• Ability to apply Oracle Clusterware upgrades, patch sets, and interim patches in a rolling fashion

  For example, upgrading Oracle Clusterware from Oracle 10g to Oracle 11g, patching Oracle Clusterware from Oracle 10.2.0.3 to 10.2.0.4, and patching Oracle Clusterware from Oracle 10.2.0.2 Bundle 1 to Oracle 10.2.0.2 Bundle 2

• Rolling upgrades for system and hardware changes

• Rolling patch upgrades for some interim patches

• Service relocation and, when you perform additional Fast Application Notification (FAN) and client configuration, applications can receive FAN events and react immediately to achieve fast, automatic, and intelligent connection and failover

• Load balancing advisory

• Runtime connection load balancing with Oracle JDBC, OCI, and ODP.NET

• Flexibility to increase processing capacity using commodity hardware without downtime or changes to the application

• Comprehensive manageability integrating database and cluster features

• Scalability across database instances

Specifically, Oracle Clusterware provides the following benefits

• Automatically restarts failed Oracle processes

• Automatically manages and fails over Oracle Virtual IP (VIP) on another node in the cluster on node failures

• Automatically restarts resources from failed nodes on surviving nodes

• For Oracle RAC databases, all Oracle processes are under the control of Oracle Clusterware by default; for Oracle single-instance databases, you can configure the Oracle processes into a resource group that is under the control of Oracle Clusterware

• For Oracle and non Oracle applications, Oracle Clusterware provides an application programming interface (API) that enables you to control other Oracle processes with Oracle Clusterware, such as restart or react to failures and certain rules

• Manages node membership and prevents split brain syndrome in which two or more instances attempt to control the database

• Provides rolling release upgrades of Oracle Clusterware, with no downtime for applications

2.1.3 Oracle Data Guard

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable Oracle databases to survive disasters and data corruptions. Data Guard maintains standby databases as transactionally consistent copies of the primary (production) database. Then, if the primary database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the primary role, minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.With Data Guard, administrators can optionally improve primary database performance by offloading resource-intensive backup and reporting operations to standby systems.

An Oracle Data Guard configuration consists of one primary database and one or more standby databases. Using a backup copy of the primary database, you can create up to nine 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.

A standby database can be a physical standby database, a snapshot standby database, or a logical standby database, and a Data Guard configuration can include any combination of these types of standby databases:

• Physical standby database

  Provides a physically identical copy of the primary database, with datafiles that are identical to the primary database. The database schema, including indexes, are the same. A physical standby database is kept synchronized with the primary database, though Redo Apply, which recovers the redo data received from the primary database and applies the redo to the physical standby database.

  A physical standby database can be used for business purposes other than disaster recovery. Starting in Oracle Database 11g Release 1, the physical standby database can be opened with read-only access while redo is being applied to the standby database. This mode, referred to as real-time query standby, allows users to access an up-to-date physical standby database for queries at any time. Also, you can convert a physical standby database into a snapshot standby database.

• Snapshot standby database

  A snapshot standby database is an updatable standby database that you create from a physical standby database. A snapshot standby database receives and archives redo data received from the primary database, but the snapshot standby database does not apply redo data from the primary database while the standby is open read/write. Because of this, the snapshot standby typically diverges from the primary database over time. Moreover, local updates to the snapshot standby database cause additional divergence.

  Redo data is not applied until you convert the snapshot standby database back into a physical standby database, and after all local updates to the snapshot standby database are discarded. With a single command, you can revert a snapshot standby back to a physical standby database, at which time the changes made to the snapshot standby state are discarded, and Redo Apply automatically resynchronizes the physical standby database with the primary database using the redo that was archived.

• Logical standby database

  Contains the same logical information as the primary database, although the physical organization and structure of the data can be different. The logical standby database is kept synchronized with the primary database though SQL Apply, which transforms the data in the redo received from the primary database into SQL statements and then executing the SQL statements on the standby database.

  A key benefit of a logical standby database is that you can create significant auxiliary structures to optimize the reporting workload, including structures that could have a prohibitive effect on the primary database's transactional response time. A logical standby database can have its data physically reorganized into a different storage type with different partitioning, having many different indexes, having on-demand refresh materialized views created and maintained, and it can be used to drive the creation of data cubes and other OLAP data views.

  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.

Oracle Data Guard provides the following benefits:

• Maintenance of real-time, transactionally consistent database copies to provide protection against unplanned downtime and disaster.

• Data protection and fast repair against computer failures, human errors, data corruption, lost writes, and site failures.

• Automatic failover with flexible data protection levels to support all network configurations and business requirements.

• Faster redo application, redo transport, and role transitions with various enhancements.

• Reduction of planned downtime for system changes, some platform migrations, hardware and system upgrades, and Oracle patch set and database upgrades (see also Table 2-1, "Outage Types and Oracle High Availability Solutions for Unplanned Downtime").

• Multiple levels of data protection and performance to balance data availability against system performance requirements.

• Support for the real-time query capability of physical standby databases provides better primary database performance and better use of standby resources, because real-time query:

  • Diverts read-only queries and transactions from the primary database to standby databases.

  • Diverts backup operations from the primary database to standby databases.

• Support for both physical standby databases (real-time query) and logical standby databases to provide more efficient use of system resources by diverting more querying and reporting functions from the primary database to standby databases (with the logical standby databases providing greater flexibility for any activity that requires access to a standby database that is open read/write).

• Support for snapshot standby database for reporting or testing (cloning) purposes and automatic resynchronization with the primary database once reporting or testing has completed.

• Managed and automatic role transition and application notification to minimize planned and unplanned downtime.

• Automatic or automated resynchronization of a failed primary database following a failover.

• Management of all systems as a single configuration for simplified administration.

• Increased flexibility for Data Guard configurations where the primary and standby systems may have different CPU architectures, operating systems (for example, Windows and Linux), operating system binaries (32-bit and 64-bit), and Oracle database binaries (32-bit and 64-bit); this is subject to restrictions that are defined in MetaLink note 413484.1.

  See Also:

  Metalink note 413484.1 at https://metalink.oracle.com/ for the latest capabilities and restrictions

2.1.4 Oracle Streams

Oracle Streams is a very flexible and powerful database feature to implement fine-grained replication, multimaster replication, many-to-one replication, data transformation, hub and spoke replication, and message queuing.

Comparing Streams and Data Guard

Streams is designed from the ground up for information sharing. It enables highly customized replication strategies to satisfy the many varied uses of data replicated to a target database. These same capabilities can also make Streams a useful technology for addressing HA/DR requirements and for minimizing planned downtime during upgrades to new database releases and patch sets.Data Guard is designed for simple, one-way replication of an entire database expressly for maintaining a synchronized copy that can assume the primary role in the event of a failure. Data Guard Redo Apply (physical standby) best exemplifies this notion of simplicity, as a disaster recovery solution that is both datatype and application agnostic, and able to scale to very high levels of performance. While Data Guard also provides capabilities that enable a standby database to offload the primary database of the overhead of performing backups, queries, and reports, these capabilities are ancillary to Data Guard's primary mission, and are provided to increase the ROI of customer HA/DR investments. You can use Data Guard SQL Apply (logical standby) to get additional value from a Data Guard configuration by minimizing planned downtime during upgrades to new database releases and patch sets.

Streams Messaging and Information Flow

Oracle Streams enables information sharing. Using Streams, each unit of shared information is called a message, and you can share these messages in a stream. The stream can propagate information within a database or from one database to another.

For example, Figure 2-1 shows a multimaster configuration where all sites are directly connected to all other sites participating in the replication environment. This enables data to be replicated between all locations in a near realtime manner.

Figure 2-1 Oracle Streams Multimaster Configuration

Description of "Figure 2-1 Oracle Streams Multimaster Configuration"

Another example is the Oracle Streams 1-N, or hub-and-spoke configuration in which changes made at the primary or hub location can be propagated to the remote or spoke locations in a near real-time manner.

Although it is possible to configure a hub-and-spoke configuration for bidirectional replication, you may prefer to restrict updates to a single location, the hub, as shown in Figure 2-2. In query intensive environments, you can still balance the load between multiple locations, with fast local access, while updates are restricted to the hub. By offloading reporting to the spoke locations, you improve performance at the hub, or primary OLTP location. This type of configuration is easier to implement than multimaster replication because it is not necessary to establish connectivity between all locations in the replication environment and it is not necessary to implement a conflict resolution strategy.

Figure 2-2 Information Dissemination with Oracle Streams (1-N configuration)

Description of "Figure 2-2 Information Dissemination with Oracle Streams (1-N configuration)"

The stream routes specific information to specific destinations. The result is a feature that provides greater functionality and flexibility than traditional solutions for capturing and managing messages, and sharing the messages with other databases and applications. Streams provides the capabilities needed to build and operate distributed enterprises and applications, data warehouses, and high availability solutions. You can use all of the capabilities of Oracle Streams at the same time. If your business requirements change, then you can implement a new capability of Streams without sacrificing existing capabilities.

As with any Oracle Streams configuration, there are three phases: capture, stage (propagate), and consume (apply). Using Oracle Streams, you control what information is put into a stream, how the stream flows or is routed from database to database, what happens to messages in the stream as they flow into each database, and how the stream terminates. By configuring specific capabilities of Streams, you can address specific requirements. Based on your specifications, Streams can capture, stage, and manage messages in the database automatically, including, but not limited to, data manipulation language (DML) changes and data definition language (DDL) changes. You can also put user-defined messages into a stream, and Streams can propagate the information to other databases or applications automatically. When messages reach a destination, Streams can consume them based on your specifications.

The following figure shows the Oracle Streams information flow.

Figure 2-3 Oracle Streams Information Flow

Description of "Figure 2-3 Oracle Streams Information Flow"

With Streams, you can create a local or remote copy of a production database. In the event of human error or a catastrophe, the copy can be used to resume processing. You can use Streams to configure flexible high availability environments.You can use the features of Oracle Streams to achieve little or no database down time during database upgrade and maintenance operations. Maintenance operations include migrating a database to a different platform, migrating a database to a different character set, modifying database schema objects to support upgrades to user-created applications, and applying an Oracle software patch.

Figure 2-4 shows an application that explicitly enqueues and dequeues messages through Oracle Streams Advanced Queuing as a method of sharing information with business partners or customers with different messaging systems. Once enqueued, messages can be transformed and propagated as desired, before being dequeued to a business partner's application that is a non-database oriented messaging systems.

Figure 2-4 Oracle Streams Message Queuing

Description of "Figure 2-4 Oracle Streams Message Queuing"

Benefits of Using Oracle Streams

Oracle Streams provides the following benefits:

• Data protection by maintaining a full or partial remote copy of the database

• Achieves little or no downtime during database upgrade or maintenance operations such as migrating a database to a different platform or character set, modifying database objects to support upgrades to applications, and applying an Oracle software patch

• Data replication by capturing DML and DDL changes made to database objects and replicating these changes to one or more other databases; bidirectional replication environment, in which exactly two databases share the replicated database objects and data, is possible.

• Event management and notification by enqueuing messages or capturing events, propagating the messages and events through queues, and dequeuing and applying or acting upon the message or event (as shown in Figure 2-4)

• Supports heterogeneous platforms across databases within the configuration

• Allows character sets to differ between replicas

• Permits fine-grained control of data sharing

2.1.5 Transportable Technologies

Transportable technologies provides transportable database and transportable tablespace:

• Transportable database is used to transport an entire database (user data and the Oracle dictionary) to a new platform with the same endian format. Transportable database permits a minimal downtime migration to a new platform by avoiding the time-consuming method of unloading all user data from the source database and loading it into the target database.

• Transportable tablespaces is a feature designed to move a subset of one database into another, even among platforms that differ in endian format. The cross-platform capability of transportable tablespaces can be used to migrate all user data within a database to a new platform with a different endian format. Leveraging transportable tablespaces in this manner permits a minimal downtime migration to a new platform by avoiding the time-consuming method of unloading all user data from the source database and loading it into the target database.

2.1.6 Oracle Flashback Technology

Flashback technology provides a set of features to switch between views of the data as it existed at different points in time. Using flashback features you can query past versions of schema objects and historical data. You can also perform change analysis and self-service repair to recover from logical corruption while the database is online.

Flashback technology provides a SQL interface to quickly analyze and repair human errors. Flashback provides fine-grained analysis and repair for localized damage such as deleting the wrong customer order. Flashback technology also enables correction of more widespread damage, yet does it quickly to avoid long downtime. Flashback technology is unique to Oracle Database and supports recovery at all levels including row, transaction, table, tablespace, and database.

Most of the flashback features use undo data while other features, such as Flashback Database and Block Media Recovery, use flashback logs:

• Undo tablespace—A dedicated tablespace that stores only undo information when the database is run in automatic undo management mode.

• Flashback data archive—An archive that is stored in a tablespace and contains transactional changes to every record in a table for the duration of the record's lifetime. The archived data can be retained for much longer duration than the retention period offered by an undo tablespace.

• Flashback logs—Oracle-generated logs used to perform flashback operations. The database can only write flashback logs to the flash recovery area. Flashback logs are written sequentially and are not archived. They cannot be backed up to disk.

The following list describes the Flashback features:

• Oracle Flashback Query

  Oracle Flashback Query provides the ability to view the data as it existed in the past by using the Automatic Undo Management system to obtain metadata and historical data for transactions. Undo data is persistent and survives a database malfunction or shutdown. The unique features of Flashback Query not only provide the ability to query previous versions of tables, they also provide a powerful mechanism to recover from erroneous operations.

  Uses of Flashback Query include:

  • Recovering lost data or undoing incorrect, committed changes. For example, rows that have been deleted or updated can be immediately repaired even after they have been committed.

  • Comparing current data with the corresponding data at some time in the past. For example, using a daily report that shows the changes in data from yesterday, it is possible to compare individual rows of table data, or find intersections or unions of sets of rows.

  • Checking the state of transactional data at a particular time, such as verifying the account balance on a certain day.

  • Simplifying application design by removing the need to store certain types of temporal data. Using a Flashback Query, it is possible to retrieve past data directly from the database.

  • Applying packaged applications, such as report generation tools, to past data.

  • Providing self-service error correction for an application, enabling users to undo and correct their errors.

  See Also:

  Oracle Database Advanced Application Developer's Guide

• Oracle Flashback Versions Query

  Oracle Flashback Versions Query is an extension to SQL that you can use to retrieve the versions of rows in a given table that existed in a specific time interval. Oracle Flashback Versions Query returns a row for each version of the row that existed in the specified time interval. For any given table, a new row version is created each time the COMMIT statement is executed.

  Flashback Versions Query is a powerful tool for the DBA to run analysis to determine the sources of problems. Additionally, application developers can use Flashback Versions Query to build customized applications for auditing purposes.

  See Also:

  Oracle Database Advanced Application Developer's Guide

• Oracle Flashback Transaction

  Oracle Flashback Transaction is a new feature in Oracle Database 11g Release 1 that can easily back out a transaction and its dependent transactions. The DBMS_FLASHBACK.TRANSACTION_BACKOUT() procedure rolls back a transaction and its dependent transactions while the database remains online. This recovery operation uses undo data to create and execute the compensating transactions that return the affected data to its original state. You can query the DBA_FLASHBACK_TRANSACTION_STATE view to see the current state of a transaction with respect to whether the transaction has been backed out using dependency rules or forced out by either:

  • Backing out nonconflicting rows

  • Applying undo SQL

  Oracle Flashback Transaction increases availability during logical recovery by easily and quickly backing out a specific transaction or set of transactions and their dependent transactions, with one command while the database remains online.

  See Also:

  Oracle Database Advanced Application Developer's Guide

• Oracle Flashback Transaction Query

  Oracle Flashback Transaction Query provides a mechanism to view all changes made to the database at the transaction level. When used in conjunction with Flashback Versions Query, it offers a fast and efficient means to recover from a human or application error. Flashback Transaction Query increases the ability to perform online diagnosis of problems in the database by returning the database user that changed the row, and performs analysis and audits on transactions.

  See Also:

  Oracle Database Advanced Application Developer's Guide

• Oracle Flashback Table

  Oracle Flashback Table enables you to recover a table to a previous point in time. It provides a fast, online solution for recovering a table or set of tables that has been modified by a human or application error. In most cases, Flashback Table alleviates the need for administrators to perform more complicated point-in-time recovery operations. Even after a flashback, the data in the original table is not lost; it can later be reverted back to the original state.

  See Also:

  Oracle Database Backup and Recovery User's Guide

• Oracle Flashback Drop

  Dropping objects by accident is a problem for database users and DBAs alike. While there is no easy way to recover dropped tables, indexes, constraints, or triggers, Oracle Flashback Drop provides a safety net when dropping objects. When you drop a table, Oracle automatically places it into the Recycle Bin. The Recycle Bin is a virtual container where all dropped objects reside. You can continue to query data in a dropped table.

  See Also:

  Oracle Database Backup and Recovery User's Guide

• Oracle Flashback Restore Points

  When an Oracle Flashback recovery operation is performed on the database, the DBA must determine the point in time—identified by the System Change Number (SCN) or timestamp—to which the data can later be flashed back. Oracle Flashback restore points are labels you can define that can be substituted for the SCN or transaction time used in Flashback Database, Flashback Table, and Recovery Manager (RMAN) operations. Furthermore, a database can be flashed back through a previous database recovery and open resetlogs by using guaranteed restore points. Guaranteed restore points allow major database changes—such as database batch jobs, upgrade, or patch—to be quickly undone by ensuring that the undo required to rewind the database is retained.

  Using the Oracle Flashback restore points feature provides the following benefits:

  • Provides the ability to quickly restore to a consistent state, to a point in time that was prior to a planned operation that has gone awry (for example, a failed batch job, an Oracle software upgrade, or an application upgrade.

  • Allows the snapshot standby to be resynchronized with the production database.

  • Allows for a quick mechanism to restore a test or cloned database back to its original state.

  See Also:

  Oracle Database Backup and Recovery User's Guide

• Oracle Flashback Database

  Oracle Flashback Database provides a more efficient alternative to database point-in-time recovery. With Oracle Flashback Database, current datafiles can be reverted to their contents at a past time. The result is much like restoring data from data file backups and executing point-in-time database recovery. However, Flashback Database skips the data file restoration and most of the application of redo data.

  Enabling Oracle Flashback Database provides the following benefits:

  • Eliminates the time to restore a backup when fixing human error that has a database-wide impact.

  • Because human errors can be quickly undone, it allows standby databases to use real-time apply to synchronize with the primary database.

  • Allows quick standby database reinstantiation after a database failover.

  See Also:

  • Oracle Database Backup and Recovery User's Guide

  • Oracle Database SQL Language Reference

• Block Recovery Using Flashback Logs

  Starting with Oracle Database release 11.1, block recovery can optionally retrieve a more recent copy of a data block from the flashback logs to reduce recovery time. Furthermore, a corrupted block encountered during instance recovery does not result in instance recovery failing. The block is automatically marked as corrupt and added to the RMAN corruption list in the V$DATABASE_BLOCK_CORRUPTION table. You can subsequently issue the RMAN RECOVER BLOCK command to fix the associated block.

  See Also:

  Oracle Database Backup and Recovery User's Guide

• Flashback Data Archive

  An archive that is stored in a tablespace and contains transactional changes to every record in a table for the duration of the record's lifetime. The archived data can be retained for much longer duration than the retention period offered by an undo tablespace.

2.1.7 Automatic Storage Management

Automatic Storage Management (ASM) provides a vertically integrated file system and volume manager directly in the Oracle kernel, resulting in:

• Significantly less work to provision database storage

• Higher level of availability

• Elimination of the expense, installation, and maintenance of specialized storage products

• Unique capabilities for database applications

For optimal performance, ASM spreads files across all available storage. To protect against data loss, ASM extends the concept of SAME (stripe and mirror everything) and adds more flexibility in that it can mirror at the database file level rather than the entire disk level.

More importantly, ASM simplifies the processes of setting up mirroring, adding disks, and removing disks. Instead of managing hundreds and possibly thousands of files (as in a large data warehouse), DBAs using ASM create and administer a larger-grained object called a disk group. The disk group identifies the set of disks that are managed as a logical unit. Automation of file naming and placement of the underlying database files save DBAs time and ensures adherence to standard best practices.

The ASM native mirroring mechanism (2-way or 3-way) is an option that protects against storage failures. With ASM mirroring, an additional level of data protection can be provided with the use of failure groups. A failure group is a set of disks sharing a common resource (disk controller or an entire disk array) whose failure can be tolerated. Once defined, an ASM failure group intelligently places redundant copies of the data in separate failure groups. This ensures that the data is available and transparently protected against the failure of any component in the storage subsystem.

ASM provides the following benefits:

• Provides the ability to mirror and stripe across drives and storage arrays

• Automatically re-mirrors from a failed drive to remaining drives

• Automatically rebalances stored data when disks are added or removed while the database remains online

• Allows for operational simplicity in managing database storage

• Manages OCR and voting disks

• Provides local read capability, which gives better performance in an extended cluster

• Supports very large databases

• Supports ASM rolling upgrades

• Supports finer granularity in tuning and security

• ASM Fast Mirror Resync, which provides fast repair after a temporary disk failure

2.1.8 Recovery Manager

Recovery Manager (RMAN) is an Oracle utility to manage the backup and, more importantly, the recovery of the database. It eliminates operational complexity while providing superior performance and availability of the database.

Recovery Manager determines the most efficient method of executing the requested backup, restoration, or recovery operation and then submits these operations to the Oracle Database server for processing. Recovery Manager and the server automatically identify modifications to the structure of the database and dynamically adjust the required operation to adapt to the changes.

RMAN provides the following benefits:

• Automated channel failover on backup and restore operations

• Automatic failover to a previous backup when the restore operation discovers a missing or corrupt backup

• Automated creation of new database and temporary files during recovery

• Automated recovery through a previous point-in-time recovery—recovery through resetlogs

• Block media recovery enables the datafile to remain online while fixing the block corruption

• Fast incremental backups using block change tracking

• Fast backup and restore operations with intrafile and interfile parallelism

• Enhanced security with Virtual Private Catalog

• Lower space consumption when creating a database over the network by eliminating staging areas

• Merge incremental backups into image copies in the background providing up-to-date recoverability

• Optimized backup and restore of required files only

• Retention policy ensures that relevant backups are retained

• Ability to resume backup and restore of previously failed operations

• Automatic backup of the control file and the server parameter file ensuring that backup metadata is available in times of database structural changes as well as media failure and disasters

• Online backup does not require the database to be placed into hot backup mode

  See Also:

  Oracle Database Backup and Recovery User's Guide

2.1.9 Oracle Secure Backup

Oracle Secure Backup (OSB) is a centralized tape backup management solution providing performant, heterogeneous data protection in distributed UNIX, Linux, Windows, and Network Attached Storage (NAS) environments. By protecting file system and Oracle database data, OSB provides a complete tape backup solution for your IT environment.

OSB is tightly integrated with Recovery Manager (RMAN) to provide the media management layer for RMAN, supporting releases since Oracle9i. With optimized integration points, OSB and RMAN provide the fastest most efficient tape backup for the Oracle database.

You can backup distributed servers to local and remote tape devices from a central OSB administrative server using backup policies, calendar based scheduling for lights out operations, or on-demand backup for immediate requirements. With its highly scalable client/server architecture, OSB provides local and remote data protection, leveraging SSL for secure intradomain communication and two-way server authentication.

The following list describes the key benefits of OSB:

• Optimized tape backup for the Oracle database by backing up only the currently used blocks and increasing backup performance by 10% to 25%.

• Policy based management allows backup administrators to exercise precise control over the backup domain.

• Dynamic drive sharing for increased tape resource use.

• Heterogeneous storage area network (SAN) support allowing NAS, UNIX, Windows, and Linux to share tape drives and media.

• File system backup at the file, directory, file system or raw partition level with full, incremental and offsite backup scheduling.

• Integrated with Oracle Enterprise Manager, providing an intuitive, familiar interface.

• Backup encryption to tape.

• Broad tape-device support for new and legacy tape devices in SAN and SCSI environments.

• Network Data Management Protocol (NDMP) support for highly efficient backup of NAS filers.

• Scalable, low-cost licensing model reduces IT costs and operational considerations.

2.1.10 Data Recovery Advisor

Data Recovery Advisor, a new feature in Oracle Database 11g release 1 (11.1), automatically diagnoses persistent (on disk) data failures, presents appropriate repair options, and runs repair operations at your request.

Data Recovery Advisor includes the following functionality:

• Failure Diagnosis

  The first symptoms of database failure are usually error messages, alarms, trace files and dumps, and failed health checks. Assessing these symptoms can be complicated, error-prone and time-consuming. Data Recovery Advisor automatically diagnoses data failures and informs you about them.

• Failure Impact Assessment

  After a failure is diagnosed, you must understand its extent and assess its impact on applications before devising a repair strategy. Data Recovery Advisor automatically assesses the impact of a failure and displays it in a easily understood format.

• Repair Generation

  You typically have several repair options available, offering trade-offs in recovery time and potential data loss. If there are multiple failures present, you must also determine the best sequence of repair steps. In some situations it can be advantageous to consolidate repairs. Data Recovery Advisor does all this for you, automatically determining the best repair options.

• Repair Feasibility Checks

  Before presenting repair options, Data Recovery Advisor validates them with respect to the specific environment and availability of media components required to complete the proposed repair. The feasibility check is fast and validates if the required backups are available. The actual contents of these backups will be validated during repair.

• Repair Automation

  If you accept the suggested repair option, Data Recovery Advisor automatically performs the repairs, verifies that the repair was successful, and closes the appropriate failures.

• Validation of Data Consistency and Database Recoverability

  Data Recovery Advisor can validate the consistency of your data, as well as backups and redo stream, whenever you choose.

• Early Detection of Corruption

  Through Health Monitor, you can schedule periodic runs of Data Recovery Advisor diagnostic checks to detect, analyze, and repair data failures before a database process executing a transaction discovers the corruption and signals an error. Early warnings can limit the damage caused by corruption.

• Integration of Data Validation and Repair

  Data Recovery Advisor is a single tool for data validation and repair.

2.1.11 Flash Recovery Area

The flash recovery area is a unified storage location for all recovery-related files and activities in Oracle Database. After this feature is enabled, all RMAN backups, archive logs, control file autobackups, and datafile copies are automatically written to a specified file system or automatic storage management disk group, and the management of this disk space is handled by RMAN and the database server.

Making a backup to disk is faster because using the flash recovery area eliminates the bottleneck of writing to tape. More importantly, if database media recovery is required, then datafile backups are readily available. Restoration and recovery time is reduced because you do not need to find a tape and a free tape device to restore the needed datafiles and archive logs.

The flash recovery area provides:

• Unified storage location of related recovery files

• Management of the disk space allocated for recovery files, which simplifies database administration tasks

• Fast, reliable disk-based backup and restoration

• Ability to backup and restore the entire flash recovery area

• Ability to tolerate failures to the flash recovery area

2.1.12 Oracle Security Features

The best protection against human errors is to prevent their occurrence. The best way to prevent human errors is to restrict user access to only those data and services truly needed to perform business functions. Oracle provides a wide range of security tools to control access to application data by authenticating database users and then enabling administrators to grant them only those privileges required to perform their duties.

In addition, the Oracle Database security model provides the ability to restrict data access at a row level using Virtual Private Database, thereby further isolating database users from data that they do not need to access.

Oracle security features include:

• Authentication control to validate the identities of entities using networks, databases, and applications. Network sessions between databases, such as redo transport sessions, are also authenticated.

• Authorization control to provide limits to access and actions linked by database user identities and roles.

• Access control to objects, providing protection regardless of the entity seeking to access or alter them.

• Auditing control to monitor and gather data about specific database activities, investigate suspicious activity, deter users (or others) from inappropriate activities, and detect problems with authorization or access control implementation.

• Security policy management using profiles.

• Encryption of data residing within the database and backups, or transferred to and from databases.

2.1.13 LogMiner

Oracle log files contain useful information about the activities and history of the Oracle database. Log files contain all data necessary to perform database recovery, and also record all changes made to the data and metadata within the database.

LogMiner is a fully relational tool that allows redo log files to be read, analyzed, and interpreted using SQL. Analysis of the log files with LogMiner can be used to:

• Track or audit changes to data

• Provide supplemental information for tuning and capacity planning

• Retrieve critical information for debugging complex applications

• Recover deleted data

• Provide additional browser-based simplification to help troubleshoot and resolve logical failures

LogMiner features include:

• Pinpoint when a logical corruption to the database—such as errors made at the application level—may have occurred

• Determine the necessary actions to perform fine-grained recovery at the transaction level

• Performance tuning and capacity planning through trend analysis

• Perform post auditing

2.1.14 Hardware Assisted Resilient Data (HARD) Initiative

The Hardware Assisted Resilient Data (HARD) Initiative is a joint initiative between Oracle and hardware vendors to prevent data corruptions from being written out to disk. Data corruption is very rare, but when it happens, it can have a catastrophic effect on a database, and therefore a business.

Under the HARD Initiative, Oracle works with selected system and storage vendors to build operating system and storage components that can detect corruption early and prevent corrupted data from being written to disk. The key approach is block checking where the storage subsystem validates the Oracle block contents.

Any datafiles and log files located on HARD-compliant storage is protected. You must also enable the HARD validation feature on the storage, using the vendor-provided interface. When Oracle writes data to the storage, the storage system validates the data. If the data appears to be corrupted, then the write is either rejected with an error, or it is accepted with an error logged by the storage in the internal logs.

Figure 2-5 Oracle Data Validation

Description of "Figure 2-5 Oracle Data Validation"

Storage vendors may choose to implement some or all of the checks in their implementation. Also, each vendor's implementation is unique and their control interfaces may have different features.

2.1.15 Hang Manager

The Hang Manager, a new feature in Oracle Database 11g Release 1, simplifies database management by enabling you to more quickly resolve database hangs. It automatically detects, analyzes, and dumps diagnostic information for hangs in Oracle Database environments, including Oracle RAC and ASM databases.

The Hang Manager is enabled by default in Oracle RAC databases and ASM instances. Thus, you can use Hang Manager to follow a hang from the database instance to the underlying ASM instance.

Active entities that attempt to obtain restrictive access to shared resources or request services from other Oracle Database processes, sessions, and transactions are in danger of hanging. A hang chain is a chain of processes with each one waiting on a resource held by the next, with a single process serving as the root of the hang.

Hangs in Oracle Database can cost a great deal in terms of system unavailability. Specifically, hangs lead to the following problems:

• Extended system outages. These outages may occur frequently before a fix is found, which adds to the total downtime.

• Difficult analysis: Analyzing the hang to determine where the problem lies can be lengthy, complex, and prone to error.

2.1.16 Data Block Corruption Prevention and Detection Parameters

Prior to Oracle Database 11g, RMAN-detected block corruptions were recorded in V$DATABASE_BLOCK_CORRUPTION. In Oracle Database 11g, several database components and utilities, including RMAN, can now detect a corrupt block and record it in that view. Oracle Database automatically updates this view when block corruptions are detected or repaired (for example, using block media recovery or data file recovery). The benefit is that the time it takes to discover block corruptions is shortened.

In addition, you can use the DB_ULTRA_SAFE initialization parameter to automatically configure the appropriate data protection block checking level in the database. The performance impact may vary depending on the application and available system resources, but the effect can vary from 1% to 10%.

The DB_ULTRA_SAFE initialization parameter:

• Controls the setting of other related initialization parameters, including DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM, and DB_LOST_WRITE_PROTECT

• Controls other data protection behavior in the Oracle Database, such as requiring ASM to perform sequential mirror writes

By making it possible to detect data corruptions in a timely manner, these features provide critical high availability benefits for the Oracle database.

2.1.17 Oracle HA Solutions and Recovery Times for Unplanned Downtime

Oracle provides high availability solutions to prevent, tolerate and reduce downtime for all types of unplanned failures.

Table 2-1 describes the various Oracle high availability solutions for unplanned downtime along with the recovery time that can be attained with each solution. The table shows how the features discussed in Section 2.1.1 through Section 2.1.16 can be used to address various causes of unplanned downtime. Also, see Table 4-4 for a summary of the attainable recovery times for all types of unplanned downtime for each Oracle high-availability architecture.

2.2.1 Dynamic Resource Provisioning

This section describes dynamic resource provisioning under the following topics:

• Dynamic Reconfiguration of the Database

• Autotuning Memory Management

• Automated Distribution of Datafiles, Control Files, and Log Files

2.2.2 Oracle High Availability Solutions and Recovery Times for Planned Downtime

Oracle provides high availability solutions to prevent, tolerate and reduce downtime for all types of unplanned failures.

Table 2-2 describes the various Oracle high availability solutions for planned downtime along with the outage time that can be attained with each solution and their known considerations. In all cases, Oracle recommends you perform extensive testing prior to performing any rolling upgrade. Also, see Table 4-5 for a summary of the attainable recovery times for all types of planned downtime for each Oracle high-availability architecture.

^Footnote 1 Patches that cannot be applied by performing a rolling upgrade can be applied with the MINIMIZE_DOWNTIME option of the OPatch utility to reduce the availability impact of the patch application.

^Footnote 2 An example is migration from traditional storage to low-cost storage

2.2.3 Online Reorganization and Redefinition

One way to enhance availability and manageability is to allow customary user access to the database during a data reorganization operation. The Online Reorganization and Redefinition feature in Oracle Database offers administrators significant flexibility to modify the physical attributes of a table and transform both data and table structure while allowing customary user access to the database. This capability improves data availability, query performance, response time, and disk space utilization. All of these are important in a mission-critical environment and make the application upgrade process easier, safer, and faster.

This online architecture provides the following benefits:

• Tables can be reorganized and redefined online

  • Any physical attribute of the table can be changed online. The table can be moved to a new location, partitioned, and converted from one organization (such as 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.

• All index operation can be performed online

  • Indexes can be created online and analyzed simultaneously. Online repair of the physical guess component of logical rowids (used in secondary indexes and in the mapping table for index-organized tables) can also be used.

  • An index-organized table and secondary indexes can be reorganized online to eliminate the reorganization maintenance window. Secondary indexes support efficient use of block hints (physical guesses). Invalid physical guesses of logical rowids stored in secondary indexes on index-organized table can also be repaired online.

  • An index-organized table or table partition can be reorganized without rebuilding its secondary indexes, resulting in a short reorganization maintenance window.

• Online move of a partitioned table

• Online reorganization support for advanced queues, clustered tables, materialized views, and abstract data types (objects)

• Fast ADD COLUMN with default value (does not need to update all rows to default value)

• Invisible Indexes speed application migration and testing:

  • Speeds up migration with explicit hints, then drops when finished

  • Prevents premature use of newly created indexes

  • Tests effects of DROP INDEX, making the index visible if needed, thus there is no need for an index rebuild

• Online index build with no pause to DML (no exclusive DML locks are required)

• No recompilation of dependent objects when online redefinition does not logically affect objects (for example, when columns are added to tables, or when procedures are added to packages)

• Easier to execute table DDL operations online (there is an option to wait for active DML operations instead of aborting)

• Support for redefinition of tables that have materialized views or materialized view logs

Depending on the type of online reorganization that is required, you can perform the following types of data reorganization using the DBMS_REDEFINITION package or the SQL CREATE/ALTER TABLE and INDEX commands:

• Modify table storage parameters

• Move table to a different tablespace

• Add support for parallel queries

• Add or drop partitioning support

• Re-create table to avoid fragmentation

• Change from table to IOT or from IOT to table

• Add or drop a column

• Transform a column using a function

• Create indexes online

• Rebuild indexes online

• Coalesce indexes online

• Move index-organized tables online

• Copy dependent objects (such as triggers, constraints, and indexes)

• Convert LONG and LONG RAW columns to a LOB

• Use a unique key as an alternative to a primary key or rowid

• Specify columns to order data by

• Change a table without recompiling stored procedures

• Online segment shrink

• Reorganize a single partition

• Reorganize advanced queue and clustered tables

• Reorganize a table containing an ADT

• Retain and clone statistics

• Copies check and not null constraints

• Copies dependent objects for nested tables

2.2.4 Online Application Maintenance and Upgrades

The following sections describe features that can significantly reduce (or eliminate) the application downtime required to make changes to an application's database objects.

2.3.1 Grid Computing

Grid computing is a computing architecture that effectively pools large numbers of servers and storage into a flexible, on-demand computing resource for all enterprise computing needs.

Oracle Database captures the cost advantages of Grid enterprise computing without sacrificing performance, scalability, security, manageability, functionality, or system availability. A Database Server Grid is a collection of commodity servers connected together to run on one or more databases. A Database Storage Grid is a collection of low-cost modular storage arrays combined together and accessed by the computers in the Database Server Grid.

With the Database Server and Storage Grid, you can build standby and testing Hubs to leverage a pool of system resources. The system resources can be dynamically allocated and deallocated depending on various priorities. For example, if the production database fails over to one of the standby databases in the standby hub, it will acquire more system and storage resources while the testing resources may be temporarily starved. With Grid technologies, you can enable high level of utilization and low TCO without sacrificing business requirements.

Figure 2-6 illustrates the Database Server Grid and Database Storage Grid in a Grid enterprise computing environment.

Figure 2-6 Grid Computing Environment

Description of "Figure 2-6 Grid Computing Environment"

2.3.2 Database Server Grid

The availability of low-cost and reliable blade servers, small multiprocessor servers, and inexpensive open-source operating systems such as Linux, has made it possible to build a Database Server Grid that is highly available, scalable, flexible, and manageable.

Oracle RAC is the technology that enables a Database Server Grid by providing a single database that spans multiple low-cost servers yet appears to the application as a single, unified database system. Oracle RAC provides flexibility to dynamically provision resources and services within the Grid as computing needs change, and to add systems to the Grid as capacity demands increase. In addition, Oracle RAC provides protection from system failures by automatically recovering the processing of a failed node by any of the surviving systems running the database, and facilitating the reconnection of clients and redistribution of load affected by the failed system.

2.3.3 Database Storage Grid

The availability of low-cost ATA disk-based storage arrays and low-cost storage networks has made it possible to use a Database Storage Grid with Oracle Database at very low cost. A DBA can use the Automatic Storage Management (ASM) interface to specify the disks within the Database Storage Grid that ASM should manage across all server and storage platforms. ASM partitions the disk space and evenly distributes the data storage throughout the entire storage array. Additionally, ASM automatically redistributes the data storage as storage arrays are added or removed from the Database Storage Grid.

2.3.4 Disaster Recovery Solutions with Better Standby Database Usage

Beginning in Oracle Database 11g, standby databases can be used for dynamic IT and application requirements in addition to providing disaster recovery. The real-time query feature in Oracle Data Guard enables you to use physical standby databases for other useful work during normal operations, in addition to providing a disaster-recovery solution.

The following sections describe the Oracle Data Guard features that help you to leverage physical standby databases for additional business purposes:

• Real-Time Query Physical Standby Databases

• Web Scale Using Standby Reader Farms

2.3.4.2 Web Scale Using Standby Reader Farms

Beginning with 11gR1, you can use both physical standby databases (using real-time query) and logical standby databases to deploy a reader farm. An example of such a configuration is provided Figure 2-7, complete with the use of Data Guard fast-start failover to automatically fail over should the primary database fail. Note that all standby databases in the reader farm automatically recognize the new primary database after such a fast-start failover occurs.

Because a Data Guard configuration can support multiple standby databases, customers have used this capability to boost read performance of the most demanding web applications beyond what the underlying system and storage architecture can support. This provides a relatively low-cost method of scaling out using a Grid architecture where I/O is the driving factor.

The concept is straightforward—a single primary database that supports read/write transactions, and multiple standby databases that provide read-only access to web users. Such an approach scales read performance linearly as additional standby databases are added. It is also an effective way to isolate faults, because problems that impact one standby database are isolated from the other standby databases in the configuration.

The benefits of creating a reader farm of physical standby databases include the following:

• Fault isolation

• High performance with physical standby databases and Redo Apply

• Seamless support for all DDL and data types using Redo Apply

• All reader databases are kept up-to-date with changes made to the primary database

• Automatic, zero or minimal data loss failover capability

• Management as a unified configuration through Grid Control

• Scale-out using single writer database and n reader databases.

Figure 2-7 shows a good example of how you can leverage Oracle Data Guard, physical standby databases and real-time query to provide the flexibility you need to grow your business quickly, while still providing disaster recovery. In the configuration, the primary database transmits redo data to multiple standby database, one of which is also enabled for fast-start failover for automatic, zero or minimal data loss failover.

Figure 2-7 Standby Database Reader Farms

Description of "Figure 2-7 Standby Database Reader Farms"

If a fast-start failover is triggered in the Data Guard configuration in Figure 2-7:

• Automatic failover occurs to the designated standby database

• All standby databases accept data from new primary database

• You can perform a switchover at a convenient time in the future to return all databases to their original roles

2.4.1 Intelligent Infrastructure

Oracle Database has a sophisticated self-management infrastructure that allows the database to learn about itself and use this information to adapt to workload variations or to automatically remedy any potential problem. The self-management infrastructure includes the following:

• Automatic Workload Repository

  The Automatic Workload Repository (AWR) is a built-in repository that contains performance statistics used by Oracle Database for problem detection and self-tuning purposes. At regular intervals, Oracle Database makes a snapshot of vital statistics and workload information and stores them in the AWR. The data contained in the snapshots is then analyzed by the Automatic Database Diagnostic Monitor (ADDM). See the Oracle Database Performance Tuning Guide for information about the AWR.

• Automatic Maintenance Tasks

  By analyzing the information stored in the AWR, the database can identify the need to perform routine maintenance tasks. The automated maintenance tasks infrastructure (known as ÒAutoTaskÓ) enables Oracle Database to automatically schedule such operations. AutoTask schedules automatic maintenance tasks to run in a set of Oracle Scheduler windows known as maintenance windows. Maintenance windows are those windows that are members of the Oracle Scheduler window group MAINTENANCE_WINDOW_GROUP. See the Oracle Database Administrator's Guide and the Oracle Database 2 Day DBA for more information.

• Fault diagnosability infrastructure

  Oracle Database includes an advanced fault diagnosability infrastructure for preventing, detecting, diagnosing, and resolving problems. The problems that are targeted are critical errors such as those caused by database code bugs, metadata corruption, and customer data corruption. This includes:

  • The automatic diagnostic repository (ADR), which is a file-based repository for database diagnostic data such as traces, the alert log, health monitor reports, and more. It has a unified directory structure across multiple instances and multiple products.

  • The incident packaging services that a DBA can use to automatically and easily gather all diagnostic data (traces, health check reports, SQL test cases, and more) pertaining to a critical error and package the data into a zip file suitable for transmission to Oracle Support.

  See the Oracle Database Administrator's Guide for more information about these components.

• Server generated alerts

  For problems that cannot be resolved automatically and require administrators to be notified (such as running out of space) the Oracle Database provides server-generated alerts. Oracle Database can monitor itself and send out alerts to notify you of any problem and provide recommendations on how the reported problem can be resolved. This ensures quick problem resolution and helps prevent potential failures.

• Advisor framework

  Oracle Database includes a number of advisors for different subsystems in the database to automatically determine how the operation of the corresponding subcomponents could be further optimized. The SQL Tuning Advisor and the SQL Access Advisor, for example, provide recommendations for running SQL statements faster. Memory advisors help size the various memory components without resorting to trial-and-error techniques. The Segment Advisor handles space-related issues, such as recommending wasted-space reclamation and analyzing growth trends, while the Undo Advisor guides you in sizing the undo tablespace correctly. See the Oracle Database 2 Day DBA for more information about using advisors.

• Hang Manager

  The Hang Manager is an Oracle Database infrastructure that can detect hangs, analyze them, and then obtain the required diagnostic data from Oracle. The Hang Manager is enabled by default in single-instance databases, Oracle RAC databases, and Automatic Storage Management (ASM) instances. Thus, you can use Hang Manager to follow a hang from the database instance to the underlying ASM instance.

2.4.2 Change Assurance

Oracle Database 11g Release 1 introduces automatic capture and replay of workloads before and after changes so that you can analyze the impact of a database or a SQL change:

• Database Replay

  The Database Replay feature addresses enables you to perform real-world testing by capturing the actual database workload on the production system and replaying it on the test system. It also provides analysis and reporting to highlight potential problems (for example, errors encountered and divergence in performance) and recommend ways to remedy the problems.

• SQL Performance Analyzer

  SQL performance regression is always a concern during system changes such as database upgrades, initialization parameter changes, and addition or dropping of indexes. The SQL Performance Analyzer feature alleviates this concern by providing an easy way to assess the impact of a change on the performance of SQL statements by comparing and contrasting their response times before and after the change. SQL Replay enables you to capture the SQL workload from the source system, such as the production database, and to replay it on the test system where the change has been applied.

2.4.3 Oracle Enterprise Manager Grid Control

By reducing the amount of human intervention required to execute routine and repetitive tasks, services become more stable, reliable, and available. This is particularly important when administrators need to manage very large numbers of systems as efficiently as possible.

Oracle Enterprise Manager Grid Control is an HTML-based interface that provides the administrator with complete monitoring across the entire Oracle technology stack—business applications, application servers, databases, and the E-Business Suite—as well as non Oracle components. If a component within the fast application notification becomes unavailable or experiences performance problems, an alert is automatically generated to Grid Control to inform the administrator so appropriate action can be taken.

The components of Grid Control include:

• Oracle Management Service (OMS)

  The OMS is now a set of J2EE applications that renders the interface for Grid Control, works with all Management Agents to process monitoring information, and uses the Management Repository as its persistent data store.

• Oracle Management Agents

  These are processes deployed on each monitored host to monitor all targets on the host, communicate that information to OMS, and maintain the host and its targets.

• Oracle Management Repository

  This is a schema in Oracle Database that contains all available information about administrators, targets, and applications managed by Grid Control.

Communication between Grid Control, the OMS, and Oracle Management Agents is done through HTTP. Also, you can enable SSL to allow secure communications between tiers within firewall-protected environments. The Management Agent uploads collected monitoring data to the OMS, which in turn loads the data into the Management Repository. Changes in a target state (such as an availability state change) result in an alert being generated to Grid Control.

Using Grid Control, an administrator can:

• Monitor architecture components and be alerted when a failure occurs

• View overall system status, such as the number of nodes in the database cluster and their current status

• View alerts aggregated across all instances

• Set thresholds for alert generation on a database cluster-wide basis

• Monitor performance metric across all instances

• Perform database cluster-wide operations such as backup and recovery

• Interconnect monitoring of cluster databases