Выбор конфигурации сервера субд

Хотя данный материал предлагает некоторые рекомендации по конфигурированию систем, полезность этих рекомендаций в значительной степени зависит от анализа самого приложения. Важность такого анализа невозможно переоценить! Эффективность работы самого приложения и СУБД намного важнее, чем конфигурация хост-машины. Имеются буквально сотни примеров небольших изменений, проведенных в приложении или в схеме базы данных, которые обеспечивали 100- или 1000-кратное (или даже большее!) увеличение производительности системы. Например, в зависимости от того индексируется или нет таблица с помощью ключа просмотра (lookup key), выполнение оператора select, который запрашивает одну определенную запись, может приводить к тому, что СУБД будет читать из таблицы всего одну запись, либо каждую запись в таблице, содержащей 10 Гбайт данных. Часто для того чтобы оптимально обрабатывать несколько различных шаблонных обращений, генерируемых приложением, таблица должна индексироваться более чем одним ключом или набором ключей. Хорошо осмысленная индексация может иметь весьма существенное воздействие на общую производительность системы (см. разд. 2.2.6.1). После начальной инсталляции системы обязательно нужно произвести сбор статистики о ее работе, чтобы выяснить необходимость внесения изменений в базу данных, даже для приложений собственной разработки или приложений третьих фирм. Часто оказывается возможным улучшить производительность приложения путем реорганизации базы данных даже без обращения к исходному коду приложения.

Другим соображением, которому уделяется недостаточно внимания, но которое часто оказывает огромные воздействие на результирующую производительность системы, являются конфликты по внутренним блокировкам. СУБД должна блокировать доступ к данным при наличии конфликтующих одновременных обращений. Любой другой процесс, который требует доступа к этим данным должен быть отложен до тех пор, пока блокировка не будет снята. Если выбрана неоптимальная стратегия блокировок, то система может оказаться очень плохо работающей.

Каждая СУБД имеет огромное число настраиваемых параметров, некоторые из которых могут серьезно воздействовать на общую производительность системы. Приводимые здесь рекомендации предполагают разумную настройку приложений и СУБД.

Предпосылки выбора

Ниже перечислены вопросы, ответы на которые позволяют обобщить процесс достижения разумной точности конфигурации СУБД:

• Какая используется СУБД? Это "2N" или многопотоковая реализация?

• Какие используются мониторы транзакций (если таковые вообще применяются)?

• Можно ли использовать систему в конфигурации клиент/сервер?

• Сколько одновременно активных пользователей должна поддерживать система?

• Можно ли выделить основной или доминирующий шаблон (образец) обращения к системе? Какие запросы доминируют в нагрузке?

• Какова стратегия индексации? Какие запросы будут оптимизированы с помощью индексации (например, преобразуются для реализации произвольного доступа к данным вместо последовательного) и какие запросы должны быть реализованы с помощью полного или частичного сканирования таблицы?

• Насколько велик чистый размер базы данных?

• Имеется ли достаточное количество дисковых накопителей и главных адаптеров SCSI, сконфигурированных для обеспечения обработки предполагаемой нагрузки? Имеются ли отдельные диски для журналов СУБД и архивов?

• Имеется ли достаточная емкость дисковой памяти для хранения необработанных данных, индексов, временных табличных пространств, а также место для возможного увеличения объема данных?

• Достаточно ли число процессоров, сконфигурированных для работы с предполагаемым количеством пользователей?

• Требуется ли специальная выделенная сеть для организации связи между клиентскими системами и сервером?

• Если предполагаемая нагрузка ориентирована на интенсивное внесение обновлений в базу данных, имеется ли место в конфигурации для NVRAM?

• Согласована ли предполагаемая стратегия резервного копирования с типом, числом и местом размещения устройств резервного копирования SCSI?