這篇文章給大家介紹怎么分析db file sequential read，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

創(chuàng)新互聯(lián)建站服務(wù)項(xiàng)目包括金昌網(wǎng)站建設(shè)、金昌網(wǎng)站制作、金昌網(wǎng)頁(yè)制作以及金昌網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，金昌網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到金昌省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

db file sequential read

db file sequential read 事件有三個(gè)參數(shù):file#,first block#, block count, 在oracle 10g里,此等待事件在歸于 User I/O wait class 下面的. 處理db file sequential read 事件要牢牢把握下面三個(gè)主要思想:
1)oracle 進(jìn)程需要訪問(wèn)的block不能從SGA 中獲取,因此oracle 進(jìn)程會(huì)等待block從I/O讀到SGA
2)兩個(gè)重要參數(shù)TIME_WAITED,AVERAGE_WAIT,是以單個(gè)session獲取的
3)影響較大的db file sequential read 一般很像應(yīng)用程序問(wèn)題

Common Causes, Diagnosis, and Actions

db file sequential read 等待事件被SQL 語(yǔ)句初始化,主要從index,rollback(or undo) segments, tables(通過(guò)rowid訪問(wèn)表),control files 和data file headers中進(jìn)行single-block read.

訪問(wèn)數(shù)據(jù)對(duì)象(table,index)總是會(huì)產(chǎn)生Physical I/o需求,當(dāng)出現(xiàn)db file sequential read等待事件時(shí),并不意味著數(shù)據(jù)庫(kù)產(chǎn)生系統(tǒng)問(wèn)題,基至它大量出現(xiàn)都不是一件壞事.真正要引起注意的是像enqueue 和latch free等待事件,它們總是引起系統(tǒng)性題的根源.并且它們使single-block(單塊讀取)變得因難了.

那么什么情況下, 當(dāng)出現(xiàn)db file sequential read等待事件,才可以視為性能問(wèn)題呢?
什么情況下,db file sequential read可以視為系統(tǒng)的超額負(fù)擔(dān),并且基準(zhǔn)線應(yīng)該怎樣去定義?
這是一個(gè)比較復(fù)雜的問(wèn)題.在沒(méi)有工業(yè)標(biāo)準(zhǔn)指引的情況下.我們要依據(jù)數(shù)據(jù)庫(kù)運(yùn)行環(huán)境來(lái)制定標(biāo)準(zhǔn)線.
比如,我們定義超過(guò)多少時(shí)間的db file sequential read等待事件,可以視為性能問(wèn)題,還可以用最原始的方法,那就是等待用戶抱怨.

在V$SESSION_EVENT視圖中,db file sequential read的高TIME_WAITED是較為容易發(fā)現(xiàn)的,當(dāng)時(shí)因?yàn)閂$SESSION_EVENT是記錄從實(shí)例啟動(dòng)以來(lái)的數(shù)據(jù),所以我們同以前的TIME_WAITED進(jìn)行比較,當(dāng)然跟同一個(gè)session,同一個(gè)LOGON_TIME的非空閑事件進(jìn)行比較是可以的,也是比較準(zhǔn)確的.當(dāng)實(shí)例不間斷運(yùn)行很長(zhǎng)一段時(shí)間(數(shù)天或數(shù)星期)之后,TIME_WAITED的累計(jì)值就會(huì)很高,這當(dāng)然不能說(shuō)是性能問(wèn)題.

select a.sid,
a.event,
a.time_waited,
a.time_waited / c.sum_time_waited * 100 pct_wait_time,
round((sysdate - b.logon_time) * 24) hours_connected
from v$session_event a, v$session b,
(select sid, sum(time_waited) sum_time_waited
from v$session_event
where event not in (
'Null event',
'client message',
'KXFX: Execution Message Dequeue - Slave',
'PX Deq: Execution Msg',
'KXFQ: kxfqdeq - normal deqeue',
'PX Deq: Table Q Normal',
'Wait for credit - send blocked',
'PX Deq Credit: send blkd',
'Wait for credit - need buffer to send',
'PX Deq Credit: need buffer',
'Wait for credit - free buffer',
'PX Deq Credit: free buffer',
'parallel query dequeue wait',
'PX Deque wait',
'Parallel Query Idle Wait - Slaves',
'PX Idle Wait',
'slave wait',
'dispatcher timer',
'virtual circuit status',
'pipe get',
'rdbms ipc message',
'rdbms ipc reply',
'pmon timer',
'smon timer',
'PL/SQL lock timer',
'SQL*Net message from client',
'WMON goes to sleep')
having sum(time_waited) > 0 group by sid) c
where a.sid = b.sid
and a.sid = c.sid
and a.time_waited > 0
and a.event = 'db file sequential read'
order by hours_connected desc, pct_wait_time;
(本條語(yǔ)句來(lái)源于OWI 材料,但是本SQL語(yǔ)句計(jì)算的結(jié)果是不精確的,因?yàn)閟ession sid是時(shí)時(shí)改變的)

減少db file sequential read 等待事件,我們可以從兩方面入手:
1)第一條當(dāng)然是優(yōu)化SQL語(yǔ)句,以減少物理讀和邏輯讀
2)第二條是從統(tǒng)計(jì)上減少平均等待時(shí)間(比如優(yōu)化最高wait_time的等待事件)
備注:特別是給客戶看結(jié)果時(shí)效果最明顯,因?yàn)閳D形給人的感觀是比較明顯的

相對(duì)每一條來(lái)說(shuō),除非用你10046事件或自己做一個(gè)不間斷等待事件程序,不然是非常難以鎖定哪一條SQL引起長(zhǎng)時(shí)間的wait_time.退一步講,當(dāng)前的SQL也不一定就是引起wait_time的原因.所以我們發(fā)現(xiàn)要解決等待事件的問(wèn)題沒(méi)有歷史數(shù)據(jù)是很困難的.

你也可以通過(guò)查詢V$SQL視圖獲取平均DISK_READS,當(dāng)然我們不能就認(rèn)為此SQL就屬于某個(gè)SESSION,所以下次對(duì)session進(jìn)行trace,一般可以定位SQL,然后優(yōu)化SQL以減少物理讀與邏輯讀.

備注:除了DISK_READS之外,oracle 10g為V$SQL 和V$SQLAREA視圖增加了一些另人興奮不己的新列:
USER_IO_WAIT_TIME
DIRECT_WRITES
APPLICATION_WAIT_TIME
CONCURRENCY_WAIT_TIME
CLUSTER_WAIT_TIME
PLSQL_EXEC_TIME
JAVA_EXEC_TIME
當(dāng)然我們通過(guò)高累計(jì)的USER_IO_WAIT_TIME去定位SQL是可能的,但V$SQL和V$SQLAREA兩個(gè)視圖的訪問(wèn)速度是較慢的.
另外可以減少db file sequential read等待事件影響的方法是減少AVERAGE_WAIT ,AVERAGE_WAIT列是一個(gè)session等待single block被從硬盤(pán)獲取的平均等待時(shí)間(英文好讀,中文有點(diǎn)扭,主要我的水平不夠)
This is the average time a session has to wait for a single block fetch from disk(英文原句).AVERAGE_TIME是V$SESSION_EVENT視圖中的列.在高速的存儲(chǔ)系統(tǒng)中,平均的single-block讀不能夠超過(guò)10ms(milliseconds,千分之一秒) 或1cs(centiseconds,百分之一秒).一般的情況下,SAN(storage area network,網(wǎng)絡(luò)存儲(chǔ))的AVERAGE_TIME平均等待事間在4至8ms之間,因?yàn)镾AN的cache都較大.
AVERAGE_TIME的值越大,single-block讀的系統(tǒng)資源開(kāi)耗也隨之增大,也即進(jìn)程的響應(yīng)時(shí)間會(huì)受到影響.

從另外一個(gè)方面來(lái)講,較低的AVERAGE_TIME值反應(yīng)進(jìn)程等待single-block讀的時(shí)間會(huì)較短.當(dāng)然
AVERAGE_TIME調(diào)優(yōu)的優(yōu)先級(jí)遠(yuǎn)沒(méi)有SQL優(yōu)化的優(yōu)先級(jí)高,因?yàn)閮?yōu)化一個(gè)占用大量資源的SQL的效果是非常明顯和有效的.

需要注意的db file sequential read 并不總是對(duì)index對(duì)像進(jìn)行資源占用,有時(shí)也會(huì)對(duì)table/partition對(duì)像進(jìn)行資源占用.所以我們需要將P1/P2參數(shù)的值進(jìn)行轉(zhuǎn)換,在此我們會(huì)用到視圖DBA_EXTENTS以獲取對(duì)像名.
但是DBA_EXTENTS是一個(gè)復(fù)雜的,響應(yīng)極慢的視圖.要想用快一點(diǎn)的方法,X$和DBA_OBJECTS將是一個(gè)更好的選擇.因?yàn)閄$BH不占用BUFFER_CACHE所以,訪問(wèn)X$BH會(huì)有I/O產(chǎn)生,還有就是DBA-OBJECTS視圖不包括rollback 和undo 段,所以如果db file sequential read訪問(wèn)這兩個(gè)對(duì)象,也是不能被解析的.
查詢的例子:

select b.sid,
       nvl(substr(a.object_name,1,30),
                  'P1='||b.p1||' P2='||b.p2||' P3='||b.p3) object_name,
       a.subobject_name,
       a.object_type
from   dba_objects a, v$session_wait b, x$bh c
where  c.obj = a.object_id(+)
and    b.p1 = c.file#(+)
and    b.p2 = c.dbablk(+)
and    b.event = 'db file sequential read'
union
select b.sid,
       nvl(substr(a.object_name,1,30),
                  'P1='||b.p1||' P2='||b.p2||' P3='||b.p3) object_name,
       a.subobject_name,
       a.object_type
from   dba_objects a, v$session_wait b, x$bh c
where  c.obj = a.data_object_id(+)
and    b.p1 = c.file#(+)
and    b.p2 = c.dbablk(+)
and    b.event = 'db file sequential read'
order  by 1;

  SID OBJECT_NAME               SUBOBJECT_NAME            OBJECT_TYPE
----- ------------------------- ------------------------- -----------------
   12 DVC_TRX_REPOS             DVC_TRX_REPOS_PR64        TABLE PARTITION
  128 DVC_TRX_REPOS             DVC_TRX_REPOS_PR61        TABLE PARTITION
  154 ERROR_QUEUE               ERROR_QUEUE_PR1           TABLE PARTITION
  192 DVC_TRX_REPOS_1IX         DVC_TRX_REPOS_20040416    INDEX PARTITION
  194 P1=22 P2=30801 P3=1
  322 P1=274 P2=142805 P3=1
  336 HOLD_Q1_LIST_PK                                     INDEX

像本例中的object_type,如果是table,要進(jìn)SQL進(jìn)行相應(yīng)的優(yōu)化.

Sequential Reads Against Indexes

db file sequential read 主要的問(wèn)題不是對(duì)index的訪問(wèn),而且超額的對(duì)錯(cuò)誤index的訪問(wèn).當(dāng)系統(tǒng)的
訪問(wèn)路徑發(fā)生更改時(shí),可能對(duì)效能慢的index進(jìn)行訪問(wèn),從而產(chǎn)生等待.當(dāng)然如果一個(gè)SQL執(zhí)行了大量的index讀
這也可能是一個(gè)性能問(wèn)題.所以分析SQL的執(zhí)行計(jì)劃是一個(gè)比較好的方法,當(dāng)要用FULL TABLE SCAN時(shí),用index
就會(huì)產(chǎn)生性能問(wèn)題.還有就是FIRST_ROWS 和ALL_ROWS的問(wèn)題,當(dāng)然從大的方面講OLTP與DSS的混用也會(huì)產(chǎn)生不
合時(shí)適的db file sequential read.還有關(guān)于驅(qū)動(dòng)表(driving table)的問(wèn)題.不對(duì)的驅(qū)動(dòng)表,性能也不會(huì)好.

記住,所有的努力的目的應(yīng)該是一樣的,那就是降低logical and physical I/Os

下面有個(gè)種方法:
1)分析SQL,弄清SQL的邏輯,看看SQL到底想獲取什么,然后優(yōu)化,甚至重寫(xiě)
2)將index放在快磁盤(pán)上,尤其不要放在RAID-5上,因?yàn)槁疟P(pán)導(dǎo)致高average time,然而I/O優(yōu)化的優(yōu)先級(jí)
  不可以高于SQL CODE的優(yōu)化.因?yàn)镾QL有問(wèn)題再快的磁盤(pán)的也不行,最好用OUTLINE穩(wěn)固執(zhí)計(jì)計(jì)劃,尤其是第三方軟件
3)關(guān)于index表,最好將數(shù)據(jù)進(jìn)行排列,以減少I(mǎi)/O.可以通過(guò)DBA_INDEXS.CLUSTERING_FACTOR來(lái)查看index有沒(méi)有達(dá)到
  表的所有塊的數(shù)量,如有是,說(shuō)明大部份列是排列的,如是不是,表時(shí)表是隨機(jī)排列的.這時(shí)可以通過(guò)重組表以解決問(wèn)題.
4)看看表最近沒(méi)有沒(méi)建立新的index,使SQL的執(zhí)行計(jì)劃發(fā)生改變.(下面的語(yǔ)句可以查看到)
  看看有沒(méi)有invalid的index.

select owner, 
       substr(object_name,1,30) object_name, 
       object_type, 
       created
   from   dba_objects
   where  object_type in ('INDEX','INDEX PARTITION')
   order by created;

5)OPTIMIZER_INDEX_COST_ADJ 和OPTIMIZER_INDEX_CACHING

(來(lái)源于網(wǎng)上)其次，由于測(cè)試環(huán)境的不同，Tom的測(cè)試結(jié)果是在缺省值（100）的環(huán)境下，
就已經(jīng)和上面取值500時(shí)一樣了，即對(duì)T2全表掃描而T1使用索引。Tom試驗(yàn)中，減小取值直至0，
訪問(wèn)路徑就變成使用兩個(gè)索引，而并不會(huì)出現(xiàn)均不使用索引的情況。除去系統(tǒng)的不同
（可能導(dǎo)致取缺省值時(shí)訪問(wèn)路徑是否一致），只看變化趨勢(shì)，顯然10g中靈活性更高
，1-10000的取值使得CBO可以覆蓋所有的訪問(wèn)路徑。另一方面，正如Tom的結(jié)論所說(shuō)，
OPTIMIZER_INDEX_COST_ADJ的取值越大，優(yōu)化器越傾向于使用全表掃描，取值越小，
優(yōu)化器越傾向于使用索引。
                 再次，我們對(duì)比相同訪問(wèn)路徑下的不同點(diǎn)。在取值從1變化到200（1-50-100-200）
的過(guò)程中，優(yōu)化器計(jì)算出的代價(jià)是持續(xù)增長(zhǎng)的，而從1000到10000則是不變的。
這說(shuō)明這個(gè)參數(shù)與索引I/O的代價(jià)有關(guān)，而和全表掃描并無(wú)關(guān)系，這與Tom所說(shuō)的并不矛盾，
不過(guò)顯然更精確一點(diǎn)。
                 最后我們其實(shí)應(yīng)該看到，雖然有如上所說(shuō)的代價(jià)變化問(wèn)題，
同一訪問(wèn)路徑下實(shí)際的運(yùn)行性能并無(wú)區(qū)別，由于數(shù)據(jù)量比較小，上面的例子也許不能很好的說(shuō)明這一點(diǎn)，
不過(guò)想想Oracle用相同的路徑去執(zhí)行，也沒(méi)有理由不同性能吧。
              OPTIMIZER_INDEX_CACHING值為0,值越大,系統(tǒng)越tendence去用nested loops .
Find out what values the sessions are running with. Up to Oracle9 Database,
 this information could only be obtained by tracing the sessions with the trace 
event 10053 at level 1 and examining the trace files. In Oracle Database 10, 
this is as simple as querying the V$SES_OPTIMIZER_ENV view.
可以通過(guò)10053事件查看SESSION相應(yīng)的OPTIMIZER_INDEX_COST_ADJ 和OPTIMIZER_INDEX_CACHING值是多少,
在10g中省不了事,直接查V$SES_OPTIMIZER_ENV視圖就可以了,下面的是例子:

select * FROM V$SES_OPTIMIZER_ENV  WHERE NAME=LOWER('OPTIMIZER_INDEX_COST_ADJ') or 
                                         name=lower('OPTIMIZER_INDEX_CACHING');

SID   ID    NAME                       ISDEFAULT  VALUE
--------------------------------------------------------
144   67    optimizer_index_caching    YES        0
145   66    optimizer_index_cost_adj   YES        100
145   67    optimizer_index_caching    YES        0

因?yàn)閛racle的optimizer依賴于表與索引的statistics,所以要確保現(xiàn)在的statistics能夠代表現(xiàn)有數(shù)據(jù),
不正確的statistics會(huì)讓optimizer 產(chǎn)生低效的執(zhí)行計(jì)劃,當(dāng)然statistics也不必天天更新,因?yàn)檫@樣的話,
執(zhí)行計(jì)劃就也會(huì)天天更新,這對(duì)性能問(wèn)題的分析會(huì)產(chǎn)生干擾

System-Level Diagnosis

V$SYSTEM_EVENT視圖為系統(tǒng)級(jí)別的診斷提供數(shù)據(jù),基中AVERAGE_TIME和TIME_WAITED與I/O相關(guān)事件關(guān)聯(lián)
記住TIME_WAITED只是記錄自實(shí)例啟動(dòng)以來(lái)的記錄,當(dāng)實(shí)例運(yùn)行比較長(zhǎng)的一段時(shí)間后,db file sequential read 
通常較高.當(dāng)然,經(jīng)常查詢V$SYSTEM_EVENT并且以TIME_WAITED排序,能夠通過(guò)相互比較而找到比較明顯的等待事件.
當(dāng)db file sequential read 不位于top five時(shí),不要擔(dān)心,因?yàn)榭赡苡懈蟮膯?wèn)題要去發(fā)現(xiàn)
當(dāng)db file sequential read 位于top five時(shí),也總能說(shuō)明數(shù)據(jù)庫(kù)進(jìn)行了大量的single-block讀.
這里可以看系統(tǒng)級(jí)別的診斷能力是非常受限的.但事件總是兩面情,這里卻可以看系統(tǒng)硬件上瓶頸
這在v$session_wait事件里可是看不到的.當(dāng)你想升級(jí)系統(tǒng),可是你的直接上司要求你提供系統(tǒng)瓶頸報(bào)告時(shí),
下面就是那個(gè)好辦法:

select a.event, 
       a.total_waits, 
       a.time_waited, 
       a.time_waited/a.total_waits average_wait,  這里的average_wait是很用的
       sysdate – b.startup_time days_old
from   v$system_event a, v$instance b
order by a.time_waited;  
當(dāng)average single-block讀超過(guò)你所定的閥門(mén)的時(shí)候,你要看看I/O子系統(tǒng)是不是得到優(yōu)化了.
當(dāng)然用操作系統(tǒng)的I/O控制命令(iostat,vmstat)去監(jiān)控硬盤(pán),可以發(fā)現(xiàn)I/O的瓶頸,
可以去評(píng)估各I/O子系統(tǒng)之間是不是平衡.
Device:                  tps         Blk_read/s         Blk_wrtn/s         Blk_read         Blk_wrtn
dev8-0                  3.93              17.03              34.66         54592552  111099454
dev8-1                 12.08              56.68              99.93  181659920  320286944
dev8-2                 23.38             194.11             189.93  622154550  608747464
dev8-3                 16.00             230.43             128.04  738570544  410383416
dev8-4                  4.73              59.89              80.98  191965458  259557752
通過(guò)上例,可以看到dev8-2,dev8-3的塊讀寫(xiě)是遠(yuǎn)遠(yuǎn)超過(guò)其它的,所以可以考慮平衡一下I/O

另外,除了從V$SYSTEM_EVENT視圖中進(jìn)行系統(tǒng)級(jí)別的db file sequential read average wait之外,
oracle也提供了另外一個(gè)視圖v$filestat來(lái)獲取single-block讀的統(tǒng)計(jì)數(shù)據(jù).

select a.file#, 
       b.file_name, 
       a.singleblkrds, 
       a.singleblkrdtim, 
       a.singleblkrdtim/a.singleblkrds average_wait
from   v$filestat a, dba_data_files b 
where  a.file# = b.file_id   
and    a.singleblkrds > 0
order by average_wait;


FILE# FILE_NAME                     SINGLEBLKRDS SINGLEBLKRDTIM AVERAGE_WAIT
----- ----------------------------- ------------ -------------- ------------ 
  367 /dev/vgEMCp113/rPOM1P_4G_039          5578            427   .076550735
  368 /dev/vgEMCp113/rPOM1P_4G_040          5025            416    .08278607
  369 /dev/vgEMCp113/rPOM1P_4G_041         13793           1313   .095193214
  370 /dev/vgEMCp113/rPOM1P_4G_042          6232            625   .100288832
  371 /dev/vgEMCp113/rPOM1P_4G_043          4663            482   .103366931
  372 /dev/vgEMCp108/rPOM1P_8G_011        164828         102798   .623668309
  373 /dev/vgEMCp108/rPOM1P_8G_012        193071         125573    .65039804
  374 /dev/vgEMCp108/rPOM1P_8G_013        184799         126720   .685717996
  375 /dev/vgEMCp108/rPOM1P_8G_014        175565         125969   .717506337

其中SINGLEBLKRDTIM是centiseconds

關(guān)于怎么分析db file sequential read就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

文章名稱：怎么分析dbfilesequentialread
文章轉(zhuǎn)載：http://www.ekvhdxd.cn/article16/psgcgg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、Google、網(wǎng)站導(dǎo)航、網(wǎng)站設(shè)計(jì)公司、網(wǎng)站制作、關(guān)鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)