この表は、sysdepend
ビューの依存関係を示しています。列は次のとおりです。
- btabid - ベーステーブル ID 番号
- btype - 通常、テーブルの場合は T、ビューの場合は V
- dtabid - 従属テーブル ID 番号
- dtype - 通常、テーブルの場合は T、ビューの場合は V
したがって、タブ ID が N の特定のビューに対して、次のように記述できます。
SELECT b.owner, b.tabname, d.*
FROM "informix".systables b, "informix".sysdepend d
WHERE d.dtabid = N
AND d.btabid = b.tabid;
ビュー名しか知らない場合、データベースが MODE ANSI データベースであり、同じテーブル名 (またはこの場合はビュー名) を持つ複数のテーブルがあり、所有者がそれぞれ異なる場合、ビューのタブ ID を決定するのは驚くほど困難です。ただし、通常の場合 (非 ANSI データベース、または一意のテーブル/ビュー名)、クエリは非常に簡単です。
SELECT b.owner, b.tabname, d.*
FROM "informix".systables b, "informix".sysdepend d
WHERE d.dtabid = (SELECT v.tabid FROM "informix".systables v
WHERE v.tabname = "viewname"
)
AND d.btabid = b.tabid;
質問は、ビューで使用されるインデックスについて尋ねます。インデックスはビュー自体では使用されません。インデックスは、クエリを処理するときにクエリ エンジンによって使用されますが、使用されるインデックスはクエリ全体に応じて変化する可能性があるため、これら 2 つのクエリには異なるインデックスが使用される可能性があります。
SELECT * FROM SomeView;
SELECT * FROM SomeView
WHERE Column1 BETWEEN 12 AND 314;
使用されるインデックスは、システム カタログのどこにも記録されていません。これらは、ステートメントが準備されるときに動的に再決定されます。
質問には次のことも記載されています。
背景: 一部の重要なビューが現在の (たとえば、「再編成」された後) テーブルを指していることを確認する必要があります。インデックスが作成されていない古いバックアップ テーブルを参照しているビューを頻繁に見てきました。
再編成はどのように行いますか?目的の構造を持つ新しいテーブルを作成し、データを古いものから新しいものにコピーしてから、古い名前を変更し、新しい名前を変更しますか? それはおそらく説明です-テーブルの名前を変更すると、テーブルを参照するビューが作り直されます。どのような組織再編を行っていますか?別のテクニックを使用できますか?従来のスタンバイでは、ALTER INDEX indexname TO CLUSTER を使用します (既にクラスター化されている場合は、NOT CLUSTER に変更した後)。これにより、ビューが壊れることなく、テーブルとインデックスが再構築されます。または、ALTER FRAGMENT 操作を検討できます。
また、古いテーブルをそのままにしておくのも少し奇妙に思えます。これは、再編成が古いデータの削除の問題であることを示唆しています。おそらく、テーブルを日付範囲でフラグメント化して、「耐用年数の終わり」の日付に達したときにフラグメントを切り離す必要があります。テーブルを削除すると、それに依存するビューも削除されるため、新しいテーブル名でビューを再構築することが保証されます。
したがって、もう 1 つの方法は、再編成によってビューが削除され、再作成されるようにすることです。
これらのクエリを定期的に特定し、チューニング DBA にビュー/インデックスを再構築するよう「通知」する必要があります。
気になる…これは、再編成を完了するための標準的な手順の一部であるべきです。基本的に、その手順で報告するバグがあります。ビューが完全に機能することを保証するものではありません。