The table sysdepend documents view dependencies. The columns are:
- btabid - base table ID number
- btype - normally T for table or V for view
- dtabid - dependent table ID number
- dtype - normally T for table or V for view
Consequently, for a given view with tabid N, you can write:
SELECT b.owner, b.tabname, d.*
FROM "informix".systables b, "informix".sysdepend d
WHERE d.dtabid = N
AND d.btabid = b.tabid;
If you only know the view name, then determining the view's tabid is surprisingly tricky if your database is a MODE ANSI database where you may have multiple tables with the same table name (or view name in this case) but each with a different owner. However, in the usual case (a non-ANSI database, or a unique table/view name), the query is easy enough:
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;
The question asks about the indexes used by a view. Indexes are not used by a view, per se; indexes are used by the query engine when processing a query, but the indexes used could change depending on the total query - so different indexes might be used for these two queries:
SELECT * FROM SomeView;
SELECT * FROM SomeView
WHERE Column1 BETWEEN 12 AND 314;
The indexes that will be used are not recorded anywhere in the system catalog; they are redetermined dynamically when a statement is prepared.
The question also notes:
Background: I need to make certain that some critical views point to current (e.g. after being "reorganized") tables. Too often I have seen views pointing to old backup tables, that were no longer indexed, and took forever to query.
How do you do your reorganization? Do you create a new table with the desired structure, copy the data from old to new, then rename old, rename new? That probably would be the explanation - the table renaming reworks the views that reference the table. What form of reorganization are you doing? Can you use a different technique? A classic standby is to use ALTER INDEX indexname TO CLUSTER (after altering it to NOT CLUSTER if it was already clustered). This rebuilds the table and the indexes - without the views breaking. Alternatively, you can consider an ALTER FRAGMENT operation.
It also seems a bit odd to keep the old tables around. That suggests that your reorganization is more a question of dropping old data. Maybe you should fragment your table by date ranges, so that you detach a fragment when it has reached its 'end of useful life' date. Dropping the tables would also drop the views that depend on it, ensuring that you rebuild the views with the new table names.
Another alternative, therefore, is to simply ensure that the reorganization drops and recreates the views.
I need to identify these queries regularly and "remind" the tuning DBA to rebuild the views/indexes.
Worrisome...it should just be part of the standard procedure for completing the reorganization. Basically, you have a bug to report in that procedure - it does not ensure that the views are fully operational.