Page History

...

• 交互参照順序の形式はサポートされていません。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 ユーザーガイド』「コ ンパイルと編集の設定」の&<a href="../../../lansa010/content/lansa/ladugub7_0035.htm"&>「HST に追加する拡張テーブルを許可」&</a&> を参照してください。進数の列の場合は、そのバイト長ではなく、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 または任意の形式の相対レコードのアドレス指定
• 任意の形式の ISS_MSG パラメータ

...

高速テーブルについてのよくある質問には、以下のようなものがあります。

質問：高速テーブルには、どのようなタイプのテーブルが適していますか?

一般的には、以下のような特性をもつデータベース・テーブルが、高速テーブルの実装に適していると言えます。

• データの内容が、デコード (例：州コード "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 が作成されると、テーブルに対して実行される挿入、更新、削除の回数をカウントするための補助的なコードが追加されます。

...

• テーブルとミラーの索引は、実際は同時に保守されるわけではありません。テーブルが閉じられると、まずミラーリングされた既存の索引エントリーが削除され、その次にテーブルの更新されたバージョンを基に索引エントリーが再作成されます。
• テーブルおよびそのすべてのビューは、個別の高速索引データで維持管理されます。つまり、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''')

質問：テーブルのレイアウトを変更すると、どうなりますか?

テーブルのレイアウトを変更して変更を実行可能にすると、テーブルと索引との再同期が自動的に実行されます。この自動同期は、変更された定義を変更後に他のシステムにエクスポートした場合は実行されません。

質問：高速テーブルを他のシステムにインポートするとどうなりますか?

高速テーブルは、通常のテーブルと同様に他のシステムへインポートされます。しかし、テーブルのデータがインポートされた場合、またはテーブル・レイアウ トが変更された場合は、関連の索引は自動的に更新または再フォーマットされることはありません。索引の更新または再フォーマットを行うためには、前述した方法のいずれかを使用して、テーブルとその索引との「再同期」を起動してください。

警告 警告

• 拡張入力レコード長を使用可能にするためにシステム・データ域 DC@OSVEROP に *HSTABEXTEND オプションが追加された場合、または拡張入力 レコード長を削除してエントリーの長さを制限する場合は、高速テーブルとして設定されたすべてのテーブル、これらのテーブルを使用する読み取り専用のすべてのファンクション、および検索の妥当性検査のために高速テーブルを使用する他のすべての OAM と DBOPTIMIZED ファンクションを、現在のユーザー索引の削除後に再コンパイルすることを強くお勧めします。なお、この現在のユーザー索引とは、*HSTABEXTEND を追加する場合は DC@TBLIDX、*HSTABEXTEND を削除する場合は DC@TBLIDY です。
• 上記のことを実行しない場合は、特定のテーブルとOAM を使用するすべてのファンクションを同時に再コンパイルする必要があります。そうしないと、これらのファンクションは同じ索引を指し示さなくなります。検索の妥当性検査のために高速テーブル・テーブルを使用する OAM と DBOPTIMIZED ファンクションが、間違った索引を指し示すため、状況はさらに複雑になります。データベース・テーブルと特定の索引が非同期化されてもプログラム障害が発生しないため、ユーザーが問題を認識することができない場合があります。

...