スケーラブルデータベースサーバ HiRDB Version 8 システム導入・設計ガイド(UNIX(R)用)
システムログファイルのスワップ時に,スワップ先にできる状態のシステムログファイルがないとHiRDBは異常終了します。これを予防するため,HiRDBにはシステムログファイルの空き容量を監視する機能(システムログファイルの空き容量監視機能)があります。この機能は,システムログファイルの空き率が警告値未満になったときに作動します。次に示す二つのレベルのどちらかを選択できます。
- レベル1:
- システムログファイルの空き率が警告値未満になった場合,警告メッセージKFPS01162-Wを出力します。
- レベル2:
- システムログファイルの空き率が警告値未満になった場合,新規トランザクションのスケジューリングを抑止して,サーバ内の全トランザクションを強制終了します。このとき,KFPS01160-Eメッセージを出力します。これによって,システムログの出力量を抑えます。
レベル2を選択した場合,システムログファイルの空き容量が不足したときにサーバ内の全トランザクションが強制終了されます。このため,システムログファイルの設計をより正確に行う必要があります。
システムログファイルの設計方針について説明します。
- <この項の構成>
- (1) 設計方針
- (2) 信頼性向上のための方針
- (3) システムログの並列出力機能(AIX版及びLinux版限定)
- (4) システムログファイルのレコード長
- (5) システムログファイルの定義
- ユティリティ専用ユニットにシステムログファイルは必要ありません。
- すべてのシステムログファイルのレコード長及びレコード数を同じにしてください。
- 作成できるシステムログファイルは,2〜200グループです(ただし,6グループ以上作成することを推奨します)。
システムログファイルの容量不足によって異常終了したHiRDBを再開始する場合,作成済みのシステムログファイルと同じ数のシステムログファイルを追加する必要があります。例えば,最大量(100ギガバイト)のシステムログファイルを50個で50グループ作成している場合は,更に最大量のシステムログファイルを50個で50グループ追加します。したがって,作成するシステムログファイルは100グループ以内とすることをお勧めします。
- システムログファイルの総容量の上限は20テラバイトになります。
- アンロードする回数を少なくしたい場合は,システムログファイルの1ファイル容量を大きくします。
- HiRDB運用ディレクトリがあるディスクに大量に入出力が発生するファイル(システムログのアンロードログファイルなど)を作成しないでください。
- 一つのシステムログファイルの容量は,次に示す条件を満たす必要があります。
一つのシステムログファイルの容量(バイト)≧↑(a+368)÷c↑×c×b×d
|
- a:pd_log_max_data_sizeオペランドの値
- b:pd_log_sdintervalオペランドの値
- c:pd_log_rec_lengオペランドの値
- d:pd_spd_assurance_countオペランドの値
- 全システムログファイルの容量(二重化している場合は片系の容量だけを対象とする)は,次に示す二つの条件を満たす必要があります。
- 条件1
- 「18.1.1(1)システムログファイルの総容量の求め方」で見積もった容量以上の値にしてください。
- 条件2
- 長大トランザクションが終了するまでは,長大トランザクション開始以降のシステムログファイルの上書きができません。また,シンクポイントダンプファイルの有効保証世代とカレント世代のシステムログファイルは上書きできません。そのため,これらの分のシステムログファイル容量を確保してください。次の計算式で求めます。
システムログファイルの総容量(バイト)≧3×a×(b+1)
|
- a:
- データベースを更新するトランザクションのうち,実行時間が最大のトランザクション実行中に該当するサーバで出力されることのあるシステムログ量
- システムログ量の見積もり式については,「18.1 システムログファイルの容量の見積もり」を参照してください。
- b:pd_spd_assurance_countオペランドの値
- シンクポイントダンプファイルの有効保証世代数です。
(a) システムログファイルの世代数と運用への影響
システムログファイルの総容量が同じ場合,システムログファイルの世代数によって,1世代当たりの容量が変化します。システムログファイルの世代数と運用への影響を次の表に示します。システムログファイルの総容量は同じとします。
表9-3 システムログファイルの世代数と運用への影響
比較項目 |
システムログファイルの構成 |
世代数を少なくした場合 |
世代数を多くした場合 |
システムログファイル1世代当たりの容量 |
大きくなります。 |
小さくなります。 |
スワップ間隔 |
システムログファイル1世代当たりの容量が大きくなるため,スワップ間隔は長くなります。 |
システムログファイル1世代当たりの容量が小さくなるため,スワップ間隔は短くなります。 |
アンロード回数 |
スワップ間隔が長くなるため,アンロード回数は少なくなります。 |
スワップ間隔が短くなるため,アンロード回数は多くなります。 |
ディスク障害などでシステムログファイルの数世代が使用できなくなった場合のシステムログ容量への影響 |
- システムログファイル1世代当たりの容量が大きくなるため,ディスク障害時にデータベースの回復に用いるログ量は多くなり,データベース回復に掛かる時間は長くなります。
- システムログ容量の減少幅が大きいため,システムログの容量が減少したことによるHiRDBの稼働に及ぼす影響は大きくなります。
|
- システムログファイル1世代当たりの容量が小さくなるため,ディスク障害時にデータベースの回復に用いるログ量は少なくなり,データベース回復に掛かる時間は短くなります。
- システムログ容量の減少幅が小さいため,システムログの容量が減少したことによるHiRDBの稼働に及ぼす影響は小さくなります。
|
通常の運用では,システムログファイルの世代数を少なくした場合の方がスワップ間隔及びアンロード回数の点で利点があります。ただし,障害発生時には,世代数を多くした場合の方が障害の影響が小さくなります。
(2) 信頼性向上のための方針
システムログファイルを二重化すると,HiRDBは両方の系に同じシステムログを取得します。取得したシステムログを読み込むとき,片方のファイルに異常が発生しても,もう一方のファイルからシステムログを読み込めるため,システムの信頼性を向上できます。なお,二重化する場合,ディスクをミラー化して二重化するより,HiRDB管理下で二重化することをお勧めします。システムログファイルを二重化する場合は,それぞれの系のファイルを別々のハードディスクに作成してください。
システムログファイルを二重化する場合は,サーバ定義で次に示すオペランドを指定してください。
- pd_log_dual = Y
- pdlogadpfオペランドの-bオプション(B系のシステムログファイル名を指定します)
システムログファイルの片系運転は,システムログファイルを二重化する場合に適用されます。
システムログファイルに障害が発生して,両系とも使用できるシステムログファイルがない場合でも,HiRDBのユニットを異常終了しないで正常な系だけで処理を続行できます。これをシステムログファイルの片系運転といいます。システムログファイルの片系運転をする場合は,サーバ定義でpd_log_singleoperation = Yを指定してください。
システムログファイルの片系運転に対し,両方のシステムログファイルで処理を続行すること(通常の処理形態)をシステムログファイルの両系運転といいます。
HiRDBを再開始するときに,上書きできる状態のシステムログファイルがない場合,予約のファイルがあればHiRDBが予約のファイルをオープンして上書きできる状態にし,処理を続行します。これをシステムログファイルの自動オープンといいます。
システムログファイルの自動オープンをする場合は,サーバ定義でpd_log_rerun_reserved_file_open = Yを指定してください。
システムログファイルを二重化している場合に,システムログの並列出力機能を使用すると,両系へのログの出力処理を並列して実行できるため,ログ出力に掛かる時間を短縮できます。システムログの並列出力機能を使用するには,aioライブラリ(AIXの場合はAsynchronous I/O Subsystem,Linuxの場合はlibaio)が必要になります。Asynchronous I/O Subsystem又はlibaioについては,OSのマニュアルを参照してください。
なお,Linux版でシステムログの並列出力機能を使用する場合は,次のどれかのプラットフォームを使用していることが前提となります。
- Red Hat Enterprise Linux ES 4(AMD64 & Intel EM64T)以降
- Red Hat Enterprise Linux AS 4(IPF)以降
- Red Hat Enterprise Linux AS 4(AMD64 & Intel EM64T)以降
(a) お勧めの使い方
ログ出力に掛かる時間をより短縮するため,A系とB系をそれぞれ別デバイスに配置することをお勧めします。
(b) 環境設定(システム定義の設定)
サーバ定義でpd_log_dual_write_method=parallelを指定してください。ただし,次の場合は指定値に関係なく,システムログの並列出力機能は適用されません。
- システムログファイルが二重化されていない(pd_log_dualオペランドにYが指定されていない)
- システムログファイルがキャラクタ型スペシャルファイルに配置されていない
(c) 環境設定(aioライブラリの設定)
サーバマシンにaioライブラリを導入し,必要な設定を行ってください。aioライブラリの導入と設定方法については,OSのマニュアルを参照してください。
(b)で説明した環境設定を行っている状態で,aioライブラリの導入と設定が正しく行われていない場合,HiRDBを開始できません。
- ●AIX 5L版を使用している場合
- HiRDBを開始する前に,Asynchronous I/O Subsystemを有効化しておく必要があります。有効化されていないと,HiRDBを開始できません。なお,AIX 5L V5.2以降の場合,Asynchronous I/O Subsystemはレガシー版とPOSIX版があります。HiRDBが使用するのはレガシー版のため,レガシー版のAsynchronous I/O Subsystemを有効化してください。
- また,Asynchronous I/O Subsystemの導入後,次のパラメタを設定してください。
パラメタ名 |
推奨値 |
STATE to be configured at system restart |
available |
STATE of FastPath |
enable※ |
- 注※ デフォルト値のため,変更する必要はありません。変更すると,性能が劣化します。
- 上記以外のパラメタはチューニング不要です。
- AIX 5L版のHiRDBの場合,Asynchronous I/O Subsystemが有効化されていないと,HiRDBが開始できないで,異常終了します。Asynchronous I/O Subsystemを有効化するか,pd_log_dual_write_methodオペランドを省略するか,又はserialを指定して,HiRDBを再開始してください。なお,Asynchronous I/O SubsystemのパラメタをSTATE to be configured at system restart = availableに設定しておくと,自動起動します。
- システムログの並列出力機能は,通常ファイルに配置されたシステムログファイルには適用されません。そのため,システムログファイルを追加する場合,キャラクタ型スペシャルファイルに配置してください。
- システムログの並列出力機能が適用されるのは,両系の現用ファイルがキャラクタ型スペシャルファイルに配置されており,かつ両系の現用ファイルにシステムログが出力できる状態の場合(クローズ状態,予約状態,又は障害発生時ではない)だけです。現用ファイルが次の条件に該当する場合,システム定義に関係なく,システムログの並列出力を行いません。
- A系又はB系のどちらかの現用ファイルが通常ファイルに配置されている
- A系又はB系のどちらかの現用ファイルにログが出力できない状態である
- 系切り替え機能使用時など,システムログの並列出力機能を適用するサーバが複数のサーバマシンで稼働する場合,aioライブラリを有効化していないサーバマシンがあると,待機系ユニットの開始,又は系切り替えに失敗します。全サーバマシンでaioライブラリを有効化してください。
システムログファイルのレコード長をpdloginitコマンドの-lオプションで指定します。レコード長は1024,2048,4096のどれかを選択できます。
(a) 新規にHiRDBを構築する場合
新規にHiRDBを構築する場合は,レコード長を1024にすることをお勧めします。この場合,サーバ定義のpd_log_rec_lengオペランドで1024を指定してください。
(b) 既にHiRDBを稼働している場合
レコード長が1024以外の場合,1024に変更することをお勧めします。
システムログファイルのレコード長の変更方法については,マニュアル「HiRDB Version 8 システム運用ガイド」を参照してください。
- レコード長を変更するときの考慮点
(5) システムログファイルの定義
作成したシステムログファイルをどのファイルグループに対応させるかをサーバ定義のpdlogadfg及びpdlogadpfオペランドで定義します。
All Rights Reserved. Copyright (C) 2006, 2016, Hitachi, Ltd.