Ниже перечислены вопросы, ответы на которые позволяют обобщить процесс достижения разумной точности конфигурации СУБД:
Какая используется СУБД? Это "2N" или многопотоковая реализация?
Какие используются мониторы транзакций (если таковые вообще применяются)?
Можно ли использовать систему в конфигурации клиент/сервер?
Сколько одновременно активных пользователей должна поддерживать система?
Можно ли выделить основной или доминирующий шаблон (образец) обращения к системе? Какие запросы доминируют в нагрузке?
Какова стратегия индексации? Какие запросы будут оптимизированы с помощью индексации (например, преобразуются для реализации произвольного доступа к данным вместо последовательного) и какие запросы должны быть реализованы с помощью полного или частичного сканирования таблицы?
Насколько велик чистый размер базы данных?
Имеется ли достаточное количество дисковых накопителей и главных адаптеров SCSI, сконфигурированных для обеспечения обработки предполагаемой нагрузки? Имеются ли отдельные диски для журналов СУБД и архивов?
Имеется ли достаточная емкость дисковой памяти для хранения необработанных данных, индексов, временных табличных пространств, а также место для возможного увеличения объема данных?
Достаточно ли число процессоров, сконфигурированных для работы с предполагаемым количеством пользователей?
Требуется ли специальная выделенная сеть для организации связи между клиентскими системами и сервером?
Если предполагаемая нагрузка ориентирована на интенсивное внесение обновлений в базу данных, имеется ли место в конфигурации для NVRAM?
Согласована ли предполагаемая стратегия резервного копирования с типом, числом и местом размещения устройств резервного копирования SCSI?
В большинстве прикладных систем СУБД можно выделить три логических части: пользовательский интерфейс (средства представления), обеспечивающий функции ввода и отображения данных; некоторую прикладную обработку, характерную для данной предметной области; и собственно сервисы СУБД. Пользовательский интерфейс и прикладная обработка обычно объединены в одном двоичном коде, хотя некоторые из наиболее продвинутых приложений теперь обеспечивают многопотоковую фронтальную обработку, которая отделена от средств представления. Как правило, по мере роста базы данных сервер СУБД реализуется на выделенной системе, чтобы гарантировать минимизацию помех для его работы.
Рис. 2.3. Сравнение модели клиент/сервер с моделью разделения времени при работе прикладной системы Oracle*Financials.
Если в системе можно реализовать модель вычислений клиент/сервер, отделяющую фронтальную (прикладную) обработку и средства представления от поставщика услуг СУБД, ее использование обычно обеспечивает существенное улучшение общей производительности системы. Такая организация системы позволяет наиболее важному ресурсу (серверу СУБД) работать без помех на своей собственной хост-машине. Это в первую очередь справедливо для систем, в которых работа средств представления связана с управлением сотнями или тысячами терминалов в режиме cbreak. Большинство программ, базирующиеся на curses- (screen-), сегодня используют cbreak-поддержку терминалов.
Режим разделения времени, в отличие от режима клиент/сервер, обычно обеспечивает большую производительность только тогда, когда требования к компоненту представления оказываются очень легкими, или когда одновременная пользовательская нагрузка невелика. Существенно что приложения, в основе компонента представления которых лежат формы, никогда не бывают легковесными. Даже приложения, работающие в диалоговом режиме printf/get обычно значительно более тяжелые, что позволяет оправдать использование конфигураций клиент/сервер. Тест TPC-A определяет возможно наиболее легкое требование приложения/представления (он включает ровно по одному вызову scaf(n) и printf(n)). Следует отметить, что даже тест TPC-A работает только на 5% быстрее в режиме разделения времени. Некоторые сравнительно недавние исследования компании Sun с использованием Oracle*Financials и Oracle 7 показали, что 6-процессорный сервер СУБД на базе SPARCserver 1000 с фронтальной системой на базе SPARCstation 10 Model 512 может поддерживать почти на 40% пользователей больше, чем 8-процессорный SPARCserver 1000, работающий в режиме разделения времени (рис. 2.3).
Рекомендации:
Всегда, если это возможно, следует применять конфигурацию клиент/сервер, если только нагрузка по прикладной обработке и обработке представления являются необычно легкими.
Где это возможно, собственно сервер СУБД должен работать на выделенной системе.
