Sttspackの14-「log file sync」イベント待ち

9297 ワード

原文の出所:
http://www.eygle.com/statspack/statspack14-LogFileSync.htmユーザーが(comits)またはロールバックを提出すると、sessionのredo情報がredo logfileに書き出される必要があります.ユーザプロセスはLGWRに書き出す操作を実行するように通知します.LGWRは任務を完了したらユーザープロセスに通知します.この待ち時間とは、ユーザプロセスがLGWRの書き込み完了通知を待つことです.
ロールバック操作に対して、このイベント記録はユーザからロールバック完了までの時間を記録します.
この待ち時間が多すぎると、LGWRの書き込み効率が低下している、あるいはシステムの提出が頻繁すぎるということになります.この問題に対して、「log file parallel write」はイベントを待つアメリカ人のcomits、user rollbackなどの統計情報を使って、提出回数やロールバック回数を観察することができます.
解決策:1.LGWRの性能を高めるためには、なるべく快速ディスクを使って、redo log fileをライヴ5のディスクに保存しないでください.量産提出3.適当にNOLOGGING/UNRECOVERBLEなどのオプションを使用してください.
平均的な書き込みサイズは、次の式で計算できます.
avg.redo write size=(Redo block written/redo writes)*512 bytes
もしシステムがredoをたくさん生成して、毎回書くのが少ないならば、普通はLGWRがあまりにも頻繁に活性化されたと説明します.多すぎるredo関連latchの競争を招くかもしれません.
私たちは一つのstatspackからいくつかのデータを抽出してこの問題を研究します.
1.主な情報

DB Name         DB Id    Instance     Inst Num Release     OPS Host
------------ ----------- ------------ -------- ----------- --- ------------
DB           1222010599  oracle              1 8.1.7.4.5   NO  sun
                Snap Id     Snap Time      Sessions
                ------- ------------------ --------
 Begin Snap:       3473 13-Oct-04 13:43:00      540
   End Snap:       3475 13-Oct-04 14:07:28      540
    Elapsed:                  24.47 (mins)

Cache Sizes
~~~~~~~~~~~
           db_block_buffers:     102400          log_buffer:   20971520
              db_block_size:       8192    shared_pool_size:       600M

Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                   ---------------       ---------------
                  Redo size:             28,458.11              2,852.03
                  ......

2.イベント待ち

Event                               Waits   Timeouts  Time (cs)    (ms)   /txn
---------------------------- ------------ ---------- ----------- ------ ------
log file sync                      14,466          2       4,150      3    1.0
db file sequential read            17,202          0       2,869      2    1.2
latch free                         24,841     13,489       2,072      1    1.7 
direct path write                     121          0       1,455    120    0.0
db file parallel write              1,314          0       1,383     11    0.1
log file sequential read            1,540          0          63      0    0.1
....
log file switch completion              1          0           3     30    0.0
refresh controlfile command            23          0           1      0    0.0
LGWR wait for redo copy                46          0           0      0    0.0
....
log file single write                   4          0           0      0    0.0

ここではlog file syncとdb file parallel writeが同時に出現するのを見ました.明らかにlogfile syncはdb file parallel writeの完成を待っています.
ディスクIOには必ずボトルネックがあります.実際のユーザーのredoとデータファイルが同時にRaidのディスクに保存されています.性能に問題があります.調整が必要です.
3.統計情報

 
Statistic                                    Total   per Second    per Trans
--------------------------------- ---------------- ------------ ------------
....
redo blocks written                         93,853         63.9          6.4
redo buffer allocation retries                   1          0.0          0.0
redo entries                               135,837         92.5          9.3
redo log space requests                          1          0.0          0.0
redo log space wait time                         3          0.0          0.0
redo ordering marks                              0          0.0          0.0
redo size                               41,776,508     28,458.1      2,852.0
redo synch time                              4,174          2.8          0.3
redo synch writes                           14,198          9.7          1.0
redo wastage                             4,769,200      3,248.8        325.6
redo write time                              3,698          2.5          0.3
redo writer latching time                        0          0.0          0.0
redo writes                                 14,572          9.9          1.0
....
sorts (disk)                                     4          0.0          0.0
sorts (memory)                             179,856        122.5         12.3
sorts (rows)                             2,750,980      1,874.0        187.8
....
transaction rollbacks                           36          0.0          0.0
transaction tables consistent rea                0          0.0          0.0
transaction tables consistent rea                0          0.0          0.0
user calls                               1,390,718        947.4         94.9
user commits                                14,136          9.6          1.0
user rollbacks                                 512          0.4          0.0
write clones created in backgroun                0          0.0          0.0
write clones created in foregroun               11          0.0          0.0
          -------------------------------------------------------------


avg.redo write size = (Redo block written/redo writes)*512 bytes
		    = ( 93,853 / 14,572 )*512 
		    = 3K

これは平均的に小さすぎます.システムの提出が頻繁すぎると説明します.

 
Latch Sleep breakdown for DB: DPSHDB  Instance: dpshdb  Snaps: 3473 -3475
-> ordered by misses desc

                                Get                                  Spin &
Latch Name                    Requests         Misses      Sleeps Sleeps 1->4
-------------------------- -------------- ----------- ----------- ------------
row cache objects              12,257,850     113,299          64 113235/64/0/
                                                                  0/0
shared pool                     3,690,715      60,279      15,857 52484/588/65
                                                                  46/661/0
library cache                   4,912,465      29,454       8,876 23823/2682/2 
                                                                  733/216/0
cache buffers chains           10,314,526       2,856          33 2823/33/0/0/
                                                                  0
redo writing                       76,550         937           1 936/1/0/0/0
session idle bit                2,871,949         225           1 224/1/0/0/0
messages                          107,950         159           2 157/2/0/0/0
session allocation                184,386          44           6 38/6/0/0/0
checkpoint queue latch             96,583           1           1 0/1/0/0/0
          -------------------------------------------------------------

移行が頻繁なため、LGWRは過度に頻繁にアクティブ化しています.ここでredo writingのlatch競争が発生しているのを見ました.
redo writingについて競争していますが、steveのサイトで詳しい紹介を見つけられます.http://www.ixora.com.au/notes/lgwr_lattch.htm
以下のように引用する

When LG WR wakes up,it first tarst the reredow w reretititing latt uudate the SGA variablath shshshat showwhehehether ititisactive.This prevents Prother Oracle processffrom posting LR neeeeeeeeedededededelessly. LR.LLLLLR nererererererererererererererererererererererererererererererererererererererererererererererererererererererererererererererererererererererererererererelatch).If none,it tars the redo writing latch again to record that it isのlonger active,before starting another rdbms ipc message wait.If there is redo to write,LGWR then inspects the latch recovery are for the the relatchトdetermine whether there re re re any incomplette copies into the log buffer.For incocomplette e copies above the sync RBA,LGWR just defers the writing of that block and subsequent logs logs logs.For buffers.For bloce bloce block.For the For For For For For Forever block.Forerever blocs.and is posted when the required copy latch es have been released.The time taken by LG WR to take the redo writing and redo allocation latch and to wait for the redo copy latch is accumutlated in the retch statch time.
(Prior to release 8 i、forground processes held the redo copy latch more brienfly because the y did not retain the m for the ap plication of the change vectors.The refore、LGBR would instead therst thereiture the the therererereretwitwith the the the the the rerererereretwitch.
After each redo write has completted、LGWR Taes the redo allocation latch again in order to udate the SGA variable containing the base disk for the log buffer.This effectively frees the logbath the lover blocth the the lover blocatwith the

この記事の著者:eyegle.Oracle技術の注目者は、中国最大のOracle技術フォーラムからのitpb.www.eyegle.comは作者の個人サイトです.Groqiangを通じてアクセスできます[email protected]作者に連絡します.技術検討交流及びリンク交換を歓迎します.
原文の出所:
http://www.eygle.com/statspack/statspack14-LogFileSync.htm

ES 6エッセンス:関数拡張