テンポラリログファイルの見積り式について説明します。
最初に同時実行アプリケーション数や更新BIログ量などにあわせて以下の項目を見積もります。
次にBIログ域サイズやデータベースリカバリ処理時間(ダウンリカバリ時間)の目標値にあわせて以下の項目を見積もります。
注意
見積り式の値より大きな値を指定すると、テンポラリログインデックス域への I/O 負荷が増加し、性能劣化となる場合がありますので、十分に注意してください。
トランザクションエントリ数の見積り式を以下に示します。
なお、ロードシェア運用で、フラッシュトリートメントリカバリ機能を利用する場合は、見積り式の値を2倍にしてください。
トランザクションエントリ数 = Mt × (1 + S) × λ
Mt: 同時に実行するトランザクション数の最大値(最大の多重度)
S : コマンドキャンセル(SQL文単位のキャンセル)を含む
コミットトランザクションの割合(0～1)
λ : 安全率(1.5～2)トランザクションエントリ数によって、テンポラリログインデックス域のサイズが決まります。以下の式によってログインデックス部のサイズを見積もってください。
テンポラリログインデックス域のサイズ = ブロック長 + 2 × BLOCK(248 × T + 304) (バイト)
T : トランザクションエントリ数
ブロック長 : テンポラリログ域のブロック長です。
テンポラリログファイル作成時にioオプションで
指定する値です。
特に指定しない場合は、512バイトです。
BLOCK( ) : カッコ内の式を、ブロックバウンダリで切り上げます。テンポラリログインデックス域のサイズ = ブロック長 + 2 × BLOCK(240 × T + 304) (バイト)
T : トランザクションエントリ数
ブロック長 : テンポラリログ域のブロック長です。
テンポラリログファイル作成時にioオプションで
指定する値です。
特に指定しない場合は、512バイトです。
BLOCK( ) : カッコ内の式を、ブロックバウンダリで切り上げます。Symfoware Server Enterprise Extended Editionでブロック長が512(バイト)、トランザクションエントリ数が20の場合
テンポラリログインデックス域のサイズ = 512 + 2 × BLOCK(248 × 20 + 304)
= 512 + 2 × 5632
= 11776 (バイト)トランザクションの更新データ量は、“C.3 ログ量の見積り式”を参照し、見積もってください。
トランザクションの多重度は、同時に実行するトランザクション数の最大値をもとに、見積もってください。
なお、テンポラリログファイルは、16ギガバイト未満で作成してください。
トランザクションが収集するログにトランザクション間でばらつきが大きい場合は、本見積り式の誤差が大きくなるため、実際に動作させて、必要ならテンポラリログファイルを変更してください。
運用を続けているうちにテンポラリログファイルの容量を変更しなければならなくなった場合は、rdblogコマンドで変更することができます。
BIログ域は、トランザクション多重度およびそのトランザクションが出力するBIログ量を観点にして見積もります。トランザクションが収集するログにトランザクション間でばらつきが大きい場合は、本見積り式の誤差が大きくなるため、実際に動作させて、必要ならテンポラリログファイルを変更してください。
なお、ロードシェア運用で、フラッシュトリートメントリカバリ機能を利用する場合は、見積り式の値を2倍にしてください。
BIログ域のサイズ = Lb × トランザクションエントリ数 Lb : トランザクションの更新ログ量の最大値 (バイト数)
処理時間の長いトランザクションを処理時間の短いトランザクションに分割し、分割後に前述の方法で再見積もりを行う、または、
処理時間の長いトランザクションの処理中は、他のトランザクションの実行を極力抑止し、下記の方法で再見積もりを行う。
BIログ域のサイズ = ( LongLb + ΣLb )× λ LongLb: 最も処理時間の長いトランザクションのBIログ量 Lb : 最も処理時間の長いトランザクション開始後から終了までの間に実行される他のトランザクションのBIログ量の総量 λ : 安全率(2以上を推奨)
データベース運用中にシステムダウンが発生したときに、Symfoware/RDBの再起動または切替えの延長で行うデータベースのリカバリ処理の時間です。
システムダウン発生後の再起動時間の目標値(お客さまの要件など)から、ダウンリカバリ時間を検討する必要があります。
スケーラブルログ運用の場合は、複数のロググループのダウンリカバリ処理を並行に行うため、複数のロググループの中で最長のダウンリカバリ時間が、システム全体のダウンリカバリ時間となります。
AIログ域のサイズは、原則としてリカバリログ量を基準に決定します。AIログ域全体サイズは、リカバリログ量のおよそ2倍程度を目安にします。
ただし、リカバリ時間を抑えたい場合でも、AIの全体サイズが少なすぎると、トランザクション実行中に枯渇が発生する危険がありますので全体サイズは、BIサイズ以下とならない容量が必要となります。
なお、ロードシェア運用で、フラッシュトリートメントリカバリ機能を利用する場合は、見積り式の値を2倍にしてください。
α = リカバリログ量 × 2 β = BIログ域サイズ AIログ域のサイズ = MAX(α、β) … α、βいずれかの多い方を選択してください。
Advanced Backup Controllerを使用する場合は、バックアップ取得期間のログ量が増加します。以下の見積り式により算出した値を、AIログ域のサイズに加算してください。
算出結果が負となった場合は、本ログ量について考慮する必要はありません。
AIログ増分 = O × P × n - R O: 1秒あたりの1データベーススペースへの書き込み回数 (注) P: ページ長(単位:バイト) n: データベーススペース数 R: リカバリログ量(単位:バイト)
注) Oについては、sarコマンドによる実測データから統計的に算出することを推奨します。見積り段階では以下を目安にしてください。
O = K × T K: トランザクションあたりの更新ページ枚数 T: 1秒あたりの平均トランザクション量(/s)
算出例を以下に示します。
O: 1秒あたりの1データベーススペースへの書き込み回数 = 300 × 1 = 300
K: トランザクションあたりの更新ページ枚数 = 1
T: 1秒あたりの平均トランザクション量 = 300
P: ページ長 = 32,768(32キロバイト)
n: データベーススペース数 = 3
R: リカバリログ量 = 10,485,760(10メガバイト)
AIログ増分 = 300 × 32,768 × 3 - 10,485,760
= 19,005,400(約19メガバイト)リカバリログ量は、定常性能およびダウンリカバリ時間に影響を与えます。RDBシステムは、リカバリログ量を一定に保つように、一定間隔で、データベースバッファからディスクへの書込みを行います。
リカバリログ量が少ない場合は、データベースバッファの書込み頻度が増えるため、定常性能に悪い影響を与える可能性があります。
リカバリログ量が多い場合は、ダウンリカバリ時間が長くなります。
したがって定常性能を重視する場合は、ダウンリカバリ時間が運用に問題ない程度までリカバリログ量を多くとるようにしてください。
スケーラブルログ運用を行っている場合は、各ロググループごとに、リカバリ処理が同時に実行されます。よって、リカバリログ量が異なる場合は、ダウンリカバリ時間にも差異が生じます。
スケーラブルログ運用時に、ダウンリカバリ時間を見積もる場合には、各ロググループごとに算出し、その中の最遅の時間をダウンリカバリ時間の見積もり値としてください。
フラッシュトリートメントリカバリ機能を利用する場合は、ダウンリカバリ時間の計算方法が異なります。以下にフラッシュトリートメントリカバリ機能を利用した場合と、利用しない場合に分けて説明します。
参照
フラッシュトリートメントリカバリ機能についての詳細は、“クラスタ導入運用ガイド”を参照してください。
フラッシュトリートメントリカバリ機能を利用する場合のダウンリカバリ時間は、以下の式で見積もります。
ダウンリカバリ時間 = リカバリログ量10メガバイトにつき約5秒
リカバリログ量の指定を省略した場合、デフォルト値は、AIログ域サイズが1.25メガバイト以上では512キロバイトが設定され、1.25メガバイト未満ではAIログ域サイズの40%が設定されます。その場合のダウンリカバリの時間は、およそ1～2秒です。リカバリログ量10メガバイトごとに5秒から15秒程度のダウンリカバリ時間がかかるとみて初期設定します。ただし、リカバリログ量と、ダウンリカバリ時間の関係は、ディスク性能、バッファのサイズにより大きく影響を受けます。したがって、より精度の高いリカバリログ量とするためには、実際の運用に沿った環境下でダウンリカバリ時間を実測し、rdblogコマンドのUオプション、tオプションおよびcオプションで、リカバリログ量を再設定してください。