|
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, поэтому будет выбирать план для общего
73
74
Глава 1
случая, когда индекс скорее всего не будет использоваться (даже если 99,9 процентов
запросов будут содержать конструкцию WHERE x < 50).
Кроме того, я обнаружил, что, хотя установка CURSOR_SHARING = FORCE обес-
печивает намного большую скорость работы, чем повторный анализ и оптимизация мно-
жества одинаковых запросов как уникальных, это все равно медленнее, чем выполне-
ние запросов, где связываемые переменные используются изначально. Это происходит
не из-за неэффективности механизма совместного использования кода курсора, а из-за
неэффективности самой программы. В главе 10 мы рассмотрим, как разбор операторов
SQL может влиять на производительность в целом. Во многих случаях приложение, не
использующее связываемые переменные, также не обеспечивает эффективного анализа
и повторного использования курсоров. Поскольку в приложении предполагается уни-
кальность каждого запроса (так как для каждого из них создается уникальный опера-
тор), то и курсор в нем не будет использоваться более одного раза. Факт в том, что если
программист использует связываемые переменные, то он зачастую также разбирает зап-
рос один раз и затем использует многократно. Именно затраты ресурсов на повторный
разбор приводят к наблюдаемому снижению производительности.
Итак, важно помнить, что просто добавление параметра инициализации
CURSOR_SHARING = FORCE не всегда позволяет решить проблемы. Могут даже воз-
никнуть новые. Во многих случаях параметр CURSOR_SHARING — действительно по-
лезное средство, но это не панацея. Для хорошо продуманного приложения он не ну-
жен. В долгосрочной перспективе обоснованное использование связываемых переменных
(и при необходимости — констант) — наиболее правильно.
Даже если есть соответствующие параметры, которые можно установить на уровне
базы данных, а их пока немного, проблемы одновременного доступа и неэффективных
запросов (неудачно сформулированных или вызванных неудачной организацией данных)
нельзя решить только установкой параметров сервера. Для решения этих проблем не-
обходимо переписать приложение (а зачастую и изменить его архитектуру). Перенос
файлов данных с одного диска на другой, изменение количества блоков, читаемых под-
ряд одной операцией ввода, и другие настройки "на уровне базы данных" часто мало
влияют на общую производительность приложения. Они никак не дадут ускорения в 2,
3, ... N раз, необходимого для достижения приемлемой скорости работы приложения.
Как часто требуется ускорить работу приложения на 10 процентов? Если надо ускорить
работу на 10 процентов, обычно никто вообще не поднимает вопрос об этом. Пользова-
тели начинают жаловаться, когда, по их мнению, скорость надо увеличить раз в пять.
Однако повторяю: вы не увеличите скорость работы в пять раз за счет переноса файлов
данных на другие диски. Это можно сделать только путем изменения приложения, на-
пример, сократив объем ввода/вывода.
О производительности необходимо думать уже на уровне проекта, а затем непрерывно
проверять в процессе разработки. Это нельзя откладывать на потом. Я удивляюсь, стал-
киваясь со случаями, когда разработчики передают приложение заказчику, устанавли-
вают и только после этого начинают настраивать. Я видел приложения, которые постав-
лялись клиентам только с первичными ключами, вообще без дополнительных индексов.
Запросы никто не настраивал и вообще не тестировал их производительность. С прило-
жением никогда не работало более десятка пользователей. Настройка считается частью
Разработка успешных приложений для Oracle
процесса установки и внедрения программного продукта. Для меня такой подход не-
приемлем. Пользователи должны получать быстро работающую, хорошо настроенную
систему. Проблем с продуктом у них будет достаточно и без производительности. Пользо-
ватели готовы к тому, что в приложении будут ошибки, но не заставляйте их бесконеч-
но ждать появления сообщений об этих ошибках на экране.
Do'stlaringiz bilan baham: |
