В таблице sysdepend документы просматривают зависимости. Столбцы:
- btabid - идентификационный номер базовой таблицы
- btype - обычно T для таблицы или V для просмотра
- dtabid - ИД таблицы зависимых таблиц
- dtype - обычно T для таблицы или V для просмотра
Следовательно, для данного представления с tabid N вы можете написать:
SELECT b.owner, b.tabname, d.*
FROM "informix".systables b, "informix".sysdepend d
WHERE d.dtabid = N
AND d.btabid = b.tabid;
Если вы знаете только имя представления, то определение tabid представления на удивление сложно, если ваша база данных является базой данных MODE ANSI, где у вас может быть несколько таблиц с одинаковым именем таблицы (или именем представления в этом случае), но каждая с другой владелец. Однако в обычном случае (база данных не-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;
Вопрос задает вопрос об индексах, используемых представлением. Индексы не используются представлением как таковым; индексы используются механизмом запросов при обработке запроса, но используемые индексы могут изменяться в зависимости от общего запроса - поэтому для этих двух запросов могут использоваться разные индексы:
SELECT * FROM SomeView;
SELECT * FROM SomeView
WHERE Column1 BETWEEN 12 AND 314;
Индексы, которые будут использоваться, нигде не записаны в системном каталоге; они переопределяются динамически, когда готовится инструкция.
Вопрос также отмечает:
Справочная информация. Мне необходимо убедиться, что некоторые критические представления указывают на текущие (например, после "реорганизации") таблицы. Слишком часто я видел представления, указывающие на старые таблицы резервных копий, которые больше не индексируются и на которые уходит бесконечный запрос.
Как вы проводите реорганизацию? Вы создаете новую таблицу с нужной структурой, копируете данные из старой в новую, затем переименовываете старую, переименовываете новую? Это, вероятно, будет объяснением - переименование таблицы перерабатывает представления, которые ссылаются на таблицу. Какую форму реорганизации вы делаете? Можете ли вы использовать другую технику? Классическим резервом является использование ALTER INDEX indexname TO CLUSTER (после изменения на NOT CLUSTER, если он уже был кластеризован). Это перестраивает таблицу и индексы - без нарушения представлений. В качестве альтернативы вы можете рассмотреть операцию ALTER FRAGMENT.
Также немного странно держать старые столы рядом. Это говорит о том, что ваша реорганизация - это скорее вопрос удаления старых данных. Возможно, вам следует разбить таблицу на диапазоны дат, чтобы отсоединить фрагмент, когда он достиг даты окончания срока полезного использования. Удаление таблиц также приведет к удалению зависимых от него представлений, что позволит перестроить представления с новыми именами таблиц.
Поэтому другой альтернативой является просто обеспечение того, чтобы реорганизация отбрасывала и воссоздала представления.
Мне нужно регулярно идентифицировать эти запросы и «напоминать» настраиваемому администратору баз данных для перестройки представлений / индексов.
Беспокойно ... это должно быть частью стандартной процедуры завершения реорганизации. По сути, в этой процедуре вы можете сообщить об ошибке - это не гарантирует, что представления полностью работоспособны.