Oracle для профессионалов Том Кайт торгово-издательский дом DiaSoft

41

---

42
Глава 1
работки меня попросили оценить производительность приложения. Прежде всего я хо-
тел узнать подход разработчиков к СУБД:
• где, по их мнению, у приложения могут быть узкие места, точки потенциальных
конфликтов?
• каковы, по их мнению, основные препятствия для достижения требуемой произ-
водительности?
Они не имели ни малейшего представления об этом. На вопрос о том, кто поможет
мне переписать код компонента EJB для настройки сгенерированного запроса, ответ был
следующий: "О, этот код нельзя изменять, все надо делать в базе данных". То есть, при-
ложение должно оставаться неизменным. В этот момент я был готов отказаться от ра-
боты над проектом — ясно, что заставить это приложение нормально работать невоз-
можно:
• приложение было создано без учета масштабирования на уровне базы данных;
• приложение нельзя настраивать и вообще изменять;
• по моему опыту, от 80 до 90 процентов
 всей
настройки выполняется на уровне
приложения, а не на уровне базы данных;
• разработчики не представляли себе, что делают их компоненты с базой данных и
где искать потенциальные проблемы.
Все это стало понятно уже через час тестирования. Как оказалось, в приложении сна-
чала выполнялся оператор:
select * from t for update;
Это приводило к строго последовательной работе
 всех
клиентов. В базе данных была
реализована такая модель, что перед выполнением любых существенных действий при-
ходилось блокировать весьма большой ресурс. Это моментально превращало приложе-
ние в очень большую однопользовательскую систему. Разработчики не верили мне (в
другой СУБД, использующей разделяемую блокировку чтения, наблюдалась другая си-
туация). После десяти минут работы с инструментальным средством TKPROF (о нем
подробно написано в главе 10) я смог продемонстрировать, что именно этот оператор
SQL выполнялся приложением (они об этом не знали — просто никогда не видели ге-
нерируемых операторов SQL). Я не просто показал, какие операторы SQL выполняют-
ся приложением, но и с помощью пары сеансов SQL*Plus продемонстрировал, что вто-
рой сеанс не начинается до полного завершения работы первым сеансом.
Итак, вместо того, чтобы неделю тестировать производительность приложения, я
употребил это время на обучение разработчиков настройке, особенностям блокирова-
ния в базах данных, механизмам управления одновременным доступом, сравнение их
реализаций в СУБД Oracle, Informix, SQL Server, DB2 и так далее (во всех этих СУБД
они различны). Но сначала мне пришлось понять, однако, почему использовался опера-
тор