Rich Niemiec 先生趁这次上海OOW的机会，在中国巡游。安排了到杭州我们公司做一堂课，选择了oracle internals at the block level ！ 可能是听说我们公司dba在国内算是领先的，所以选择了这个题材，这也是在国内唯一一处地方讲了这个内容。

其实内容基本上我还是比较清楚的，只可惜总是觉得要想和他深入沟通难度太大，也怪自己口语不行了。后来课完之后一起吃午饭，单独做了一些交流。

优秀数据库工程师评选，IT168 网络采访

1 我注意到您发在itpub论坛上的招聘广告了，您觉得目前在国内，招聘一个满足阿里巴巴这样的大型电子商务网站应用的数据库的DBA是否容易？为什么？

2 您心目中理想的DBA应该具备哪些技能？

3 您觉得造成目前中国合格数据库人才缺乏的原因有哪些？

4 您为何选择到专业论坛（itpub）发招聘帖子的方式来招揽人才？

5 据了解，目前中国从事数据库开发、管理的人才（包括开发人员）大约有20万，其中
专职的DBA，您估计目前中国有多少？

优秀数据库工程师评选，赛迪网络采访

1、你认为国内数据库应用水平与人才状况如何？

2、结合你的工作与项目经历，请谈谈数据库工程师在应用上面对的难点。

3、要解决这些应用难点，工程师的个人经验能起到哪些作用？数据库技术发展能起到
什么作用？

4、您认为“2006年中国首届杰出数据库工程师评选”活动的意义？

新系统IBM P590,AIX5.3,8 cpus /16G 内存，为了同时兼顾IO压力，我特地把 buffer cache 只给了1G大小。模拟应用的sql调用，用5台2 cpus的linux机器并发16*5 个线程同时循环跑一个client无IO的模拟应用的随机用户登陆流程(这个期间会运行一系列的sql)。linux机器上开16个线程同时跑的时候load 已经在2左右。而IBM服务器上cpu  idle 2%,IO 为 read  40MB/S,write  8MB/S ，网络 IN  12MB/S  ,  out  6MB/S。run queue (load)为 50。

在statspack采样数据load  profile 为

STATSPACK report for

DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
OCNDB 3701801852 ocndb 1 9.2.0.6.0 NO ocndb1

Snap Id Snap Time Sessions Curs/Sess Comment
--------- ------------------ -------- --------- -------------------
Begin Snap: 104 19-May-05 17:27:53 91 27.3
End Snap: 105 19-May-05 17:57:54 91 27.8
Elapsed: 30.02 (mins)

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 1,024M Std Block Size: 8K
Shared Pool Size: 512M Log Buffer: 2,048K

Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 344,880.30 555.47
Logical reads: 198,459.35 319.64
Block changes: 2,494.51 4.02
Physical reads: 5,105.48 8.22
Physical writes: 48.74 0.08
User calls: 84,336.12 135.83
Parses: 6,208.79 10.00
Hard parses: 0.03 0.00
Sorts: 1,242.01 2.00
Logons: 0.00 0.00
Executes: 19,867.03 32.00
Transactions: 620.88

% Blocks changed per Read: 1.26 Recursive Call %: 26.51
Rollback per transaction %: 0.00 Rows per Sort: 23.61

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.30 Redo NoWait %: 100.00
Buffer Hit %: 97.43 In-memory Sort %: 100.00
Library Hit %: 100.02 Soft Parse %: 100.00
Execute to Parse %: 68.75 Latch Hit %: 99.32
Parse CPU to Parse Elapsd %: 34.12 % Non-Parse CPU: 96.74

Shared Pool Statistics Begin End
------ ------
Memory Usage %: 20.97 21.15
% SQL with executions>1: 83.85 83.54
% Memory for SQL w/exec>1: 88.18 85.88

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 8,558 52.19
db file sequential read 9,194,762 4,730 28.84
buffer busy waits 2,500,799 1,639 10.00
log file sync 1,076,173 771 4.70
latch free 174,822 588 3.58
-------------------------------------------------------------

看起来系统还是蛮强的，executions 为 19867次/S ,620个事务/S……

我们通常希望把oracle sga锁定在内存中，并且使文件系统缓存比例控制到一定范围，在AIX5.3之前版本，一般是使用vmtune -p 5 -P 20 -S 1

而在AIX5.3中则使用

 vmo   -r -o v_pinshm=1
 vmo -o minperm%=5
 vmo -o maxclient%=20
 vmo -o  maxperm%=20

重新启动生效的参数记录在 /etc/tunables/nextboot 文件中，通过 vmo -L 可以查看相关系列参数。

rootvg 中原来mirror的是 hdisk0 和 hdisk1，由于这两块磁盘是同一个BUS上的，我想换另外一个BUS上的磁盘，用hdisk4替换掉hdisk1

root用户执行：

extend rootvg hdisk4
migratepv -l  hd5  hdisk1 hdisk4
bosboot -ad  /dev/hdisk4
chpv -c  hdisk1
bootlist -m  nornal  hdisk0 hdisk4

sysdumpdev -p /dev/sysdumpnull
migratepv hdisk1 hdisk4
sysdumpdev -p /dev/hd6

reducevg rootvg hdisk1

shutdown -Fr

参考

http://www.cnoug.org/viewthread.php?tid=52545

有人问：

看ixora 中的文件。

上面說 在控制文件中除第一個 section 外﹐每個 邏輯塊都是兩個物理塊來表示.一個是當前的信息﹐另一個是舊的 copy 版本或未提交的信息.

因為 發生 controlfile transactions 時﹐這個 session 會有一個exclusive lock on the CF enqueue ﹐所以這個時候是不會允許任何操作﹐即使讀也不允許。

所以我有疑惑﹐因為一旦發生 Controlfile Transactions ﹐整個 contrfolfike 就會被 lock ﹐即對 全部 session 來說﹐要么能訪問﹐要么不能用.那么 用兩個 物理塊來作 recovery 的功能是不是就沒有必要了﹐隊非在 Controlfile Transactions 期間發生 system /instance 錯誤﹐或 hot backup。才有可能用到。不過文檔中又有說到當一個session 來讀 controlfile 時﹐它會首先去訪問 block version bitmap 以取得正確的塊版本﹐這說明應有其它情況存在.....

另有一個問題﹐因為在發生改變邏輯塊時﹐它會先更新一個物理的塊﹐那么這個邏輯塊所對應另一個物理塊什么時候更新﹐在這個 Controlfile Transactions 提交的時候嗎﹖好像不像﹐﹔因為它允許其中一個塊包括以前舊的拷貝。

今天有人在论坛上问起，顺便也说说我的看法。

一方面技术类的书籍，时效性比较高，生命中期不太长。通常出版的书册数不会太多。如果一个工薪族技术类高手要出一本书，出版商所出的价格，可能还不如其月薪，而写一本书，却是需要长达几个月的心血。首先在这个环节上，就降低了技术类高手出书的可能性，倾心血觉得不值得，不倾心血呢觉得没意思，技术类书籍出书目前只是一个短期效益而不是长期效益。因为工薪族，长期潜心技术的人相对是比较少的，国内环境下技术人才得到重视的不多，都琢磨着做别的呢。

以oracle技术方面的书籍为例，欧洲和美国出的非常经典书籍相对数量比较多一些，但是绝对数量恐怕也就在10来本左右。而这些书的作者，几乎都是早年在oracle工作了多年，潜心研究过oracle，不少人离开oracle公司之后，就是靠这方面的技能开公司做服务或者做个人服务。他们一直关注着相关的技术，并且把自己的经验很好的整理了下来，通过几年甚至十多年的积累，才出了一本书。这些人在internet上往往也非常活跃，出书既是他们经验的总结，也能给他们带来不错的经济和名声收益，为此同时还给他们带来更多的做服务的机会。

我想国内IT可能还需要进一步发展，等到IT类的服务更专业更成熟以后，使得潜心研究技术的人能通过长期的研究获得更多的回报，出书只是他们多年经验的汇集，他们不需要为月薪所累，可以通过出书、培训、服务等等方式挣钱，这个时候，应该就可以看到好书了。

10G 前数据库跨平台迁移非常的麻烦，为此我曾经思考过其他方案，但一直没有测试。最近有人提到这个问题，做一些探讨。

 查看全文

DB 与OS 之间，设计思想异曲同工，理解了，也不那么神秘了。

小case，随笔记录下，或许有些人有用。

由于显示问题，请参考

http://blog.csdn.net/biti_rainy/archive/2004/07/03/learn_oracle_20040703_6.aspx

也许对于普通大众来说，对于股票，可能具体地并不是很清楚，我也不是专家，但就我个人的认知，我来谈谈我为什么不想买股票。

今天销售报告crm系统bug：翻页显示中有少量记录是重复的。检查sql发现写法没什么问题，于是我进一步进行检查。

当要求汉字进行模糊匹配的时候，由于oracle是采用存储的字节流进行查找的，所以有存在着一个汉字的后半截和另一个汉字的前半截拼起来正好构成某个汉字。这样则存在着模糊匹配出现错误的可能性。碰巧，今天我在生产数据库应用中遭遇了好几个。

'db file sequential read' ----- 表达的含义是 一次 IO 的 block 存放在一段连续的内存上，当然，1个block自然是连续内存,而2个以上 block 基本都是离散的内存,但是oracle从来没有说 2个以上的 block 一定是不相临的内存，只不过几乎等价于不相临的内存，这就是 'db file scattered read'。

clustering_factor 是表征表中数据的存储顺序和某索引字段顺序的符合程度。

oralce的内部事务计时机制是有问题的，v$transaction.start_time(事务开始时间) 以及 v$undostat.begin_time  都是数据库内部计时的。原先的设计方案是只有lgwr定期更新这个sga中的时间钟，结果由于其他相关人员在32处source code中也调用了类似操作，使得server process也能去更新这个时间，由于时间更新不存在latch机制使得这个时间可以走的飞快。

 查看全文

easyfree喜欢称oldwain为老斗，他们俩大抵是在我还不知道oracle是什么的时候就认识了吧。更巧的是两人居然是同年同月同日生的60年代的老革命。

 查看全文

今天早上一来，数据库load就比往常高了许多。想想数据库唯一的变化是昨天早上我曾经重新分析过数据库对象。

 查看全文

我们将要测试IO的工具介绍参考

http://www.textuality.com/bonnie/advice.html

接下来我在自己的pc(redhat linux AS2.1)上对比测试IO状况  ,AS3.0 是自动打开的

经常有人说count(1)比count(*)快。实际上是这样吗？不是的，作为数据库的衡量性能的逻辑读来说，是没有差异的。但是在实际的多次反复测试中，我们可以来对比看看真实状况。

先子查询再做表连接比较有利，也就是说子查询本身代价不大，并且过滤掉很多记录，产生一个很小的结果集再做表连接，比较有利。

一个出错的诊断过程

我们有时候会遇见这样的烦恼，在特定的时候总有某个大查询导致临时表空间出错。但我们总不能守侯着捕获相关sql以优化或者处理。可以通过events来诊断

在oracle中存在 dirty list(也就是write list)的说法，但是同时又有checkpoint queue 。这两个东西往往让人容易混淆。他们是同一个东西吗？之间关系如何？

阅读本文前请先阅读<<32bit oracle 扩展SGA原理>>

隐藏参数不过也保存在 x$ 中而已

简单的做了一个测试  

SQL> desc obj$
  名称                                     空?      类型
  ---------------------------------------- -------- ---------------------------
  OBJ#                                     NOT NULL NUMBER
  DATAOBJ#                                          NUMBER
  OWNER#                                   NOT NULL NUMBER
  NAME                                     NOT NULL VARCHAR2(30)
  NAMESPACE                                NOT NULL NUMBER
  SUBNAME                                           VARCHAR2(30)
  
FTS 的表
  
SELECT o.name FROM obj$ o,x$bh x  
WHERE x.obj=o.dataobj#
AND standard.bitand(x.flag,524288)>0  
AND o.owner# = 41;
  
SQL> SELECT o.name FROM obj$ o,x$bh x  
   2  WHERE x.obj=o.dataobj#
   3  AND standard.bitand(x.flag,524288)>0  
   4  AND o.owner# = 41;
NAME
------------------------------
T1
  
desc x$bh
  
SQL> desc x$bh
  名称                                     空?      类型
  ---------------------------------------- -------- ------------------
  ADDR                                              RAW(4)
  INDX                                              NUMBER
  INST_ID                                           NUMBER
  BUF#                                              NUMBER
  HLADDR                                            RAW(4)
  NXT_HASH                                          RAW(4)
  PRV_HASH                                          RAW(4)
  NXT_REPL                                          RAW(4)
  PRV_REPL                                          RAW(4)
  FLAG                                              NUMBER
  LRU_FLAG                                          NUMBER
  TS#                                               NUMBER
  FILE#                                             NUMBER
  DBARFIL                                           NUMBER
  DBABLK                                            NUMBER
  CLASS                                             NUMBER
  STATE                                             NUMBER
  MODE_HELD                                         NUMBER
  CHANGES                                           NUMBER
  CSTATE                                            NUMBER
  X_TO_NULL                                         NUMBER
  FORCED_READS                                      NUMBER
  FORCED_WRITES                                     NUMBER
  LE_ADDR                                           RAW(4)
  DIRTY_QUEUE                                       NUMBER
  SET_DS                                            RAW(4)
  OBJ                                               NUMBER
  BA                                                RAW(4)
  CR_SCN_BAS                                        NUMBER
  CR_SCN_WRP                                        NUMBER
  CR_XID_USN                                        NUMBER
  CR_XID_SLT                                        NUMBER
  CR_XID_SQN                                        NUMBER
  CR_UBA_FIL                                        NUMBER
  CR_UBA_BLK                                        NUMBER
  CR_UBA_SEQ                                        NUMBER
  CR_UBA_REC                                        NUMBER
  CR_SFL                                            NUMBER
  LRBA_SEQ                                          NUMBER
  LRBA_BNO                                          NUMBER
  HRBA_SEQ                                          NUMBER
  HRBA_BNO                                          NUMBER
  RRBA_SEQ                                          NUMBER
  RRBA_BNO                                          NUMBER
  US_NXT                                            RAW(4)
  US_PRV                                            RAW(4)
  WA_NXT                                            RAW(4)
  WA_PRV                                            RAW(4)
  TCH                                               NUMBER
  TIM                                               NUMBER
  
SQL>  

chao_ping:

        经过别的session Update之后,select 语句的buffer gets 会变大,这是可以理解的.
因为Oracle需要从别的Block里面得到他需要的Block的之前的映像。

但是,这里的这个参数就好像有点南里理解:
  
SQL> select * from t where object_id=100;
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 cc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=14 Bytes=          420)
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=2 Card=14 ytes
           =420)
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 rd=        14)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           4  consistent gets
           3  physical reads
           0  redo size
         424  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           1  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
另外开一个session, 把这个表全部都UPdate掉. 在这边再次select:  
  
SQL> /
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 cc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=14 Bytes=          420)
  
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=2 Card=14 Bytes          =420)
  
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=          14)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
         557  consistent gets
           0  physical reads
          52  redo size
         424  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
SQL> /
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 cc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=14 Bytes=          420)
  
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=2 Card=14 Bytes          =420)
  
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=          14)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           4  consistent gets
           0  physical reads
           0  redo size
         424  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
SQL> /
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 cc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=14 Bytes=          420)
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=2 Card=14 Bytes          =420)
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=          14)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           4  consistent gets
           0  physical reads
           0  redo size
         424  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
SQL> select count(*) from t;
  
   COUNT(*)
----------
       6996
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=1)
    1    0   SORT (AGGREGATE)
    2    1     TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=1307)
  
Statistics
----------------------------------------------------------
           0  recursive calls
          12  db block gets
          20  consistent gets
           0  physical reads
           0  redo size
         368  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           1  sorts (memory)
           0  sorts (disk)
           1  rows processed

这里如果update 只是很少记录的话,那么这边的consistent gets地数量也会小很多.
这个时可以理解的.
  
update 整个表,为什么检索这条记录,Buffer gets会增加这么多?
标被另外sesision update 之后:
SQL> /
  
   COUNT(*)
----------
       6996
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=1)
    1    0   SORT (AGGREGATE)
    2    1     TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=1307)
  
Statistics
----------------------------------------------------------
           0  recursive calls
          12  db block gets
        7033  consistent gets
           0  physical reads
         832  redo size
         368  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
那个session commit 之后:
SQL> /
  
   COUNT(*)
----------
       6996
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=1)
    1    0   SORT (AGGREGATE)
    2    1     TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=1307)
  
Statistics
----------------------------------------------------------
           0  recursive calls
          12  db block gets
          21  consistent gets
           0  physical reads
          60  redo size
         368  bytes sent via SQL*Net to client
         426  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed

但是，如果即使update 其他整个表（除了object_id=100)对应的记录所在地lock,

这个select 的成本还是不变
SQL> select * from t where object_id=100;
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 zc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=1 Card=1 Bytes=3
           0)
  
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=1 Card=1 Bytes=
           30)
  
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=
           1)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           4  consistent gets
           0  physical reads
           0  redo size
         436  bytes sent via SQL*Net to client
         504  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed
  
如果只是update 改记录所在地Block的某一个记录，那么buffer gets增加为2：

SQL> /
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 zc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=1 Card=1 Bytes=3
           0)
  
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=1 Card=1 Bytes=
           30)
  
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=
           1)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
           6  consistent gets
           0  physical reads
          52  redo size
         436  bytes sent via SQL*Net to client
         504  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed

如果update 了这个记录所在地Block的全部记录，那么consisteng gets 就会是何update 整个表所在地记录一样的结果：
SQL> update t set owner='c' where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)=17470 ;  
  
616 rows updated.
  
Execution Plan
----------------------------------------------------------
    0      UPDATE STATEMENT Optimizer=FIRST_ROWS (Cost=2 Card=1 Bytes=2
           4)
  
    1    0   UPDATE OF 'T'
    2    1     TABLE ACCESS (FULL) OF 'T' (Cost=2 Card=1 Bytes=24)
  
Statistics
----------------------------------------------------------
           0  recursive calls
         630  db block gets
          19  consistent gets
           0  physical reads
      150724  redo size
         624  bytes sent via SQL*Net to client
         576  bytes received via SQL*Net from client
           3  SQL*Net roundtrips to/from client
           1  sorts (memory)
           0  sorts (disk)
         616  rows processed
那么select 的成本：
SQL> /
  
  OBJECT_ID OWNER
---------- ------------------------------
        100 zc
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=1 Card=1 Bytes=3
           0)
  
    1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=1 Card=1 Bytes=
           30)
  
    2    1     INDEX (RANGE SCAN) OF 'IDX_T' (NON-UNIQUE) (Cost=1 Card=
           1)
  
Statistics
----------------------------------------------------------
           0  recursive calls
           0  db block gets
         622  consistent gets
           0  physical reads
          52  redo size
         436  bytes sent via SQL*Net to client
         504  bytes received via SQL*Net from client
           2  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
           1  rows processed

biti_rainy  回复： buffer gets?


因为 产生 consistent gets 的时候决定于  CR block 的生成 ,select count(*) from x$bh where state = 3; 这里的数量的变化代表着  CR block 重构的生成 ,对于oracle来说，若查询到一条记录，发现已经被更改，于是拷贝当前block到新的地方，从回滚段取回before image 再rollback而重构block，这样的block的 state 为3 ,对于block中每一条记录都会去重构一次( 发现被修改，拷贝到新的block(CR)，然后row--->ITL  --> transaction table ---> undo record  --->rollback新的blcok(CR)），所以跟一个块中的记录数有关。
  
      但这里要注意，虽然重构了很多CR，但是在我的曾经的测试中发现一次select中一个block的CR block似乎,不超过 3 blocks .也就是说同一个 DBA 的 cache  buffer chain 下的 CR 类型的blocks不超过3，我估计是为了节约内存和降低 该  latch(cache  buffer chain) 上由于搜索所等待的时间的一种策略。因为 CR block一旦产生后就没有用处了(实际上这个数是一个oracle隐藏参数控制的)

测试如下

SQL> create table test(a number);
  
Table created.
  
SQL> insert into test select rownum from t where rownum < 1001;
  
1000 rows created.
  
SQL> commit;
  
Commit complete.
  
SQL> select count(*) from t;
  
   COUNT(*)
----------
     154986
  
SQL> update test set a = 0 where a = 1;
  
1 row updated.
  
SQL> update test set a = 0 where a < 100;
  
99 rows updated.
  
SQL>  
  
通过打开不同的sqlplus反复执行下面的语句观察 后面 的 x$bh 查询表的变化
  
SQL>  select * from test where a < 101;
  
100 rows selected.
  
Execution Plan
----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=CHOOSE
    1    0   TABLE ACCESS (FULL) OF 'TEST'
  
Statistics
----------------------------------------------------------
           0  recursive calls
           4  db block gets
         110  consistent gets
           0  physical reads
          52  redo size
        2475  bytes sent via SQL*Net to client
        1091  bytes received via SQL*Net from client
           8  SQL*Net roundtrips to/from client
           0  sorts (memory)
           0  sorts (disk)
         100  rows processed
  
SQL>  
  
SQL> select ts#,file#,dbablk,state,obj from x$bh where state = 3 order by 1,2,3,4;
  
        TS#      FILE#     DBABLK      STATE        OBJ
---------- ---------- ---------- ---------- ----------
          0          1        133          3 4294967294
          0          1        925          3          6
          0          1        930          3          6
          0          1      11579          3         10
          0          1      11579          3         10
          0          1      27273          3         34
          0          1      33837          3          6
          0          1      34264          3          8
        &