Перевод.
Оригинал находится по ссылке.
Одна из частей моей работы здесь в Rittman Mead состоит в чтобы следить за производительностью ХД, как с точки зрения запросов, сформированных пользователями, так и с точки зрения ETL процессов, загружающих данные в хранилище данных. Иногда я изучаю ситуацию в уже существующей системе, иногда же моя работа является частью процесса разработки нового комплекса.
Недавно, меня попросили посмотреть на таблицу, использующую очень сложную логику агрегации и расчетов, при этом расчеты проводились в ситуации почти реального времени. Передо мной поставили три жестких условия: генерировать как можно более малый объем redo лога, обновление таблицы должно быть максимально быстрым и данные в целевой таблице должны быть доступны все время – нет такого периода времени, даже во время обновления, в течение которого к данным нельзя обратиться через запрос. Я решил, что в этом случае подход с обменом секциями (партициями), с использованием операции truncate и вставки добавлением в обменную таблицу сработает лучше всего.
Добавим к этому пару специальных штучек Exadata, таких как гибридное сжатие столбцов в целевой таблице - и все путем. Для вставки я должен использовать хинт чтобы сообщить Oracle, что нужно использовать direct path load метод для вставки и второй хинт, чтобы выполнять вставку данных в параллельном режиме.
Обычно я не очень люблю использовать хинты. По моему мнению, использование хинтов говорит о том, что оптимизатор стоимости выполнения (CBO) не получил все, что ему нужно, чтобы выполнить свою работу; это может быть связано со статистикой (отсутствует или устарела), отсутствие необходимых ограничений целостности в БД (чем больше мы сообщим CBO о данных, тем лучше), или, как я видел в некоторых случаях, использование хинтов на самом деле не помогает в текущей ситуации.
Хинт, добавленный в запрос во времена Oracle 8i, может принести больше вреда, чем пользы. Так же и в ситуациях, когда хинт добавляется по причине - "а мы всегда добавляем такой хинт в этих типах запросов" или "А я его нагуглил",- результаты могут стать не тем, на что мы рассчитывали.
В основном, я использую хинты только при черновой разработке SQL запросов, и использование хинтов напоминает мне, что CBO не может делать свою работу так хорошо, как должен был, потому что я не предоставил ему доступа ко всей нужной информации. И меня немного настораживает, если CBO по прежнему нуждается в хинтах когда код идет на продуктив. На самом деле есть некоторые моменты в ХД, с которыми у CBO могут возникнуть проблемы – коррелированные колонки это один из примеров. Корреляция может привести к неправильной оценке мощности количества затрагиваемых строк.
Я всегда использую хинты которые изменяют способ выполнения чего-то базой данных – и слово хинт для этих целей - слово не совсем подходящее. Например, хинт APPEND это фундаментально другой способ вставки данных в таблицу, это намного больше, чем просто указать, какой использовать индекс, или указание на соединение с использованием вложенных циклов (nested loop).
Так же и в ситуации с GATHER_PLAN_STATISTICS хинтом – мы сообщаем Oracle изменить что-то более важное, чем план выполнения запроса. Я выбрал APPEND режим для вставки данных, потому что характеристики такого типа добавления данных подходят под то, что мне нужно сделать, будь это вставка без логгирования, сжатие данных или что-либо другое, для чего используется прямая загрузка. Относительно запросов – я не слишком волнуюсь, как они выполняются, главное, чтобы они делали это как можно быстрее и результаты были корректными.
И последнее замечание относительно хинтов. Подготовка и использование хинтов в процессе разработки не обязательно приведет к тому же плану выполнения запросов на другой системе. Конечно, это относится и к SQL запросам без хинтов. Но никогда не рассчитывайте на то, что то, что дает хорошие результаты на одной системе, будет так же хорошо и на другой. Или, говоря иначе, проверяйте ваш код во всех системах, где вы его собираетесь использовать.
Смотри также: Использование хинтов в OBIEE
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.