Skip Headers

Oracle® Database High Availability Architecture and Best Practices
10g Release 1 (10.1)

Part Number B10726-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

A Hardware Assisted Resilient Data (HARD) Initiative

A.1 Preventing Data Corruptions with HARD-Compliant Storage

Oracle has introduced the Hardware Assisted Resilient Data (HARD) Initiative, which is a program designed to prevent data corruptions before they happen. Data corruptions are very rare, but when they happen, they can have a catastrophic effect on a database, and therefore a business.

Under the HARD Initiative, Oracle continues to work with selected system and storage vendors to build operating system and storage components that can detect corruptions early and prevent corrupted data from being written to disk. The kay approach is block checking where the storage subsystem validates the Oracle block contents. Implementation of this feature is transparent to the end user or DBA, regardless of the hardware vendor.

To use HARD validation, all datafiles and log files are placed on HARD-compliant storage. The user 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 it appears to be corrupted, then the write is rejected with an error.

Figure A-1 Oracle Data Validation

Description of maxav029.gif follows
Description of the illustration maxav029.gif

A.2 Data Corruptions

Data corruption may occur due to many reasons: a bit-flip on a disk; a software bug in a database, an operating system, a storage area network (SAN), or a storage system. If not prevented or repaired, data corruptions can bring down a database or cause key business data to be lost.

Oracle provides sophisticated techniques for detecting data corruptions and recoverying from them. These techniques include block-level recovery, automated backup and restore, tablespace point-in-time recovery, remote standby databases, and transactional recovery. However, recovering from a corruption can take a long time. Furthermore, corruptions to critical data can cause the entire database to fail. It is better to prevent the data corruption in the first place. HARD provides the mechanism that prevents business data from becoming corrupted

Oracle's Maximum Availability Architecture (MAA) describes an infrastructure that reduces the impact of outages using Oracle RAC, Oracle Data Guard, and HARD.

A.3 Types of Data Corruption Addressed by HARD

The HARD program defines multiple levels of protection. Oracle storage partners may choose to implement firmware or hardware checks that can prevent the following types of corruptions:

A.4 Possible HARD Checks

In a storage system where the Oracle HARD functionality is implemented, the Oracle server can validate the Oracle block structure, block integrity, and block location with numerous checks. If a block fails validation when it is written, then the storage rejects the write and thereby protects the integrity of the data. The HARD validation checks can also be selectively disabled during system management operations that may temporarily leave data in an inconsistent state.

The following Oracle objects can be validated during I/O writes:

DBAs and system administrators using HARD should be aware that a HARD error will be reported back through to the ORACLE instance as an I/O error. System administrators must carefully check the system log to check for HARD-enabled storage before starting any recovery actions.

Automatic storage management (ASM) rebalancing is currently not supported with HARD implementations. ASM rebalancing moves the complete disk block, which may be larger than the datablock and have spurious characters not covered by HARD checking. This would cause a false HARD validation error.

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. Please check with the HARD Initiative page for the latest vendor and implementation information.

http://otn.oracle.com/deploy/availability/index.html