Oracle для профессионалов



              

Как ускорить работу? - часть 3


Итак, важно помнить, что просто добавление параметра инициализации CURSOR_SHARING = FORCE не всегда позволяет решить проблемы. Могут даже возникнуть новые. Во многих случаях параметр CURSOR_SHARING — действительно полезное средство, но это не панацея. Для хорошо продуманного приложения он не нужен. В долгосрочной перспективе обоснованное использование связываемых переменных (и при необходимости — констант) — наиболее правильно.

Даже если есть соответствующие параметры, которые можно установить на уровне базы данных, а их пока немного, проблемы одновременного доступа и неэффективных запросов (неудачно сформулированных или вызванных неудачной организацией данных) нельзя решить только установкой параметров сервера. Для решения этих проблем необходимо переписать приложение (а зачастую и изменить его архитектуру). Перенос файлов данных с одного диска на другой, изменение количества блоков, читаемых подряд одной операцией ввода, и другие настройки "на уровне базы данных" часто мало влияют на общую производительность приложения. Они никак не дадут ускорения в 2, 3, ... N раз, необходимого для достижения приемлемой скорости работы приложения. Как часто требуется ускорить работу приложения на 10 процентов? Если надо ускорить работу на 10 процентов, обычно никто вообще не поднимает вопрос об этом. Пользователи начинают жаловаться, когда, по их мнению, скорость надо увеличить раз в пять. Однако повторяю: вы не увеличите скорость работы в пять раз за счет переноса файлов данных на другие диски. Это можно сделать только путем изменения приложения, например, сократив объем ввода-вывода.

О производительности необходимо думать уже на уровне проекта, а затем непрерывно проверять в процессе разработки. Это нельзя откладывать на потом. Я удивляюсь, сталкиваясь со случаями, когда разработчики передают приложение заказчику, устанавливают и только после этого начинают настраивать. Я видел приложения, которые поставлялись клиентам только с первичными ключами, вообще без дополнительных индексов. Запросы никто не настраивал и вообще не тестировал их производительность. С приложением никогда не работало более десятка пользователей. Настройка считается частью процесса установки и внедрения программного продукта. Для меня такой подход неприемлем. Пользователи должны получать быстро работающую, хорошо настроенную систему. Проблем с продуктом у них будет достаточно и без производительности. Пользователи готовы к тому, что в приложении будут ошибки, но не заставляйте их бесконечно ждать появления сообщений об этих ошибках на экране.




Содержание  Назад  Вперед