Заключительные рекомендации по конфигурированию сетевого ввода/вывода
Для конфигураций клиент/сервер, где клиенты работают на удаленных ПК или рабочих станциях, следует конфигурировать по 20-50 клиентов на одну сеть Ethernet. Количество клиентов в одной сети 16 Мбит/с Token Ring может достигать 100 благодаря прекрасной устойчивости к деградации под нагрузкой.
Если фронтальная система обслуживает большое количество клиентов, то между фронтальной системой и сервером СУБД следует предусмотреть специальную выделенную сеть. При этом если приходится манипулировать очень большими объектами данных (более 500 Кбайт на объект), то вместо сетей Ethernet или Token Ring следует применять FDDI.
Фронтальная система и сервер СУБД могут объединяться с помощью глобальных сетей, обеспечивающих "достаточную" полосу пропускания. В идеале это предполагает по крайней мере использование неполной линии T1. Такие приложения должны быть относительно малочувствительны к задержке сети.
При конфигурировании систем клиент/сервер с использованием глобальных сетей следует исследовать возможность применения мониторов обработки транзакций для снижения трафика клиент/сервер до минимума.
В частных сетях обычно нет никаких проблем с использованием терминальных серверов, если только сами разделяемые сети не загружены тяжело для других целей.
По определению семантики оператора SQL COMMIT_WORK любая СУБД должна гарантировать, что все обновления базы данных должны направляться и фиксироваться в стабильной памяти (т.е. любой памяти, которая обеспечивает устойчивое хранение данных даже в условиях сбоев системы или отказов питания). Чтобы СУБД могла дать такую гарантию, она должна выдавать для выполнения по крайней мере некоторые из своих операций записи синхронно. Во время выполнения таких записей операционная система блокируется и не возвращает управление вызвавшей программе до тех пор, пока данные не будут зафиксированы в стабильной памяти. Хотя эта стратегия очень надежна, вместе с тем она приводит к существенному замедлению операций, поскольку при выполнении синхронных записей обязательно требуется, чтобы данные были записаны непосредственно на дорожку диска. Синхронная запись на "чистый" диск занимает примерно 20 мс, а синхронная запись в файловую систему может занять в несколько раз больше времени (если должны быть выполнены обновления в косвенные блоки или блоки с двойной косвенностью).
Обычно СУБД осуществляют синхронную запись только в свои журналы - в случае отказа системы сама база данных может быть реконструирована из синхронно записанного журнала. Иногда система в целом становится узким местом в процессе заполнения журнала. Обычно это случается в среде тяжелой обработки транзакций, которая выполняет многочисленные обновления базы данных (приложения, выполняющие только чтение базы данных, подобные системам поддержки принятия решений, осуществляют немного записей в журнал). Этот эффект еще более усиливается при использовании для журнальных дисков зеркальных пар. В этих случаях для ускорения процесса журнализации часто полезно использовать PrestoServe или NVSIMM. Фиксация записей в немеханических NVRAM, устанавливаемых на PrestoServe или в NVSIMM может существенно расшить узкое горло в некоторых системах.
Рекомендации:
Если приложение связано с ведением журнала или если приложение жестко ориентировано на проведение обновлений, следует включить в конфигурацию системы NVSIMM или PrestoServe.
Для гарантии от потери данных следует размещать журналы СУБД на зеркальных дисковых парах.
