SQL: вопросы и ответы. Предотвращение перезагрузок, установка нескольких обновлений и другое

Предотвращение перезагрузок

Вопрос. Как ограничить число перезагрузок при установке исправлений и других дополнений к SQL Server и к серверной операционной системе в целом?

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

Во-первых, нужно узнать, какие именно файлы во время инсталляции были заняты и заблокированы. Для этого откройте раздел реестра HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations. С помощью этого раздела вы сможете решить сразу две задачи: убедиться в том, что запрос на перезагрузку действительно был подан вследствие блокировки, и узнать перечень заблокированных файлов. Анализ содержимого упомянутого раздела между установкой и перезагрузкой позволит вам разобраться в причинах перезагрузки и предпринять меры к исключению аналогичных ситуаций в ходе последующих сеансов установки.

В этом разделе вам могут встретиться записи двух типов. Если файл был заблокирован для чтения, ему соответствует однострочная запись; это значит, что обновленный файл уже записан на диск и теперь необходимо удалить его временную копию. Если файл был заблокирован для записи, соответствующая ему запись состоит из двух строк; следовательно, обновление еще не произошло, состояние приложения неизвестно и обращаться к нему не следует. Записи такого типа отражают заминку в ходе установки. В таком случае в одной строке указывается существующий файл, а во второй — временный файл (после перезагрузки первый заменяется вторым).

Содержание следующего этапа зависит от многих факторов, но суть в том, чтобы определить, какое ПО обращается к заблокированным файлам. По возможности воспользуйтесь средствами контроля зависимостей или базой данных DLL HELP в системе MSDN® (см. support.microsoft.com/kb/815065 (на английском языке).

Если программному обеспечению, которое обращается к файлу, соответствует та или иная служба, остановите её вручную и повторите проверку. Если речь идет о приложении, закройте его и проведите повторную проверку. В некоторых случаях к одному файлу обращаются сразу несколько приложений; если это так, нужно закрыть их все.

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

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

Есть еще одно правило, о котором стоит упомянуть. Иногда в одной системе устанавливается сразу несколько версий SQL Server™ или других продуктов, при этом у них даже могут быть разные уровни версий. В подобных ситуациях обновление всегда следует начинать с самой свежей версии. Скорее всего, в таком случае все необходимые файлы будут заменены последними версиями, а остальные экземпляры продукта не станут блокировать их. К примеру, если в системе установлено три экземпляра SQL Server 2000 SP3, при обновлении первого из них до SP4 файл MSXML3.dll должен быть заменен, а значит, нужна перезагрузка. Предположим, что вы её выполнили. При обновлении двух оставшихся экземпляров до SP4 перезагрузка не потребуется – ведь новая версия MSXML3.dll уже установлена. Аналогичное правило действует и в других случаях: при обновлении экземпляров SQL Server 2005 перед SQL Server 2000, SQL Server 2000 перед SQL Server 7.0 и так далее. Это универсальная, фактически работающая методика минимизации перезагрузок.

Если рассуждать стратегически, группы разработчиков корпорации Майкрософт уже долгое время трудятся над тем, чтобы исключить или по меньшей мере ограничить число перезагрузок в различных ситуациях. Так как тема этой статьи — «SQL, вопросы и ответы», рассмотрим в качестве примера SQL Server.

При подготовке версии SQL Server 2005 разработчики SQL Server разбили код компонентов MDAC (Microsoft® Data Access Components), необходимый для функционирования SQL Server, на SQLNCLI (новые файлы), отказавшись от обновления собственно MDAC, при этом компоненты MDAC были возвращены в распоряжение ОС. К чему это привело? Дело в том, что операционная система Windows® сама обращается к компонентам MDAC и блокирует их файлы. По этой причине установка пакетов обновления SQL Server и других пакетов традиционно сопровождалась перезагрузкой. Теперь SQL Server обновляет собственную версию MDAC, не обращаясь к файлам MDAC, применяемым операционной системой, следовательно, необходимость перезагрузки отпадает.

Более того – в программе установки SQL Server 2005 SP1 есть встроенное средство контроля зависимостей и предусмотрена возможность приостановки. Это средство показывает перечень заблокированных файлов и предполагаемые источники блокировки; вы можете сразу остановить ПО, блокирующее необходимые файлы, и продолжить установку без перезагрузки. Таким образом, у вас появляется возможность предпринять меры к предотвращению перезагрузки в реальном времени, не обращаясь к тестовой среде. Естественно, при необходимости, а также при работе в несопровождаемом режиме можно продолжить установку без закрытия блокирующего ПО и выполнить перезагрузку. Как видите, выявить источники блокировки файлов теперь очень просто!

Помимо прочего, технология Microsoft Installer сейчас значительно эффективнее работает с разделом реестра PendingFileRenameOperations (PFR). Если вы помните, при обнаружении в вышеупомянутом разделе реестра записей о любых файлах процесс установки SQL Server 2000 блокировался. Что же касается программы установки SQL Server 2005, то она блокируется только если файлы относятся к SQL Server (и продолжение установки может привести к конфликту), но даже в таких случаях ей зачастую удается обратиться к разделу PFR и обновить его содержимое напрямую, тем самым избежав перезагрузки. На том или ином уровне эта технология реализована как в MSI, так и в update.exe — двух стандартных на сегодняшний день программах установки от Майкрософт, с помощью которых выполняются все обновления.

Каковы известные факторы, приводящие к перезагрузке? В первую очередь, это файл MSXML3.dll. Он постоянно заблокирован службой Windows SVCHost, и при любом обращении к этой службе перезагрузки не избежать. Аналогичная ситуация характерна для большинства стеков MDAC (mdac_typ.exe). К счастью, в Windows Server® 2003, Windows XP SP2 и последующих версиях ОС компоненты MDAC являются "разделенными". Разработчики SQL Server здорово потрудились, отделив msxmlsql.dll, в результате чего обновления SQL Server обычно не сопряжены с перезагрузкой, хотя иногда её все же не избежать. В таких ситуациях трудно предложить какое-то решение — закрыть службу SVCHost и продолжить обновление невозможно.

Кроме того, стоит упомянуть об особенностях процесса деинсталляции в исполнении пакетов update.exe. При деинсталляции они блокируют (естественно, вне разделов PFR) наличные файлы программы установки. В результате исполнение других пакетов update.exe до перезагрузки, при которой такая блокировка снимается, становится невозможным. С этим вряд ли что-то можно поделать – разве что планировать перезагрузку после деинсталляции исправлений.

Другая проблема – периодичность. Не все программы обращаются к тому или иному файлу постоянно. На самом деле большинство общих библиотек DLL используются не постоянно, а в отдельные моменты времени; это значит, что другие программы могут обращаться к ним только по необходимости, в зависимости от своей рабочей нагрузки и путей, заданных в коде. В такой ситуации даже десятикратные испытания могут не выявить заблокированных файлов, но не исключено, что впоследствии они совершенно неожиданно обнаружатся в рабочей среде. Увы, с этим ничего нельзя поделать. Попробуйте максимально приблизить тестовую среду к рабочей, в том числе смоделировать рабочую нагрузку (впрочем, к этому нужно стремиться всегда) и провести столько испытаний, сколько необходимо для выявления подобных явлений.

Установка пакетов обновления и отдельных обновлений ОС всегда сопряжена с перезагрузкой. Следует иметь в виду, что в версиях ОС нижнего уровня (Windows 2000, Windows XP и во всех предшествующих версиях) установка считается незавершенной вплоть до завершения перезагрузки — даже если раздел реестра pendingfilerenameoperations пуст. Существуют операции, направленные на регистрацию пакетов исключений (exception packages), которые могут исполняться во время перезагрузки для установки кода. Они не входят в состав пакетов обновления; это встроенные команды операционной системы, которые запускаются сценариями обновления для сохранения работоспособности отдельных блоков кода.

Наконец, раздел PFR не выполняет ни проверок версий файлов, ни упорядочивания путем сериализации. Иными словами, он запускает процесс замены файлов в том порядке, в котором они перечислены. С другой стороны, на жестком диске они сохраняются в порядке «от последнего завершенного» (в противоположность порядку «от первого запущенного»). Это вполне разумное решение, но оно также означает, что при наличии в рамках одного пути двух копий одного и того же файла, указывающих на разные его версии, перезагрузка приведет к произвольному результату. Столкнувшись с подобной ситуацией, обязательно исправьте ее. Если вы не уверены, что нужно сделать, запустите после перезагрузки обе программы установки. При правильном подборе файлов ни один из них не приведет к сбою. При неправильном подборе запуск пакета с нужным файлом поможет исправить ситуацию. Честно говоря, это и быстрее и безопаснее, чем попытки определить желаемый результат.

Установка нескольких пакетов обновления

Вопрос. В кластере из четырех узлов установлено восемь кластеризованных экземпляров SQL Server 2000. Как провести установку SP4 с минимальным числом перезагрузок? Можно ли последовательно установить SP4 на всех 8 экземплярах, а затем провести перезагрузку всех узлов?

Ответ. После завершения установки первого экземпляра SQL Server SP4 (в результате которой может потребоваться перезагрузка) на любом сервере Windows (вне зависимости от того, входит ли он в состав кластера или нет) инсталляция SQL Server SP4 для других экземпляров SQL Server в данной системе не приводит к перезагрузке. Дело в том, что все общие файлы — инструментальные средства, MDAC, MSXML и т. д. — к этому моменту обновлены до нужной версии, и поэтому независимо от того, заблокированы они или нет, не требуют дополнительного обновления. Все файлы, не являющиеся общими, используются только первым экземпляром, который будет остановлен программой установки. Следует отметить, что при наличии нескольких экземпляров нескольких версий хронологически последний экземпляр SQL следует обновлять в первую очередь.

Исполнение от имени сетевой службы

Вопрос. Что конкретно представляет собой учетная запись NT AUTHORITY\NETWORK SERVICE и в чем её основное назначение? Кроме того, какой уровень безопасности обеспечивает эта учетная запись, в особенности если ей присвоены полномочия системного администратора (SA)?

Ответ. Учетная запись Network Service совпадает по составу сетевого удостоверения (удостоверения машины) с учетной записью System, но уступает ей по набору полномочий в локальной среде. Таким образом, если службе требуется доступ к сетевым ресурсам (например, для разрешения имен учетных записей на контроллере домена), она исполняется с учетной записью домена, System или Network Service. Последний вариант, как правило, безопаснее других, поскольку по своему диапазону эта учетная запись ограничивается локальной средой, в которой ей предоставляется ограниченный набор полномочий.

Присвоение учетной записи Network Service полномочий системного администратора в SQL Server приведет к тому, что любая другая служба, исполняемая в локальной среде с учетной записью Network Service, сможет получить полный контроль над сервером. Это, в частности, происходит при настройке исполнения учетной записи службы SQL Server в качестве Network Service. В то же время, включение учетной записи службы SQL Server в группу SA требуется для обеспечения функциональности сервера (например, для того, чтобы сделать возможным установление соединений обратной связи). Присвоение Network Service административных полномочий в среде SQL Server – не самое удачное с точки зрения безопасности решение, но в определенных (не во всех) случаях оно предпочтительнее по сравнению с привлечением для таких целей учетной записи домена, и определенно безопаснее присвоения SQL Server полномочий учетной записи LocalSystem.

Если вы не хотите присваивать Network Service полномочия на уровне системного администратора, попробуйте создать учетную запись домена, специально предназначенную для управления SQL Server в одной или нескольких инсталляциях Windows NT®.

В этом вам помогут следующие статьи: msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp (на английском языке) и microsoft.com/technet/security/topics/serversecurity/serviceaccount (на английском языке).

Создание нескольких баз данных

Вопрос. Я намерен распределить данные между несколькими базами – возможно, число баз данных, одновременно находящихся в оперативном режиме, достигнет 250. По моим оценкам, в каждый отдельно взятый момент для исполнения активных запросов будет привлекаться только 20 баз данных. Действительно ли чем больше баз, тем лучше?

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

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

С учетом всего вышеизложенного можно сделать вывод, что распределение данных по нескольким базам вполне оправданно в силу нескольких причин:

• Требования по резервированию отдельного подмножества данных изолируются от аналогичных требований в отношении других данных.
• Некоторые данные должны существовать в отдельном контексте безопасности – иными словами, в базе данных отдельного владельца.
• Иногда данные сохраняются в целях архивирования, в каковом случае им присваиваются полномочия «только чтение».