3.6.14 IBM i 高速テーブル
「読み取り専用」の場合に、より高速にアクセスできるように対象のテーブル定義と関連のインデックスを高速の IBM i ユーザー索引にミラーリングするかどうかを指定します。
以下の各項目は、IBM i の高速テーブル機能についての基本情報です。この機能を使用する前に、必ずこれらの項目を読んで理解しておいてください。
- 高速テーブル自体は「物」ではありません。高速テーブルとは「高速」フラグが YES に設定されている通常の LANSA テーブル定義のことです。
- 高速テーブルとしてフラグの立てられた LANSA テーブル定義は、通常のデータベース・テーブルとして実装されます。テーブルにデータを挿入したり、これを 更新または削除したりするファンクションは、すべて通常のデータベース・テーブルに実際にアクセスして実行されます。
この通常のデータベース・テーブルには実際にデータが含まれているため、データ損失の危険があるという点で通常のファイル定義と高速テーブルとの間に何ら違いはありません。
また、高速テーブルのフラグを NO に戻せば、定義やデータを失わずにいつでも通常のデータベース・テーブルに再度戻せるということも意味しています。
通常のファイルと高速テーブルの違いは、高速テーブルが(通常のデータベース・テーブルの他に)追加のオブジェクトを使用することです。このオブジェクトは IBM i で「ユーザー索引」と呼ばれ、関連のデータベース・テーブルとそのインデックス内にデータの複製または「ミラー」を保持します。
テーブルを読み取るだけのファンクションは、実際にユーザー索引内の「ミラー」データにアクセスします。このようなアクセス方法には、次のような顕著な利 点があります。
- 通常のデータベース・テーブルを開いたままにしておくことに関連する通常のスペース (PAG) のオーバーヘッドがほとんどない
例えば、40 個のデータベース・テーブルを開くような従来の商用アプリケーションでは、40 個のテーブルを開き、その後開いたままにしておくためのスペー スおよび時間には大幅なオーバーヘッドが存在します。
しかし、これらのテーブルのうち 20 個が高速テーブルとして実装された場合は、スペースと時間のオーバーヘッドが約 50 %に減少します。これによって、このアプリケーションのパフォーマンスは大幅に向上するはずです。高速テーブル索引は、IBM i の「プラットフォーム固有」のオプションです。他のプラッ トフォーム上では、「高速テーブル」フラグは無視されて他のテーブルと同様に実装されます。
これは設計上の考慮事項かもしれませんが、通常のデータベース管理機能を使用している他のプラットフォーム上では、あまり高速な IBM i のユーザー索引を使用しないでください。高速なユーザー索引を使用して改良し過ぎるとアプリケーションが機能しなくなる可能性があります。IBM i のユーザー索引機能の詳細とその用途については、IBM の Information Center に説明されています。既存の 3GL ベースのアプリケーション・プログラムから、この高速テーブルにアクセスすることも可能です。
デフォルト：NO (チェックなし/未選択)
使用規則
高速テーブルとして有効であるためには、テーブル定義が以下のルールに従っている必要があります。これらの項目の大部分は、テーブルの作成または変更を「実行可能」にする段階で検査されます。ルールに違反すると、該当のエラー・メッセージが表示されて、実行可能にする処理は失敗します。
これらのルールは、以下の基本的な物理テーブル定義とそれに対して定義されるインデックスすべてに適用されます。
- 交互参照順序の形式はサポートされていません。IBM i のユーザー索引機能は、単純なバイナリー参照しかサポートしていません。
"SC21-8226" (マニュアル番号) のマニュアルには、IBM i のユーザー (または独立) 索引へのアクセスについての詳しい説明がありますが、以下はこのマニュアルからの引用です。
「各エントリーは、引数のバイナリ値に基づく適切な位置の索引へ挿入されます。他の参照順序はサポートされていません。」
- キー列はすべて昇順で、値は符号なしである必要があります。
- テーブルのキー・リスト内に日付、時刻、時刻スタンプ列を持つテーブルが高速テーブルへミラーリングされる場合は、読み取り専用でテーブルへアクセスする LANSA テーブルは、OAM を使用しません。日付、時刻、時刻スタンプ列ドは、高速テーブル内で英数字列として扱われ ます。したがって、レコードを取り込む際は、値を略さずに入力する必要があります (例えば、1999-1-2 ではなくて、1999-01-02 と入力します)。また、無効な値が入力されると、LANSA ファンクションは日付、時刻または時刻スタンプの有効性を検査せず、単に存在しないというステータスを返すのみです。
- テーブルに含めることのできる列数は、 99 個までです。
- テーブル入力の最大レコード長は、システム・データ域の DC@OSVEROP によって決まります。*HSTABEXTEND オプションが挿入されている場合は、最大入力レコード長は 1988 バイト (OS/400 の制限) で、最大キー長は 108 バイト (LANSA の記憶域とパフォーマンス上の理由による制限) です。キーは 1988 バイトのレコード長に含まれます。*HSTABEXTEND オプションがシステム・データ域にない場合は、テーブル入力レコード長は 108 バイト以内である必要があります。警告：108 バイトを超える入力レコード長は、OS/400 の V2R2M0 よりも前のリリースへは保管できず、またそこから復元することもできません。10 進数の列の場合は、そのバイト長ではなく、10進数の桁数がカウントされます。詳細については『LANSA/AD ユーザーガイド』「コ ンパイルと編集の設定」の「HST に追加する拡張テーブルを許可」 を参照してください。
- 基本物理テーブルには、1 つ以上の 1 次キー列が必要です。
- 高速テーブル実行環境においては、テーブル・メンバー、実行時ライブラリ・リストの変更、およびテーブルのオーバーライドまたはリネームという概念はサポートされていません。高速テーブル索引は、LANSA 区画ごとに 1 つあります。索引へのアクセスが必要なアプリケーションが呼び出されると、このアプリケー ションは現在の区画に関連付けられた単一の索引を使用します。
- テーブル内のすべての列に対して、列レベルまたはテーブル・レベルでの「OPEN (開く)」、「READ (読み取り)」、または 「CLOSE (閉じる)」のトリガーは指定できません。
- 仮想列またはロジック (コード) は定義できません。
- テーブルに対する読み取り機密保護は機能しません。つまり、高速テーブルの内容を読み取るファンクションを停止させることはできません。しかし、高速テーブルの内容を変更するファンクションは、通常の方法で停止させることができます (これは、高速索引を変更しているのではなく、実際に通常のデータベース・テーブルを変更しているためです)。
この制約によって、読み取り専用アプリケーションのパフォーマンスを最大限に高めることができます。読み取り機密保護を適用すると、ほんの数件のアクセス しか実行されていない場合でも、テーブルのパフォーマンスに重大な影響を与えます。
事実、機密保護検査にかかる時間は、多数のテーブル・エントリーへのアクセスの実時間よりもはるかに長いためです。
- 高速テーブルとして設定されたテーブルを変更 (INSERT、UPDATE、またはDELETE) するファンクションでは、*DBOPTIMISE、*DBOPTIMISE_BATCH、またはこれらのオプションと結果的に同様の意味を持つ他のオプションを使用することはできません。
この制約がある理由は、実テーブル・データを高速索引にミラーリングするために必要な特別なロジックが、関連の OAM 内にしか存在しないためで す。このため、すべての「テーブル変更機能」は、該当の OAM を使用する必要があります。
- 高速テーブルからの読み取りのみを行うファンクションは、通常の方法で *DBOPTIMISE または *DBOPTIMISE_BATCH を使用することがで きます。
- 高速テーブルの定義 (つまり、レイアウト) を変更する場合は、実テーブルではなく、高速テーブルから読み取るファンクションと OAM をすべて再コ ンパイルする必要があります。この場合も、パフォーマンスを最大にするために、この制約が設けられています。
テーブルは設計と内容については本来大部分が静的であるため、これは問題にはなりません。もし問題になるようであれば、テーブル定義から高速テーブル・オプションを除去してください。
- 高速テーブルから読み取るのみのアプリケーションでは、ロックはサポートされていません。「読み取り専用」ファンクションでレコードのロックが必要な場合は、対象のテーブルは高速テーブル機能に適していません。
- 高速テーブルに対する以下の各機能の使用については検査されませんが、高速テーブルへの「読み取り専用」アクセスが必要なファンクションでは以下の機能はいかなる形式でもサポートされません。
- *OPNQRYF オプションの付いた OPEN コマンドの使用
- 任意の形式での *BLOCKnnn オプションの使用
- 任意の形式での SELECT_SQL オプションの使用
- WITH_RRN、RETURN_RRN または任意の形式の相対レコードのアドレス指定
要約すれば、高速テーブル機能とは、シンプルな検索とデコード型のテーブル用にのみ設計されたものであるということです。他の高度な方法で使用されるテーブルは、高速テーブルとして実装しないでください。
ヒントとテクニック
高速テーブルについてのよくある質問には、以下のようなものがあります。
質問：高速テーブルには、どのようなタイプのテーブルが適していますか?
一般的には、以下のような特性をもつデータベース・テーブルが、高速テーブルの実装に適していると言えます。
- データの内容が、デコード (例：州コード "CA" は "CALIFORNIA" と印刷される) や妥当性検査 (例：州コード "CA" が妥当かどうか) に広く使用されるファイル
- データの内容が比較的安定しているテーブル (例：州の名前)。一般には、毎日頻繁に、しかもランダムに変更されるようなファイルではないことです。製品が頻繁に作成されたり変更されたりしないため、製品の記述のみが含まれている「製品」テーブルなどは高速テーブルに適しています。ただし、在庫数量の情報も含まれている場合は、在庫数量が絶えず変更されるため適していません。
- 通常、少数のレコードしか含まれていないテーブル (例：5,000 件以下)
- テーブルを保守するアプリケーションが通常1つしかなく、それもあまり頻繁には使用されない (例えば、使用頻度が 1 日に 1 度使用されるかどうかの) テーブル
- 大部分のアプリケーションが、デコードと妥当性検査の目的でテーブルから「読み取り」のみを行うようなテーブル
質問：高速テーブルのデータはどこに保管されますか?
高速テーブルとしてフラグの立っている LANSA テーブル定義も、他のテーブルと同様に設定されます。実際のテーブル・データは、この通常のテーブルに格納され維持管理されます。ただし、データはまた「読み取り専用」高速索引にミラーリングされ、「読み取り専用」アプリケーションから非常に高速にアクセスできるようになります。
この高速索引は、実際は IBM i のユーザー索引 (オブジェクト・タイプは *USRIDX) です。このユーザー索引は、現在の区画のモジュール (またはプログラム) ライブラリ内に自動的に作成され、そこに常駐している必要があります。この索引はユーザーが作成する必要はありませんが、定期的に削除し再作成することも可能です。このユーザー索引の例を探す際のポイントは、ユーザー索引に DC@TBLIDX という名前が付いているかどうかを見つけることです。
質問：高速索引のバックアップは必要ですか?
必要ありません。個々のテーブルにはそれぞれ関連するデータの実テーブルがあり、そこには「実」データが含まれているため、すべてのテーブルの高速索引を 組み込み関数のREBUILD_FILE_INDEXを使用して、ほんの数分で再作成することができます。
ただし、万一復元手順を呼び出す必要がある場合は、索引と「実」データを含む関連のデータベース・テーブルのすべてが同期しているバックアップがあれば、復元手順を簡略化して高速化できる場合があります。
質問：高速索引へのアクセスは、どのような場合に行われるのですか?
LANSA コード変換機能は、さまざま時点で、データベース・テーブルにアクセスするコードを生成する可能性があります。この生成が実行され、呼び出されるテーブルが高速テーブルである場合は、以下のような場合に、実テーブルの代わりに高速索引が実際にアクセスされます。
- CHECK_FOR、FILECHECK、FETCH または SELECT コマンドを使用して、テーブルから「読み取り」のみを行う RDML ファンクションの場合。RDML ファンクションがコンパイルされる際、高速テーブルへ直接アクセスできるかどうかの検査が行われます。このファンクションで使用されるすべての高速テーブルへのアクセスがいずれも「読み取り専用」である場合は、I/O は実データベース・テーブルではなく、高速テーブルに対して行われます。
- テーブル間の妥当性検査が行われる場合。妥当性検査の結果、テーブルのエントリーを検索する必要のある OAM または *DBOPTIMISE で生成されたコードは、実テーブルではなく、必ず高速索引を検索します。
質問：高速テーブルで *DBOPTIMISE または *DBOPTIMIZE を使用できますか?
はい、ファンクションが高速テーブルを更新する場合を除いて、どのような場合でも可能です。高速テーブルを更新するファンクションは、テーブルへのすべての I/O を、関連する OAM を通じて行う必要があります。これにより、実データ・テーブルとミラーリングされた高速索引は、同時に更新されるようになります。
質問：高速索引の更新は、どのような場合に行われるのですか?
高速テーブルとしてフラグの立っているファイルに対して OAM が作成されると、テーブルに対して実行される挿入、更新、削除の回数をカウントするための補助的なコードが追加されます。
テーブルが閉じられる際にこのカウントが検査され、0 より大きければそのテーブルの既存のエントリーのすべてが高速索引から消去されます。次に、高速索引に新しいエントリーを挿入するために、実テーブル (およびそのビュー) 全体が読み取られます。
このアーキテクチャは、以下のような仕組みを持ち、また高速テーブルの使用に影響を与えます。
- テーブルとミラーの索引は、実際は同時に保守されるわけではありません。テーブルが閉じられると、まずミラーリングされた既存の索引エントリーが削除され、その次にテーブルの更新されたバージョンを基に索引エントリーが再作成されます。
- テーブルおよびそのすべてのビューは、個別の高速索引データで維持管理されます。つまり、1 つのテーブルにビューが 4 つある場合は、実際はソース・テーブルの索引スペースを 5 倍使用することになります。これは、索引がテーブル自体に 1 つ、そして各ビューに 1 つずつあるためです。
- 複数のユーザーが高速索引ミラーを持つテーブルを同時に更新しようとすると、競合が発生する可能性があります。この問題は、高速テーブルを更新するアプリケーションを、1 ユーザーのアクセスに制限すれば、簡単に解決できます。
あるファンクションを 1 ユーザーのアクセスに制限するために使用される簡単な方法がいくつもあります。このようなアプリケーションを設計する際に支援が必 要であれば、製品の販売代理店までご連絡ください。
質問：「実」テーブルと索引との同期が取れていない状態になることはありますか?
前項の説明からもわかるように、テーブルとそのミラーリングされた高速索引との同期が取れていない状態になる可能性があります。例えば、あるファンクションが 1 つのテーブルに 3 つの新規エントリーを挿入した直後にエラーが発生したとします。この時点では、各新規エントリーは実テーブル内に格納されていますが、高速索引には反映されていません。
質問：同期が取れていない状態は、どのようにすれば修正することができますか?
テーブルとその高速索引との同期が取れていない場合に、それらを再度同期させるには、以下の処理を実行してください。
- テーブルに対して「ダミー」の更新を行います。この更新により、関連する OAM は更新されたテーブルを反映するために索引を再作成します。このため、テーブルと索引は再び同期した状態になります。
- 組み込み関数の REBUILD_FILE_INDEX を使用して手作業で I/O モジュールを起動し、ファイル (複数可) の索引を再作成します。
実際には、次の一連のコマンドにより、IBM i のユーザー索引域全体が物理的に削除された後、現在の区画内にあるすべての高速テーブルの索引が再作成さ れます。IBM i のユーザー索引が存在していない場合は、最初に再作成されたテーブルがこれを再作成します。
EXEC_OS400 CMD('DLTUSRIDX DC@TBLIDX')
USE BUILTIN(REBUILD_FILE_INDEX) WITH_ARGS('''*ALL''')
質問：テーブルのレイアウトを変更すると、どうなりますか?
テーブルのレイアウトを変更して変更を実行可能にすると、テーブルと索引との再同期が自動的に実行されます。この自動同期は、変更された定義を変更後に他のシステムにエクスポートした場合は実行されません。
質問：高速テーブルを他のシステムにインポートするとどうなりますか?
高速テーブルは、通常のテーブルと同様に他のシステムへインポートされます。しかし、テーブルのデータがインポートされた場合、またはテーブル・レイアウ トが変更された場合は、関連の索引は自動的に更新または再フォーマットされることはありません。索引の更新または再フォーマットを行うためには、前述した方法のいずれかを使用して、テーブルとその索引との「再同期」を起動してください。
注：1GB を超えるユーザー索引、または入力レコード長が 108 バイトを超えるユーザー索引は、OS/400 の V2R2M0 よりも前のリリースに保管することも、そこから復元することもできません。
警告
- 拡張入力レコード長を使用可能にするためにシステム・データ域 DC@OSVEROP に *HSTABEXTEND オプションが追加された場合、または拡張入力 レコード長を削除してエントリーの長さを制限する場合は、高速テーブルとして設定されたすべてのテーブル、これらのテーブルを使用する読み取り専用のすべてのファンクション、および検索の妥当性検査のために高速テーブルを使用する他のすべての OAM と DBOPTIMIZED ファンクションを、現在のユーザー索引の削除後に再コンパイルすることを強くお勧めします。なお、この現在のユーザー索引とは、*HSTABEXTEND を追加する場合は DC@TBLIDX、*HSTABEXTEND を削除する場合は DC@TBLIDY です。
- 上記のことを実行しない場合は、特定のテーブルとOAM を使用するすべてのファンクションを同時に再コンパイルする必要があります。そうしないと、これらのファンクションは同じ索引を指し示さなくなります。検索の妥当性検査のために高速テーブル・テーブルを使用する OAM と DBOPTIMIZED ファンクションが、間違った索引を指し示すため、状況はさらに複雑になります。データベース・テーブルと特定の索引が非同期化されてもプログラム障害が発生しないため、ユーザーが問題を認識することができない場合があります。
プラットフォームについて
- IBM i：このテーブル属性は、IBM i のデータベースのみに適用されます。
