Какой SQL-запрос показывает мне таблицы и индексы, используемые представлением Informix?
Вопрос
Какой SQL-запрос показывает мне таблицы и индексы, используемые представлением Informix?
Я знаю, как найти «исходный оператор создания» для представления в SYS_VIEWS, но для этого требуется сканирование / поиск человеческого мозга, который выбирает.Я считаю, что смогу определить, проиндексированы ли таблицы, как только они будут идентифицированы.
Фон:Мне нужно убедиться, что некоторые критические взгляды совпадают с текущими (например,после «реорганизации») таблиц.Слишком часто я видел представления, указывающие на старые резервные таблицы, которые больше не индексировались и запрос к которым занимал целую вечность.
Мне нужно регулярно идентифицировать эти запросы и «напоминать» администратору базы данных о необходимости перестроить представления/индексы.
Решение
Стол sysdepend
документы просматривают зависимости.Столбцы:
- btabid — идентификационный номер базовой таблицы
- btype — обычно T для таблицы или V для просмотра.
- dtabid - идентификационный номер зависимой таблицы
- dtype — обычно T для таблицы или V для просмотра.
Следовательно, для данного представления с табидом 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, где у вас может быть несколько таблиц с одним и тем же именем таблицы (или именем представления в данном случае), но каждая из которых имеет разных владельцев.Однако в обычном случае (база данных, не поддерживающая 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. индексное имя TO CLUSTER (после изменения значения на NOT CLUSTER, если оно уже было кластеризовано).Это перестраивает таблицу и индексы без нарушения представлений.В качестве альтернативы вы можете рассмотреть операцию ALTER FRAGMENT.
Также кажется немного странным хранить старые таблицы.Это говорит о том, что ваша реорганизация — это скорее вопрос удаления старых данных.Возможно, вам следует фрагментировать таблицу по диапазонам дат, чтобы отделить фрагмент, когда он достигнет даты окончания срока службы.Удаление таблиц также приведет к удалению зависимых от них представлений, что гарантирует перестроение представлений с новыми именами таблиц.
Поэтому другой альтернативой является просто гарантировать, что реорганизация отбросит и заново создаст представления.
Мне нужно регулярно идентифицировать эти запросы и «напоминать» администратору базы данных о необходимости перестроить представления/индексы.
Вызывает беспокойство... это должно быть просто частью стандартной процедуры завершения реорганизации.По сути, вам нужно сообщить об ошибке в этой процедуре — она не гарантирует, что представления полностью работоспособны.