Home >Database >Mysql Tutorial >Oracle空间管理实验

Oracle空间管理实验

WBOY
WBOYOriginal
2016-06-07 17:35:14959browse

实验分两步: 1.LMT本地管理的表空间,ASSM 自动段管理时数据文件的结构分析 Oracle 11G:0号操作系统块,1-2是文件头,3-127是位

实验分两步:
1.LMT本地管理的表空间,ASSM 自动段管理时数据文件的结构分析 Oracle 11G:0号操作系统块,1-2是文件头,3-127是位图信息。128号开始及之后存放的是数据了—可能是段头或段的数据。
ORACLE 10G时数据文件头只有8个块存放位图信息。--本文未实验。

2.位图块中对于区的使用情况的记录--第一个记录区使用情况的是3号块,本文查看的就是3号块。 在位图块中用二进制数值1来表示区的起始个数--或者叫第一个可以分配的区的位置。 这个记录上的区个数和自动或固定区大小是没有关系的,可以通过建两个不同分配方式表空间来验证,下面贴有。

结合实验,我理解的是位图中的表示的是区的位置,不是DBA这种绝对位置,而是相对的第几个第几个这种,ORACEL在分配时根据位图块中的信息,找到第一个可以供分配的区。--不知道这样说准确不,弄不清的就看后面实验吧。

3.哪些操作会释放空间?空间释放会做什么操作?

删除段时的位图变化:如果段被删除(DROP)或TRUNCATE,相应的区将被回收。如果只是DELETE数据,是不会回收区空间的--数据块中的空间也不会回收-高水位。

比如1、2、3、4、5个区,TRUNCATE 2号区所在的表A,
truncate table a;DDL操作,做一次完全检查点,再DUMP位图中记录区的数据文件3号块,发现FIRST已经变化,释放区空间。
就是DUMP的数据文件3号块这一行信息中变化:RelFno: 14, BeginBlock: 128, Flag: 0, First: 1, Free: 63487

 

4.是否开启闪回DROP回收站功能时验证Oracle找寻可用区的不同方式

打开闪回DROP回收站功能-11G默认打开,比如一个数据文件中有多个段(表),表的建立先后顺序不同,分配到的区在数据文件中的先后也会不同。这时,如果把数据文件上建的第一个表drop,DUMP位图块会发现,First: 4,这个值会变为First: 1, ,后面可能在很远后会有 0000FFFFFFFF0F00。 但是据说,开启闪回时查找可用区是扫描整个位图,First: 4,这个值是没用的。 在drop后,事实上是将表系统命令rename,区及数据还存在数据文件上。如果查找整个位图区,都没有可用区,则会按 drop的时间,将最早drop的区释放。如果释放了所有回收站中的表的空间,还是不够用,就会扩展数据文件。

如未打开闪回DROP的回收站功能,如果把数据文件上建的第一个表删除或TRUNCATE,,位图中First: 4, 这个值是不会变的,会一直接从First: 4,往下分配,直到数据文件中区分配完,才会再回到最前面查找空闲。

 

 

注;关于位图中对区使用的记录的计算方法如下:
DUMP此块,可以看到比如以下:
RelFno: 7, BeginBlock: 128, Flag: 0, First: 4, Free: 63451
0F00000000000000
这是因为,块中用16进制来表示2进制,应该将16进制转化为2进制,查看二进制1的个数来计算起始区的个数。
更简单的计算方法是:每个16进制最多表示4个1,分别是十六进制1--二进制1,十六进制3--二进制11,十六进制7--二进制11,十六进制F--二进制1111
在我这里0F就是四个二进制1了,表示分配了四个区。


实验第一步:LMT本地管理的表空间,ASSM 自动段管理时数据文件的结构分析

新建一个表空间test4,在test4表空间上新建一个数据文件,插入一行数据,做一个完全检查点。可以从dba_segments.header_block查出段头的位置,DUMP test4表空间的1-4及127-131号块。

BYS@ bys3>create table test4(aa int) tablespace test4;
Table created.
BYS@ bys3>insert into test4 values(99889);
1 row created.
BYS@ bys3>commit;
Commit complete.
BYS@ bys3>select segment_name,header_block,header_file,blocks from dba_segments where segment_name='TEST4';
SEGMENT_NAME HEADER_BLOCK HEADER_FILE BLOCKS
--------------- ------------ ----------- ----------
TEST4 130 14 8
BYS@ bys3>alter system checkpoint; ---要做一个完全检查点,不然新插入的数据未写入数据文件。
System altered.
#############
BYS@ bys3>alter system dump datafile 14 block min 1 block max 4;
System altered.
BYS@ bys3>select value from v$diag_info where name like 'De%';
VALUE
----------------------------------------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_12335.trc
BYS@ bys3>alter system dump datafile 14 block min 127 block max 131;
System altered.
BYS@ bys3>select value from v$diag_info where name like 'De%';
VALUE
----------------------------------------------------------------------------------------------------
/u01/diag/rdbms/bys3/bys3/trace/bys3_ora_12377.trc
################

DUMP数据块的内容分析

2号块内容:--位图块头

Start dump data blocks tsn: 9 file#:14 minblk 1 maxblk 4

Block 1 (file header) not dumped:use dump file header command --DUMP数据文件第1个块--块头,要用alter system set events 'immediate trace name file_hdrs level 3';
Block dump from cache: --这一点从buffer cache中来的
Dump of buffer cache at level 4 for tsn=9 rdba=58720258
BH (0x217f7538) file#: 14 rdba: 0x03800002 (14/2) class: 13 ba: 0x2171c000 --BH信息详解见:详解Buffer Header--DUMP buffer结合X$BH视图各字段
set: 3 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,0
dbwrid: 0 obj: -1 objn: 1 tsn: 9 afn: 14 hint: f
hash: [0x2a39741c,0x2a39741c] lru: [0x22fed538,0x22fe44d8]
ckptq: [NULL] fileq: [NULL] objq: [0x24444154,0x22fe44f0] objaq: [0x2444414c,0x22fe44f8]
st: XCURRENT md: NULL fpin: 'ktfbwh0d: ktfbsearch' tch: 2
flags: block_written_once redo_since_read
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [1]
Block dump from disk:
buffer tsn: 9 rdba: 0x03800002 (14/2) ------tsn: 9表空间号,rdba: 0x03800002 (14/2) 14号文件2号块
scn: 0x0000.0077dfdb seq: 0x02 flg: 0x04 tail: 0xdfdb1d02
frmt: 0x02 chkval: 0xb96b type: 0x1d=KTFB Bitmapped File Space Header --这里可以看到这个块是位图块的信息
Hex dump of block: st=0, typ_found=1
Dump of memory from 0xB6C22600 to 0xB6C24600
B6C22600 0000A21D 03800002 0077DFDB 04020000 [..........w.....]
B6C22610 0000B96B 0000000E 00000008 00000500 [k...............]
B6C22620 00000001 00000000 00000000 0000007E [............~...]
B6C22630 000004FF 00000001 0000008F 00000003 [................]
B6C22640 00000000 00000000 00000000 00000000 [................]
B6C22650 00000080 00000008 00000000 00000000 [................]
B6C22660 00000000 00000000 00000000 00000000 [................]
Repeat 504 times
B6C245F0 00000000 00000000 00000000 DFDB1D02 [................]
File Space Header Block:
Header Control:
RelFno: 14, Unit: 8, Size: 1280, Flag: 1 ---相对文件号14,Unit: 8--分配单元,每个块的大小为8192,。 Size: 1280--此数据文件包含的块数-1280*8K=10M
AutoExtend: NO, Increment: 0, MaxSize: 0 ---
Initial Area: 126, Tail: 1279, First: 1, Free: 143 ---Initial Area: 126,这是指出了有126个块用于记录位图信息-,从3-127-11G前是6个
Deallocation scn: 3.0
Header Opcode:
Save: No Pending Op
Block dump from cache:

Dump of buffer cache at level 4 for tsn=9 rdba=58720259 --TNS9是表空间号,rdba=58720259是FILE和BLOCK,RDBA计算方法如下:

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Previous article:ORA-01034错误Next article:常用的DB2命令