Проверка плана запроса

После того, как вы идентифицировали медленно выполняющиеся запросы и начальные проверки не выявили основные причины проблем, имеет смысл проанализировать план запроса, сгенерированный базой данных для медленно выполняющегося запроса. Интерпретировать эти планы и (особенно) сделать правильные выводы из полученных результатов не всегда просто, и вам может понадобиться помощь специалистов по базам данных.

Симптомы

Если цель заключается в том, что нужно изменить или извлечь лишь несколько строк из некоторых больших таблиц, то лучший метод - дать серверу базы данных возможность найти соответствующие строки с использованием индексов, а не сканирования таблиц.

Диагностика проблемы

Для проверки плана запроса, используемого для конкретного SQL, можно использовать следующие методы.

Oracle:
- План запроса в установках на основе Oracle можно посмотреть непосредственно в консоли администрирования базы данных. Вставьте запрос в окно команд SQL и щелкните по Объяснить план.
  Прим.: Не нажимайте Выполнить запрос, особенно если вы изучаете оператор update, insert или delete.
DB2:
- Для генерирования планов запросов в DB2 есть несколько опций, но предпочтительная опция - использование утилиты db2exfmt, так как сгенерированные выходные результаты будут наиболее подробными.
- Чтобы сгенерировать план запроса, сделайте следующее:
  1. Войдите на сервер DB2 как владелец экземпляра.
  2. Убедитесь, что таблицы существуют или создайте их заново. Подробности смотрите в Информационном центре DB2. Например:
    db2 connect to <database name> db2 "CALL SYSPROC.SYSINSTALLOBJECTS('EXPLAIN', 'C',CAST (NULL AS VARCHAR(128)), CAST (NULL AS VARCHAR(128)))" или db2 connect to <database name> cd ~/sqllib/misc db2 -tvf EXPLAIN.DDL
  3. Сохраните проблемный оператор SQL в файле (например, sql1.sql). Операторы должны заканчиваться символом ;. Либо используйте полные имена таблиц, включая имя схемы, либо добавьте к началу оператора SQL текущий оператор схемы, например:
    set current schema nes1011b; select * from (SELECT itm_id, itm_primary_key pk , '' d FROM tctg_itm_item WHERE itm_id IN ( select pk_row.ita_item_id from tctg_ita_item_attributes pk_row where pk_row.ita_node_id = 1657 and pk_row.ita_value_string like '%335245' ESCAPE '\' and pk_row.ita_next_version_id >= 999999999 and pk_row.ita_version_id <= 999999999 and pk_row.ita_catalog_id = 1602 fetch first 500 rows only ) AND itm_container_id = 1602 AND itm_version_id <= 999999999 AND itm_next_version_id >= 999999999 ORDER BY UPPER(pk) ) AS OM98 fetch first 10 rows only;
  4. Используйте команду db2exfmt, чтобы сгенерировать план запроса:
    db2 set current explain mode explain db2 -tvf sql1.sql db2exfmt -d <dbname> -# 0 -w -1 -g TIC -n % -s % -o sql1_exfmt. db2 set current explain mode no
    Сгенерированный файл sql1_exfmt содержит графический план запроса со статистической информацией о каждом действии извлечения данных.
    Можно также использовать функцию db2support для сбора диагностической информации, относящейся к оптимизатору.
  5. Введите следующую команду как владелец экземпляра DB2:
    db2support . -d <dbname> -sf search.sql -cl 1
    Будет создан файл db2support со всей запрошенной информацией и с выходными результатами db2exfmt. Дополнительную информацию смотрите в технической записке DB2: https://www-304.ibm.com/support/docview.wss?uid=swg21106550

Разрешение проблемы

Если оптимизатор выбирает неэффективный план доступа (например, сканирование больших таблиц или использование неподходящих индексов - индексов, которые не содержат столбцы, используемые как предикаты поиска), то это может быть обусловлено следующими причинами:

статистика неактуальна (обновите статистику)
статистика сгенерирована с использованием неподходящего метода выборки (используйте коэффициент выборки 100%)
индекс не содержит правильный набор столбцов, обеспечивающий быстрый доступ (убедитесь, что компоновка таблицы и индекса соответствует схеме InfoSphere MDM Collaboration Server по умолчанию).

Последнее изменение: 23 октября 2014