Shulou(Shulou.com)06/02 Report--

The author believes that it can not be simply said that the damage of the physical hard disk leads to the physical damage of the block, and the Oracle bug leads to the logical damage of the block. In this article, we will discuss in detail the concept of physical corruption and logical corruption of the Oracle database. Here is an article by METALINK:

Physical and Logical Block Corruptions. All you wanted to know about it. [ID 840978.1] modification time 21-MAY-2012 type BULLETIN status PUBLISHED

In this Document

PurposeScopeDetailsPhysical Block CorruptionsFractured BlockBad ChecksumBlock MisplacedLogical Block CorruptionsReferencesApplies to:Oracle Server-Enterprise Edition-Version 9.2.0.1 to 11.2.0.3 [Release 9.2 to 11.2]

Information in this document applies to any platform.

* Checked for relevance on 21 May 2012, May 2012

Purpose

Oracle classifies the Data File Block corruptions as Physical and Logical. This is also referred as intra block corruptions. This document is intended to provide detailed information and errors example about it.

Scope

This document is intended for Database Administrators.

DetailsPhysical Block Corruptions

This kind of block corruptions are normally reported by Oracle with error ORA-1578 and the detailed corruption description is printed in the alert log.

Corruption Examples are:

Bad header-the beginning of the block (cache header) is corrupt with invalid valuesThe block is Fractured/Incomplete-header and footer of the block do not matchThe block checksum is invalidThe block is misplacedZeroed out blocks / ORA-8103

Detailed Corruption Description:

Fractured Block

A Fractured block means that the block is incomplete. Information from the block header does not match the block tail.

Corrupt block relative dba: 0x0380e573 (file 14, block 58739)

Fractured block found during buffer read

Data in bad block-

Type: 6 format: 2 rdba: 0x0380e573

Last change scn: 0x0288.8e5a2f78 seq: 0x1 flg: 0x04

Consistency value in tail: 0x00780601

Check value in block header: 0x8739, computed block checksum: 0x2f00

Spare1: 0x0, spare2: 0x0, spare3: 0x0

***

Reread of rdba: 0x0380e573 (file 14, block 58739) found same corrupted data

Bad Checksum

Block Checksums are used to identify if the block was changed by something external to Oracle and after the block was last written by Oracle.

Checksum is calculated by DBWR or direct loader before writing the block to disk and stored in the block header. Every time that the block is read and if db_block_checksum is different than false, Oracle calculates a checksum and compares it to the one stored in the block header. Reference Note 30706.1

Example of a corrupt block due to invalid checksum:

Corrupt block relative dba: 0x0380a58f (file 14, block 42383)

Bad check value found during buffer read

Data in bad block-

Type: 6 format: 2 rdba: 0x0380a58f

Last change scn: 0x0288.7784c5ee seq: 0x1 flg: 0x06

Consistency value in tail: 0xc5ee0601

Check value in block header: 0x68a7, computed block checksum: 0x2f00

Spare1: 0x0, spare2: 0x0, spare3: 0x0

***

Reread of rdba: 0x0380a58f (file 14, block 42383) found same corrupted data

A value different than zero (0x0) in "computed block checksum" means that the checksum

Differs and the result of this comparison is printed.

Block Misplaced

This is when Oracle detected that the content of the block being read belongs to a different block and the checksum is valid:

Corrupt block relative dba: 0x0d805a89 (file 54, block 23177)

Bad header found during buffer read

Data in bad block-

Type: 6 format: 2 rdba: 0x0d805b08-> Block is different than expected 0x0d805a89

Last change scn: 0x0692.86dc08e3 seq: 0x1 flg: 0x04

Consistency value in tail: 0x08e30601

Check value in block header: 0x2a6e, computed block checksum: 0x0

Spare1: 0x0, spare2: 0x0, spare3: 0x0

* Logical Block Corruptions

This is when block contains a valid checksum and the structure below the beginning of the block is corrupt (Block content is corrupt). It may cause different ORA-600 errors.

The detailed corruption description for Logical Corruptions are not normally printed in the alert.log. DBVerify will report what is logically corrupted in the block.

Corruption Examples are:

Row locked by non-existent transaction-ORA-600 [4512], etcthe amount of space used is not equal to block sizeavsp badetc.

When db_block_checking is enabled, it may produce the internal errors ORA-600 [kddummy_blkchk] or ORA-600 [kdBlkCheckError].

If db_block_checking is enabled and the block is already logically corrupt on disk, the next block update will mark the block as Soft Corrupt and future reads of this block will produce the error ORA-1578. In that case DBVerify reports this corruption with error "DBV-200: Block, dba, already marked corrupted".

ReferencesNOTE:1088018.1-Master Note for Handling Oracle Database Corruption Issues

NOTE:1578.1-OERR: ORA-1578 "ORACLE data block corrupted (file # s, block # s)" Master Note

NOTE:28814.1-Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g

NOTE:794505.1-ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING-Error explanation and solution

NOTE:819533.1-How to identify the corrupt Object reported by ORA-1578 / RMAN / DBVERIFY

NOTE:836658.1-Identify the corruption extension using RMAN/DBV/ANALYZE etc

one。 Physical block damage: various kinds of block damage are usually reported by ORA-1578, and detailed information is recorded in the alert log. Examples of physical damage include: > Bad header > Block damage / incomplete (Fractured Block) > incorrect checksum of Block (Bad Checksum) > Block location error (Block Misplaced) > Zero Block / ORA-8103

two。 Logical block corruption: when the block contains a correct checksum and structure, but the part below the block (the contents of the block) is damaged, it may cause different ORA-600 errors. Logical corruption detailed damage information is not usually printed in the alert log, and DBV will report logically damaged blocks. Examples of logic corruption include: > rows are locked by non-existent transactions-ORA-600 [4512], etc. > the space size used is not equal to the block size > avsp bad > and so on. When db_block_checking is enabled, an internal error ORA-600 [kddummy_blkchk] or ORA-600 [kdBlkCheckError] may be generated.

III. DB _ BLOCK_CHECKSUM and DB_BLOCK_CHECKING

DB_BLOCK_CHECKSUM is used to prevent physical IO from being damaged. The default value is TYPICAL. When the DBWR process writes to disk, the check sum value of the data is recorded and stored in the block head. The next time it is read, the check sum value of the block is recalculated and compared with the block head to determine whether the block is damaged. If it is set to FULL, the check sum value of the block in memory is also verified to avoid block corruption caused by memory problems. Even if the DB_BLOCK_ check sum value is set to FALSE, relevant validation is performed for SYSTEM tablespaces.

DB_BLOCK_CHECKING is used for logic control blocks. If db_block_checking is enabled, the block of the disk has been damaged by logic. The next update block will mark the block with soft damage, and future reading of this block will generate ORA-1578 errors. In this case, the damage error "DBV-200:Block,dba, already marked corrupted" will be reported. Even if the DB_BLOCK_ check value is set to FALSE, the SYSTEM tablespace is validated.

four。 Introduction to verification tools

There are two main tools for verifying bad blocks: DBV and RMAN.

1.DBV tool

DBV, which stands for DBVERIFY, is an external command-line tool that performs physical data structure integrity checks. It can be used in offline or online databases or in backing up files. Because DBVERYIFY can run against offline database, the speed of integrity check is greatly improved. DBV inspection is limited to cache-managed blocks (data blocks). DBV is used only for data files and cannot be used to control the inspection of files or Redo log files.

Dbv help=y can see detailed help information about the parameters of the DBV tool.

2.RMAN tool

The following is about RMAN's VALIDATE command verifying logical and physical bad blocks:

How to check for physical and logical database corruption using "backup validate check logical database" command for database on a non-archivelog mode [ID 466875.1] modified time 30-JUN-2011 type FAQ? / em > PUBLISHED

In this Document

Purpose

Questions and Answers

PurposeHow can we use this command for a non-archivelog database so we can use this as opposed to the dbv command?

RMAN > backup validate check logical database

Questions and Answers "backup validate check logical database" RMAN command could NOT be used for a non-archivelog database.

RMAN > backup validate check logical database

RMAN-00571: =

RMAN-00569: = ERROR MESSAGE STACK FOLLOWS =

RMAN-00571: =

RMAN-03009: failure of backup command on ORA_DISK_2 channel at 11/06/2007 14:56:31

ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode

The only way to do that for database on no-archive log mode is to perform. Above command while the target database in MOUNT status not OPEN

Additional Information:

-

-RMAN restore/backup validate with check logical will ensure that there is no logical and also physical corruption.However, DBV would report only physical corruption.

-If the backup validate discovers corrupt blocks, then RMAN updates the V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions.

-After corrupt block is repaired the row identifies this block is deleted from the view.

As can be seen from the above description, DBV only reports physical damage, and validate check logical database can verify physical damage and logical damage. After executing the VALIDATE command, you can get the details of the bad block by querying the V$DATABASE_BLOCK_CORRUPTION view. After the block is repaired, the corresponding record in the V$DATABASE_BLOCK_CORRUPTION will be deleted. This command can only be run in a database in archive mode, and if you want to execute the command in non-archive mode, you must keep the database in MOUNT mode.

Execute the following command to verify the logical and physical corruption of the archive log:

RMAN > BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL

Execute the following command to verify the physically damaged blocks of the database:

RMAN > BACKUP VALIDATE DATABASE | ARCHIVELOG ALL

BACKUP commands without the CHECK LOGICAL keyword will only verify physical corruption.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.