Oracle Data Block INTRODUCTION 1

ORACLE DATA BLOCK

The Oracle data block is the smallest unit of the database management files.

At the physical level, the Oracle data file is stored on the operating system, the smallest I/O unit is the operating system block, and the Oracle data block is the Oracle DB logical minimum I/O unit with a different structure and system block, and the size is an integer multiple of the system block.

650) this.width=650; "src="/e/u261/themes/default/images/spacer.gif "class=" ynote-attachment "style=" background: URL ("/e/u261/lang/zh-cn/images/localimage.png") no-repeat center;border:1px solid #ddd; "alt=" Spacer.gif "/>650) this.width=650, "src=" Http://s1.51cto.com/wyfs02/M01/7D/14/wKiom1bfwNLTHswXAAAyNYobnL4808.png "title=" Clipboard.png "alt=" Wkiom1bfwnlthswxaaaynyobnl4808.png "/>

DATA BLOCK SIZE

Oracle DB configures the Db_block_size parameter to determine the size of the default data block size for Oracle DB when building a library. The database default block size cannot be changed after the library is built, unless the database is rebuilt.

If you do not specify the Db_block_size parameter when you are building a library, the system will set the default data block size,4k or 8k. The Oracle DB data block size refers to the integer multiple system block size.

DATA block Format

Whether it is the data block that holds table, index, cluster table, its chunks are similar,

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M02/7D/14/wKiom1bfwPzQ77p-AAAvssJi6YI651.png "title=" Clipboard.png "alt=" Wkiom1bfwpzq77p-aaavssji6yi651.png "/>

Data block Overhead

Oracle DB manages data blocks by managing the overhaed. Data block is not used to store data, and its contents are as follows:

1.block Header data block holds the basic information about the chunk and the type of location and block on the disk. It is also used for the management of transactions, and its head records information about activities and historical transactions.

A Transaction Entryis required for every transaction that updates the block. Oracle Database initially reserves space in the block header for transaction entries. In data blocks allocated to segments the support transactional changes, free space can also hold transaction entries when The header space is depleted. The space required for transaction entries is operating system dependent. However, transaction entries in the most operating systems require approximately.

2.table Directory

For a heap-organized Table , this directory contains metadata about tables whose rows is stored in this block. Multiple tables can store rows in the same block.

3.row Directory

For a heap-organized table, this directory describes the location of the rows in the data portion of the block.

After space have been allocated in the row directory, the database does not reclaim this space after row deletion. Thus, a block that's currently empty but formerly had up to $ rows continues to has bytes allocated for the row dir Ectory. The database reuses this space is only when new rows is inserted in the block.

Oracle blocks hold variable-length data, and one data entry includes one or more item slices, each of which includes the row header and row column data.

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M00/7D/12/wKioL1bfwazybo2YAABJH70V4rI795.png "title=" Clipboard.png "alt=" Wkiol1bfwazybo2yaabjh70v4ri795.png "/>

Row Header

Oracle Database uses the row header to manage the row piece stored in the block. The row header contains information such as the following:

• Columns in the row piece

• pieces of the row located in other data blocks

  if an entire row can is inserted into a single data block and then Oracle Database s Tores the row as one row piece. However, if all of the row data cannot is inserted into a single block or an update causes an existing row to outgrow its block, then the database stores the row in multiple row Pieces. a data block usually contains only one row piece per Row.

• Cluster keys for table Clusters

A row fully contained in one block have at least 3 bytes of row header.

Column Data

After the row header, the column data section stores the actual data in the row. The row piece usually stores columns in the order listed in theCREATE TABLEstatement, but this order was not guaranteed. For example, columns of typeLONGis created last.

Rowid format

Oracle database uses a ROWID to uniquely identified a row. Internally, the ROWID is a structure, the information, the database needs to acceces a row. A rowid are not a physically sotred in database, but are inferred from the file and block on which the data is stored.

[email protected] >select rowid from Test1 WHERE rownum < 2;

ROWID

------------------

Aaaweyaaeaaaalpaaa

A ROWID includes a data object number. This ROWID type uses a base is encoding of the physical address for each row. This encoding character is a-z,a-z,0-9,+ and/.

Aaawey data Object Number The data object number identifies a segment number.

AAE relate file Number The tablespace relative file, which stores the row

Aaaalp The data bolck number the data block number, stores the row

AAA Row number The block Nunmber identifies the row in block.

The format of the Oracle database block is corrupted next to some specific factors, known as bad blocks.

causes of database bad blocks

The Oracle database bad blocks classify physical bad blocks and logical bad blocks. The so-called physical bad block is due to hardware I/O failure or operating system failure caused by block write errors, and logical bad block is usually caused by Oracle software problems, specifically, the data block information is written bad, causing the header information does not match the content of the data blocks. As a result, there are many reasons for bad database blocks, such as host hardware failure, storage hardware and software failure, operating system failure, Oracle software failure, and even the application of software stress can lead to bad blocks in the database.

But there is a bad block phenomenon is normal phenomenon. That is, when an action is nologging on a data object, such as "ALTER INDEX < index name > Rebuild nologging", and the data file containing the object is subsequently recover through the log. In this way, the data block corresponding to the object will be identified by Oracle as corrupt, and Oracle will report a ORA-1578 error when accessing these bad blocks. In this case, although the following methods can be used to find out which data objects have bad blocks, but not only to recover data through the recover, but also by other means to effectively salvage data from the bad block. The only thing customers can do is to be careful, careful, and careful, do not recover the data Objects nologging operation!

main process of bad block processing

The impact of just a few database bad blocks can be fatal. How to improve the efficiency of bad block processing and reduce the range of bad blocks? Just as the world deals with all emergency emergencies, there must be pre-planning and handling procedures. The following are the main flowchart for the bad block processing provided by Oracle:

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M01/7D/12/wKioL1bfww6gfSZpAABDRfLpE_A120.png "title=" 8f%e5% 9d%971.png "alt=" Wkiol1bfww6gfszpaabdrflpe_a120.png "/>

Let's follow this flowchart for a more detailed description:

Identify problem areas

First, once a database bad block is found, all information about the bad block, including information about the Alert.log file and trace file records, should be logged to determine the range of bad blocks involved. For example, you should evaluate whether it is a single data bad block, or because of a large number of bad blocks caused by recover operations on the data objects that nologging operations.

At this point, Oracle recommends that you scan the data files and other files where the bad blocks reside by using the Dbverify tool to analyze the presence of more bad blocks to more accurately determine the scope of the problem. If we get a detailed data file/bad block list, we can target and significantly improve the efficiency of bad block processing.

Some of the best practice experiences that Oracle recommends are as follows:

-Complete recording of original bad block error messages, and application module information that encountered a bad block.

-Extract the log information from hours to the current time of the first encounter with a bad block, and save it as a single file for critical analysis.

-Save the trace file that is involved in the log file.

-Understand the hardware and operating system level for error messages.

-Find out whether hardware and storage employ asynchronous I/O (async I/O), fast disk sketching (Fast Write disk), and more.

-Query Current Oracle backup information, backup time, backup type, backup location, etc.

-Query whether the database is an archive or non-archive mode.

Check for and replace problematic hardware

In general, most bad blocks are caused by a hardware failure. Therefore, it is best to check the hardware thoroughly before the bad block data is repaired, especially if a large number of data blocks are present or the error is sporadic. Also, according to Oracle experience, operating system errors may lag, even if the operating system checks properly, does not mean that the hardware is normal.

Therefore, it is better to replace or repair faulty or suspected faulty hardware before the bad block data is repaired. If possible, it is best to move the data files of the failed storage device to a normal storage device.

Bad block processing gossip map

The so-called "choosing the right method for data recovery and salvage" is based on the different types of data objects in the bad block, such as: CACHE, CLUSTER, index PARTITION, index, Lobinde, Lobsegment, ROLLBACK, TABLE PARTITION, TABLE, temporary, TYPE2 UNDO, other data objects and so on, reasonable formulation strategy and concrete method for data recovery and rescue.

The following is a summary of the data that I processed based on several bad blocks of Oracle:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/7D/12/wKioL1bfwvjiKZ8TAADR71bEQgc511.png "title=" 8f%e5% 9d%973.png "alt=" Wkiol1bfwvjikz8taadr71beqgc511.png "/>

The above gossip map is described in detail below:

- first determine whether the database object affected by the bad block is a data object that is not already in use, and if so, do nothing.

- second, determine if the database object affected by the bad block is in a temporary tablespace, and if so, refer to the above: Create a new temporary tablespace and set the temporary tablespace of the affected user to the new temporary tablespace.

- Third, if the database object that the bad block affects is an index, further determine whether the table that contains the index also has a bad block. If so, resolve the table's bad block problem first. If not, it can be restored by means of index rebuilds.

Note:

Partial content References MacLean Blog

This article is from the "DBA Sky" blog, so be sure to keep this source http://kevinora.blog.51cto.com/9406404/1749117

Oracle Data Block INTRODUCTION 1