對于實際的業務系統，通常有一些熱點的表，insert和delete的量非常大，這個時候就會發現一些查詢語句的邏輯讀比較偏高，

這時可能就是oracle在構建一致性塊的進行的consistent

read。

下面做一個測試看下：

第一步準備數據：

create tabletest(

col1varchar2(12)

col2numberextvarchar2(4000)

);create index test_ind on test(user_id, col2);create sequence seq_test cache 200;

這樣這樣的表，我們假設有頻繁的插入和刪除操作，那么下面來測試一下select的邏輯讀的情況。

開啟兩個session:

1，創建表保存snapshot

在session1：create table prefix_stats tablespace IW_ACCOUNT_LOG_01 as select * from v$sesstat where sid=&1;

2，在session2查詢

select * from (select * from test t where col1 = ‘xpchild001‘ order by trans_log_id) where rownum <= 200;

3，在session1監控session2的統計信息

select *

from (selectt.name,

pre.valueaspre,

suf.valueassuf,

(suf.value- pre.value) asdifffromprefix_stats pre, v$sesstat suf, v$statname twhere pre.sid =suf.sidand pre.STATISTIC# =suf.STATISTIC#and pre.STATISTIC# =t.STATISTIC#) tmpwhere tmp.diff > 0

order by tmp.diff descName PRE SUF DIFF---------------------------------------------------------------------- ---------- ---------- ----------

session pga memory max 957208 1153816 196608session pga memory957208 1153816 196608bytes sent via SQL*Net to client 6692 37013 30321redo size0 8256 8256session logical reads52 1508 1456consistent getsfrom cache 52 1508 1456consistent gets52 1508 1456bytes received via SQL*Net from client 4385 5639 1254consistent gets- examination 21 1253 1232data blocks consistent reads- undo records applied 0 920 920consistent changes0 920 920bufferis not pinned count 17 222 205

table fetch by rowid 6 206 200bufferis pinned count 0 197 197CR blocks created0 160 160callsto kcmgas 0 160 160db block changes0 120 120redo entries0 120 120cleanout- number of ktugct calls 0 120 120cleanoutsand rollbacks - consistent read gets 0 120 120immediate (CR) block cleanout applications0 120 120nowork - consistent read gets 19 83 64heap block compress0 51 51rollbacksonly - consistent read gets 0 40 40shared hash latch upgrades- no wait 0 5 5

user calls 28 33 5

execute count 21 23 2DB time0 2 2parsecount (total) 22 24 2sessioncursor cache count 16 17 1CPU usedwhen call started 0 1 1recursive calls92 93 1parsecount (hard) 0 1 1sessioncursor cache hits 4 5 1CPU usedby this session 0 1 1

這一次的查詢，返回記錄200條。table fetch by rowid=200;

1，邏輯讀session logical reads=consistent gets(一致讀)+db block

gets(當前讀);

這個sql只有一致性讀session logical reads=consistent gets=1456

2，構建一致性讀應用回滾記錄統計：data blocks consistent reads(undo records

applied)：920

等價于consistent changes。

3，需要回滾或者塊清除產生的一致性讀(這里邊沒有回滾，只可能有塊清除)cleanouts and rollbacks - consistent read

gets：120

跟db block changes=120一致，這里進行了塊清楚，從而改變了db block。

4，構建一致性讀clone的塊數：CR blocks created=160

5，塊清除產生的redo：redo size 8256

驗證了開始的猜測：大量的構建一致性讀。

對于這樣的熱點表，通常有幾種手動去調整，但核心都是要分散熱點，減少爭用。

hash表，分散熱點

調整pctfree，增加pctfred的大小。使用塊中的記錄數變少，減少構建一致性讀的問題。

未完待續。。。

原文：http://www.cnblogs.com/xpchild/p/3694987.html

總結

以上是生活随笔為你收集整理的oracle consistent gets,oracle构建一致性读的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。