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