浅析Oracle全表扫描下的逻辑读

T1表全表扫描产生逻辑读的分析

做个实验给你演示一下:以表t1为例,对段t1做dump

1、t1表就一条数据

gyj@OCM> select * from t1;

     ID NAME

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

      1 AAAAA

2、找t1段的段头块

gyj@OCM> select  header_file,header_block from dba_segments where segment_name='T1' and owner='GYJ';

HEADER_FILE HEADER_BLOCK

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

       7          130

3、另开一个会话:dump段头块( 7文件130号块)

[root@guoyj ~]# su - oracle

[oracle@guoyj ~]$ sqlplus / as sysdba

sys@OCM> 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

查看本栏目更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/

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

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

gyj@OCM> set autot traceonly;

gyj@OCM> 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

gyj@OCM> 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号块

时间: 2024-11-01 00:41:11

浅析Oracle全表扫描下的逻辑读的相关文章

Oracle 全表扫描及其执行计划(full table scan)

    全表扫描是Oracle访问数据库表是较为常见的访问方式之一.很多朋友一看到SQL语句执行计划中的全表扫描,就要考虑对其进行修理一番.全表扫描的存在,的确存在可能优化的余地.但事实上很多时候全表扫描也并非是最低效的,完全要看不同的情形与场合,任一方式都是有利有弊的,也就是具体情况要具体分析.本文描述了什么是全表扫描以及何时发生全表扫描,何时全表扫描才低效.  本文涉及到的相关链接:     高水位线和全表扫描      启用 AUTOTRACE 功能     Oracle 测试常用表BIG

大幅提升MySQL中InnoDB的全表扫描速度的方法_Mysql

 在 InnoDB中更加快速的全表扫描 一般来讲,大多数应用查询的时候都会用索引,查找很少的几行数据(主键查找或百行内的查询),但有时候我们需要全表查询.典型的全表扫描就是逻辑备份  (mysqldump) 和 online schema changes( 注:在线上对大表 schema 的操作,也是 facebook 的一个开源项目) (SELECT ... INTO OUTFILE).  在 Facebook我们用 mysqldump 来备份数据库. 正如你所知MySql提供两种备份方式,提

常识之外:全表扫描为何产生大量 db file sequential read 单块读?

原创 2016-07-05 熊军 Oracle   编辑手记:在理解Oracle技术细节时,我们不仅应该读懂概念,还要能够通过测试验证细节,理解那些『功夫在诗外』的部分,例如全表扫描和单块读. 开发人员在进行新系统上线前的数据校验测试时,发现一条手工执行的 SQL 执行了超过1小时还没有返回结果.SQL 很简单: 下面是这条 SQL 的真实的执行计划: 很显然,在这个表上建 billing_nbr 和 start_date 的复合索引,这条 SQL 就能很快执行完(实际上最后也建了索引).但是这

SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析

在SQL SERVER的查询语句中使用OR是否会导致不走索引查找(Index Seek)或索引失效(堆表走全表扫描 (Table Scan).聚集索引表走聚集索引扫描(Clustered Index Scan))呢?是否所有情况都是如此?又该如何优化呢? 下面我们通过一些简单的例子来分析理解这些现象.下面的实验环境为SQL SERVER 2008,如果在不同版本有所区别,欢迎指正.   堆表单索引 首先我们构建我们测试需要实验环境,具体情况如下所示: DROP TABLE TEST    CRE

SQL中WHERE变量IS NULL条件导致全表扫描问题的解决方法_MsSql

复制代码 代码如下: SET @SQL = 'SELECT * FROM Comment with(nolock) WHERE 1=1    And (@ProjectIds Is Null or ProjectId = @ProjectIds)    And (@Scores is null or Score =@Scores)' 印象中记得,以前在做Oracle开发时,这种写法是会导致全表扫描的,用不上索引,不知道Sql Server里是否也是一样呢,于是做一个简单的测试1.建立测试用的表结

[20151228]小表全表扫描为何如此慢2.txt

[20151228]小表全表扫描为何如此慢2.txt --论坛上有人问的问题,小表全表扫描为何如此慢,200M的大小.链接如下. http://www.itpub.net/thread-2049088-1-1.html --我的猜测是可能含有lob字段,不过对方的恢复没有lob字段.仔细检查发现array使用缺省值,zergduan,bfc99观察都比我细致. --拿例子sh.sales测试看看. SCOTT@book> @ &r/ver1 PORT_STRING              

库表字符集不一致导致的全表扫描问题

背景: 当数据库的建库字符集和表不一样时,在库下针对表创建存储过程可能导致全表扫描 如下例: drop database if exists xx1; drop database if exists xx2; create database xx1 character set utf8; create database xx2 character set gbk;   然后分别在xx1 和 xx2下执行: CREATE TABLE t1 ( `col1` varchar(10) NOT NULL

MongoDB Primary 为何持续出现 oplog 全表扫描?

线上某 MongoDB 复制集实例(包含 Primary.Secondary.Hidden 3个节点 ),Primary 节点突然 IOPS 很高,调查后发现,其中 Hidden 处于 RECOVERING 状态,同时 Priamry 上持续有一全表扫描 oplog 的操作,正是这个 oplog 的 COLLSCAN 导致IO很高. 2017-10-23T17:48:01.845+0800 I COMMAND [conn8766752] query local.oplog.rs query: {

高水位线和全表扫描

   高水位线好比水库中储水的水位线,用于描述数据库中段的扩展方式.高水位线对全表扫描方式有着至关重要的影响.当使用delete 操作 表记录时,高水位线并不会下降,随之导致的是全表扫描的实际开销并没有任何减少.本文给出高水位线的描述,如何降低高水位线,以及高水 位线对全表扫描的影响.   一.何谓高水位线    如前所述,类似于水库中储水的水位线.只不过在数据库中用于描述段的扩展方式.     可以将数据段或索引段等想象为一个从左到右依次排开的一系列块.当这些块中未填充任何数据时,高水位线位于