Best Practices for Corruption Detection, Prevention, and Automatic Repair - in a Data Guard Configuration
(Doc ID 1302539.1)
Last updated on JUNE 13, 2023
Applies to:
Oracle Database - Enterprise Edition - Version 11.1.0.7 to 12.1.0.1 [Release 11.1 to 12.1] Oracle Database - Enterprise Edition - Version 12.1.0.2 to 19.3.0.0.0 [Release 12.1 to 19] Oracle Database Cloud Schema Service - Version N/A and later Oracle Database Exadata Express Cloud Service - Version N/A and later Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later Information in this document applies to any platform.
Purpose
Oracle Active Data Guard is a data protection and availability solution for the Oracle Database. The purpose of this document is to provide Database Administrators best practice recommendations for configuring key parameters, database features, system features and operational practices to enable best corruption detection, prevention, and automatic repair, in a MAA or Data Guard configuration for on-premise or in the cloud. This note also provides:
1. additional background information on each parameter with performance considerations and relevant Oracle documentation references 2. clarity on what’s default in the database, in Exadata or in Oracle cloud and recommended MAA settings.
Scope
This document is intended for Database Administrators wanting to learn how to prevent, detect and automatically repair from various data block corruptions.
A corrupt block is a block that has been changed so that it differs from what Oracle Database expects to find. This note covers two data block corruption types:
In a physical block corruption, which is also called a media corruption, the database does not recognize the block at all: the checksum is invalid or the block contains all zeros. An example of a more sophisticated physical block corruption is when the block header and block footer are inconsistent.
In a logical block corruption, the contents of the block are physically sound and pass the physical block checks; however the block can be logically inconsistent. Examples of logical corruption include incorrect block type, incorrect data or redo block sequence number, corruption of a row piece or index entry or data dictionary corruptions.
Block corruptions caused by stray writes, lost writes or misdirected writes can also cause havoc to your database availability. The data block may be physically or logically correct but in this case the block’s content is older or stale or in the wrong location.
Block corruptions can also be divided into interblock corruption and intrablock corruption:
In intrablock corruption, the corruption occurs in the block itself and can be either a physical or a logical corruption.
In an interblock corruption, the corruption occurs between blocks and can only be a logical corruption.
Details
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!