oracle表空间管理

教程发布:风哥 教程分类:ITPUX技术网 更新日期:2022-02-12 浏览学习:1384

空间管理:

一、表空间管理

1、表空间的多数据文件

1)相关视图

静态视图存储system表空间, tab$,col$,seg$…..(s数据字典表)

v$---x$---SGA内存结构 动态性能视图

DBA技能体现在两个方面:视图和等待事件
表空间=>区
区分配:统一与自动
一个区最少有5个块

块是最小的IO单元,区是最小的分配单元

create tablespace tp1 datafile 'tp1_01.dbf' size 100M uniform size 1M;
alter tablespace tp1 add datafile 'tp1_02.dbf' size 100M;
create table t1 (id int ,name varchar2(50)) tablespace tp1;
insert into t1 select rownum,rpad('abcde',50,'-') from dba_objects;
select extent_id,file_id,block_id,blocks from dba_extents where segment_name='T1' order by

extent_id;
逐个分配,1区1M

create tablespace tp2 datafile 'tp2_01.dbf' size 100M;
alter tablespace tp2 add datafile 'tp2_02.dbf' size 100M;
create table t2 (id int ,name varchar2(50)) tablespace tp2;
insert into t2 select * from t1;
select extent_id,file_id,block_id,blocks from dba_extents where segment_name='T2' order by

extent_id;
前16区是8块,而且全部集中在第一个文件中,第17个区就是128个块,然后逐个分配,

pad是填充的 rpad在右填充 lpad是左填充

2)空间分配单元:区:统一区大小和系统定义区大小:区是空间分配最小单元;
如果表空间存在多个数据文件,表分配是平均分配到多个数据文件,以区为单位,逐个分配

3)大区去对性能的影响。---

大区、大IO:无并发全表扫描速度快点(并发IO测试)

小区、小IO:有并发全表扫描速度更快

----用ASM测,全表扫描,不会有缓存文件系统,11g全表是走直接路径读
----------------------------------------------------------------------单用户下测试
大区(2M)、大IO:无并发全扫描速度更快
alter system set db_file_multiblock_read_count=256; --正好2M
create tablespace tp3 datafile '/tp3.dbf' size 200m reuse uniform size 2m;
drop table t3;
create table t3 (id int,name varchar2(50)) tablespace tp3;
insert into /*+ append */ inot t3 select rownum,'aaaaa' from dba_objects;
commit;
insert into /*+ append */ inot t3 select * from t3;
commit;
set timing on;  --测试结果:3秒左右
select count(*) from t3;--多测几次,取平均值
drop tablespace tp3 including contents;

小区(1M)、小IO:有并发全扫描速度更快
alter system set db_file_multiblock_read_count=128; --正好1M
create tablespace tp3 datafile '/tp3.dbf' size 200m reuse uniform size 1m;
create table t4 (id int,name varchar2(50)) tablespace tp3;
insert into /*+ append */ inot t4 select rownum,'aaaaa' from dba_objects;
commit;
insert into /*+ append */ inot t4 select * from t4;
commit;
set timing on; --测试结果:4秒左右
select count(*) from t4;--多测几次,取平均值

结论:无并发全扫描速度大区更快
-------------------------------------------------多用户测试,即并发测试:开多个窗口执行
区大小1M,多块是128块
第3-4个窗口:
declare
n number;
begin
for i in 1 .. 100000 loop
select count(*) into n from t4;
end loop;
end;
/
第5个窗口:观察
set timing on; --测试结果:6-7秒左右
select count(*) into n from t4;

区大小2M,多块是256块
alter system set db_file_multiblock_read_count=256;
drop tablespace tp3 including contents;
create table t3 (id int,name varchar2(50)) tablespace tp3;
insert into /*+ append */ inot t3 select rownum,'aaaaa' from dba_objects;
commit;
insert into /*+ append */ inot t3 select * from t3;
commit;
第3-4个窗口:
declare
n number;
begin
for i in 1 .. 100000 loop
select count(*) into n from t3;
end loop;
end;
/
第5个窗口:观察
set timing on; ---测试结果:7-8秒
select count(*) into n from t3;

结论:并发全扫描速度小区更快

注意:
当我们上线时压力较小把区设的比较大,之前压力变大,那改变区大小比较困难,那把

db_file_multiblock_read_count设小也是中折中的方案
数据仓库把区设大点。
2M => 1M+1M => 2M(solaris 启2个线程,Linux 启2个异步IO、连发2个1M的IO)

4)多数据文件的空间分配:平均分配,依次分配区

5)数据文件分配:redo和数据文件分离还是不分离

不分离:IO更加平均,

分离:相互影响小

6)碎片问题

统一区大小一般不会有碎片,系统管理的时候也许有碎片,情况很小

碎片最严重的地方:表内部、索引、共享池

例子:

create tablespace tbs_test01 datafile ‘ ‘ size 200m

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K; alter tablespace tbs_test01 datafile ‘ ‘ size 200m

create table t1 (id int,name vachar2(30)) tablespace tbs_test01; insert into to select

rownum,rpad(‘adbcd’,30,'-') from dba_objects;/

/

/

查询 dba_extents

select EXTENT_ID,FILE_ID,BLOCK_ID ,BLOCKS from dba_extents where segment_name=’T1’

经过查看发现两个文件平均分配,查看定位了块数目、块号

要是自动扩展的,也会发现一些规律:先扩展小的 ,先1M的64k区放在一起,然后扩展大的,以1M扩展。

区大小不一致会对大表的全表扫描有影响。当然也会有空间浪费情况。

2.本地管理文件

1)本地管理模式介绍(跟踪分区区操作)

2)文件头、位图块(注意:系统留用块)注意64k

文件管理:
1号块文件头与备份恢复相关
2号块位图头
3号块-8号块(128号块)位图

---11G 就是预留了128个块

alter system dump datafile 5 block 1;--文件头不能这样dump
alter system dump datafile 5 block 2;--位图头
alter system dump datafile 5 block 3;
select bytes/1024/1024,blocks,user_bytes/1024/1024,user_blocks from dba_data_files where

file_id=5;

drop闪回有没有打开???
 ile Space Bitmap Block:
BitMap Control:
RelFno: 4, BeginBlock: 64, Flag: 0, First: 18, Free: 128990
FFFF0300FFFF0000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
 关闭闪回drop:与first相关,从first开始找区空间
 打开闪回drop:与first无关,为了能让drop的段保存的时间长,从文件头开始找区空间,找空间会有一点点慢
   打开闪回实验观察:
    select segment_name,extent_id,file_id,block_id,blocks from dba_extents where file_id=8

order by block_id;
create table t5 tablespace tp5 as select * from t1;
create table t6 tablespace tp5 as select * from t1;
truncate table t5;
create table t7 tablespace tp5 as select * from t1;

-----------
3)回到drop之前,trunc与ora 08103
var x refcursor
exec open 😡 for select * from lhb.t3;
print x;

commit;

drop 重命名-->tab$ seg$ ext$ col$
数据库比较忙,用drop替换truncate,索引,约束重建(空表重建索引很快的)。
回滚操作穿越drop,一边做全表扫描,另一边把表给drop(当没打开闪回时用truncate和drop一样都会报错误ora-

08103object no longer exists),当打开闪回drop时,drop后全表扫描不报错。
实验测试:
var x refcursor
exec open 😡 for select * from t1;--(这个命令做三件事:1.打开cursor的时间即scn记录在PGA中 2.同时

生成执行计划解析 3.执行)
print :x; --获取fecth数据(BufferCache->PGA)

操作print之前,用以下两种方式另开会话:删除表,看会不会报错
truncate table t1;--修改seg$,ext$这些可以回滚,但空间释放了,修改了文件头,这个不能回滚。
drop table t1; --recyclebin on

二、段与EMP块:Extent Map 区地图块(全表扫描和索引扫描如何完成)表、段(segment)
段头:高水点,EMP(Fid,Bid,Blocks)
select extent_id,file_id,block_id,blocks from dba_extents where segment_name='T1';
EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
0 7 272 8
1 7 280 8
2 7 288 8
3 7 296 8
4 7 304 8
5 7 312 8
6 7 320 8
7 7 328 8
8 7 336 8
9 7 344 8
10 7 352 8
11 7 360 8
12 7 368 8
13 7 376 8
14 7 512 8
15 7 520 8
16 7 640 128
17 7 1152 128

select header_file,header_block from dba_segments where segment_name='T1';
HEADER_FILE HEADER_BLOCK
----------- ------------
7 274 --段头块

alter system dump datafile 7 block 274;

分析段头dump内容:
Block dump from disk:
buffer tsn: 7 rdba: 0x01c00112 (7/274)
scn: 0x0000.006bcb88 seq: 0x01 flg: 0x04 tail: 0xcb882301
frmt: 0x02 chkval: 0x8fab type: 0x23=PAGETABLE SEGMENT HEADER --PAGETABLE指堆表
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00D9B600 to 0x00D9D600
D9B600 0000A223 01C00112 006BCB88 04010000 [#.........k.....]
D9B610 00008FAB 00000000 00000000 00000000 [................]
D9B620 00000000 00000012 00000180 00000A9C [................]
D9B630 00000011 00000080 00000080 01C00500 [................]
D9B640 00000000 00000011 00000000 00000172 [............r...]
D9B650 00000000 00000000 00000000 00000011 [................]
D9B660 00000080 00000080 01C00500 00000000 [................]
D9B670 00000011 00000000 00000180 01C00481 [................]
D9B680 01C00481 00000000 00000000 00000000 [................]
D9B690 00000000 00000000 00000000 00000000 [................]
Repeat 3 times
D9B6D0 00000001 00002000 00000000 00001434 [..... ......4...]
D9B6E0 00000000 01C00111 00000001 01C00481 [................]
D9B6F0 01C00111 00000000 00000000 00000000 [................]
D9B700 00000000 00000000 00000012 00000000 [................]
D9B710 00012678 10000000 01C00110 00000008 [x&..............]
D9B720 01C00118 00000008 01C00120 00000008 [........ .......]
D9B730 01C00128 00000008 01C00130 00000008 [(.......0.......]
D9B740 01C00138 00000008 01C00140 00000008 [8.......@.......]
D9B750 01C00148 00000008 01C00150 00000008 [H.......P.......]
D9B760 01C00158 00000008 01C00160 00000008 [X.......`.......]
D9B770 01C00168 00000008 01C00170 00000008 [h.......p.......]
D9B780 01C00178 00000008 01C00200 00000008 [x...............]
D9B790 01C00208 00000008 01C00280 00000080 [................]
D9B7A0 01C00480 00000080 00000000 00000000 [................]
D9B7B0 00000000 00000000 00000000 00000000 [................]
Repeat 143 times
D9C0B0 01C00110 01C00113 01C00110 01C00118 [................]
D9C0C0 01C00120 01C00121 01C00120 01C00128 [ ...!... ...(...]
D9C0D0 01C00130 01C00131 01C00130 01C00138 [0...1...0...8...]
D9C0E0 01C00140 01C00141 01C00140 01C00148 [@mailto:...A...@...H]...A...@...H...]
D9C0F0 01C00150 01C00151 01C00150 01C00158 [P...Q...P...X...]
D9C100 01C00160 01C00161 01C00160 01C00168 [`...a...`...h...]
D9C110 01C00170 01C00171 01C00170 01C00178 [p...q...p...x...]
D9C120 01C00200 01C00201 01C00200 01C00208 [................]
D9C130 01C00280 01C00282 01C00480 01C00482 [................]
D9C140 00000000 00000000 00000000 00000000 [................]
Repeat 143 times
D9CA40 00000000 00000000 01C00111 00000000 [................]
D9CA50 00000000 00000000 00000000 00000000 [................]
Repeat 185 times
D9D5F0 00000000 00000000 00000000 CB882301 [.............#..]
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 18 #blocks: 384
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x01c00500 ext#: 17 blk#: 128 ext size: 128
#blocks in seg. hdr's freelists: 0
#blocks below: 370
mapblk 0x00000000 offset: 17
Unlocked
--------------------------------------------------------
Low HighWater Mark :
Highwater:: 0x01c00500 ext#: 17 blk#: 128 ext size: 128
#blocks in seg. hdr's freelists: 0
#blocks below: 384
mapblk 0x00000000 offset: 17
Level 1 BMB for High HWM block: 0x01c00481
Level 1 BMB for Low HWM block: 0x01c00481
--------------------------------------------------------
Segment Type: 1 nl2: 1 blksz: 8192 fbsz: 0
L2 Array start offset: 0x00001434
First Level 3 BMB: 0x00000000
L2 Hint for inserts: 0x01c00111
Last Level 1 BMB: 0x01c00481  
Last Level II BMB: 0x01c00111  --273号块
Last Level III BMB: 0x00000000
Map Header:: next 0x00000000 #extents: 18 obj#: 75384 flag: 0x10000000
Inc # 0
Extent Map --这就是区地图 EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------------------------- --------- -------- --------- ------
0x01c00110 length: 8 0 7 272 8
0x01c00118 length: 8 1 7 280 8
0x01c00120 length: 8 2 7 288 8
0x01c00128 length: 8 3 7 296 8
0x01c00130 length: 8 4 7 304 8
0x01c00138 length: 8 5 7 312 8
0x01c00140 length: 8 6 7 320 8
0x01c00148 length: 8 7 7 328 8
0x01c00150 length: 8 8 7 336 8
0x01c00158 length: 8 9 7 344 8
0x01c00160 length: 8 10 7 352 8
0x01c00168 length: 8 11 7 360 8
0x01c00170 length: 8 12 7 368 8
0x01c00178 length: 8 13 7 376 8
0x01c00200 length: 8 14 7 512 8
0x01c00208 length: 8 15 7 520 8
0x01c00280 length: 128 16 7 640 128
0x01c00480 length: 128 17 7 1152 128
--如果区地图很大,那会在最后一行记录区地址(还没有length长度),这个区会记录区地图信息

Auxillary Map --辅助地图,更详细描述了数据块
--------------------------------------------------------
Extent 0 : L1 dba: 0x01c00110 Data dba: 0x01c00113 --第一个区第一个可用的数据块:275号块

,276 277 278 279
Extent 1 : L1 dba: 0x01c00110 Data dba: 0x01c00118 --280
Extent 2 : L1 dba: 0x01c00120 Data dba: 0x01c00121 --289
Extent 3 : L1 dba: 0x01c00120 Data dba: 0x01c00128 --296
Extent 4 : L1 dba: 0x01c00130 Data dba: 0x01c00131 --305
Extent 5 : L1 dba: 0x01c00130 Data dba: 0x01c00138 --312
Extent 6 : L1 dba: 0x01c00140 Data dba: 0x01c00141 --321
Extent 7 : L1 dba: 0x01c00140 Data dba: 0x01c00148 --328
Extent 8 : L1 dba: 0x01c00150 Data dba: 0x01c00151 --337
Extent 9 : L1 dba: 0x01c00150 Data dba: 0x01c00158 --344
Extent 10 : L1 dba: 0x01c00160 Data dba: 0x01c00161 --353
Extent 11 : L1 dba: 0x01c00160 Data dba: 0x01c00168 --360
Extent 12 : L1 dba: 0x01c00170 Data dba: 0x01c00171 --369
Extent 13 : L1 dba: 0x01c00170 Data dba: 0x01c00178 --376
Extent 14 : L1 dba: 0x01c00200 Data dba: 0x01c00201 --513
Extent 15 : L1 dba: 0x01c00200 Data dba: 0x01c00208 --520
Extent 16 : L1 dba: 0x01c00280 Data dba: 0x01c00282 --642
Extent 17 : L1 dba: 0x01c00480 Data dba: 0x01c00482 --1154
--------------------------------------------------------

Second Level Bitmap block DBAs
--------------------------------------------------------
DBA 1: 0x01c00111

End dump data blocks tsn: 7 file#: 7 minblk 274 maxblk 274

表扫描步骤:
1.读段头,seg$,找EMP
 2.读取EMP,确定高水位
3.按EMP读

索引扫描:
根枝页
root=段头+1---去找枝---去找叶---根据叶的指向地址访问块
row cache 缓存seg$信息

4、ASSM的三级位图块
(1)、ASSM的目的
(2)、三级位图块
(3)、Pctfree、Pctused
段大小 Blocks Mapped 详细说明
------ --------------- -----------------------------------------
<= 1MB 16 Data Blocks 当段小于1M时,每个L1 BMB存储16块的地图 <= 32MB 64 Data Blocks 当段小于32M时(但大于1M),每个L1 BMB存储64块的地图 <= 1GB 256 Data Blocks 当段小于1G时(但大于32M),每个L1 BMB存储256块的地图 > 1GB 1024 Data Blocks 当段大于1G时,每个L1 BMB存储1024块的地图
(4)、高高水点和低高水点
(5)、ASSM带来的问题
I、大、小块的问题
II、新的高低水点机制,带来的插入不分散的问题

(1)、ASSM的目的:大并发插入
(2)、三级位图块:L3 --> L2 -> L1

---system表空,undo表空,temporary表空间不能用ASSM
select tablespace_name,segment_space_management from dba_tablespaces;
TABLESPACE_NAME SEGMEN
------------------------------ ------
SYSTEM MANUAL
SYSAUX AUTO
UNDOTBS1 MANUAL
TEMP MANUAL

MSSM:手工段空间管理
 用FreeList(在段头记录5个空闲的块)来管理空块(以5个块为单位),块空间写满就从Freelist中摘掉(相

当于修改段头)
搞多条FreeList解决争用,但无法从根本上解决问题,因为FreeList信息全记录在段头中,段头空间有限

ASSM:自动段空间管理
 三级位图块
select s.sid,p.pid,p.spid from v$session s,v$process p where s.paddr=p.addr and s.sid in(select

sid from v$mystat where rownum=1);
SID PID SPID
---------- ---------- ------------------------
162 19 5756

SID:会话号
PID:Oracle内部的进程号
SPID:操作系统的进程号
--用PID+目标数量这两个做hash运算产生一个随机数(HASH作用:1.产生随机数,2.快速搜索)
插入数据的顺序:L3 --> L2 -> L1 -> Data
select 30*30*30 from dual;--大并发插入
在同一个会话中做插入:肯定会插入在同一个块中
在不同的会话中做插入:肯定不会插入在同一个块中
实验测试:
gyj@OCM> create tablespace tp128 datafile '/u01/app/oracle/oradata/ocm/tp128.dbf' size 10M uniform

size 1M;

Tablespace created.

gyj@OCM> create table t128(id int,name varchar2(100)) tablespace tp128;

Table created.

gyj@OCM> insert into t128 select rownum,object_name from dba_objects where rownum=1;

1 rows created.

gyj@OCM> select extent_id,file_id,block_id,blocks from dba_extents where segment_name='T128';

EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
0 6 128 128

gyj@OCM> select header_file,header_block from dba_segments where segment_name='T128';

HEADER_FILE HEADER_BLOCK
----------- ------------
6 131

可以得出L3=>131号块 L2=>130号块 L1=>128号块、129号块
dump段头L3找L2:
 alter system dump datafile 6 block 131;

 Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 1 #blocks: 128
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x018000c0 ext#: 0 blk#: 64 ext size: 128 -- Highwater::

0x018000c0 即192号块(第二个L1的第一个块)
#blocks in seg. hdr's freelists: 0
#blocks below: 60
mapblk 0x00000000 offset: 0
Unlocked
--------------------------------------------------------
Low HighWater Mark :
Highwater:: 0x01800084 ext#: 0 blk#: 4 ext size: 128
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 0
Level 1 BMB for High HWM block: 0x01800080
Level 1 BMB for Low HWM block: 0x01800080
--------------------------------------------------------
Segment Type: 1 nl2: 1 blksz: 8192 fbsz: 0
L2 Array start offset: 0x00001434
First Level 3 BMB: 0x00000000
L2 Hint for inserts: 0x01800082
Last Level 1 BMB: 0x01800081
Last Level II BMB: 0x01800082
Last Level III BMB: 0x00000000
Map Header:: next 0x00000000 #extents: 1 obj#: 75480 flag: 0x10000000
Inc # 0
Extent Map
-----------------------------------------------------------------
0x01800080 length: 128

Auxillary Map
--------------------------------------------------------
Extent 0 : L1 dba: 0x01800080 Data dba: 0x01800084
--------------------------------------------------------

Second Level Bitmap block DBAs
--------------------------------------------------------
DBA 1: 0x01800082   --即L2的内容在6号文件130号块

End dump data blocks tsn: 16 file#: 6 minblk 131 maxblk 131

dump L2:
 alter system dump datafile 6 block 130;

Dump of Second Level Bitmap Block
number: 2 (2个L1) nfree: 2 (2个L1是空闲的) ffree: 0 pdba: 0x01800083
Inc #: 0 Objd: 75480 (对象号)
opcode:0
xid:
L1 Ranges :
--------------------------------------------------------
0x01800080 Free: 5 Inst: 1      --6号文件,128号块
0x01800081 Free: 5 Inst: 1      --6号文件,129号块

dump L1:
 alter system dump datafile 6 block 128;
alter system dump datafile 6 block 129;
Dump of First Level Bitmap Block
--------------------------------
nbits : 4 nranges: 1 parent dba: 0x01800082 poffset: 0
unformatted: 44 total: 64 first useful block: 4
owning instance : 1
instance ownership changed at 02/15/2013 21:05:59
Last successful Search 02/15/2013 21:05:59
Freeness Status: nf1 0 nf2 0 nf3 0 nf4 16

Extent Map Block Offset: 4294967295
First free datablock : 4
Bitmap block lock opcode 0
Locker xid: : 0x0000.000.00000000
Inc #: 0 Objd: 75480
HWM Flag: Not Set
Highwater:: 0x018000c0 ext#: 0 blk#: 64 ext size: 128
#blocks in seg. hdr's freelists: 0
#blocks below: 60
mapblk 0x00000000 offset: 0
--------------------------------------------------------
DBA Ranges :
--------------------------------------------------------
0x01800080(这个区的第一个块) Length: 64 (64个块) Offset: 0

0:Metadata 1:Metadata 2:Metadata 3:Metadata --前四个块不能动,元数据块
4:unformatted 5:unformatted 6:unformatted 7:unformatted -- 未格式化
8:unformatted 9:unformatted 10:unformatted 11:unformatted
12:unformatted 13:unformatted 14:unformatted 15:unformatted
16:75-100% free 17:75-100% free 18:75-100% free 19:75-100% free --格式化操作一次16个连续

块,在块头写上:对象编号、scn等
20:75-100% free 21:75-100% free 22:75-100% free 23:75-100% free --从这里看不出来这个块被

插入到哪了?用DBMS_ROWID来看
24:75-100% free 25:75-100% free 26:75-100% free 27:75-100% free
28:75-100% free 29:75-100% free 30:75-100% free 31:75-100% free
32:unformatted 33:unformatted 34:unformatted 35:unformatted
36:unformatted 37:unformatted 38:unformatted 39:unformatted
40:unformatted 41:unformatted 42:unformatted 43:unformatted
44:unformatted 45:unformatted 46:unformatted 47:unformatted
48:unformatted 49:unformatted 50:unformatted 51:unformatted
52:unformatted 53:unformatted 54:unformatted 55:unformatted
56:unformatted 57:unformatted 58:unformatted 59:unformatted
60:unformatted 61:unformatted 62:unformatted 63:unformatted
--------------------------------------------------------
End dump data blocks tsn: 16 file#: 6 minblk 128 maxblk 128

select dbms_rowid.rowid_relative_fno(rowid),dbms_rowid.rowid_block_number(rowid) from t128;
gyj@OCM> select dbms_rowid.rowid_relative_fno(rowid),dbms_rowid.rowid_block_number(rowid) from

t128;

DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------ ------------------------------------
6 151

再换个会话:插入数据
insert into t128 values(2,'gyj2');

gyj@OCM> select dbms_rowid.rowid_relative_fno(rowid),dbms_rowid.rowid_block_number(rowid) from

t128;

DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------ ------------------------------------
6 162

并发插入
L3=>131号块 L2=>130号块 L1=>128号块、129号块 Data=>64个块 Data=>64个块
L3->L2->L1->Data(64个块) =>64个并发
L3->L2->L1->Data(64个块) =>64个并发
--推出128个并发,实际是达不到128个并发,会有buffer busy waits等待
--多分配区对大并发没什么效果
--每次并发用一个L1(64个块),用完一个L1再用下一个L1
--并发到高水点位置的之下,这是关键!!!!!
--查一下高水点,在段头dump中找到:Highwater:: 0x018000c0 即192号块(第二个L1的第一个块)
--当区大小是1M时,一次以64个块为单位扩展
--解决高并发很容易想到:让高水点往后多扩一点(先插一点再删一点),这样操作浪费CPU,IO

搞个小脚本:
vi assm.sh

sqlplus gyj/gyj < 1GB 1024 Data Blocks 当段大于1G时,每个L1 BMB存储1024块的地图

实验测试:
建一个表空间,建一个4M大小的区
gyj@OCM> create tablespace tp512 datafile '/u01/app/oracle/oradata/ocm/tp512.dbf' size 300M

uniform size 4M;
gyj@OCM> create table t512(id int,name varchar2(100)) tablespace tp512;
gyj@OCM> insert into t512 values(1,'gyj1');
gyj@OCM> commit;
gyj@OCM> select extent_id,file_id,block_id,blocks from dba_extents where segment_name='T512';

EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
0 8 128 512

gyj@OCM> select header_file,header_block,bytes/1024/1024 from dba_segments where

segment_name='T512';

HEADER_FILE HEADER_BLOCK BYTES/1024/1024
----------- ------------ ---------------
8 137 4

gyj@OCM> select 4*1024/64 from dual;

4*1024/64
----------
64

第一个L1: alter system dump datafile 8 block 128;
最后一个L1: alter system dump datafile 8 block 135;

扩表的大小为50M
alter table t512 allocate extent(size 50m);--发现虽然把区加大到4M,但L1对应的块还是64个块
扩表的大小为200M
alter table t512 allocate extent(size 200m);--继续加大段,L1对应的块为256个块
gyj@OCM> select extent_id,file_id,block_id,blocks from dba_extents where segment_name='T512';

gyj@OCM> select extent_id,file_id,block_id,blocks from dba_extents where segment_name='T512';

EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------- ---------- ---------- ----------
0 8 128 512
1 8 640 512
2 8 1152 512
3 8 1664 512
4 8 2176 512
5 8 2688 512
6 8 3200 512
7 8 3712 512
8 8 4224 512
9 8 4736 512
10 8 5248 512
11 8 5760 512
12 8 6272 512
13 8 6784 512
14 8 7296 512
15 8 7808 512
16 8 8320 512
17 8 8832 512
18 8 9344 512
19 8 9856 512
20 8 10368 512
21 8 10880 512
22 8 11392 512
23 8 11904 512
24 8 12416 512
25 8 12928 512
26 8 13440 512
27 8 13952 512
28 8 14464 512
29 8 14976 512
30 8 15488 512
31 8 16000 512
32 8 16512 512
33 8 17024 512
34 8 17536 512
35 8 18048 512
36 8 18560 512
37 8 19072 512
38 8 19584 512
39 8 20096 512
40 8 20608 512
41 8 21120 512
42 8 21632 512
43 8 22144 512
44 8 22656 512
45 8 23168 512
46 8 23680 512
47 8 24192 512
48 8 24704 512
49 8 25216 512
50 8 25728 512
51 8 26240 512
52 8 26752 512
53 8 27264 512
54 8 27776 512
55 8 28288 512
56 8 28800 512
57 8 29312 512
58 8 29824 512
59 8 30336 512
60 8 30848 512
61 8 31360 512
62 8 31872 512
63 8 32384 512

64 rows selected.

dump最后一个L1:
alter system dump datafile 8 block 32384;
DBA Ranges :
--------------------------------------------------------
0x02007e80 Length: 256 Offset: 0

0:Metadata 1:Metadata 2:unformatted 3:unformatted
4:unformatted 5:unformatted 6:unformatted 7:unformatted
8:unformatted 9:unformatted 10:unformatted 11:unformatted
12:unformatted 13:unformatted 14:unformatted 15:unformatted
16:unformatted 17:unformatted 18:unformatted 19:unformatted
20:unformatted 21:unformatted 22:unformatted 23:unformatted
24:unformatted 25:unformatted 26:unformatted 27:unformatted
28:unformatted 29:unformatted 30:unformatted 31:unformatted
32:unformatted 33:unformatted 34:unformatted 35:unformatted
36:unformatted 37:unformatted 38:unformatted 39:unformatted
40:unformatted 41:unformatted 42:unformatted 43:unformatted
44:unformatted 45:unformatted 46:unformatted 47:unformatted
48:unformatted 49:unformatted 50:unformatted 51:unformatted
52:unformatted 53:unformatted 54:unformatted 55:unformatted
56:unformatted 57:unformatted 58:unformatted 59:unformatted
60:unformatted 61:unformatted 62:unformatted 63:unformatted
64:unformatted 65:unformatted 66:unformatted 67:unformatted
68:unformatted 69:unformatted 70:unformatted 71:unformatted
72:unformatted 73:unformatted 74:unformatted 75:unformatted
76:unformatted 77:unformatted 78:unformatted 79:unformatted
80:unformatted 81:unformatted 82:unformatted 83:unformatted
84:unformatted 85:unformatted 86:unformatted 87:unformatted
88:unformatted 89:unformatted 90:unformatted 91:unformatted
92:unformatted 93:unformatted 94:unformatted 95:unformatted
96:unformatted 97:unformatted 98:unformatted 99:unformatted
100:unformatted 101:unformatted 102:unformatted 103:unformatted
104:unformatted 105:unformatted 106:unformatted 107:unformatted
108:unformatted 109:unformatted 110:unformatted 111:unformatted
112:unformatted 113:unformatted 114:unformatted 115:unformatted
116:unformatted 117:unformatted 118:unformatted 119:unformatted
120:unformatted 121:unformatted 122:unformatted 123:unformatted
124:unformatted 125:unformatted 126:unformatted 127:unformatted
128:unformatted 129:unformatted 130:unformatted 131:unformatted
132:unformatted 133:unformatted 134:unformatted 135:unformatted
136:unformatted 137:unformatted 138:unformatted 139:unformatted
140:unformatted 141:unformatted 142:unformatted 143:unformatted
144:unformatted 145:unformatted 146:unformatted 147:unformatted
148:unformatted 149:unformatted 150:unformatted 151:unformatted
152:unformatted 153:unformatted 154:unformatted 155:unformatted
156:unformatted 157:unformatted 158:unformatted 159:unformatted
160:unformatted 161:unformatted 162:unformatted 163:unformatted
164:unformatted 165:unformatted 166:unformatted 167:unformatted
168:unformatted 169:unformatted 170:unformatted 171:unformatted
172:unformatted 173:unformatted 174:unformatted 175:unformatted
176:unformatted 177:unformatted 178:unformatted 179:unformatted
180:unformatted 181:unformatted 182:unformatted 183:unformatted
184:unformatted 185:unformatted 186:unformatted 187:unformatted
188:unformatted 189:unformatted 190:unformatted 191:unformatted
192:unformatted 193:unformatted 194:unformatted 195:unformatted
196:unformatted 197:unformatted 198:unformatted 199:unformatted
200:unformatted 201:unformatted 202:unformatted 203:unformatted
204:unformatted 205:unformatted 206:unformatted 207:unformatted
208:unformatted 209:unformatted 210:unformatted 211:unformatted
212:unformatted 213:unformatted 214:unformatted 215:unformatted
216:unformatted 217:unformatted 218:unformatted 219:unformatted
220:unformatted 221:unformatted 222:unformatted 223:unformatted
224:unformatted 225:unformatted 226:unformatted 227:unformatted
228:unformatted 229:unformatted 230:unformatted 231:unformatted
232:unformatted 233:unformatted 234:unformatted 235:unformatted
236:unformatted 237:unformatted 238:unformatted 239:unformatted
240:unformatted 241:unformatted 242:unformatted 243:unformatted
244:unformatted 245:unformatted 246:unformatted 247:unformatted
248:unformatted 249:unformatted 250:unformatted 251:unformatted
252:unformatted 253:unformatted 254:unformatted 255:unformatted

--变成256个块了

dump段头:
gyj@OCM> select header_file,header_block,bytes/1024/1024 from dba_segments where

segment_name='T512';

HEADER_FILE HEADER_BLOCK BYTES/1024/1024
----------- ------------ ---------------
8 137 256

 alter system dump datafile 8 block 137;

二、高高水点和低高水点
1.高水点一般移以L1中的块为准或区的块为准(L1的未尾,或区的头部)
2.在ASSM:低高水点(低高水点之下全是用过的),高高水点(高高水点之上是完全没有格式化过的,insert into

/*+ append */),低高水点与高高水点之间是混杂的块
3.在MSSM:只有一个高水点,高水点之下的肯定是用过的

三、Pctfree、Pctused(这个值在ASSM中废了)
Pctfree:10%
 在ASSM中的块有6种状态:unformatted 75-100% 50-75% 25-50% 0-25% FULL
到达Full(以Pctfree为准,当达到90%,就变成Full)
 由Full变成非Full(过这四个界线0 25% 50% 75%)

四、为Pctfree设定合适的值
          :用默认Pctfree10%
插入和删除都很多:Pctfree25%

  实验测试:L1的对应数据块空闲空间状态会变
  select count(*) from t3;
alter table t3 pctfree 24;--较差的情况
  数据块包括三部分:块头(SCN DBA ITL等大约占200字节),空闲块,块尾存放数据
  select ((8192-8192*0.24)-200)/110 from dual;--PCTfree24%,假设平均行长度110字节
   ((8192-8192*0.24)-200)/110
    --------------------------
54.7810909
  insert into t3 select 50,rpad('AAA',100,'-') from dba_objects where rownum<=55; COMMIT; 这55行数据应该把这个块给插满了,找到数据块号是30号 做一下dump,找到30号的对应的L1为9号块 alter system dump datafile 8 block 9;   看一下状态,如果没满,那再插入一行 insert into t3 select 50,rpad('AAA',100,'-') from dba_objects where rownum=1;   变为Full 再删除一行 delete from t3 where id=51; commit; 变为25%-50% 五、ASSM带来的问题 I、大、小块的问题 II、新的高低水点机制,带来的插入不分散的问题 III、数据插入的比较散,数据比较乱,带有索引的,那聚簇因子会很大 IIII、数据插入的比较散,全表扫描时间会比较长   64M的表有128个L1 SQL> select 64*1024/8/64 from dual;
64*1024/8/64
------------
128

  1024M的表有480个L1
SQL> select (1024-64)*1024/8/256 from dual;
    (1024-64)*1024/8/256
    --------------------
480

六、MSSM
1.SYSTEM没有大并发插入,所以用MSSM
2.UNDO有大并发,但是它是由多段形式来管理的来解决大并发问题,来一个事务建一个UNDO段(当然这是在有空间的

情况下),所以用MSSM
3.临时表空间基于会话级别的,私有的空间,没有大并发,所以用MSSM

***************************************************************************************
七、网络
1、监听器配置
(1)、动态监听与静态监听
(2)、非1521端口

# ipcs
IPC status from as of Sat Feb 16 20:35:14 CST 2013
T ID KEY MODE OWNER GROUP
Message Queues:
Shared Memory:
m 1 0x1e2cd474 --rw-rw---- oracle oinstall
Semaphores:
s 3 0x17150c14 --ra-ra---- oracle oinstall

KEY=>ORACLE_SID &ORACLE_HOME

2、TNSNAMES.ORA
(1)、services_name与相关视图

3、共享服务器模式
DISPATCHERS、MAX_DISPATCHERS

4、tnsping的注意事项(只Ping监听,不管数据库)
--------------------------------------
四、空间管理
1、解析数据文件中空间如何被使用
(1)、表空间
A表空间中有1、2、3、4个数据文件

10M的T1表:
A. 在某一个文件当中分得10M
B. 每一个文件各分配2.5M

表从数据文件中分配空间单位:区。

R1_1 R1_2 R1_3 R2_1 R2_2 R2_3

create diskgroup dg1 .... disk
R1_1,R2_1,R1_2,R2_2,R1_3,R2_3;
0 1 2 3 4 5

AU:分配单元 1M

create diskgroup dg1 .... disk
R1_1,R1_2,R1_3,R2_1,R2_2,R2_3;
0 1 2 3 4 5

134 2917 0945 吕海波
2、理解区的意义
表从数据文件中分配空间单位:区
(1)、系统管理区大小
区大小:
段的前1M空间:区大小8个块 64K,前16个区。
之后64M之前:区大小1M,128个块
之后:区大小8M

段:64M前。

(2)、大、小区的优缺点
小区:优点省空间
:缺点

大区:缺点浪费空间、和在分配和回收时多耗用一点点CPU
:优点:全扫描段时减少I/O的次数
减少分配的次数。
扫描段时也会减少的次数吧段头的

8M
块:大块、小块。Buffer Pin Lock

8M AU,8M区,存储中使用8M的Stripe Size。

3、I/O的类型:超过1M的区有意义吗
OS、硬件驱动:最大IO大小1M。

读一个8M的区,包含8个1M的I/O,很有可能,这8次I/O,是顺序IO。
读8个1M的区,至少8次随机I/O。

4、区中空间的使用:ASSM原理测试
区大小1M,块大小8K。
一个区128块
插入一行,行被插入到哪里?

在ASSM表空间下:行被随机插入
L3选择L2,不随机
在L2中,根据PID进行HASH,得到一个随机值,根据此值选择L1.
在L1中,…………………………………………,根据此值选择数据块。

128 129 130 131
L1 L1 L2 L3

01c00082
0000 000111 00
7 130

L2 Hint for inserts: 0x01c00082

Second Level Bitmap block DBAs
--------------------------------------------------------
DBA 1: 0x01c00082
DBA 1: 0x01c000XX
DBA 1: 0x01c000XX
DBA 1: 0x01c00082
DBA 1: 0x01c00082
DBA 1: 0x01c00082

ID NAME
---------- --------------------
1 AAAAAA
2 BBBBBB
4 DDDD
3 CCCCC

不会

(1)、文件头
I. 纯文件头:第一块
II.位图区(本地管理的位图区)2-8,其中第2个块是位图

ls -lFrt
ocp_ora_4923.trc
ocp_m000_7660.trc

后台进程的DUMP文件:实例名_进程名_SPID.XXX
服务器进程的DUMP文件:实例名_ORA_SPID.XXX

First:8
111111101111111111111111111111111111111…………0
truncate table t2;
127-2=125/2=
6个块/2:10G

5、被忽略的参数:Pctfree设置为多少合适
6、Oracle数据块内部格式解析

本文标签:
本文标题:oracle表空间管理
网站声明:本文由风哥整理发布,转载请保留此段声明,本站所有内容将不对其使用后果做任何承诺,请读者谨慎使用!
【上一篇】
【下一篇】