Зачастую мои знакомые сисадмины БД Оракл сетуют, что начальство на них "вешает" задачи по настройке производительности, но, мол, это не наша задача. Отвечаю им с использованием мировой практики... Настройка производительности базы данных Oracle является “повсеместной” задачей. Она выполняется и на этапе проектирования базы данных, и на этапе ее реализации, и на этапе ее тестирования, и на этапе ее внедрения в производственную среду. По сути, настройка производительности представляет собой такую задачу, которая требует постоянного внимания со стороны хорошего администратора баз данных Oracle.
В зависимости от структуры организации, администратору баз данных может быть необходимо выполнять настройку производительности как базы данных, так и приложений. Обычно администратор баз данных выполняет настройку производительности только базы данных и просто помогает разработчикам приложений с настройкой их производительности на этапах их тестирования и реализации.
Требования к производительности постоянно используемой базы данных все время меняются и потому администратору баз данных нужно постоянно следить за производительностью, проверяя соответствующие показатели. Например, после миграции на более новую версию базы данных Oracle автор обнаружил, что несколько крупных пакетных программ перестали укладываться со своим выполнением в выделенное для них время. После ряда длительных мучений автору таки удалось выяснить, что причина скрывалась в использовании в определенной части кода рекомендаций оптимизатора по стоимости (cost-based optimizer), которые под управлением новой версии Oracle больше оптимальными не являлись. Быстрое исправление этих рекомендаций привело к значительному улучшению производительности программ. Мораль этой истории такова: нужно обязательно тестировать весь код под управлением новой версии Oracle прежде, чем переходить на нее.
Все связанные с настройкой производительности операции можно поделить на два типа: профилактические (proactive) и реактивные (reactive). Первые, как понятно по названию, позволяют администратору баз данных предупреждать появление проблем путем внимательного наблюдения за соответствующими необходимыми показателями. Как всем известно, предупреждение всегда лучше любого лечения, поэтому профилактические операции будут всегда превосходить реактивные. Однако у большинства администраторов, отвечающих за производственные базы данных, зачастую просто нет времени заниматься профилактической настройкой — они слишком заняты реагированием на жалобы по поводу медленно работающей базы данных или чего-нибудь в подобном роде. Но все же то, что, будучи администратором баз данных Oracle, доведется сталкиваться с выполнением и тех и других операций по настройке производительности, все-таки не исключено.
