七章 調整日誌機制 2.調整日誌快取 ! {G 0'
y
F/> \ uzu
調整日誌快取 p 2t0 4p!
· 日誌快取的管理機制可以類似理解成一個漏斗，日誌資料不斷地從漏斗上方加入，然後偶爾開啟漏斗下方的開關將加入的資料清空，這個開關就是LGWR程式，為了日誌快取有空間容納不斷加進來的日誌資料，LGWR在下面列出的任何一個條件下都會執行寫出日誌快取的操作： Yukn Z&Q
Ø 應用程式發出Commit命令時； =N C?? e{
Ø 三秒間隔已到時； Ta?}n^V?;
Ø 日誌快取三分之一滿時； `
Ø 日誌快取達到1M時； { P~r f&Ee
Ø 資料庫檢查點發生時； ; n(f?RO3X
· 測量日誌快取的效能 通過伺服器程式放置日誌條到日誌快取時發生等待的次數和時間來測量； qD> ^aEd@4
Ø Select Name, Value n A b~
From V$sysstat z&d.YO _W
Where Name In ('redo entries', 'redo buffer allocation retries', U; oXX
'redo log space requests'); @s-P!uCaT
redo entries 伺服器程式放進日誌快取的日誌條的總數量； l6 HtZ (
redo buffer allocation retries 伺服器放置日誌條時必須等待然後再重試的次數； t(*n[7 e
redo log space requests LGWR程式寫出日誌快取時等待日誌切換的次數； LQPQ !) :;
MZh . Xo
Select Retries.Value / Entries.Value "Redo log Buffer Retry Ratio" jJiuq# ;T3
From V$sysstat Entries, V$sysstat Retries Y0,{ f w<
Where Entries.Name = 'redo entries' V X. LL 5
And Retries.Name = 'redo buffer allocation retries' _9lMa 7i
這個查詢用於計算日誌快取重試率，這個比率應該小於百分之一； ,V9qiu=m
Ø Select s.Username, Sw.Wait_Time, Sw.Seconds_In_Wait, Sw.State jV *10 kM<
From V$session_Wait Sw, V$session s tjtvO @?1-
Where Sw.Sid = s.Sid And Sw.Event Like '%log buffer space%'; n}Z% D -b$
這個查詢用來顯示哪些會話的LGWR正在進行寫等待； rwj+ N %N
State有四個取值：WAITING(會話正在等待),WAITED UNKNOWN TIME(等待時間未知),WAITED SHORT TIME(等待時間小於百分之一秒),WAITED KNOWN TIME(等待時間已知，為wait_time欄位所示的時間); .c]>*/(+
Ø Statspack中有兩個地方存有與日誌快取效能相關的資料： yGtTD 9j
例項命中率（Instance Efficiency Percentages）中的Redo NoWait%，這個值與日誌快取重試率之和等於1； s*g qKQ;
例項活動統計（Instance Activity Stats）中的redo entries, redo buffer allocation retries, redo log space requests； [ G8 EX 3
` $ju n
· 改進日誌快取的效能 bh5 D } w
改進日誌快取的效能就是減少或者消除伺服器程式讀取日誌快取及放置日誌條到日誌快取時發生的等待，可以從下面兩個方面入手： n32"cFPpT
Ø 增大日誌快取 ')q4d0 B`"
ü 日誌快取由初始引數LOG_BUFFER指定，最小值是64K，預設值是greatest(512k , 128k * CPU數); *C Xc{ {
ü 當你指定的日誌快取小於最小值時，會以預設值來生效； b |.Cqsb
ü 日誌快取的最大值由作業系統來指定，考慮到LGWR寫出日誌快取的特點，大於3M的日誌快取已沒有多大實際意義； e bp t/q [
Ø 減少日誌的產生：UNRECOVERABLE，NOLOGGING RdD>& D$I
ü UNRECOVERABLE 這個關鍵字用在下面的語法中：create table table_a as select * from table_b unrecoverable; 在表建立的過程可以儘可能少地產生日誌，但對該表的後續DML操作沒有影響，也不能用於分割槽表，索引組織表，含有大物件的表的建立，這個關鍵字的功能已被nologging取代； %C`P7&8m=O
ü NOLOGGING是表的一個屬性，可以在表建立時指定，也可以在表建立以後用alter命令進行更改，這個屬性可以從許多字典表（DBA_TABLESPACES， DBA_TABLES， DBA_INDEXES，DBA_LOBS等）的logging欄位查到； ! dwZ` D
ü 啟用該屬性，可以在表建立，表上的索引建立及重建時產生較少的日誌（DDL）； ( / $-2.@
ü 啟用該屬性，針對表上的資料插入，在以下兩種情形下可以產生較少的日誌（DML）：用SQL*Loader進行Direct Path Loads ，用append提示進行的Direct Load Inserts； EGgw#JAi#t
ü 啟用該屬性後，用direct path方法裝入的資料將會在媒體恢復的過程中丟失，如果這些資料裝載發生在最近一次備份操作之後的話。 3}s] F/e
v) *M gf S
?=4oxP e
第七章 調整日誌機制 3.調整檢查點 7 +f6?
\:Tq0 |]Px
@~s 5 { 4
調整檢查點 Q e+;BE-H
· 檢查點事件代表在那個時刻資料庫處於一致的狀態，檢查點之所以重要，是因為在例項失敗後，只有發生在最後一個檢查點之後事務需要恢復；有兩種型別的檢查點：增量檢查點和完全檢查點； ,nL~?h -Zh
· 增量檢查點是從ORACLE 8開始引入的，之前的版本只存在完全檢查點，這個時候，所有的髒資料都要寫回磁碟，巨大的I/O對系統性帶來很大影響，而且在寫出所有髒塊的過程中會鎖定資料快取，寫出完成之前再不能夠產生新的髒塊；和增量檢查點相關的一個新的結構是檢查點佇列，這個佇列中存放了所有按low RBA(第一次對此塊修改對應的Redo Block Address)排序的髒塊，每三秒，增量檢查點去更新控制檔案，記錄當前檢查點佇列的最小的low RBA以及on-disk RBA(LGWR程式已經寫入到日誌檔案的最後的日誌位置)等資訊，例項恢復的時候將從控制檔案的low RBA開始，而不是從資料檔案的Checkpoint SCN開始； `q]' ^EzJ
· 完全檢查點發生時，會執行下面的動作： W=A0+t% XC
Ø 通知DBWn程式將所有的髒塊寫回磁碟； Su jEF ` "
Ø DBWn在寫出髒塊時如果發現對應的日誌還在日誌緩衝區，就觸發LGWR寫出日誌條； ' fK=;mM
Ø 檢查點程式更新控制檔案和資料檔案頭； D Z L(G [
· 檢查點的觸發條件有下面一些： cd ,'37pZ
Ø 例項關閉（ABORT方式除外）； > CKa ?N;
Ø 日誌切換； Y
Ø 使用者觸發：Alter System Checkpoint; Alter Tablespace … Begin Backup; M 6MxY\uM
Ø 初始引數FAST_START_MTTR_TARGET指定的值已超過（增量檢查點）； XdIno }pN
Ø 日誌檔案長度的90%（增量檢查點）； l] DR J
Ø 每三秒（增量檢查點）； k Kbbs B
· 完全檢查點發生時，必須等到要求DBWn完成的任務完成後，檢查點才能結束，增量檢查點（FAST_START_MTTR_TARGET以及日誌檔案長度的90%）也會去建議DBWn應該儘快完成的任務，但不會強制觸發DBWn，更不會等待其完成（看http://asktom.oracle.com/pls/ask ... 5023372後的理解）； 5C *Zb3VG4
· 監控檢查點的活動很重要，因為太多的檢查點會增加不必要的I/O，太少的檢查點會使資料庫在例項恢復時經歷過長的時間； ]igCV
· 測量檢查點效能有下面一些方法： .-s!} P"
Ø Select n.Name, Se.Total_Waits, Se.Average_Wait { 3 vm ]
From V$system_Event Se, V$event_Name n z}5'TV = ^
Where n.Name = Se.Event(+) 2 ( ux
And n.Name In c:z}$DK&'
('checkpoint completed', 'log file switch (checkpoint incomplete)'); Qw % 0
z9#jXC#OdN
checkpoint completed等待檢查點的完成; =g@hh)3wP
log file switch (checkpoint incomplete) 如果緊接著的一個日誌切換檢查點發生，前面日誌切換檢查點尚未完成，這時，前面的檢查點會終止，後面的檢查點得從頭再來，導致更多的I/O操作卻不能縮短例項恢復的時間； G Eb)nHQq
Ø Select * x i\uLu?i
From V$sysstat V |0 UwS\n
Where Name In ^h|' \- d\
('background checkpoints started', 'background checkpoints completed')； naB[0I& N
0$ 4 9 X
background checkpoints started 自例項啟動以來開始過的檢查點； /L[: C=u
background checkpoints completed自例項啟動以來已經成功完成的檢查點； veE8 N~0N.
這兩個值的差異值或者差異值減一等於未完成的日誌切換檢查點； +~/zCJ; F
Ø Statspack中與檢查點效能相關的資料有：例項活動統計（Instance Activity Stats）的background checkpoints started 和background checkpoints completed； Ox 43 (S0~
Ø 當出現日誌切換檢查點未完成事件時，報警日誌檔案中會有記錄，大致的描述如下：Thread x cannot allocate new log, sequence y Checkpoint not complete; C"mb-n 7s
Ø 初始引數LOG_CHECKPOINTS_TO_ALERT置為TRUE時，每一個檢查點的性息都可以在報警日誌檔案中找到； q{JD] A:
· 調整檢查點效能有下面兩種方法（加大日誌檔案，調整初始引數）： mg;AcAS.o,
Ø 每個日誌切換時會發生完全檢查點，加大日誌檔案可以使檢查點的間隔更大些，以減少檢查點未完成這個事件發生頻率； nMbV{h ,
Ø 增大日誌檔案方法是，先增加新的更大日誌檔案組，再刪除小的日誌檔案組； u1k bWbHu(
Ø 為了在例項恢復效能以及檢查點活動負擔間達到平衡，調整日誌檔案大小，使日誌切換的發生間隔在20到30分鐘之間為宜； 6% xl} z]o
Ø 在9i中，ORACLE建議只需調整FAST_START_MTTR_TARGET這個引數，含義是例項失敗時的平均恢復時間（秒），取值範圍為0~3600，這個引數可以用Alter System語句動態改變，為零時取消這個功能，這個引數通常是用另兩個引數來實現的：FAST_START_IO_TARGET（例項失敗時的平均贓塊數）, LOG_CHECKPOINT_INTERVAL（例項失敗時的平均日誌OS塊數）； sR0nY8 @F
Ø 設定上面的引數後，可以用V$INSTANCE_RECOVERY這個檢視觀察效果：TARGET_MTTR（平均恢復時間，通常等於上面引數指定的值，如果因為伺服器資源的限制可能稍大於上面的引數值） ESTIMATED_MTTR（評估的當前時刻例項失敗後的恢復用時）；
第七章 調整日誌機制 4.調整線上日誌檔案 >j?u I6Uw
5*r6#[S \
g s 3}rW
調整線上日誌檔案 {mQJ6 G'ny
· 所有的日誌條最後都由LGWR寫到線上日誌檔案，線上日誌檔案的損壞可能導致丟失已提交的事務，因此通常都需要給每個日誌組安排兩個或更多個成員，調整線上日誌檔案一方面要優化執行效能，另一方面要優化恢復效能； SOL=3hfb ^
· 有兩種測量線上日誌檔案的效能的方法：系統事件，OS工具： , L;vN6 ~
Ø Select Event, Total_Waits, Average_Wait 11sW$@xs 9
From V$system_Event 4#w^P M8}
Where Event In ('log file switch completion', 'log file parallel write'); Ul Iw&U
?r
log file switch completion LGWR等待日誌切換的完成 * zWn4BckN
log file parallel write LGWR等待日誌條從日誌快取寫到線上日誌檔案操作的完成 [ \ 1 l4C
這兩個等待事件的數量和平均時間很高時，表明線上日誌檔案存在效能瓶頸； K oJG! Rm
Ø 一些OS工具可以檢視到磁碟IO的活動情況，如UNIX下的SAR和IOSTAT命令，WINDOWS下的工作管理員；（可用V$LOGFILE查到線上日誌檔案的對應位置）； * lAdS] I
· 改進線上日誌檔案相關的效能： P;&p[ [ 7
Ø 減少磁碟競爭：將線上日誌檔案與其它檔案（資料檔案，控制檔案，歸檔日誌檔案）放在不同的磁碟上 ( $> 0&w
Ø 最大化日誌產能：將線上日誌檔案移到更快的裝置，如裸裝置上，儘量避免使用RAID裝置存放線上日誌檔案； >i N % Uz
jqWvLBU!
[u QZD1
七章 調整日誌機制 5.調整歸檔 LB7I` W
4 CT9-2 UC
)% w8>1 }c
調整歸檔 B R j KV
· 歸檔程式用來將線上日誌檔案的內容複製到歸檔目錄，歸檔日誌檔案用於媒體失敗或使用者錯誤時執行恢復；歸檔機制是備份與恢復的重要組成部分，也是IO效能問題的一個重要來源； ^ ) ^|;C\`
· 測量歸檔的效能（歸檔目錄空間不足，歸檔程式太慢） b I6wE'h
Ø 當歸檔目錄所在磁碟沒空間時，整個系統會被掛住，系統寫一條出錯資訊進報警日誌，描述類似於：ORA-16038 log x sequence# y cannot be archived; 這時管理員可以手工臨時改變歸檔目錄（Alter system archive log all to …）或者移出部分歸檔以增加歸檔目錄所在磁碟的可用空間； 00 a
Ø 在歸檔模式下，日誌切換成功前，LGWR不僅可能要等待即將要被重寫的日誌檔案上的檢查點的完成，還可能要等待針對這個檔案的歸檔的完成，後面這個等待事件可以通過下面的語句查詢得到： B\ >}X_ \4
Select n.Name, Se.Total_Waits, Se.Average_Wait _XN R u m4
From V$system_Event Se, V$event_Name n )w zs~ Fn/
Where n.Name = 'log file switch (archiving needed)' !X A% [u
And Se.Event(+) = n.Name; Z 6( [/ n
· 改進歸檔的效能 EJ;0ypbG
Ø 當確定歸檔是一個效能瓶頸時，可以考慮用下面的方法來處理（加多日誌組，加大日誌檔案，選擇多個歸檔目標，啟動更多的歸檔程式）； C\ ^< v&
Ø 加多日誌組可以減少LGWR在日誌切換時對歸檔的等待，在一般的OLTP系統中，5~20個日誌組是比較合適的； 4OZ 5hH h
Ø 加大日誌檔案也能達到減少日誌切換時LGWR對歸檔的等待這個目標，加大日誌檔案會使日誌切換的間隔變得更長，這種型別的檢查點間隔也變得更長，前面曾提到，Oracle推薦檢查點間隔在20~30分鐘為宜，為解決這個矛盾，可以通過適當設定FAST_START_MTTR_TARGET這個引數來達到這個目標； VO;UV $ $
Ø 為了減少因歸檔目標磁碟已滿而使系統被掛起的可能性，以及使用歸檔日誌的多個冗餘備份，可以通過下面的初始引數指定多個歸檔目標和歸檔最小成功個數； BOi z ~h6
LOG_ARCHIVE_DEST 首選的歸檔目標 h[ZN >T
LOG_ARCHIVE_DUPLEX_DEST 第二個歸檔目標 0.B U fuuh
LOG_ARCHIVE_DEST_n 指定最多可到十個的冗餘歸檔目標（企業版才有，標準版中沒有，和上面的引數互相排斥）
LOG_ARCHIVE_DEST_STATE_n 同上面的引數相對應，可選值有enable與defer F2PLy q
LOG_ARCHIVE_MIN_SUCCEED_DEST 在多個歸檔目標的配置下用於指定歸檔最小成功的個數，預設值是1，取值範圍是：1-2（LOG_ARCHIVE_DUPLEX_DEST生效時）或1-5（LOG_ARCHIVE_DEST_n生效時）； _ [ {:!?-?
上面的n的取值在1~10之間； qv0 DrL ,3
相關的檢視有V$ARCHIVE_DEST, V$ARCHIVE_DEST_STATUS, V$ARCHIVED_LOG; DNW2;i
Ø 如果出現LGWR等待歸檔時，LGWR可以啟動更多的ARCn程式來處理歸檔任務； Hr
也可以通過更改初始引數LOG_ARCHIVE_MAX_PROCESSES（預設值為1，取值範圍2~10）來指定例項啟動時就開始執行的歸檔程式的個數（通常這個值應該等於歸檔目標的個數）； ^QXw[th!d
可以通過V$ARCHIVE_PROCESSES檢視到歸檔程式的狀態以及它正在處理的日誌序號； L'\/)!cEd