管理の手引き


データ管理

データベースの作成、表スペースの作成、表の作成、表へのデータの配置に続き、 表の編成および表データを検索するための索引の使用方法について説明します。

図 70. 表、レコード、および索引


DMTRI000

論理的には、表データはデータ・ページのリストとして編成されます。 そして、これらのデータ・ページは、 表スペースのエクステント・サイズに基づいて論理的にグループ分けされます。 たとえば、エクステント・サイズが 4 の場合、 0 ページから 3 ページが最初のエクステントに入り、 4 ページから 7 ページが 2 番目のエクステントに入るようになります。

それぞれのデータ・ページに入るレコードの数は、 データ・ページのサイズやレコードのサイズによって異なります。 1 ページに最大 255 個のレコードが入ります。 大半のページには、ユーザー・レコードしか入りません。 ただし、一部の少数のページには特殊な内部レコードが含まれます。 これは表を管理するのに DB2 によって使用されます。 たとえば、データ・ページで 500 ページごとに空きスペース制御レコード (FSCR) があるとします。 これらのレコードは、 FSCR に続く 500 個のデータ・ページ (次の FCSR まで) に存在する新しいレコードの空きスペースの量をマップします。 この使用可能な空スペースは、 表にレコードを挿入する際に使用されます。

論理的には、索引ページは B ツリーとして編成されています。 B ツリーでは、特定のキー値を持つ表データでレコードを効率的に配置できます。 索引ページでのエンティティーの数は固定しておらず、キーのサイズによって異なります。 DMS 表スペースの表では、索引ページにあるレコード識別子 (RID) は、 オブジェクト相対ページ番号ではなく表スペース相対ページ番号を使用します。 これによって、 索引走査は、マップのためにエクステント・マップ・ページ (EMP) を要求することなく、 データ・ページに直接アクセスできるようになります。

データ・ページの形式は、次のとおりです。 データ・ページの先頭にはページ・ヘッダーがあります。 ページ・ヘッダーの後には、スロット・ディレクトリーがあります。 スロット・ディレクトリーの各エントリーは、 ページの異なるレコードに対応します。 エントリー自体は、レコードが開始するデータ・ページへのバイト・オフセットです。 マイナス 1 (-1) のエントリーは、削除されたレコードに対応します。

レコード識別子とページ

レコード識別子 (RID) は、 3 バイトのページ番号の後に 1 バイトのスロット番号が付いたものです。 索引を使用して RID が識別されると、 その RID は正確なデータ・ページおよびそのページのスロット番号を取得するのに使用されます。 スロットの内容は、 ページ内のバイト・オフセットから、検索されるレコードの先頭まであります。 レコードに割り当てられた RID は、 表の再編成まで変わりません。

図 71. データ・ページと RID の形式


SQLRID01

表が再編成されるとき、 レコードの削除の後でデータ・ページに残された埋め込み空きスペースは、 使用可能な空きスペースに変換されます。 RID がデータ・ページのレコードの移動に基づいて再定義され、 使用可能な空きスペースが活用されます。

DB2 では、さまざまなページ・サイズがサポートされています。 行に順次アクセスする傾向のある作業負荷には大きいページ・サイズを使用します。 たとえば、順次アクセスが意思決定支援アプリケーションに使用される場合や、 一時表が集中的に使用される場合などです。 アクセスがランダムである傾向の作業負荷には、小さいページ・サイズを使用してください。 たとえば、ランダム・アクセスは OLTP 環境で使用されます。

表の再編成について詳しくは、カタログとユーザー表の再編成を参照してください。

スペース管理

新しい情報を表に入れるには SQL INSERT ステートメントを使用します。 これを実行すると、 この後に INSERT 探索アルゴリズムが実行されて作業が完了します。 最初に、空きスペース制御レコード (FSCR) が使用されて、十分なスペースのあるページが見つけられます。 ただし、 FSCR に空きスペースが十分にある場合でも、 他のトランザクションの非コミット DELETE により "予約" されているために、 このスペースを使用できない可能性もあります。 結果として、 すべてのトランザクションが頻繁に COMMIT されるようにしなければなりません。 そうでないと、コミットされていない空きスペースが使用できなくなります。

表にあるすべての FSCR が検索されるわけではありません。 DB2MAXFSCRSEARCH 登録変数により、 INSERT の実行時に考慮される FSCR の数は制限されます。 この登録変数の省略時値は 5 です。 5 つの FSCR にスペースが見つからない場合、 挿入しようとしているレコードは表の末尾に追加されます。 また、INSERT の速度を最適化するために、 2 つのエクステントが満杯になるまで、 後続のレコードは表の末尾に追加されます。 この 2 つのエクステントが満杯になったら、 次の INSERT から、先回終了した位置からの FSCR の検索が再開されます。
注:DB2MAXFSCRSEARCH の値は重要です。 INSERT の速度を最適化するには (表がすぐに大きくなる可能性がデメリットとしてある)、 この登録変数を小さい値に設定してください。 スペースの再使用を最適化するには (INSERT 速度が遅くなる可能性がデメリットとしてある)、 この登録変数を大きい値に設定してください。

表全体が一度検索されると、 挿入されるレコードは、検索をさらに実行せずに追加されます。 FSCR を使用する検索は、 スペースが表のどこかに作成されるまで (たとえば、DELETE の後まで) 再実行されません。

他にも 2 つの検索アルゴリズム・オプションがあります。 最初は、APPEND MODE です。 このモードでは、新しい行が常に表の末尾に追加されます。 FSCR の検索や保守は実行されません。 このオプションは ALTER TABLE APPEND ON ステートメントを使用して有効にすることができ、 ジャーナルなどの大きくなるだけの表のパフォーマンスを改善することができます。 2 つ目の方法として、 表でクラスター索引を定義することができます。 この場合、 データベース・マネージャーはレコードを、 類似した索引キー値のある他のレコードと同じページに挿入しようとします。 このページにスペースがない場合には、 周辺のページにレコードを入れるように試みがなされます。 それでも正常に実行されない場合には、上記の FSCR 検索アルゴリズムが使用されます。 ただし、ここでは、 最初に見つかったスペースが使用されるのではなく、 最も大きさが異なるスペースが使用されるという違いがわずかにあります。 このアプローチは、 空きスペースがより大きいページを選択する傾向があります。 これが実行されるのは、このキー値の行の新しいクラスター域を確立するためです。

表にクラスター索引を定義する場合には、 表のロードまたは再編成の前に ALTER TABLE... PCTFREE を使用します。 PCTFREE 文節は、ロードおよび再編成の後、 指定されたパーセンテージ値をこの表のデータ・ページでの空きスペースとして残しておきます。 これにより、 クラスター索引走査が望むページに空きスペースを検出できる可能性を増すことになります。

図 72. データ・ページと桁あふれレコード


SQLOFR01

桁あふれレコードは、 更新要求で既存のレコードが大きくなり、 現行のページに入らなくなる場合に起こります。 大きくなったレコードは、桁あふれレコードとして十分なスペースのある他のページに挿入されます。 元の RID は、ポインター・レコードに変換され、 ここに、桁あふれレコードの新しい RID が組み込まれます。 表の索引では、元の RID が保持されるため、 要求されたデータ・レコードを取得するには、 余分のページ読み取りが必要です。 桁あふれレコードがたくさんあると、 余分のページ読み取りも多くなるために、 表にアクセスする際のパフォーマンスが低下します。 桁あふれレコードは、表の再編成でなくすことができます。 ただし、可能な場合はいつでも、 レコードを大きくする更新要求を避けることにより、 桁あふれレコードを回避してください。

索引管理

DB2 索引は、書き込み先行ログを使用した効率的かつ並行性の高い索引管理メソッドに基づく、 最適化された B ツリー・インプリメンテーションです。

最適化された B ツリー・インプリメンテーションでは、 双方向のポインターがリーフ・ページにあるため、 単一索引で前方または後方のいずれの方向でも走査できます (両方向を同時に走査することはできません)。 通常、索引は、ちょうど半々に分割されます。 例外として、上位キー・ページでは、90/10 の分割が使用されます。 つまり、索引キーの上位 10 パーセントは、 新しいページに入れられます。 このタイプの索引ページの分割は、 新しい上位キーを使用して INSERT 要求が頻繁に実行される作業負荷の場合に役立ちます。

ページの最後の索引キーが除去されると、 索引内のページが解放されます。 ただし、索引を作成する際に MINPCTUSED 文節が選択された場合は例外です。 この文節を使用した場合、 この索引はオンラインで再編成できます。 このとき、この文節で指定された値は、 索引リーフ・ページで使用されるスペースの最小パーセンテージのしきい値です。 索引ページからキーが削除された後で、 ページで使用されているスペースが指定された値以下である場合には、 残りのキーを近隣のページのキーにマージする試みが実行されます。 空きが十分にある場合には、 マージが実行され、リーフ・ページが削除されます。 この文節を使用すると、スペース再利用が改善される可能性があります。 ただし、使用される値が高すぎると、 マージを実行するのにかかる時間が長くなるだけでなく、 成功する可能性も低くなります。 この文節の値は、常に 50 パーセント未満にするようにお勧めします。

CREATE INDEX ステートメントの INCLUDE 文節を使用すると、 指定されたカラムをキー・カラムに加えて索引リーフ・ページに組み込むことができます。 これで、 索引のみのアクセスで適格である照会の数を増やすことができます。 ただし、同時に索引スペースの要件も増やすことになり、 組み込まれた列が頻繁に更新される場合には、 索引の保守にかかるコストも増える可能性があります。 索引 B ツリーの順序付けは、 キー・カラムを使用することによってのみ実行できます。 組み込みカラムでは実行できません。

ロック

データベース・マネージャーは、並行性制御を可能にし、 ロックを使うことによって、リソースおよびデータに無秩序にアクセスがなされることがないようにします。 ロックは、 アプリケーションをデータベース・マネージャー・リソースまたはデータ・レコードに関連付けます。 ロックは、 他のアプリケーションが同じリソースまたはデータ・レコードにアクセスする方法を制御します。

データベース・マネージャーは、 以下に基づいてレコード・レベルのロッキングおよび表レベルのロッキングを適宜使用します。

すべてのトランザクションが頻繁に COMMIT され、保持されているロックが解放されるようにしてください。

通常、以下の場合以外は、レコード・レベルのロッキングが使用されます。

ロック・エスカレーションとは、 1 つまたは複数のレコード・ロックが表ロックに変換されることです。 排他ロック・エスカレーションとは、 獲得された表ロックが排他ロックであるロック・エスカレーションのことです。 ロック・エスカレーションは並行性を低下させるので、回避する必要があります。

レコード・ロッキングの期間は、使用されている分離レベルによって異なります。

このトピックについて詳しくは、ロックを参照してください。

ロギング

ロギング・ストラテジーは、以下の 2 つから選択できます。

いずれを選択する場合でも、 正規データおよび索引ページになされた変更はすべて、 ログ・バッファーに書き込まれます。 以下の場合にのみ、ログ・バッファーにあるデータはディスクに強制書き込みされます。

注:COMMIT ステートメントを使用してトランザクションが完了すると、 変更されたページすべてがディスクにフラッシュされて回復性が保証されます。

トランザクションが短い場合、 COMMIT 時のフラッシュが頻繁に起きるために、 ログの入出力が "障害" になります。 このような環境では、 mincommit 構成パラメーターを 1 より大きい値に設定すると、 "ボトルネック"を取り除くことができます。 1 より大きい値が使用される場合には、 複数のトランザクションの COMMIT が保持されるか、 または "バッチ" されます。 COMMIT される最初のトランザクションは、 続く (mincommit - 1) 個のトランザクション COMMIT が実行されるまで待機します。 それから、ログがディスクに強制書き込みされ、 すべてのトランザクションがアプリケーションに応答します。 結果として、 個々のログ入出力が複数実行されるのではなく、 1 つだけログ入出力が実行されることになります。

応答時間が極端に遅れるのを避けるために、各トランザクションは、 (mincommit - 1) 個の他のトランザクションが COMMIT されるのを 1 秒までしか待機しません。 1 秒が経過すると、 待機しているトランザクションはログ自体に強制書き込みされ、 このアプリケーションに応答します。 これにより、 mincommit を設定すると同時に、 数の減ったトランザクションが処理されている時間のパフォーマンスを心配しなくてもよくなります。

ラージ・オブジェクト (LOB) および LONG VARCHAR への変更は、 シャドー・ページングによりトラックされます。 ログ保存が使用され、 LOB カラムが CREATE TABLE ステートメントで NOT LOGGED 文節を使用しないものとして定義されていないかぎり、 LOB カラムの変更はログ記録されません。 LONG または LOB データ・タイプの割り当てページへの変更は、 正規データ・ページと同様にログ記録されます。

更新時の処理

エージェントがページを更新すると、 ログやデータ・ページはどうなるでしょうか? ここで説明されているプロトコルは、 トランザクションで必要な入出力を最小化し、同時に回復性を保証します。

最初に、更新されるページがピンされ、排他ロックでラッチされます。 ログ・バッファーにログ・レコードが書き込まれ、 この変更を再実行したり、取り消したりする方法が説明されます。 このアクションの一部として、 ログ順序番号 (LSN) が取得され、更新されているページのページ・ヘッダーに保管されます。 この時点で、ページが変更されます。 最後に、ページがアンラッチおよび固定解除されます。 このページは、「ダーティー」ページとみなされます。 このページに変更があるものの、 ディスクにこれが書き出されていないためです。 ログ・バッファーも更新されています。

ログ・バッファーおよび「ダーティー」データ・ページの両方とも、 ディスクに強制書き込みされる必要があります。 パフォーマンスが低下しないようにするため、これらの入出力は、 適当なとき (たとえば、システム負荷が落ち着いたとき) まで、 あるいは回復性を保証しなければならなくなった時まで、 または結合回復時まで後回しにされます。 厳密に言うと、以下の場合に「ダーティー」ページがディスクに強制書き込みされます。

以下の場合に、 ログ・バッファーはロガー・エンジン・ディスパッチャブル・ユニット (EDU) によりディスクに強制書き込みされます。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]