Oracle для профессионалов
Как ускорить работу?
Вынесенный в название раздела вопрос мне задают постоянно. Все ищут, где бы сделать установку fast = true, предполагая, что настройка производительности базы данных выполняется на уровне СУБД. Мой опыт показывает, что более 80 процентов (часто — намного больше, до 100 процентов) всего повышения производительности достигается на уровне приложения, а не базы данных. Нельзя заниматься настройкой СУБД, пока не настроено приложение, использующее данные.
Со временем появился ряд установок, включая которые на уровне СУБД, можно снизить влияние грубых ошибок программирования. Например, в Oracle 8.1.6 добавлен новый параметр — CURSOR_SHARING=FORCE. Он позволяет включить автоматическое использование связываемых переменных. В результате запрос SELECT * FROM EMP WHERE EMPNO = 1234 автоматически переписывается в виде SELECT * FROM EMP WHERE EMPNO = :x. Это может существенно сократить количество полных разборов и уменьшить ожидание защелок в библиотечном кеше, которые описаны в главе об архитектуре, но (всегда есть но) может также иметь ряд побочных эффектов. Можно нарваться на проблему (или ошибку) при использовании этой возможности, как, например, в первоначальной версии:
ops$tkyte@ORA8I.WORLD> alter session set cursor_sharing=force; Session altered.
ops$tkyte@ORA8I.WORLD> select * from dual where dummy='X'and 1=0; select * from dual where dummy='X'and 1=0 * ERROR at line 1: ORA-00933: SQL command not properly ended
ops$tkyte@ORA8I.WORLD> alter session set cursor_sharing=exact; Session altered.
ops$tkyte@ORA8I.WORLD> select * from dual where dummy='X'and 1=0; no rows selected
Принятый способ переписывания запроса дает некорректный результат в версии 8.1.6 (из-за отсутствия пробела между 'X' и ключевым словом AND). В итоге запрос приобретает вид:
select * from dual where dummy=:SYS_B_0and :SYS_B_1=:SYS_B_2;
Ключевое слово AND стало частью имени связываемой переменной :SYS_B_0. В версии 8.1.7, однако, этот запрос переписывается так:
select * from dual where dummy=:"SYS_B_0"and :"SYS_B_1"=:"SYS_B_2";
Теперь на уровне синтаксиса все работает, но переписывание может отрицательно сказаться на производительности приложения. Например, обратите внимание, что в рассмотренном ранее коде условие 1=0 (всегда ложное) переписано как :"SYS_B_1" = :"SYS_B_2". Теперь на этапе анализа у оптимизатора нет полной информации чтобы определить, вернет ли этот запрос ноль строк (еще до его выполнения). Я понимаю, что запросов с конструкциями типа 1=0 у вас немного, но подозреваю, что в некоторых запросах литералы используются умышленно. В таблице может быть столбец с весьма неравномерным распределением значений (например, 90 процентов значений в столбце — больше 100, а 10 процентов — меньше 100). Причем лишь 1 процент значений меньше 50. Хотелось бы, чтобы при выполнении запроса:
select * from t where x < 50;
индекс использовался, а при выполнении запроса:
select * from t where x > 100;
не использовался. Если установить параметр CURSOR_SHARING = FORCE, оптимизатор не сможет учесть значения 50 или 100, поэтому будет выбирать план для общего случая, когда индекс скорее всего не будет использоваться (даже если 99,9 процентов запросов будут содержать конструкцию WHERE x < 50).
Кроме того, я обнаружил, что, хотя установка CURSOR_SHARING = FORCE
обеспечивает намного большую скорость работы, чем повторный анализ и оптимизация множества одинаковых запросов как уникальных, это все равно медленнее, чем выполнение запросов, где связываемые переменные используются изначально. Это происходит не из-за неэффективности механизма совместного использования кода курсора, а из-за неэффективности самой программы. В главе 10 мы рассмотрим, как анализ операторов SQL может влиять на производительность в целом. Во многих случаях приложение, не использующее связываемые переменные, также не обеспечивает эффективного анализа и повторного использования курсоров. Поскольку в приложении предполагается уникальность каждого запроса (так как для каждого из них создается уникальный оператор), то и курсор в нем не будет использоваться более одного раза. Факт в том, что если программист использует связываемые переменные, то он зачастую также анализирует курсор один раз и затем использует многократно. Именно затраты ресурсов на повторный анализ приводят к наблюдаемому снижению производительности.
Итак, важно помнить, что просто добавление параметра инициализации CURSOR_SHARING = FORCE не всегда позволяет решить проблемы. Могут даже возникнуть новые. Во многих случаях параметр CURSOR_SHARING — действительно полезное средство, но это не панацея. Для хорошо продуманного приложения он не нужен. В долгосрочной перспективе обоснованное использование связываемых переменных (и при необходимости — констант) — наиболее правильно.
Даже если есть соответствующие параметры, которые можно установить на уровне базы данных, а их пока немного, проблемы одновременного доступа и неэффективных запросов (неудачно сформулированных или вызванных неудачной организацией данных) нельзя решить только установкой параметров сервера. Для решения этих проблем необходимо переписать приложение (а зачастую и изменить его архитектуру). Перенос файлов данных с одного диска на другой, изменение количества блоков, читаемых подряд одной операцией ввода, и другие настройки "на уровне базы данных" часто мало влияют на общую производительность приложения. Они никак не дадут ускорения в 2, 3, ... N раз, необходимого для достижения приемлемой скорости работы приложения. Как часто требуется ускорить работу приложения на 10 процентов? Если надо ускорить работу на 10 процентов, обычно никто вообще не поднимает вопрос об этом. Пользователи начинают жаловаться, когда, по их мнению, скорость надо увеличить раз в пять. Однако повторяю: вы не увеличите скорость работы в пять раз за счет переноса файлов данных на другие диски. Это можно сделать только путем изменения приложения, например, сократив объем ввода-вывода.
О производительности необходимо думать уже на уровне проекта, а затем непрерывно проверять в процессе разработки. Это нельзя откладывать на потом. Я удивляюсь, сталкиваясь со случаями, когда разработчики передают приложение заказчику, устанавливают и только после этого начинают настраивать. Я видел приложения, которые поставлялись клиентам только с первичными ключами, вообще без дополнительных индексов. Запросы никто не настраивал и вообще не тестировал их производительность. С приложением никогда не работало более десятка пользователей. Настройка считается частью процесса установки и внедрения программного продукта. Для меня такой подход неприемлем. Пользователи должны получать быстро работающую, хорошо настроенную систему. Проблем с продуктом у них будет достаточно и без производительности. Пользователи готовы к тому, что в приложении будут ошибки, но не заставляйте их бесконечно ждать появления сообщений об этих ошибках на экране.
