Какой SQL-запрос показывает мне таблицы и индексы, используемые представлением Informix?

StackOverflow https://stackoverflow.com/questions/307983

  •  08-07-2019
  •  | 
  •  

Вопрос

Какой 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.

Также кажется немного странным хранить старые таблицы.Это говорит о том, что ваша реорганизация — это скорее вопрос удаления старых данных.Возможно, вам следует фрагментировать таблицу по диапазонам дат, чтобы отделить фрагмент, когда он достигнет даты окончания срока службы.Удаление таблиц также приведет к удалению зависимых от них представлений, что гарантирует перестроение представлений с новыми именами таблиц.

Поэтому другой альтернативой является просто гарантировать, что реорганизация отбросит и заново создаст представления.

Мне нужно регулярно идентифицировать эти запросы и «напоминать» администратору базы данных о необходимости перестроить представления/индексы.

Вызывает беспокойство... это должно быть просто частью стандартной процедуры завершения реорганизации.По сути, вам нужно сообщить об ошибке в этой процедуре — она не гарантирует, что представления полностью работоспособны.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top