A
Hardware Ass isted Resilient Data (HARD) Initiative

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, O racle continues to work with selected system and storage vendors to build operating system and storage components that can detect cor ruptions 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 st orage. 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.< /p>

Figure A-1 Oracle Data Validation

Text description of the illustration maxav029.gif

Data Corruptions

Data co rruption may occur due to many reasons: a bit-flip on a disk; a software bug in a database, an operating system, a storage area netwo rk (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 recove rying from them. These techniques include block-level recovery, automated backup and restore, tablespace point-in-time recovery, remo te standby databases, and transactional recovery. However, recovering from a corruption can take a long time. Furthermore, corruption s to critical data can cause the entire database to fail. It is better to prevent the data corruption in the first place. HARD provid es the mechanism that prevents business data from becoming corrupted

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

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 type s of corruptions:

• Writes of corrupted blocks

  Data that is corrupted by some intervening operating system or hardware component after the data was writt en by Oracle and before it reaches the disk. These components might include the operating system, file system, the volume manager, de vice driver, the host bus adapter, and the SAN switching fabric. Though Oracle can detect the corruption when reading the data back, Oracle may not read the data until days or months later. By then, a good backup for recovering the data may no longer be available.

• Writes of blocks to incorrect locations

  Oracle issues a write to a specific location on disk. Somehow the operating system or storage system writes the blocks to th e wrong location. This can cause two corruptions: corrupting valid data on the disk and losing the data from the committed transactio n.

• Erroneous writes by programs other than Oracle to Oracle data

  Oracle datafiles might be overwritten by non-Oracle applications. A non-Oracle process or program may accidentally overwrite the contents of an Oracle datafile. This can be either because of a bug in the application software, opera ting system, or human error (for example, accidentally copying a normal operating system file over an Oracle datafile).

• Corrupted third-party backups

  Data corrupti ons can occur when backups are copied to tape. This type of corruption is particularly pernicious because the backups are used to rep air data corruptions. So if the backups are also corrupted, then there is no way to recover any lost data. This is especially true fo r third-party backups (in which the disk storage unit directly copies data to the backup device without going through Oracle.)

Possibl e 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. T he 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:

• Datafile
• Control file
• Redo log
• Archived r edo log
• RMAN backup piece
• Flashback log
• Change tracking file
• ASM metadata
• Oracle Cluster Registry file
• Data Guard Broker configuration file

DBAs and system admin istrators using HARD should be aware that a HARD error will be reported back through to the ORACLE instance as an I/O error. System a dministrators 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. AS M 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 impl ement some or all of the checks in their implementation. Also, each vendor's implementation is unique and their control interfaces ma y have different features. Please check with the HARD Initiative page for the latest vendor and implementation information.

http://otn.oracle.com/deploy/ava ilability/index.html