Oracle Space Management Experiment (i)

Explore the structure of data file header under LMT table space management and the recording mode of bitmap Central

The experiment is divided into two steps:

1.LMT locally managed table space, the structure analysis of data files in ASSM automatic segment management

ORACLE 11g:0 OS block, 1-2 is the file header and 3-127 is bitmap information. The number 128th begins and is followed by data-possibly segments of the head or segment.

ORACLE 10G Data File header only 8 blocks to store bitmap information. --This article has not been tested.

2. The record of the use of the area in the bitmap block--the first record area used is the 3rd block, this article is looking at block 3rd.

A binary value is used in a bitmap block to indicate the starting number of the area--or the location of the first area that can be allocated. The number of areas on this record is not related to the automatic or fixed area size, which can be verified by building two different allocation table spaces, which are posted below.

In conjunction with the experiment, I understand that the bitmap represents the location of the zone, not the absolute location of the DBA, but the first few of the relative, Oracel to find the one area that can be allocated according to the information in the bitmap block at the time of allocation. --I don't know if this is accurate or not, I can't get a clear look at the back experiment.

3. Which operations will free up space? What does space release do?

Bitmap changes when a segment is deleted: If the segment is deleted (drop) or truncate, the corresponding zone is reclaimed. If you delete data only, you will not reclaim the space--the space in the block will not be recycled--high water level.

For example, 1, 2, 3, 4, 5 districts, TRUNCATE 2nd, the table A,

TRUNCATE TABLE A;DDL operation, do a full checkpoint, and then dump the record area in the bitmap data file 3rd block, found first has changed, free space.

That's the dump data file. 3rd Block This line of information changes: Relfno:14, beginblock:128, flag:0, First:1, free:63487

4. different ways to verify Oracle's search for available areas when you turn on the Flash back drop Recycle Bin function :

Turn on the flash back drop Recycle Bin function -11g Open by default, such as a data file has more than one paragraph (table), the table is established in different order, assigned to the area in the data file will also be different. At this point, if the data file built on the first table Drop,dump bitmap block will be found, first:4, this value will change to first:1, the following may be very far behind the 0000ffffffff0f00. But it is said that when the flash-back is turned on to find the available area is to scan the entire bitmap, First:4, this value is useless. After drop, the table system commands are actually rename, and the area and data are on the data file. If you look for an entire bitmap area and there is no available area, the first drop area is released at the drop time. If you free up the space in all the tables in the Recycle Bin, or if you are not enough, you will expand the data file.

If you do not turn on the return drop of the Recycle Bin function, if the data file on the first table deleted or truncate, the bitmap first:4, this value will not change, will be a direct from the first:4, down to the distribution, until the central distribution of data files, Will go back to the front to find idle.

Note: The records used for the area in the bitmap are calculated as follows.

Dump this block, you can see for example the following:

Relfno:7, beginblock:128, flag:0, First:4, free:63451

0f00000000000000

This is because the block uses 16 to represent 2, you should convert 16 to 2, and look at the number of binary 1 to calculate the number of starting areas.

A simpler calculation is that each 16 feed represents up to 4 1, hexadecimal 1--binary 1, hexadecimal 3--binary 11, hexadecimal 7--binary 11, hexadecimal f--binary 1111

Here in my 0F is four binary 1, which means that four districts are allocated.