从底向上第七篇--超255列表的存储

sundog315

原帖由 Yong Huang 于 2010-6-22 00:36 发表
Note:1062906.6 talks about intra-block chaining.

You can also verify you're NOT reading more blocks than necessary.

alter system flush buffer_cache; -- make sure you get the wait events in trace
alter session set events '10046 trace name context forever, level 8'; -- trace waits
select /*+ full(t) */ ... -- full scan
alter session set events '10046 trace name context off';

grep 'db file scattered read' tracefile

Compare the file#, block# with what you know from dba_extents or dba_segments.

We need Oracle version for this kind of research. In my 10.2.0.4 database with 8k db_block_size, I tried your table. Gather_table_stats leaves user_tables.chain_cnt as 0, but analyze table compute statistics sets it to 1. Analyze table list chained rows inserts 1 row in the chained_rows table. 'table fetch continued row' statistic does not increase during full table scan, which is correct.

Yong Huang

在11G 8k db_block_size中，两种方式统计的结果还是不同：
SQL*Plus: Release 11.2.0.1.0 Production on 星期五 6月 25 09:37:55 2010

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

SQL> conn test/test
已连接。
SQL> exec dbms_stats.gather_table_stats(user,'T');

PL/SQL 过程已成功完成。

SQL> select chain_cnt from user_tables;

CHAIN_CNT
----------
         0

SQL> analyze table t compute statistics;

表已分析。

SQL> select chain_cnt from user_tables;

CHAIN_CNT
----------
         1

sundog315

原帖由 Yong Huang 于 2010-6-22 00:36 发表
Note:1062906.6 talks about intra-block chaining.

You can also verify you're NOT reading more blocks than necessary.

alter system flush buffer_cache; -- make sure you get the wait events in trace
alter session set events '10046 trace name context forever, level 8'; -- trace waits
select /*+ full(t) */ ... -- full scan
alter session set events '10046 trace name context off';

grep 'db file scattered read' tracefile

Compare the file#, block# with what you know from dba_extents or dba_segments.

We need Oracle version for this kind of research. In my 10.2.0.4 database with 8k db_block_size, I tried your table. Gather_table_stats leaves user_tables.chain_cnt as 0, but analyze table compute statistics sets it to 1. Analyze table list chained rows inserts 1 row in the chained_rows table. 'table fetch continued row' statistic does not increase during full table scan, which is correct.

Yong Huang

我又重新做了一遍，还是运行1楼的PL/SQL块，生成1条记录。
这条记录依然被分在2个block中存储

alter system dump datafile 4 block 163;

Block header dump:  0x010000a3
Object id on Block? Y
seg/obj: 0x10c40  csc: 0x00.7fc718  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x10000a0 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000f.01c.000003db  0x03401981.02e5.02  --U-    1  fsc 0x0000.007fc71b
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
bdba: 0x010000a3
data_block_dump,data header at 0x61962264
===============
tsiz: 0x1f98
hsiz: 0x14
pbl: 0x61962264
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f8d
avsp=0x1f79
tosp=0x1f79
0xe:pti[0]        nrow=1        offs=0
0x12:pri[0]        offs=0x1f8d
block_row_dump:
tab 0, row 0, @0x1f8d
tl: 11 fb: --H-F--- lb: 0x1  cc: 1
nrid:  0x010000a7.0
col  0: [ 1]  31
end_of_block_dump

alter system dump datafile 4 block 167;

Block header dump:  0x010000a7
Object id on Block? Y
seg/obj: 0x10c40  csc: 0x00.7fc719  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x10000a0 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000f.01c.000003db  0x03401981.02e5.01  --U-    1  fsc 0x0000.007fc71b
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.00000000
bdba: 0x010000a7
data_block_dump,data header at 0x6196227c
===============
tsiz: 0x1f80
hsiz: 0x14
pbl: 0x6196227c
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1beb
avsp=0x1bd7
tosp=0x1bd7
0xe:pti[0]        nrow=1        offs=0
0x12:pri[0]        offs=0x1beb
block_row_dump:
tab 0, row 0, @0x1beb
tl: 917 fb: -----L-- lb: 0x1  cc: 255
col  0: [ 1]  32
col  1: [ 1]  33
。。。

SQL> select rowid from t;

ROWID
------------------
AAAQxAAAEAAAACjAAA

SQL> alter session set events '10202 trace name context forever';

会话已更改。

SQL> select * from t where t.rowid='AAAQxAAAEAAAACjAAA';


统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
      16122  bytes sent via SQL*Net to client
        415  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> alter session set events '10202 trace name context off';

会话已更改。

Consistent read complete...
Block header dump:  0x010000a3
Object id on Block? Y
seg/obj: 0x10c40  csc: 0x00.7fc718  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x10000a0 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000f.01c.000003db  0x03401981.02e5.02  --U-    1  fsc 0x0000.007fc71b
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
Consistent read complete...
Block header dump:  0x010000a7
Object id on Block? Y
seg/obj: 0x10c40  csc: 0x00.7fc719  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x10000a0 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000f.01c.000003db  0x03401981.02e5.01  --U-    1  fsc 0x0000.007fc71b
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.00000000

SQL> exec dbms_stats.gather_table_stats(user,'T');

PL/SQL 过程已成功完成。

SQL> select chain_cnt from user_tables;

CHAIN_CNT
----------
         0

SQL> analyze table t compute statistics;

表已分析。

SQL> select chain_cnt from user_tables;

CHAIN_CNT
----------
         1

[ 本帖最后由 sundog315 于 2010-6-25 10:12 编辑 ]

sundog315

为什么我的测试用例总是分布在两个块？郁闷。看来分布在多个块的概率不低啊。

[ 本帖最后由 sundog315 于 2010-6-25 10:11 编辑 ]

sundog315

用杨版的例子试一下：

SQL> DECLARE
  2    V_SQL VARCHAR2(32767);
  3  BEGIN
  4    V_SQL := 'CREATE TABLE T_256 (';
  5    FOR I IN 1 .. 256 LOOP
  6      V_SQL := V_SQL || 'C' || I || ' NUMBER,';
  7    END LOOP;
  8    V_SQL := RTRIM(V_SQL, ',') || ')';
  9    EXECUTE IMMEDIATE V_SQL;
10  END;
11  /

PL/SQL 过程已成功完成。

SQL> BEGIN
  2    EXECUTE IMMEDIATE 'INSERT INTO T_256 VALUES (' || LPAD('1,', 510, '1,') |
| '1)';
  3    COMMIT;
  4  END;
  5  /

PL/SQL 过程已成功完成。

SQL> SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID),
  2   DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
  3  FROM T_256;

DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------ ------------------------------------
                                   4                                  171

SQL> alter system dump datafile 4 block 171;

系统已更改。

Block header dump:  0x010000ab
Object id on Block? Y
seg/obj: 0x10c44  csc: 0x00.7fe8f8  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x10000a8 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0010.014.000003a7  0x03422fbc.0256.08  --U-    2  fsc 0x0000.007fe8fa
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.00000000
bdba: 0x010000ab
data_block_dump,data header at 0x61d1227c
===============
tsiz: 0x1f80
hsiz: 0x16
pbl: 0x61d1227c
     76543210
flag=--------
ntab=1
nrow=2
frre=-1
fsbo=0x16
fseo=0x1c74
avsp=0x1c5e
tosp=0x1c5e
0xe:pti[0]        nrow=2        offs=0
0x12:pri[0]        offs=0x1c80
0x14:pri[1]        offs=0x1c74
block_row_dump:
tab 0, row 0, @0x1c80
tl: 768 fb: -----L-- lb: 0x1  cc: 255
col  0: [ 2]  c1 02
...
tab 0, row 1, @0x1c74
tl: 12 fb: --H-F--- lb: 0x1  cc: 1
nrid:  0x010000ab.0
col  0: [ 2]  c1 02
end_of_block_dump

终于在一个块里了。

SQL> select rowid from t_256;

ROWID
------------------
AAAQxEAAEAAAACrAAB

SQL> alter session set events '10202 trace name context forever';

会话已更改。

SQL> select * from t_256 t where t.rowid='AAAQxEAAEAAAACrAAB';

统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
      15866  bytes sent via SQL*Net to client
        415  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> alter session set events '10202 trace name context off';

会话已更改。

Consistent read complete...
Block header dump:  0x010000ab
Object id on Block? Y
seg/obj: 0x10c44  csc: 0x00.7fe8f8  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x10000a8 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0010.014.000003a7  0x03422fbc.0256.08  --U-    2  fsc 0x0000.007fe8fa
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.00000000
Consistent read complete...
Block header dump:  0x010000ab
Object id on Block? Y
seg/obj: 0x10c44  csc: 0x00.7fe8f8  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x10000a8 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0010.014.000003a7  0x03422fbc.0256.08  --U-    2  fsc 0x0000.007fe8fa
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.00000000



即使intra-block，也还是需要读两遍。

Yong Huang

When you do 10202 trace on your t_256, you see two reads of the same data block. I wonder if that's a side effect of sqlplus. You can try Java or Perl.

I created t_256 as yours (in 10.2.0.4 with 8k db_block_size). In order to minimize errors introduced by sqlplus, I enlarged the table many times:

create table testintrablockchain as select * from t_256;
insert into testintrablockchain select * from testintrablockchain;
/
/
...
analyze table testintrablockchain compute statistics;

SQL> select num_rows, blocks, empty_blocks, avg_space, avg_row_len from user_tables where table_name = 'TESTINTRABLOCKCHAIN';

    NUM_ROWS       BLOCKS EMPTY_BLOCKS    AVG_SPACE  AVG_ROW_LEN
------------ ------------ ------------ ------------ ------------
       32768         3649           63         1000          777

SQL> select blocks from user_segments where segment_name = 'TESTINTRABLOCKCHAIN';

      BLOCKS
------------
        3712

SQL> set autot on
SQL> select count(*) from testintrablockchain;

    COUNT(*)
------------
       32768


Execution Plan
----------------------------------------------------------
Plan hash value: 738516490

----------------------------------------------------------------------------------
| Id  | Operation          | Name                | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                     |     1 |   804   (1)| 00:00:10 |
|   1 |  SORT AGGREGATE    |                     |     1 |            |          |
|   2 |   TABLE ACCESS FULL| TESTINTRABLOCKCHAIN | 32768 |   804   (1)| 00:00:10 |
----------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       3653  consistent gets
          0  physical reads
          0  redo size
        337  bytes sent via SQL*Net to client
        338  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed


The full table scan has done 3653 CR reads, 4 more than 3649, which is number of used blocks reported by user_tables. Suppose intra-block chaining still exists in each block, the total number of consistent gets is about the same as data blocks, not double that.

Yong Huang

sundog315

没错，全表扫描的话，确实只需要读一次。我猜想Oracle此时明白无论怎样，读这些块肯定能够满足查询的要求。

SQL> DECLARE
  2   V_SQL VARCHAR2(32767);
  3  BEGIN
  4    V_SQL := 'CREATE TABLE T_256 (';
  5   FOR I IN 1 .. 256 LOOP
  6      V_SQL := V_SQL || 'C' || I || ' NUMBER,';
  7     END LOOP;
  8     V_SQL := RTRIM(V_SQL, ',') || ')';
  9      EXECUTE IMMEDIATE V_SQL;
10   END;
11   /

PL/SQL 过程已成功完成。

SQL> BEGIN
  2    EXECUTE IMMEDIATE 'INSERT INTO T_256 VALUES (' || LPAD('1,', 510, '1,') |
| '1)';
  3    COMMIT;
  4  END;
  5  /

PL/SQL 过程已成功完成。

SQL> insert into t_256 select * from t_256;

已创建 1 行。

SQL> analyze table t_256 compute statistics;

表已分析。

SQL> select num_rows,blocks,empty_blocks,avg_space,avg_row_len,chain_cnt from us
er_tables where table_name='T_256';

  NUM_ROWS     BLOCKS EMPTY_BLOCKS  AVG_SPACE AVG_ROW_LEN  CHAIN_CNT
---------- ---------- ------------ ---------- ----------- ----------
     65536       7300          124       1008         777          0

SQL> BEGIN
  2    EXECUTE IMMEDIATE 'INSERT INTO T_256 VALUES (' || LPAD('2,', 510, '2,') |
| '2)';
  3    COMMIT;
  4  END;
  5  /

PL/SQL 过程已成功完成。

SQL> analyze table t_256 compute statistics;

表已分析。

SQL> select num_rows,blocks,empty_blocks,avg_space,avg_row_len,chain_cnt from us
er_tables where table_name='T_256';

  NUM_ROWS     BLOCKS EMPTY_BLOCKS  AVG_SPACE AVG_ROW_LEN  CHAIN_CNT
---------- ---------- ------------ ---------- ----------- ----------
     65537       7300          124       1008         777          0

SQL> set autot trace exp stat
SQL> select count(*) from t_256;


执行计划
----------------------------------------------------------
Plan hash value: 49459998

--------------------------------------------------------------------
| Id  | Operation          | Name  | Rows  | Cost (%CPU)| Time     |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     1 |  1981   (1)| 00:00:24 |
|   1 |  SORT AGGREGATE    |       |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T_256 | 65537 |  1981   (1)| 00:00:24 |
--------------------------------------------------------------------


统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       7310  consistent gets
          0  physical reads
          0  redo size
        425  bytes sent via SQL*Net to client
        416  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

但是，当使用的是ROWID，无论是user指定的rowid还是通过索引查询到的rowid，结果完全不同。

SQL> select rowid from t_256 where rownum=1;

ROWID
------------------
AAAQxQAAEAAAAiDAAB

SQL> select * from t_256 where rowid='AAAQxQAAEAAAAiDAAB';


执行计划
----------------------------------------------------------
Plan hash value: 411776331

------------------------------------------------------------------------------------
| Id  | Operation                  | Name  | Rows  | Bytes | Cost (%CPU)| Time   |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |       |     1 |   524 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY USER ROWID| T_256 |     1 |   524 |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------

统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          2  consistent gets
          0  physical reads
          0  redo size
      15866  bytes sent via SQL*Net to client
        416  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> create index t_256_idx on t_256(c1);

索引已创建。

SQL> exec dbms_stats.gather_table_stats(user,'T_256',method_opt=>'for all column
s',cascade=>true);

PL/SQL 过程已成功完成。

SQL> select num_rows,blocks,empty_blocks,avg_space,avg_row_len,chain_cnt from us
er_tables where table_name='T_256';

  NUM_ROWS     BLOCKS EMPTY_BLOCKS  AVG_SPACE AVG_ROW_LEN  CHAIN_CNT
---------- ---------- ------------ ---------- ----------- ----------
     65537       7300          124       1008         768          0

SQL> select /*+ index(t_256) */ * from t_256 where c1='2';

执行计划
----------------------------------------------------------
Plan hash value: 717313301
-----------------------------------------------------------------------------------------
| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |           | 32769 |    24M|  3713   (1)| 00:00:45 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T_256     | 32769 |    24M|  3713   (1)| 00:00:45 |
|*  2 |   INDEX RANGE SCAN          | T_256_IDX | 32769 |       |    64   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("C1"=2)

统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          4  consistent gets
          0  physical reads
          0  redo size
      15885  bytes sent via SQL*Net to client
        416  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

看看到底读了哪些块：

SQL> alter session set events '10202 trace name context forever';

会话已更改。

SQL> select /*+ index(t_256) */ * from t_256 where c1='2';

SQL> alter session set events '10202 trace name context off';

会话已更改。

Consistent read complete...
Block header dump:  0x0100260c          --索引leaf，Branch不在10202中列出，因此，10202只有3个块
Object id on Block? Y
seg/obj: 0x10c51  csc: 0x00.80e172  itc: 2  flg: E  typ: 2 - INDEX
     brn: 0  bdba: 0x1002600 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x02   0xffff.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.0080e172
Consistent read complete...
Block header dump:  0x01002506        --第一次读
Object id on Block? Y
seg/obj: 0x10c50  csc: 0x00.80e0c5  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1002500 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0013.009.0000043f  0x0340194c.03b9.41  C---    0  scn 0x0000.0080e0c2
0x02   0x000c.00a.00000385  0x03418aac.0264.4e  --U-    2  fsc 0x0000.0080e0f7
0x03   0x0000.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.00000000
Consistent read complete...
Block header dump:  0x01002506         --第二次读
Object id on Block? Y
seg/obj: 0x10c50  csc: 0x00.80e0c5  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1002500 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0013.009.0000043f  0x0340194c.03b9.41  C---    0  scn 0x0000.0080e0c2
0x02   0x000c.00a.00000385  0x03418aac.0264.4e  --U-    2  fsc 0x0000.0080e0f7
0x03   0x0000.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.00000000


[ 本帖最后由 sundog315 于 2010-6-28 10:12 编辑 ]

sundog315

还发现了一个问题
analyze table statistics可以分辨出inter-block chain和intra-block chain，对于inter会统计chain_cnt，而对于intra不统计chain_cnt。

而dbms_stats无论哪种，都不统计。

Yong Huang

> analyze table statistics可以分辨出inter-block chain和intra-block chain，对于inter会统计chain_cnt，而对于intra不统计chain_cnt。

Yes. I found that too. It indicates that your own test (table T) is NOT an intra-block chained table, but inter-block chained, while T-256 is.

I'm not sure why you do the test in message #16. As I said, sqlplus may give you an extra read. Try Java or Perl, or read more blocks to minimize this interference of sqlplus.

Yong Huang

wei-xh

学习了，好贴。

sundog315

其实为什么我用10202来做测试，是因为对于普通的没有intra-block chain的表，统计的值是正确的。

C:\Users\Administrator>sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 星期四 7月 1 19:23:11 2010

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

SQL> conn test/test
已连接。
SQL> create table t as select * from dba_objects where rownum=1;

表已创建。

SQL> select rowid from t;

ROWID
------------------
AAAQ03AAEAAAACDAAA

SQL> set autot trace exp stat
SQL> select * from t where rowid='AAAQ03AAEAAAACDAAA';


执行计划
----------------------------------------------------------
Plan hash value: 3207308387
-----------------------------------------------------------------------------------
| Id  | Operation                  | Name | Rows  | Bytes | Cost (%CPU)| Time  |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |      |     1 |   219 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY USER ROWID| T    |     1 |   219 |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------

统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          1  consistent gets
          0  physical reads
          0  redo size
       1390  bytes sent via SQL*Net to client
        415  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

Consistent read complete...
Block header dump:  0x01000083
Object id on Block? Y
seg/obj: 0x10d37  csc: 0x00.96266b  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1000080 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0xffff.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.0096266b
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000