はじめに
先日、Oracle DBにデータをinsertするとき、1件ずつコミットするのと、全部まとめてコミットするのとで、どちらが速いかをサンプルプログラムを作って検証してみました。
全部まとめてコミットした場合、redo buffer allocation retries（REDOログ・バッファへの書込み待機）の数が1件ずつコミットする場合に比べて多くなっていたので、REDOログバッファサイズを変更したら、性能が改善するかもしれないと思いました。
今回は、REDOログバッファサイズをデフォルトの4.7MBと10倍の47MBに変更した場合で性能差を測ってみました。
REDOログバッファサイズの拡張
以下のページを参照してください。
statspack(REDOログバッファ4MB)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 200M Std Block Size: 8K
Shared Pool: 300M Log Buffer: 4,784K
statspack(REDOログバッファ47MB)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 328M Std Block Size: 8K
Shared Pool: 144M Log Buffer: 47,840K
測定結果
| 1回目 | 2回目 | |
| REDOログバッファ4MB | 8732msec | 9750msec |
| REDOログバッファ47MB | 10531msec | 9953msec |
ほとんど差異が見られませんでした。
Top 5 Timed Events
log buffer spaceは表示されなくなったけど、log file syncとlog file parallel writeの待機イベントで待たされて相殺された感じ。
REDOログバッファ4MB
Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time ----------------------------------------- ------------ ----------- ------ ------ CPU time 4 50.1 log file parallel write 48 1 30 16.8 control file sequential read 506 1 2 9.5 control file parallel write 39 1 16 7.5 log buffer space 2 1 279 6.6
REDOログバッファ47MB
Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time ----------------------------------------- ------------ ----------- ------ ------ CPU time 5 57.9 db file sequential read 579 2 3 16.8 control file sequential read 352 1 3 11.7 log file sync 18 1 58 11.0 log file parallel write 69 0 2 1.6
でもredo buffer allocation retriesの数は減ったから、REDOログバッファサイズの変更とredo buffer allocation retriesは関係があることが分かりました。
関連記事
