オンラインREDOログ設計
オンラインREDOログ(以降は単にREDOログ)の設計について考えた事、Oracleがマニュアルで示している設計方針をメモ。
考える観点
- 性能
- 信頼性
- コスト
Oracleがマニュアルで示している設計方針
REDOロググループ内のメンバー数
あまり悩まずに決まる設計部分。
1個か2個以上か
| 1個 | 2個以上 | |
|---|---|---|
| 性能 | 1個にのみ書くため最もI/O量は少なく速い。アーカイブ速度は理論的には2個以上の場合より劣る。 | 複数に書くためI/O量は増える。ただし別ディスクに分散すればネックにはならない。アーカイバが複数ファイルから読み取りできるためアーカイブ速度は上がる。 |
| 信頼性 | 低い(皆無)。物理障害・論理障害でアーカイブしていないログを喪失しコミット済みのトランザクションをロストする。 | 高い。別々のディスク(Failure Group)に出力することで物理障害・論理障害ともに対応できる。残りのメンバーを使い動作継続できる。同じディスクに複数書くのは論理障害には対応できるが物理障害には耐えず、パフォーマンスも悪いのでほとんど意味がないと考えている(1ファイルが使っているセクタの障害とかその他のI/O障害・論理障害(何？)へは耐える)。 |
| コスト | 低コスト。 | 高コスト。メンバー数分だけディスク領域を使用する。ただし、REDOログサイズはデータベースに比べて遥かに小さいためこのコストを意識する必要はあまりない。注意としてはRACの場合、各ノードのスレッドでREDOログを持つため、メンバー数を増やすと(グループ数×ノード数)倍で必要なディスク領域が増えること。 |
| 使いどころ | 信頼性の考慮が皆無のため、適用できる環境は『開発環境』『検証環境』『個人の実験環境』で、トランザクションのロストが問題にならない場合に限定される。ただし、実システムだと『開発環境』や『検証環境』でも同一ディスクに2個書いたりする(上記の通り多少信頼性が上がるため)。よって『個人の実験環境』に限定されると考える(少しでもI/Oを減らしたい場合とか)。 | 実システムの全て。 |
2個以上のいくつにするのか
『信頼性』の要件による。
- 増えれば増えるだけI/Oや必要ディスク領域が比例して増えるため、『信頼性』以外にとってはメリットは無い。
- 2個以上の場合は各メンバは別々のディスク(Failure Group)に配置されているべきである。
- 各メンバの配置されるディスク(Failure Group)が同時に全滅する可能性を『想定外』にできるところまで増やせば良い。別ストレージに配置するなら2個でも十分と考えられる(エンタープライズ最高峰の金融機関様とかがどうなっているかは知りません)。
REDOログの物理配置
配置場所
ストレージ
- REDOログのI/Oの性質
- REDOログ・バッファにためたログを追記していくシーケンシャル・ライトになる(とはいえログ・バッファの溜まらない期間でフラッシュが多発するとI/O回数が支配的な問題になると考える)。
- REDOログ・バッファがフラッシュされる契機(コミット、3秒間隔、ログ・バッファ使用率が1/3を超えた、DBWn要請)ごとに発生する。
- REDOログ・バッファのフラッシュが完了しないかぎりコミット完了とならず、REDOログのI/Oが遅いとそのままコミットが遅くなる。
- REDOログ・バッファのサイズは数MB〜数十MB。
- アーカイブ処理はシーケンシャル・リードになる。
- REDOログさえ書いていればデータベースは処理を継続できる(もちろんバッファ・キャッシュの書き込みが追いつかずに空きバッファ確保待ちになる可能性はある)。
- 上記の性質からREDOログには優先的に高性能のI/Oが可能な領域を割り当てる価値があることになる。
ここまでしてたのか的配置
『Best Practices for Oracle Database on an LSI CTS2600 Storage System』の配置。メンバーでディスクを分けるのはわかるけど、グループではさすがに・・・と思ったら分けている例があった。アーカイブ処理している間は別のディスクを使うような意図なんだろうが、今だと下手にディスク本数減らしてここまで小分けにするのは勧められないだろう。
ストレージのスナップショット機能を使うオンラインバックアップを行う場合の注意事項
- スナップショット機能でオンラインバックアップを行う場合、以下のファイルはスナップショット単位が独立していなければならない(するべきだと私は考えている)。これは先のDGDATAとDGFRAにREDOログを乗せる場合には満たせない。
- まず、REDOログのバックアップはオンラインバックアップ上必須ではない。BEGIN BACKUP - END BACKUPまでのログはアーカイブしたものをバックアップする。よってデータと一緒でもアーカイブREDOログと一緒でも不要なもののスナップショットをとることになる。
- 最大の問題はリストア時に起こる。直近までの回復が必要な場合、『現在のREDOログは残して』データファイルをバックアップ時まで戻すことが求められるが、REDOログとデータファイルがDGDATAに同居していると、DGDATAを戻すと一緒にREDOログまで戻されてしまう。もちろん、DGFRA上のREDOログは残るが、リカバリを求められている時に『REDOログのメンバ間不整合』『REDOログの冗長性をあえて失わせる』という状況を作り出したいだろうか。
- これを避けるために領域を分けると下図のようになる(スナップショットの単位はLU単位)。
- 領域の分け方はいくつか考えられる。どこでミラーとストライピングをするか、がポイント。
| 方式 | ストライピング | ミラー | メリット | デメリット | 個人的評価 |
|---|---|---|---|---|---|
| ストレージレベルでRAID1+0を構成、LUを2つ切り出す。 | ストレージ内 | ストレージ内 | DGの管理がシンプル(1DG内1LU)。ASMレベルでミラーをせずストレージ内でミラーできるためサーバとストレージ間のI/O回数が半減。 | ASMによる負荷分散やデータ配置調整ができずストレージ任せ。Oracleのソフトウェアからストレージまでの垂直統合の思想からは外れる。ASMからすると1ディスクにしか見えないため、複数ディスクとして見えた場合と比べて投げるI/O数より少なく抑えられないか？(疑問なだけで確定ではない) ディスク追加時にLUを拡張するとOS側での容量再認識(場合によっては再起動)となりオンラインでの拡張が困難。 | △？ |
| ストレージレベルではRAID1を複数構成、各RAIDグループからLUを2つ切り出し、ASMでストライピング。 | ASM | ストレージ内 | ASMによる負荷分散や再配置が可能。ASMレベルでミラーをせずストレージ内でミラーできるためサーバとストレージ間のI/O回数が半減。ディスク追加時はDGへのLU追加のためオンラインで拡張が可能。 | RAIDグループが増える。 | ◯ |
| ストレージレベルではRAIDを構成せず、各ディスクからLUを2つ切り出し、ASMでストライピング・ミラー。 | ASM | ASM | ASMによる負荷分散や再配置が可能。ASMレベルでミラーをせずストレージ内でミラーできるためサーバとストレージ間のI/O回数が半減。ディスク追加時はDGへのLU追加のためオンラインで拡張が可能。 | ASMレベルでミラーするためI/Oが増える。LU内にミラー(どれが正でどれが副ということでもなく)が混在するため、スナップショットはミラー数倍の容量で取る事になる(2面ミラーなら2倍の容量のスナップショットになる)。ASMレベルのミラーはスナップショットによるバックアップの考え方とは相容れない。ディスク単体からLUを構成できるか不明(そもそも)。 | × |
REDOログ1ファイルのサイズ
グループごとに変えるかどうか
全グループでファイルサイズは同一にする。技術的にはグループごとに異なっても良いが変えてもメリットがない。
大きくするか小さくするか
- 管理者ガイドでは以下のように書かれている。この記述をみる限りではある程度のサイズであれば、あとは運用上の都合ということになる。こんな基準で大丈夫か？
REDOログ・ファイルのサイズを設定するときは、REDOログをアーカイブするかどうかを考慮してください。REDOログ・ファイルのサイズは、いっぱいになったグループを1つのオフライン記憶メディア(テープやディスクなど)にアーカイブできるとともに、そのメディア上の未使用領域が最小になるように設定します。たとえば、いっぱいになった1つのREDOログ・グループを1本のテープにアーカイブし、そのテープの記憶容量の49%が未使用のまま残っているとします。この場合は、REDOログ・ファイルのサイズを小さくして、テープごとに2つずつREDOログ・グループがアーカイブされるように構成することをお薦めします。
同一の多重REDOログ・グループのメンバーは、すべて同じサイズにする必要があります。異なるグループのメンバーは異なるサイズにすることができます。ただし、グループ間でファイル・サイズを変えても特に利点はありません。ログ・スイッチ間にチェックポイントが発生するように設定していない場合は、グループのサイズを同一に設定して、チェックポイントが一定の間隔で発生することを保証してください。
REDOログ・ファイルの最小サイズは4MBです。
- チューニング・ガイドでは以下(引用部)のように書かれている。
REDOログ・ファイルのサイズはパフォーマンスに影響を与えます。これは、データベースのライター・プロセスおよびアーカイバ・プロセスの動作がREDOログのサイズによって変わるためです。一般に、REDOログ・ファイルが大きければ、パフォーマンスは向上します。ログ・ファイルのサイズが小さいと、チェックポイント・アクティビティが増加し、パフォーマンスが低下します。
REDOログ・ファイルのサイズはLGWRのパフォーマンスに影響を与えませんが、DBWRおよびチェックポイントの動作に影響を与える可能性があります。チェックポイントの頻度には、ログ・ファイルのサイズやFAST_START_MTTR_TARGET初期化パラメータの設定など、複数の要因が影響します。インスタンスのリカバリ時間を制限するためにFAST_START_MTTR_TARGETパラメータが設定されている場合、Oracle Databaseは自動的にチェックポイントを必要に応じて頻繁に試みます。この場合は、ログ・ファイルが小さすぎることによるチェックポイントの追加発生を防ぐために、ログ・ファイルを十分なサイズに設定する必要があります。最適なサイズは、V$INSTANCE_RECOVERYビューからOPTIMAL_LOGFILE_SIZE列を問い合せることで取得できます。また、Oracle Enterprise Managerの「REDOログ・グループ」ページからも、サイズ設定のアドバイスを取得できます。
REDOログ・ファイルに特定のサイズを推奨できない場合もありますが、100MB〜数GBの範囲内にあるREDOログ・ファイルが妥当であると考えられます。システムが生成するREDOの量に従って、オンラインREDOログ・ファイルをサイズ設定します。およその目安として、多くても20分ごとに1回ログ・ファイルを切り替えます。
- 大小のメリット・デメリットを整理すると、大きいREDOログの致命的なデメリットがない。よってREDOログはあらかじめ大きめに取るか、もしくはチューニングフェーズに拡張できるように領域に余裕を持たせるかしておく。
| サイズ | メリット | デメリット |
|---|---|---|
| 小さい | REDOログに必要なディスク容量を抑えられる。チェックポイントを多発させるためインスタンスリカバリ時間が短く維持される。 | チェックポイントが多発する。ARCn、DBWn、CKPTの稼働回数が増える。 |
| 大きい | チェックポイントの多発を抑えられる。アーカイブプロセスの稼働回数が減少する。 | REDOログに必要なディスク容量が増える。ただし、大きくても数GBレベルのため大きなデメリットではない。チェックポイントが発生しない場合はインスタンスリカバリ時間が延びる。 |
チェックポイントの発生を制御するパラメータ
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- ARCHIVE_LAG_TARGET (ログスイッチを契機とするチェックポイント発生)
具体的なサイズをどう決めるか
- REDOログサイズをある程度大きく(数百MB)とり、チューニング項目として拡張できる余地を残したディスク設計にしておく(先送り案)。
- REDOログ生成量(想定)から、『多くても20分に1回』となるようにサイズを決める(計算案)。
- 繁忙期・バッチ実行時・オンライン時間帯、など明らかにREDOログ生成量が異なる条件で常に多くても20分に1回を維持するのは困難。バースト的にREDOログが出力される場合もある。一時的にチェックポイントが増えてパフォーマンスが低下しても許容できる場合(バッチなど)はスイッチがもっと短時間で発生してもよい(と私は考えている)。
- REDOログ生成量が増えてログ切り替え(チェックポイント)が発生してもすぐにDBが止まる訳ではない。1REDOログファイルサイズ×グループ数を超えて生成されるとチェックポイント未完による待ちとなる。一時的なREDOログ大量出力にはREDOログファイルサイズを増やすのではなくグループを増やすことでも対応できる。
チェックポイントに関する個人的誤解
チェックポイントが発生した場合、DBWnがダーティ・バッファをすべて書き戻しきるまでDBが待機すると思っていた。実際にはチェックポイント発生はDBWnの書き戻しをトリガーするもので、その時にDBが待機するわけではない。DBWnによるI/Oが増えるためシステムのパフォーマンスが悪くなる、ということが悪影響である。DBが待機するのは、上書きが必要なREDOログファイルの範囲ですらチェックポイントが完了しない場合(log file switch (checkpoint incomplete))。これはグループ数を増やすことで対処できる。
REDOロググループの数
データベース・インスタンスに対するREDOログ・ファイルの適切な数を決定する最良の方法は、様々な構成をテストすることです。最適な構成では、LGWRがREDOログ情報を書き込むのを妨げない最小の数がグループ数になります。
データベース・インスタンスに必要なグループが2つのみの場合もあります。また、LGWRが使用可能な再利用グループが常に存在するようにするため、データベース・インスタンスにグループを追加する必要がある場合もあります。テスト中に、現行のREDOログ構成に問題がないかどうかを確認するには、LGWRトレース・ファイルおよびデータベース・アラート・ログの内容を調べるのが最も容易です。チェックポイントが未完了か、またはグループがアーカイブされていないため、LGWRが頻繁にグループを待機することをメッセージが示す場合は、グループを追加してください。
