全表扫描读高水位以下的块

简介: Oracle全表扫描的解读。

做个实验给你演示一下:以表t1为例,对段t1做dump
1.t1表就一条数据

select * from t1;
ID NAME

1 AAAAA

2.找t1段的段头块

select header_file,header_block from dba_segments where segment_name='T1' and wner='GYJ';
HEADER_FILE HEADER_BLOCK

7 130

3另开一个会话:dump段头块( 7文件130号块)
[root@guoyj ~]# su - oracle
[oracle@guoyj ~]$ sqlplus / as sysdba

alter system dump datafile 7 block 130;

4.dump的trace内容

Extent Control Header

Extent Header:: spare1: 0 spare2: 0 #extents: 1 #blocks: 8
last map 0x00000000 #maps: 0 offset: 2716
Highwater:: 0x01c00088 ext#: 0 blk#: 8 ext size: 8 --红色的就为高水位地址

blocks in seg. hdr's freelists: 0

blocks below: 5

mapblk 0x00000000 offset: 0

Unlocked

Low HighWater Mark :
Highwater:: 0x01c00088 ext#: 0 blk#: 8 ext size: 8

blocks in seg. hdr's freelists: 0

blocks below: 5

mapblk 0x00000000 offset: 0
Level 1 BMB for High HWM block: 0x01c00080

Level 1 BMB for Low HWM block: 0x01c00080

Segment Type: 1 nl2: 1 blksz: 8192 fbsz: 0
L2 Array start offset: 0x00001434
First Level 3 BMB: 0x00000000
L2 Hint for inserts: 0x01c00081
Last Level 1 BMB: 0x01c00080
Last Level II BMB: 0x01c00081
Last Level III BMB: 0x00000000
Map Header:: next 0x00000000 #extents: 1 obj#: 78183 flag: 0x10000000
Inc # 0

Extent Map

0x01c00080 length: 8

Auxillary Map

Extent 0 : L1 dba: 0x01c00080 Data dba: 0x01c00083

Second Level Bitmap block DBAs

DBA 1: 0x01c00081

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

5.对表t1做一个全表扫描

set autot traceonly;
select * from t1;

Execution Plan

Plan hash value: 3617692013

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

| 0 | SELECT STATEMENT | | 999K| 14M| 759 (2)| 00:00:10 |

| 1 | TABLE ACCESS FULL| T1 | 999K| 14M| 759 (2)| 00:00:10 |

Statistics

0 recursive calls
0 db block gets
6 consistent gets --全表扫描读了6个块
5 physical reads
0 redo size
596 bytes sent via SQL*Net to client
523 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

6.怎么算出来的呢这个6

select file_id,block_id,blocks from dba_extents where segment_name='T1';
FILE_ID BLOCK_ID BLOCKS

7 128 8
这个t1段一共用了8个块分别是128 129 130 131 132 133 134 135
高水位: 0x01c00088 即7号文件的136号块
读了一次段头块:7文件130号块
读了高水位之下的131号块 132号块 133号块 134号块 135号块五个块
这样一共就读了6个块

注:全表扫描不坊128,129号块,对应的如下关系
Last Level 1 BMB: 0x01c00080 -->128号块
Last Level II BMB: 0x01c00081 -->129号块

相关文章
|
4月前
|
SQL 监控 关系型数据库
大数量的DML时对索引处理的技巧
【8月更文挑战第15天】在执行大批量DML操作(如INSERT、UPDATE、DELETE)时,可通过禁用索引、分批处理、选用适宜的索引类型与结构以及持续监控调整等策略优化性能。禁用索引可加速数据修改,分批处理减轻系统负担,合理索引类型支持不同查询需求,并定期优化索引结构保持高效。全程监控确保适时调整策略,提升整体效能。
|
存储 SQL Oracle
Oracle优化避免索引失效
Oracle优化避免索引失效
370 0
|
关系型数据库 MySQL 索引
一个表中索引的数量是不是越多越好?
往InnoDB表新增数据时,都会基于主键给自动建立聚簇索引。 随着我们不停的在表里插入数据,会不停的在数据页里插入数据。一个数据页放满后,就会分裂成多个数据页,这时就需要索引页去指向各个数据页。
130 0
|
关系型数据库 MySQL 索引
|
存储 SQL 缓存
为什么索引可以让查询变快?终于有人说清楚了!
上表是一张真实的数据库表,其中每一行是一条记录,每条记录都有字段。假设上面的数据库是一个有10万条记录的大数据库。现在,我们想从10万条记录中搜索一些内容,那么挨着一个一个搜索无疑将花费很长的时间,这个时候我们在数据结构与算法里学的二分查找法就派上了用场。
为什么索引可以让查询变快?终于有人说清楚了!
|
架构师 关系型数据库 MySQL
两类非常隐蔽的全表扫描,不能命中索引(一分钟系列)
两类隐蔽的不能利用索引的case: (1)表列类型,与where值类型,不一致; (2)join表的字符编码不同;
434 0
两类非常隐蔽的全表扫描,不能命中索引(一分钟系列)