国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

編輯手記:對(duì)Oracle數(shù)據(jù)庫(kù)進(jìn)行調(diào)整優(yōu)化，基本上最終都可以歸結(jié)到I/O調(diào)整上，因此，了解如何來優(yōu)化Oracle數(shù)據(jù)庫(kù)的I/O對(duì)于一個(gè)DBA來說就顯得至關(guān)重要。今天挑選此文與大家共勉。

Service Time是指'CPU used by this session'的統(tǒng)計(jì)時(shí)間。Wait Time是指所有消耗在等待事件上的總的時(shí)間。

因?yàn)榈却录泻芏?，因此我們還需要去判定哪些是真的很重要的等待事件，很多調(diào)優(yōu)工具比如說statpack都是列出最重要的等待事件，statpack工具的報(bào)告中的重要的等待事件都是包含在一個(gè)叫Top 5 Wait Events的部分中。在某些情況下， Service Time會(huì)比Wait Time顯得更加重要(例如CPU使用率),此時(shí)等待事件產(chǎn)生的影響就顯得不是那么重要了，重點(diǎn)調(diào)整的目標(biāo)應(yīng)該放在Service Time上。因此，我們應(yīng)該先比較在Top 5 Wait Events部分中的'CPU used by this session'所占用的時(shí)間，然后直接調(diào)整最消耗時(shí)間的等待事件。在Oracle9i的release2的版本以后，Top 5 Wait Events部分變成了Top 5 Timed Events，Service Time也由'CPU used by this session'變成了'CPU time'來衡量，這也就意味著可以更加精確的判斷在響應(yīng)時(shí)間中的等待事件的影響，從而調(diào)整最需要優(yōu)化的部分。

下面舉一個(gè)例子來具體說明為什么在調(diào)整數(shù)據(jù)庫(kù)性能的時(shí)候必須同時(shí)查看Service Time 和Wait Time，因?yàn)槿绻煌瑫r(shí)都查看這兩個(gè)方面，就往往容易走入調(diào)整的誤區(qū)。

上面是一個(gè)大約30分鐘的statpack收集的信息的Top 5 Wait Events部分，如果基于上面給出的列表，我們很容易發(fā)現(xiàn)direct path read的wait很高，并且會(huì)試圖去調(diào)整這個(gè)等待事件，但是這樣做就沒有考慮到Service Time。我們來看看在這個(gè)statpack中關(guān)于Service Time的統(tǒng)計(jì)：

讓我們來大致的計(jì)算一下響應(yīng)時(shí)間：

接著來計(jì)算一下響應(yīng)時(shí)間中各個(gè)部分的比例：

從上面的計(jì)算中我們可以明顯的看出來，I/O相關(guān)的等待事件所消耗的時(shí)間在整個(gè)響應(yīng)時(shí)間中占的比例并不大，只不過是很小的一部分，而相對(duì)來說Service Time所消耗的時(shí)間遠(yuǎn)遠(yuǎn)大于Wait Time，因此，應(yīng)該直接調(diào)整的是Service Time(CPU的使用率)而不是I/O相關(guān)的等待事件，因此，在調(diào)優(yōu)數(shù)據(jù)庫(kù)的時(shí)候要盡量的避免走入這種誤區(qū)。

接著來具體看看對(duì)于出現(xiàn)的I/O問題處理的一些方法。

如果數(shù)據(jù)庫(kù)的性能主要是被一些I/O相關(guān)的等待事件所限制住了，那么可以針對(duì)這種情況采用處理I/O問題的一些方法，下面對(duì)這些方法的一些概念和基本原理進(jìn)行簡(jiǎn)單的闡述說明。

方法一：優(yōu)化Oracle數(shù)據(jù)庫(kù)的SQL語句來減少數(shù)據(jù)庫(kù)對(duì)I/O的需求

如果數(shù)據(jù)庫(kù)沒有任何用戶的SQL運(yùn)行的話，一般來說只會(huì)產(chǎn)生很少的磁盤I/O或者幾乎沒有磁盤I/O，基本上來說數(shù)據(jù)庫(kù)產(chǎn)生I/O的最終原因都是直接或者間接的由于用戶執(zhí)行SQL語句導(dǎo)致的。通過優(yōu)化SQL語句改變其執(zhí)行計(jì)劃以便讓其產(chǎn)生盡可能少的I/O。讓用戶執(zhí)行的SQL語句優(yōu)化產(chǎn)生比較好的執(zhí)行計(jì)劃來減少磁盤I/O是一種非常行之有效的方法。

方法二：調(diào)整實(shí)例的初始化參數(shù)來減少數(shù)據(jù)庫(kù)的I/O需求：

一般來說可以通過兩種途徑：

一種途徑是通過內(nèi)存緩存來減少I/O。可以通過使用一定數(shù)量的內(nèi)存緩存來減少物理I/O(例如高速緩存區(qū)、日志緩存區(qū)以及各種排序區(qū)等等)。

另外一種途徑是調(diào)整一次讀取多個(gè)BLOCK的大小。在配置數(shù)據(jù)庫(kù)初始化參數(shù)的時(shí)候，根據(jù)操作系統(tǒng)的I/O吞吐能力設(shè)置的一次讀取多個(gè)BLOCK的大小盡量多，以減少讀取I/O的次數(shù)。

方法三：在操作系統(tǒng)級(jí)別上優(yōu)化I/O：

在操作系統(tǒng)級(jí)別上優(yōu)化磁盤的I/O，以提高I/O的吞吐量，如果操作系統(tǒng)支持異步I/O，盡量去使用異步I/O；還可以使用高級(jí)文件系統(tǒng)的一些特性，例如直接I/O讀取，忽略掉操作系統(tǒng)的文件緩存，也就是我們平時(shí)所說的使用裸設(shè)備。還有一種可行的方法是增大每次傳輸?shù)淖畲驣/O大小的限制，以便每次能夠傳輸?shù)腎/O盡可能的大。

方法四：通過使用RAID、SAN、NAS來平衡數(shù)據(jù)庫(kù)的I/O：

因此，利用RAID、SAN、NAS的技術(shù)在多個(gè)物理磁盤之間平衡數(shù)據(jù)庫(kù)的I/O，盡量避免數(shù)據(jù)庫(kù)產(chǎn)生I/O競(jìng)爭(zhēng)的瓶頸。

方法五：手工分配數(shù)據(jù)文件到不同的文件系統(tǒng)、控制器和物理設(shè)備來重新調(diào)整數(shù)據(jù)庫(kù)I/O

需要注意的一點(diǎn)是對(duì)于大部分?jǐn)?shù)據(jù)庫(kù)來說，一些I/O是一直會(huì)存在的。如果上述的方法都嘗試過但是數(shù)據(jù)庫(kù)的I/O性能還是沒有達(dá)到預(yù)定的要求，可以嘗試刪除數(shù)據(jù)庫(kù)中一些不用的舊數(shù)據(jù)或者使用性能更好的硬件設(shè)施。

下面是總結(jié)的在Oracle數(shù)據(jù)庫(kù)中最經(jīng)常出現(xiàn)的一些I/O相關(guān)的等待事件：

數(shù)據(jù)文件I/O相關(guān)的等待事件：

控制文件I/O相關(guān)的等待事件：

重做日志文件I/O相關(guān)的等待事件：

高速緩存區(qū)I/O相關(guān)的等待事件：

下面來對(duì)這些I/O相關(guān)的等待事件進(jìn)行具體的說明和相應(yīng)的處理方法。

數(shù)據(jù)文件相關(guān)的I/O等待事件：

db file sequential read等待事件：

這個(gè)是非常常見的I/O相關(guān)的等待事件。在大多數(shù)的情況下讀取一個(gè)索引數(shù)據(jù)的BLOCK或者通過索引讀取數(shù)據(jù)的一個(gè)BLOCK的時(shí)候都會(huì)去要讀取相應(yīng)的數(shù)據(jù)文件頭的BLOCK。在早期的版本中會(huì)從磁盤中的排序段讀取多個(gè)BLOCK到高速緩存區(qū)的連續(xù)的緩存中。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表Oracle要讀取的文件的ABSOLUTE文件號(hào)，P2代表Oracle從這個(gè)文件中開始讀取的BLOCK號(hào)，P3代表Oracle從這個(gè)文件開始讀取的BLOCK號(hào)后讀取的BLOCK數(shù)量，通常這個(gè)值為1，表明是單個(gè)BLOCK被讀取，如果這個(gè)值大于1，則是讀取了多個(gè)BLOCK，這種多BLOCK讀取常常出現(xiàn)在早期的Oracle版本中從臨時(shí)段中讀取數(shù)據(jù)的時(shí)候。

如果這個(gè)等待事件在整個(gè)等待時(shí)間中占主要的部分，可以采用以下的幾種方法來調(diào)整數(shù)據(jù)庫(kù)。

方法一：從statpack的報(bào)告中的"SQL ordered by Reads"部分或者從V$SQL視圖中找出讀取物理磁盤I/O最多的幾個(gè)SQL語句，優(yōu)化這些SQL語句以減少對(duì)I/O的讀取需求。

如果有Index Range scans，但是卻使用了不該用的索引，就會(huì)導(dǎo)致訪問更多的BLOCK，這個(gè)時(shí)候應(yīng)該強(qiáng)迫使用一個(gè)可選擇的索引，使訪問同樣的數(shù)據(jù)盡可能的少的訪問索引塊，減少物理I/O的讀??；如果索引的碎片比較多，那么每個(gè)BLOCK存儲(chǔ)的索引數(shù)據(jù)就比較少，這樣需要訪問的BLOCK就多，這個(gè)時(shí)候一般來說最好把索引rebuild，減少索引的碎片；如果被使用的索引存在一個(gè)很大的Clustering Factor，那么對(duì)于每個(gè)索引BLOCK獲取相應(yīng)的記錄的時(shí)候就要訪問更多表的BLOCK，這個(gè)時(shí)候可以使用特殊的索引列排序來重建表的所有記錄，這樣可以大大的減少Clustering Factor，例如：一個(gè)表有A,B,C,D,E五個(gè)列，索引建立在A,C上，這樣可以使用如下語句來重建表：

CREATE TABLE TABLE_NAME AS SELECT * FROM old ORDER BY A,C;

此外，還可以通過使用分區(qū)索引來減少索引BLOCK和表BLOCK的讀取。

方法二：如果不存在有問題的執(zhí)行計(jì)劃導(dǎo)致讀取過多的物理I/O的特殊SQL語句，那么可能存在以下的情況：

數(shù)據(jù)文件所在的磁盤存在大量的活動(dòng)，導(dǎo)致其I/O性能很差。這種情況下可以通過查看Statpack報(bào)告中的"File I/O Statistics"部分或者V$FILESTAT視圖找出熱點(diǎn)的磁盤，然后將在這些磁盤上的數(shù)據(jù)文件移動(dòng)到那些使用了條帶集、RAID等能實(shí)現(xiàn)I/O負(fù)載均衡的磁盤上去。

使用如下的查詢語句可以得到各個(gè)數(shù)據(jù)文件的I/O分布：

從Oracle9.2.0開始，我們可以從V$SEGMENT_STATISTICS視圖中找出物理讀取最多的索引段或者是表段，通過查看這些數(shù)據(jù)，可以清楚詳細(xì)的看到這些段是否可以使用重建或者分區(qū)的方法來減少所使用的I/O。如果Statpack設(shè)置的level為7就會(huì)在報(bào)告中產(chǎn)生"Segment Statistics"的信息。

從上面的查詢可以看到相應(yīng)的統(tǒng)計(jì)名稱，使用下面的查詢語句就能得到讀取物理I/O最多的段：

方法三：如果不存在有問題的執(zhí)行計(jì)劃導(dǎo)致讀取過多的物理I/O的特殊SQL語句，磁盤的I/O也分布的很均勻，這種時(shí)候我們可以考慮增大的高速緩存區(qū)。

對(duì)于Oracle8i來說增大初始化參數(shù)DB_BLOCK_BUFFERS，讓Statpack中的Buffer Cache的命中率達(dá)到一個(gè)滿意值；對(duì)于Oracle9i來說則可以使用Buffer Cache Advisory工具來調(diào)整Buffer Cache；對(duì)于熱點(diǎn)的段可以使用多緩沖池，將熱點(diǎn)的索引和表放入到KEEP Buffer Pool中去，盡量讓其在緩沖中被讀取，減少I/O。

db file scattered read等待事件

這個(gè)也是一個(gè)非常常見的等待事件。當(dāng)Oracle從磁盤上讀取多個(gè)BLOCK到不連續(xù)的高速緩存區(qū)的緩存中就會(huì)發(fā)生這個(gè)等待事件，Oracle一次能夠讀取的最多的BLOCK數(shù)量是由初始化參數(shù)DB_FILE_MULTIBLOCK_READ_COUNT來決定，這個(gè)等待事件一般伴隨著全表掃描或者Fast Full Index掃描一起出現(xiàn)。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表Oracle要讀取的文件的ABSOLUTE文件號(hào)，P2代表Oracle從這個(gè)文件中開始讀取的BLOCK號(hào)，P3代表Oracle從這個(gè)文件開始讀取的BLOCK號(hào)后讀取的BLOCK數(shù)量。如果這個(gè)等待事件在整個(gè)等待時(shí)間中占了比較大的比重，可以如下的幾種方法來調(diào)整Oracle數(shù)據(jù)庫(kù)：

方法一：找出執(zhí)行全表掃描者Fast Full Index掃描的SQL語句，判斷這些掃描是否是必要的，是否導(dǎo)致了比較差的執(zhí)行計(jì)劃，如果是，則需要調(diào)整這些SQL語句。

從Oracle9i開始提供了一個(gè)視圖V$SQL_PLAN，可以很快的幫助找到那些全表掃描或者Fast Full Index掃描的SQL語句，這個(gè)視圖會(huì)自動(dòng)忽略掉關(guān)于數(shù)據(jù)字典的SQL語句。

查找全表掃描的SQL語句可以使用如下語句：

查找Fast Full Index掃描的SQL語句可以使用如下語句：

如果是Oracle8i的數(shù)據(jù)庫(kù)，可以從V$SESSION_EVENT視圖中找到關(guān)于這個(gè)等待事件的進(jìn)程sid，然后根據(jù)sid來跟蹤相應(yīng)的會(huì)話的SQL。

或者可以查看物理讀取最多的SQL語句的執(zhí)行計(jì)劃，看是否里面包含了全表掃描和Fast Full Index掃描。通過如下語句來查找物理讀取最多的SQL語句：

方法二：有時(shí)候在執(zhí)行計(jì)劃很好情況下也會(huì)出現(xiàn)多BLOCK掃描的情況，這時(shí)可以通過調(diào)整Oracle數(shù)據(jù)庫(kù)的多BLOCK的I/O，設(shè)置一個(gè)合理的Oracle初始化參數(shù)DB_FILE_MULTIBLOCK_READ_COUNT，盡量使得滿足以下的公式：

DB_BLOCK_SIZE x DB_FILE_MULTIBLOCK_READ_COUNT = max_io_size of system

DB_FILE_MULTIBLOCK_READ_COUNT是指在全表掃描中一次能夠讀取的最多的BLOCK數(shù)量，這個(gè)值受操作系統(tǒng)每次能夠讀寫最大的I/O限制，如果設(shè)置的值按照上面的公式計(jì)算超過了操作系統(tǒng)每次的最大讀寫能力，則會(huì)默認(rèn)為max_io_size/db_block_size。例如DB_FILE_MULTIBLOCK_READ_COUNT設(shè)置為32，DB_BLOCK_SIZE為8K，這樣每次全表掃描的時(shí)候能讀取256K的表數(shù)據(jù)，從而大大的提高了整體查詢的性能。設(shè)置這個(gè)參數(shù)也不是越大越好的，設(shè)置這個(gè)參數(shù)之前應(yīng)該要先了解應(yīng)用的類型，如果是OLTP類型的應(yīng)用，一般來說全表掃描較少，這個(gè)時(shí)候設(shè)定比較大的DB_FILE_MULTIBLOCK_READ_COUNT反而會(huì)降低Oracle數(shù)據(jù)庫(kù)的性能，因此CBO在某些情況下會(huì)因?yàn)槎郆LOCK讀取導(dǎo)致COST比較低從而錯(cuò)誤的選用全表掃描。

此外，還可以通過對(duì)表和索引使用分區(qū)、將緩存區(qū)的LRU末端的全表掃描和Fast Full Index掃描的的BLOCK放入到KEEP緩存池中等方法調(diào)整這個(gè)等待事件。

db file parallel read等待事件

當(dāng)Oracle從多個(gè)數(shù)據(jù)文件中并行讀取多個(gè)BLOCK到內(nèi)存的不連續(xù)緩沖中(高速緩存區(qū)或者是PGA)的時(shí)候可能就會(huì)出現(xiàn)這個(gè)等待事件。這種并行讀取一般出現(xiàn)在恢復(fù)操作中或者是從緩沖中預(yù)取數(shù)據(jù)達(dá)到最優(yōu)化(而不是多次從單個(gè)BLOCK中讀取)。這個(gè)事件表明會(huì)話正在并行執(zhí)行多個(gè)讀取的需求。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表有多少個(gè)文件被讀取所請(qǐng)求，P2代表總共有多少個(gè)BLOCK被請(qǐng)求，P3代表總共有多少次請(qǐng)求。如果在等待時(shí)間中這個(gè)等待事件占的比重比較大，可以按照處理db file sequential read等待事件的方法來處理這個(gè)事件。

direct path read等待事件

這個(gè)等待事件一般出現(xiàn)在Oracle將數(shù)據(jù)直接讀入到PGA內(nèi)存中(而不是高速緩存區(qū))，如果系統(tǒng)使用了異步I/O，那么Oracle可以一邊提交請(qǐng)求一邊同時(shí)繼續(xù)處理請(qǐng)求，這樣能加速I/O請(qǐng)求的結(jié)果并會(huì)出現(xiàn)direct path read等待直到請(qǐng)求I/O完成。如果沒有使用異步I/O，I/O請(qǐng)求會(huì)被阻塞直到之前的I/O請(qǐng)求完成后，但是此時(shí)不會(huì)出現(xiàn)I/O等待，會(huì)話稍后重新恢復(fù)并加速I/O請(qǐng)求的完成，此時(shí)就會(huì)出現(xiàn)direct path read等待。因此，對(duì)于這個(gè)等待事件容易產(chǎn)生兩方面的誤解：一是認(rèn)為等待的總的數(shù)量不能反映出I/O請(qǐng)求的數(shù)量，二是消耗在這個(gè)等待事件上的總的時(shí)間不能反映出實(shí)際的等待時(shí)間。這類型的讀取請(qǐng)求主要是用于不在內(nèi)存中排序的I/O、并行查詢以及預(yù)讀操作(提前請(qǐng)求一個(gè)進(jìn)程即將使用的BLOCK)。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表等待I/O讀取請(qǐng)求的文件的ABSOLUTE文件號(hào)，P2代表等待I/O讀取請(qǐng)求的第一個(gè)BLOCK號(hào)，P3代表總共有多少個(gè)連續(xù)的BLOCK被請(qǐng)求讀取。

這個(gè)等待事件的等待時(shí)間是指等待BLOCK直到顯著的I/O請(qǐng)求完成的時(shí)間。值得注意的是對(duì)于異步I/O來說等待時(shí)間并不是I/O本身所耗費(fèi)的時(shí)間，因?yàn)榇藭r(shí)等待并沒有開始，而且在這個(gè)等待事件中Oracle并不會(huì)出現(xiàn)超時(shí)的現(xiàn)象。在DSS類型的系統(tǒng)中，執(zhí)行大量批處理操作的過程中出現(xiàn)這個(gè)等待事件屬于很正常的現(xiàn)象，然而如果在OLTP類型的系統(tǒng)中大量出現(xiàn)這個(gè)等待事件則是表明Oracle數(shù)據(jù)庫(kù)存在問題需要調(diào)整。

如果在等待時(shí)間中這個(gè)等待事件占的比重比較大，可以從如下幾個(gè)方面來調(diào)整：

如果是等待的文件是臨時(shí)表空間的數(shù)據(jù)文件，那么需要查看是否存在大量不合理的磁盤排序，優(yōu)化相應(yīng)的存在問題的SQL語句。如果是Oracle9i可以考慮使用自動(dòng)SQL執(zhí)行內(nèi)存管理，Oracle8i的話可以手工的調(diào)整各種排序區(qū)。盡量減少I/O請(qǐng)求的次數(shù)，通過設(shè)置初始化參數(shù)DB_FILE_DIRECT_IO_COUNT，使得滿足

DB_BLOCK_SIZE x DB_FILE_DIRECT_IO_COUNT = max_io_size of system

在Oracle8i中默認(rèn)這個(gè)值為64個(gè)BLOCK；在Oracle9i中可以設(shè)置隱含參數(shù)_DB_FILE_DIRECT_IO_COUNT，參數(shù)的值也變成了BYTES而不是BLOCK數(shù)量了，默認(rèn)值也變成了1M。

確認(rèn)異步I/O是否配置正確，使用異步I/O不會(huì)減少這個(gè)等待事件的等待時(shí)間但是卻可以減少會(huì)話所消耗的時(shí)間。

檢查是否存在I/O消耗很嚴(yán)重的SQL語句，如果存在，嘗試優(yōu)化SQL語句減少I/O的消耗。

最后確認(rèn)一下是否達(dá)到了磁盤的I/O極限，如果是，則需要考慮更換性能更好的硬件設(shè)備。

direct path read/write (lob) 等待事件

這個(gè)等待事件是從Oracle8.1.7開始出現(xiàn)的，表明在等待直接路徑讀取訪問一個(gè)LOB對(duì)象。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表等待I/O讀取請(qǐng)求的文件的ABSOLUTE文件號(hào)，P2代表等待I/O讀取請(qǐng)求的第一個(gè)數(shù)據(jù)BLOCK地址，P3代表總共有多少個(gè)連續(xù)的BLOCK被請(qǐng)求讀取。

對(duì)于那些沒有cache的LOB對(duì)象，強(qiáng)烈建議將其所在的數(shù)據(jù)文件放置在存在緩存的磁盤上(例如文件系統(tǒng))，這樣使得直接讀取操作能夠受益于那些非Oracle的cache，加快讀取的速度。

控制文件相關(guān)I/O等待事件：

control file parallel write等待事件

這個(gè)等待事件表明服務(wù)器進(jìn)程在更新所有的控制文件的時(shí)候等待I/O的完成。因?yàn)榭刂莆募诘拇疟P的I/O過高引起無法完成對(duì)所有控制文件的物理寫入，寫入控制文件的這個(gè)會(huì)話會(huì)擁有CF隊(duì)列，因此其他的會(huì)話都會(huì)在這個(gè)隊(duì)列中等待。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，這三個(gè)參數(shù)都設(shè)置為同樣的值，代表控制文件對(duì)I/O的請(qǐng)求數(shù)量。當(dāng)Oracle更新控制文件的時(shí)候是同時(shí)更新所有控制文件并寫入同樣的信息。

如果在等待時(shí)間中這個(gè)等待事件占的比重比較大，可以從如下幾個(gè)方面來調(diào)整：在確?？刂莆募粫?huì)同時(shí)都丟失的前提下，將控制文件的數(shù)量減小到最少。如果系統(tǒng)支持異步I/O，則推薦盡量使用異步I/O，這樣可以實(shí)現(xiàn)真正并行的寫入控制文件。將控制文件移動(dòng)到負(fù)載比較低，速度比較快的磁盤上去。

control file sequential read等待事件

讀取控制文件的時(shí)候遇到I/O等待就會(huì)出現(xiàn)這個(gè)等待事件，例如備份控制文件的時(shí)候、讀取BLOCK頭部都會(huì)引起這個(gè)等待事件，等待的時(shí)間就是消耗在讀取控制文件上的時(shí)間。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表正在讀取的控制文件號(hào)，通過下面的SQL語句可以知道究竟是具體是哪個(gè)控制文被讀?。?/span>

SELECT * FROM X$KCCCF WHERE INDX = <file#>；

P2代表開始讀取的控制文件BLOCK號(hào)，它的BLOCK大小和操作系統(tǒng)的BLOCK大小一樣，通常來說是512K，也有些UNIX的是1M或者2M，P3代表會(huì)話要讀取BLOCK的數(shù)量。一般來說使用參數(shù)P1、P2來查詢BLOCK,當(dāng)然也可以包括參數(shù)P3，但是那樣最終就變成了一個(gè)多BLOCK讀取，因此我們一般都忽略參數(shù)P3。

如果這個(gè)等待事件等待的時(shí)間比較長(zhǎng)，則需要檢查控制文件所在的磁盤是否很繁忙，如果是，將控制文件移動(dòng)到負(fù)載比較低，速度比較快的磁盤上去。如果系統(tǒng)支持異步I/O，則啟用異步I/O。對(duì)于并行服務(wù)器來說，如果這種等待比較多，會(huì)造成整個(gè)數(shù)據(jù)庫(kù)性能下降，因?yàn)椴⑿蟹?wù)器之間的一些同步是通過控制文件來實(shí)現(xiàn)的。

control file single write等待事件

這個(gè)等待事件出現(xiàn)在寫控制文件的共享信息到磁盤的時(shí)候，這是個(gè)自動(dòng)操作，并且通過一個(gè)實(shí)例來保護(hù)的，如果是并行的數(shù)據(jù)庫(kù)服務(wù)器，那么對(duì)于并行服務(wù)器來說也只能有一個(gè)實(shí)例能夠執(zhí)行這個(gè)操作。這個(gè)事件的等待事件就是寫操作所消耗的時(shí)間。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表正在讀取的控制文件號(hào)，通過下面的SQL語句可以知道究竟是具體是哪個(gè)控制文被讀?。?/span>

SELECT * FROM X$KCCCF WHERE INDX = <file#>；

P2代表開始讀取的控制文件BLOCK號(hào)，它的BLOCK大小和操作系統(tǒng)的BLOCK大小一樣，通常來說是512K，也有些UNIX的是1K或者2K，P3代表會(huì)話要讀取BLOCK的數(shù)量。一般來說使用參數(shù)P1、P2來查詢BLOCK,當(dāng)然也可以包括參數(shù)P3，但是那樣最終就變成了一個(gè)多BLOCK讀取，因此我們一般都忽略參數(shù)P3。

盡管這個(gè)事件的是single write，事實(shí)上也會(huì)出現(xiàn)多BLOCK寫的情況，即P3>1。使用參數(shù)P1、P2來查詢檢測(cè)BLOCK而不用去考慮P3的值。

如果這個(gè)等待事件等待的時(shí)間比較長(zhǎng)，則需要檢查控制文件所在的磁盤是否很繁忙，如果是，將控制文件移動(dòng)到負(fù)載比較低，速度比較快的磁盤上去。如果系統(tǒng)支持異步I/O，則啟用異步I/O。對(duì)于并行服務(wù)器來說，如果這種等待比較多，會(huì)造成整個(gè)數(shù)據(jù)庫(kù)性能下降，因?yàn)椴⑿蟹?wù)器之間的一些同步是通過控制文件來實(shí)現(xiàn)的。

重做日志文件相關(guān)的等待事件：

log file parallel write等待事件

這個(gè)等待事件出現(xiàn)在當(dāng)LGWR后臺(tái)進(jìn)程從日志緩沖區(qū)寫日志信息到磁盤上的重做日志文件的時(shí)候。只有啟用了異步I/O的時(shí)候LGWR進(jìn)程才會(huì)并行寫當(dāng)前日志組內(nèi)的重做日志文件，否則LGWR只會(huì)循環(huán)順序逐個(gè)的寫當(dāng)前日志組重做日志文件。LGWR進(jìn)程不得不等待當(dāng)前日志組所有的重做日志文件成員全部寫完，因此，決定這個(gè)等待事件的等待時(shí)間長(zhǎng)短的主要因素是重做日志文件所在磁盤的I/O讀寫的速度。

如果是當(dāng)前的LGWR進(jìn)程寫的速度不夠快導(dǎo)致了這個(gè)等待事件，可以通過查看一些和重做日志相關(guān)的統(tǒng)計(jì)值判定當(dāng)前的LGWR進(jìn)程是否效率很低，具體的可以查看"redo writes"、"redo blocks written"、"redo write time"、"redo wastage"、"redo size"統(tǒng)計(jì)值，這些都是和LGWR進(jìn)程性能直接相關(guān)的一些統(tǒng)計(jì)值。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表正在被寫入的重做日志文件組中的重做日志文件號(hào)，P2代表需要寫入重做日志組中每個(gè)重做日志文件的重做日志BLOCK數(shù)量，P3代表I/O請(qǐng)求的次數(shù)，需要被寫入的BLOCK會(huì)被分成多次分別請(qǐng)求。

如果這個(gè)等待事件占用的等待時(shí)間比較多，可以從以下幾個(gè)方面來進(jìn)行調(diào)整：

（1）對(duì)能使用UNRECOVERABLE/NOLOGGING的操作盡量使用這兩個(gè)選項(xiàng)來減少重做日志的產(chǎn)生。

（2）在保證不會(huì)同時(shí)丟失重做日志文件的前提下盡量減少重做日志組中的成員的個(gè)數(shù)，減少每次寫重做日志組文件的時(shí)間。

（3）除非在備份的情況下，否則不要在將表空間置于熱備的模式下，因?yàn)楸砜臻g處于熱備的模式下會(huì)產(chǎn)生更多的重做日志文件。

（4）對(duì)于使用LogMiner、Logical Standby或者Streams，在能夠滿足要求功能的前提下，盡量使用最低級(jí)別的追加日志以減少重做日志的產(chǎn)生。

（5）盡量將同一個(gè)日志組內(nèi)的重做日志文件分散到不同的硬盤上，減少并行寫重做日志文件的時(shí)候產(chǎn)生的I/O競(jìng)爭(zhēng)。

（6）不要將重做日志文件放置在RAID-5的磁盤上，最好使用裸設(shè)備來存放重做日志文件。

（7）如果設(shè)置了歸檔模式，不要將歸檔日志的目的地設(shè)置為存放重做日志存放的磁盤上面，避免引起I/O競(jìng)爭(zhēng)。

log file sync等待事件

這個(gè)等待事件是指等待Oracle的前臺(tái)的COMMIT和ROLLBACK操作進(jìn)程完成，有時(shí)候這個(gè)等待事件也會(huì)包括等待LGWR進(jìn)程把一個(gè)會(huì)話事務(wù)的日志記錄信息從日志緩沖區(qū)中寫入到磁盤上的重做日志文件中。因此，當(dāng)前臺(tái)進(jìn)程在等待這個(gè)事件的時(shí)候，LGWR進(jìn)程同時(shí)也在等待事件log file parallel write。理解什么造成這個(gè)等待事件的關(guān)鍵在于對(duì)比這個(gè)等待事件和log file parallel write等待事件的平均等待時(shí)間：如果它們的等待時(shí)間差不多，那么就是重做日志文件的I/O引起了這個(gè)等待事件，則需要調(diào)整重做日志文件的I/O，這個(gè)在之后會(huì)有詳細(xì)的講述。如果log file parallel write等待事件的平均等待時(shí)間明顯小于log file sync等待事件的等待時(shí)間，那么就是一些其他的寫日志的機(jī)制在COMMIT和ROLLBACK操作的時(shí)候引起了等待，而不是I/O引起的等待，例如重做日志文件的latch的競(jìng)爭(zhēng)，會(huì)伴隨著出現(xiàn)latch free或者LGWR wait for redo copy等待事件。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表在日志緩沖區(qū)中需要被寫入到重做日志文件中的緩存的數(shù)量，寫入的同時(shí)會(huì)確認(rèn)事務(wù)是否已經(jīng)被提交，并且保留提交信息到實(shí)例意外中斷之前，因此必須等待LGWR將P1數(shù)量的緩存寫入重做日志文件為止。P2、P3屬于無用的參數(shù)。

如果這個(gè)等待事件在整個(gè)等待時(shí)間中占了比較大的比重，可以從以下三個(gè)方面來調(diào)整這個(gè)等待事件：

（1）調(diào)整LGWR進(jìn)程使其具有更好的磁盤I/O吞吐量，例如不要將日志文件放置在RAID5的磁盤上。

（2）如果存在很多執(zhí)行時(shí)間很短的事務(wù)，可以考慮將這些事務(wù)集合成一個(gè)批處理事務(wù)以減少提交的次數(shù)，因?yàn)槊看翁峤欢夹枰_認(rèn)相關(guān)的日志寫入重做日志文件，因此使用批處理事務(wù)來減少提交的次數(shù)是一種非常行之有效的減少I/O的方法。

（3）查看是否一些操作可以安全的使用NOLOGGING或者UNRECOVERABLE選項(xiàng)，這樣可以減少日志的產(chǎn)生。

log file sequential read等待事件

這個(gè)等待事件是指等待讀取重做日志文件中的日志記錄，等待的時(shí)間就是耗費(fèi)在完成整個(gè)讀取日志記錄的物理I/O操作的時(shí)間。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表一個(gè)日志組里面所有日志文件的相對(duì)sequence號(hào)，P2代表日志文件在指定物理塊大小的偏移量，P3代表讀取BLOCK的數(shù)量，如果P3的值為1，一般來說都是在讀取日志文件頭。

log file single write等待事件

這個(gè)等待事件是指等待寫重做日志文件操作完成，常常是在等待寫重做日志文件頭，例如在增加一個(gè)新的重做日志組成員的時(shí)候，Oracle數(shù)據(jù)庫(kù)就會(huì)往這個(gè)重做日志文件頭寫入相應(yīng)的sequence號(hào)。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表正在被寫入的重做日志文件組的組號(hào)，P2代表日志文件在指定物理塊大小的偏移量，P3代表寫入BLOCK的數(shù)量。

因?yàn)閟ingle write通常都是在寫或者重寫日志文件頭的時(shí)候出現(xiàn)，因此開始的block號(hào)總是為1。一般如果出現(xiàn)這個(gè)等待事件，應(yīng)該對(duì)重做日志文件盡量使用裸設(shè)備，避免將多個(gè)日志文件放在同一個(gè)磁盤上，減少產(chǎn)生I/O競(jìng)爭(zhēng)的可能。

switch logfile command等待事件

這個(gè)等待事件是指執(zhí)行日志文件切換命令的時(shí)候等待日志文件切換完成，Oracle數(shù)據(jù)庫(kù)會(huì)每隔五秒鐘就檢測(cè)一次是否超時(shí)。

如果出現(xiàn)這個(gè)等待事件，表明花費(fèi)了很長(zhǎng)的時(shí)間去切換重做日志文件，此時(shí)我們需要去檢查數(shù)據(jù)庫(kù)的告警日志文件查看Oracle后臺(tái)進(jìn)程LGWR是否正常在工作。

log file switch completion等待事件

這個(gè)等待事件是指由于當(dāng)前重做日志文件已經(jīng)被寫滿了而Oracle后臺(tái)進(jìn)程LGWR需要完成寫完當(dāng)前重做日志文件并且要打開一個(gè)新的重做日志文件而導(dǎo)致的重做日志文件切換的等待，或者是其他請(qǐng)求需要切換重做日志文件導(dǎo)致等待。

如果當(dāng)前的重做日志寫滿了，這個(gè)時(shí)候Oracle數(shù)據(jù)庫(kù)就需要切換重做日志文件來提供足夠的磁盤空間給重做日志寫日志緩存。但是由于一些其他的進(jìn)程也同樣可以引起重做日志的切換，Oracle數(shù)據(jù)庫(kù)不會(huì)同時(shí)去切換重做日志兩次，因此，就出現(xiàn)了這個(gè)等待事件，在Oracle數(shù)據(jù)庫(kù)早期的版本中還有l(wèi)og_file_switch_checkpoint_incomplete、log_file_switch_archiving_needed、log_file_switch_clearing_log_file的等待事件。

log file switch (checkpoint incomplete) 等待事件

這個(gè)等待事件是指由于當(dāng)前重做日志的檢查點(diǎn)沒有及時(shí)的完成而導(dǎo)致重做日志文件無法切換到下一個(gè)日志文件引起的日志文件切換的等待。

調(diào)整這個(gè)等待事件的方法一般是加速檢查點(diǎn)的完成，可以通過減小buffer cache緩沖區(qū)或者增加更多的DBWR進(jìn)程、調(diào)整相關(guān)檢查點(diǎn)的初始化參數(shù)等方法來達(dá)到相應(yīng)的效果。

log file switch (archiving needed)等待事件

這個(gè)等待事件是指當(dāng)前的重做日志文件準(zhǔn)備切換到下一重做日志文件，但是當(dāng)前重做日志文件因?yàn)闆]有被歸檔而導(dǎo)致等待，這個(gè)等待事件只出現(xiàn)于采用了歸檔方式的Oracle數(shù)據(jù)庫(kù)中。

如果出現(xiàn)這個(gè)等待事件，首先應(yīng)該查看Oracle數(shù)據(jù)庫(kù)的告警日志文件，看是否因?yàn)閷憵w檔日志文件錯(cuò)誤導(dǎo)致歸檔進(jìn)程停止，其次，可以增加歸檔進(jìn)程的數(shù)量或者將歸檔日志文件存放到I/O速度比較快的磁盤上，還可以通過增大和增加重做日志文件的大小和數(shù)量來給予歸檔更多的時(shí)間。

高速緩存區(qū)相關(guān)的I/O等待事件：

db file parallel write等待事件

這個(gè)等待事件是指Oracle后臺(tái)進(jìn)程DBWR等待一個(gè)并行寫入文件或者是BLOCK的完成，等待會(huì)一直持續(xù)到這個(gè)并行寫入操作完成。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表Oracle正在寫入的數(shù)據(jù)文件的數(shù)量，P2代表操作將會(huì)寫入多少的BLOCK數(shù)量，P3在Oracle9i release2版本之前代表總共有多少BLOCK的I/O請(qǐng)求，等于P2的值；在Oracle9i release2版本之后則代表等待I/O完成的超時(shí)的時(shí)間，單位是百分之一秒。

這個(gè)等待事件即使在總的等待時(shí)間中占的比例比較大也不會(huì)對(duì)用戶的會(huì)話有很大的影響，只有當(dāng)用戶的會(huì)話顯示存在大量的等待時(shí)間消耗在上的時(shí)候才會(huì)影響到用戶的會(huì)話，較明顯的影響是這個(gè)寫操作的等待會(huì)影響到讀取同一個(gè)磁盤上數(shù)據(jù)的用戶會(huì)話的I/O。

db file single write等待事件

這個(gè)等待事件通常是表明在等待寫入數(shù)據(jù)到數(shù)據(jù)文件頭。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表Oracle正在寫入的數(shù)據(jù)文件的文件號(hào)：

SELECT * FROM v$datafile WHERE file# = <file#>;

P2代表Oracle正在寫入的BLOCK號(hào)，如果BLOCK號(hào)不是1，則可以通過如下查詢查出Oracle正在寫入的對(duì)象是什么：

P3代表Oracle寫入file＃的數(shù)據(jù)文件中從BLOCK#開始寫入的BLOCK的數(shù)量。

Oracle數(shù)據(jù)文件的文件頭一般來說都是BLOCK1，操作系統(tǒng)指定的文件頭是BLOCK0，如果BLOCK號(hào)大于1，則表明Oracle正在寫入的是一個(gè)對(duì)象而不是文件頭。

write complete waits等待事件

這個(gè)等待事件表明Oracle的會(huì)話在等待寫入緩存，一般都是緩存的正常老化或者是實(shí)例之間的互相調(diào)用引起的。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表Oracle正在寫入的數(shù)據(jù)文件的文件號(hào)，P2代表Oracle正在寫入的BLOCK號(hào)，可以通過如下查詢查出Oracle正在寫入的對(duì)象是什么：

P3代表產(chǎn)生這個(gè)等待事件原因的id號(hào)，具體的id號(hào)所代表的原因如下：

1022 無

1027 在寫入過程中的buffer，最多等待1秒后會(huì)重新掃描cache

1029 試圖應(yīng)用改變到正在寫入中的BLOCK，會(huì)一直等到BLOCK可用，每次等待的時(shí)間都是1秒

1030 無

1031 無

1033 無

1034 實(shí)例間的交叉寫：一個(gè)實(shí)例企圖去修改一個(gè)BLOCK，而另外一個(gè)實(shí)例想去獲得此BLOCK的狀態(tài)，這個(gè)實(shí)例產(chǎn)生最多一秒鐘的等待，1035 與1034一樣，但是產(chǎn)生的原因是由于數(shù)據(jù)庫(kù)出于熱備的狀態(tài)下。

當(dāng)Oracle的后臺(tái)進(jìn)程DBWR獲取可以寫入的緩存并標(biāo)記這些緩存為正在寫入的狀態(tài)，接著這些被收集的緩存中的數(shù)據(jù)將會(huì)被寫入磁盤上的數(shù)據(jù)文件中，當(dāng)所有的I/O完成后將清除在原來那些被標(biāo)記的緩存上的標(biāo)記，這個(gè)等待事件出現(xiàn)意味著Oracle想獲取的buffer已經(jīng)被標(biāo)記為正在寫入的狀態(tài)，只有等標(biāo)記被清除才能獲取到相應(yīng)的buffer。在Oracle7.2以前的版本中，只有當(dāng)批處理中所有的buffer都被寫入磁盤后標(biāo)記才被清除，在這之后的版本，每個(gè)buffer寫入磁盤后就將清除在這個(gè)buffer上的標(biāo)記了。增加更多的Oracle后臺(tái)DBWR進(jìn)程或者是采用異步I/O都將能減少這個(gè)等待事件的產(chǎn)生。

free buffer waits等待事件

這個(gè)等待事件出現(xiàn)的原因比較多，大致可以分為以下幾種：

（1）當(dāng)一個(gè)數(shù)據(jù)文件從只讀狀態(tài)變成為可讀寫狀態(tài)的時(shí)候，所有的buffer gets全部都被掛起了，就可能出現(xiàn)這個(gè)等待事件。已經(jīng)存在的所有buffer都必須要失效，因?yàn)樗鼈儧]有鏈接到lock elements(OPS/RAC環(huán)境下時(shí)需要)。因此，只有當(dāng)這些buffers失效完成后才能夠被分配給數(shù)據(jù)庫(kù)塊地址。

（2）當(dāng)Oracle數(shù)據(jù)庫(kù)需要從系統(tǒng)全局區(qū)(SGA)中讀取一個(gè)buffer給一致性讀(CR)操作，只讀操作或者是用于任何恢復(fù)模式中的操作的時(shí)候，也可能出現(xiàn)這個(gè)等待事件，此時(shí)可以加速Oracle后臺(tái)的DBWR進(jìn)程來獲得較多的空閑buffer。在檢查了'free buffers inspected'之后也會(huì)出現(xiàn)這個(gè)等待事件，如果沒有找到空閑的buffer，Oracle會(huì)等待1秒鐘后繼續(xù)試圖去獲取空閑的buffer。

在V$SESSION_WAIT這個(gè)視圖里面，這個(gè)等待事件有三個(gè)參數(shù)P1、P2、P3，其中P1代表Oracle讀取buffer而引起等待的數(shù)據(jù)文件的文件號(hào)，P2代表數(shù)據(jù)文件中讀取buffer的BLOCK的號(hào)，P3代表要讀取buffer的緩存中的BLOCK(7.3.X以上的版本)。

一般來說，這個(gè)等待事件都是由于Oracle的后臺(tái)進(jìn)程DBWR不能及時(shí)的將buffer寫完到磁盤上的數(shù)據(jù)文件中而引起的，盡量將I/O平均分配到各個(gè)磁盤上，減少出現(xiàn)某個(gè)磁盤上I/O負(fù)載很高而引起DBWR進(jìn)程寫入慢的情況，可以通過操作系統(tǒng)上的I/O監(jiān)控工具或者查詢V$FILESTAT視圖來獲取相應(yīng)的數(shù)據(jù)：

還可以通過查看數(shù)據(jù)文件上是否存在全表掃描來判斷：

需要注意在應(yīng)用中要避免漏建立了索引，這樣會(huì)引起I/O大幅度的增加，導(dǎo)致不必要的磁盤掃描，如果有多塊硬盤來存儲(chǔ)Oracle的數(shù)據(jù)文件，盡量使用操作系統(tǒng)的條帶化軟件來分布Oracle的數(shù)據(jù)文件使得I/O分配均勻。此外，大量的磁盤排序會(huì)導(dǎo)致存在很多的臟緩存需要寫完，因此，臨時(shí)表空間中的數(shù)據(jù)文件最好能分配到不同的磁盤上，避免同一個(gè)磁盤上的I/O競(jìng)爭(zhēng)。還有如果排序的BLOCK的檢查點(diǎn)沒有完成，將會(huì)存在于正常的緩存寫批處理中，如果緩存寫批處理中全部都被排序塊給占滿了，那其他的臟數(shù)據(jù)塊就沒法被寫入導(dǎo)致前臺(tái)的應(yīng)用不得不等待分配空閑的buffer。對(duì)于Oracle9i之后的版本，因?yàn)榕判蚴褂玫膲K通常都是來自臨時(shí)表空間文件，不會(huì)進(jìn)入到緩存中，因此，由于大量排序引起的這種等待在9i中基本上就不會(huì)存在了。

了解了在Oracle數(shù)據(jù)庫(kù)I/O性能或者是響應(yīng)時(shí)間低下的時(shí)候該如何去調(diào)整和優(yōu)化數(shù)據(jù)庫(kù)，還有一點(diǎn)很重要的需要提及的是，無論是何種情況，都應(yīng)該先去檢查操作系統(tǒng)上的日志文件，因?yàn)槿绻潜旧碓诓僮飨到y(tǒng)級(jí)別上出現(xiàn)了I/O問題，那不管如何調(diào)整Oracle數(shù)據(jù)庫(kù)都是徒勞的，所以必須首先要保證在操作系統(tǒng)級(jí)別上I/O不存在問題，然后再去Oracle數(shù)據(jù)庫(kù)中具體的檢查問題產(chǎn)生的原因。

不管用何種方法去解決Oracle數(shù)據(jù)庫(kù)的I/O性能問題，關(guān)鍵都是先找出產(chǎn)生I/O性能問題的根本最終原因，然后想各種各樣的辦法去解決產(chǎn)生的原因就可以達(dá)到優(yōu)化數(shù)據(jù)庫(kù)的目的了。以上所談到的都是關(guān)于Oracle數(shù)據(jù)庫(kù)I/O調(diào)整優(yōu)化的一些基本概念和方法，希望能起到一個(gè)拋磚引玉的作用，以便能夠更好的深入理解Oracle數(shù)據(jù)庫(kù)I/O性能方面的知識(shí)。

--the end