версии Standard (поддерживающей четыре процессора), либо версии Enterprise (возможности которой ограничиваются лишь аппаратным обеспечением и бюджетом самой организации).

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

Тем не менее создается впечатление, что наиболее важным фактором обеспечения высокого быстродействия в тех условиях, когда нагрузка преимущественно распространяется на процессор, является оперативная память. Безусловно, именно эта составляющая аппаратного обеспечения нуждается в правильном выборе. При этом следует также учитывать, что при эксплуатации мультипроцессорного компьютера (а именно такой компьютер следует применять в качестве серверного) потребность в оперативной памяти значительно возрастает. Поскольку в наши дни стоимость микросхем оперативной памяти является очень низкой, не следует допускать даже мысли о том, что СУБД SQL Server может быть установлена на компьютере с объемом оперативной памяти меньше 512 Мбайт, даже в среде разработки. А серверные компьютеры, применяемые на производстве, должны быть оснащены не меньше чем 1 Гбайт оперативной памяти, причем этот объем вполне может оказаться гораздо более значительным.

Ниже перечислены факторы, которые следует учитывать, принимая решение о том, какой объем оперативной памяти должен использоваться.

Количество одновременно поддерживаемых пользовательских соединений (ведь для поддержки каждого пользовательского соединения требуется оперативная память). Чаще всего для поддержки каждого соединения выделяется примерно 24 Кбайт памяти (а в некоторых случаях еще больше). Безусловно, этот фактор нельзя назвать решающим, посколысу для поддержки одной тысячи пользователей потребовалось бы приблизительно 24 Мбайт, но и эту величину нельзя сбрасывать со счетов.

Применение большого количества операций агрегирований и (или) сортировки. Этот фактор может оказаться гораздо более значимым в зависимости от размеров наборов данных, обрабатываемых в запросах.

Объем наиболее крупной базы данных. Если на серверном компьютере установлена только одна база данных и ее объем составляет всего 1 Гбайт (а фактически большинство баз данных содержат гораздо меньше, чем принято считать), то, по-видимому, применение оперативной памяти объемом в 4 Гбайт не имеет большого смысла.

СУБД SQL Server 2005 версии Workgroup обеспечивает адресацию памяти только до 3 Гбайт. Если же должен применяться больший объем оперативной памяти, то необходимо перейти к использованию версии Standard.

Следует также отметить, что после запуска системы в эксплуатацию (или после полного заполнения данными тестовой системы) необходимо проследить за динамикой

изменения коэффициента попадания в кэш с помощью утилиты perfmon. Дополнительная информация о том, как вычисляется это значение, будет приведена немного позже в данной главе. А на данный момент достаточно отметить, что указанный показатель может служить своего рода мерилом того, насколько часто в процессе эксплуатации базы данных удается извлекать данные из оперативной памяти, не будучи вынужденным считывать эти данные с жесткого диска (известно, что оперативная память обладает гораздо более высоким быстродействием по сравнению с жестким диском). Если значение коэффициента попадания в кэш является низким, это обычно можно рассматривать как достоверное свидетельство того, что требуется увеличение объема оперативной памяти. Но следует помнить, что высокое значение этого показателя не обязательно следует трактовать так, что потребность в дальнейшем увеличении объема оперативной памяти отсутствует. Дело в том, в СУБД SQL Server реализована функция опережающего чтения, что приводит к искусственному увеличению коэффициента попадания в кэш, но это не означает, что потребность в увеличении объема оперативной памяти отсутствует.

Сопоставление систем OLTP и OLAP

Оптимальные условия эксплуатации систем OLTP и OLAP обычно являются несовместимыми. Поэтому, не вдаваясь в подробности, автор рекомендует следующее.

Если на предприятии приходится эксплуатировать одновременно базы данных OLTP и OLAP, то они должны эксплуатироваться на разных серверных компьютерах; иного выхода просто нет.

Сопоставление условий локального и дистанционного размещения серверного компьютера

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

Но с наступлением эпохи Интернета все чаще стали применяться конфигурации, в которых серверный компьютер размещается по принципу колокации на площадке поставщика услуг (провайдера) Интернета. В таком случае ответственность за резервное копирование всей системы возлагается на провайдера Интернета, который может даже взять на себя обязанности по восстановлению всей системы в соответствии с полученными им указаниями, но ответственность за обеспечение нормальной работы прикладного программного обеспечения по-прежнему лежит на самом предприятии. Такая организация работы может стать причиной возникновения весьма серьезных проблем в случае обнаружения катастрофической программной ошибки в системе. Разумеется, всегда остается возможность дистанционно подключиться к серверу для проведения на нем каких-то работ, но все равно приходится сталкиваться с некоторыми достаточно серьезными проблемами настройки конфигурации и обеспечения высокой производительности, включая перечисленные ниже.

Безопасность. Из сказанного следует, что администраторы должны иметь удаленный доступ к своей системе, а это означает, что такой доступ могут получить и другие лица, которые на это отнюдь не уполномочены. По мнению автора, единственный выход в этой ситуации состоит в том, чтобы примен5и1ись очень жесткие ограничения, касающиеся выбора способа маршрутизации и применения сетевых портов. По отношению к тем разработчикам, которые не являются крупными специалистами в области компьютерных сетей (а к этой категории относится и сам автор), данная рекомендация означает, что должен быть регламентирован перечень IP-адресов, трафик от которых может быть разрешено перенаправлять с помощью маршрутизации на удаленный сервер.

Производительность. Для предприятий уже стала привычной скорость обмена данными в локальной сети, составляющая 100 Мбайт/с или даже 1 Гбайт/с. Если же сервер расположен дистанционно, то обмен данными с ним приходится организовывать с помощью виртуальной закрытой сети (Virtual Private Network - VPN) через Интернет или, что еще хуже, через коммутируемое соединение. При этом уже не стоит рассчитывать на высокое быстродействие (а иногда замедление в работе становится просто невыносимым).

Качество поддержки пользователей. Тем, кто эксплуатирует узел электронной коммерции или такое же ответственное оперативное приложение, часто бывает сложно добиться ответа по телефону от представителей провайдера Интернета. Очевидно, что такая ситуация вызывает глубокое разочарование. Не менее досадно бывает, когда такие представители сообщают о том, что немедленно примут меры, но проходит час за часом, а серверный компьютер продолжает простаивать. Поэтому следует очень внимательно ознакомиться с тем, как работает предполагаемая компания удаленного хостинга (дело в том, что такие компании после заключения договора с заказчиком часто утрачивают к нему интерес, полагая, что заказчик уже никуда от них не денется).

Обслуживание аппаратных средств. Многие предприятия, занимающиеся хостингом, не берут на себя обязательств по обслуживанию аппаратных средств заказчика. Поэтому если возникает нарушение в работе, требующее более серьезного вмешательства обслуживающего персонала по сравнению с перезагрузкой, то предприятию приходится самому отправлять своих сотрудников на ту площадку, где находится серверный компьютер, или привлекать к работе представителей еще одной компании для вьшолнения требуемого обслуживания; это означает, что приложение, эксплуатируемое на другой площадке, может оставаться неработоспособным в течение многих часов или даже суток.

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