(Возврат на основную страницу)

Содержание номера за Май 2009 год

SQL Server
для администраторов

Май 2009
№ 5 (35)

Стив Джонс

Отличия между SQL Server 2000 и 2005

Адам Хэйнс

Трассировка по умолчанию. Руководство для начинающих

Томас ЛаРок

Мониторинг резервного копирования баз данных при помощи Operations Manager

Operations Manager как большой конструктор

Джозеф Сэк

Шесть преимуществ использования отказоустойчивых кластеров на основе SQL Server 2008

Отличия между SQL Server 2000 и 2005

Чем отличаются SQL Server 2000 и SQL Server 2005?

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

Как и многие из вас, обычно я получаю этот во­прос от кого­то, кто не близко знаком с SQL Server. Администратора Windows, «сетевика» и т. д., кого­то, кто слабо контактирует с SQL Server. Или, может быть, это кто­то, кто запутался в администрировании SQL Server.

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

Отличия в администрировании

Для меня администрирование экземпляра SQL Ser­ver — это обеспечение эффективной и стабильной работы службы сервера, а также возможности доступа к данным для пользователей. Сервер должен обеспечивать сохранность данных и функционировать согласно правилам, описанным в коде.

Или — для не администраторов — это означает, что вы сисадмин и это просто работает.

В целом отличий не много. Конечно, мы используем Management Studio вместо Enterprise Manager, но это не большая разница. Действительно, многие изменения, например возможность менять подключение для запроса, являются косметическими улучшениями, которые не дают представления о значительных изменениях. Если вы считаете иначе, вам лучше поменять работу.

Безопасность — одна из сфер, которые подверглись значительным улучшениям. Отделение схемы (schema) от владельца (owner) делает административные изменения проще, но это важное изменение, поскольку значительно увеличиваются шансы, что вы не оставите старую учетную запись активной из­за сложностей при изменении владельцев объектов. Также с возможностью использовать схему в качестве еще одного уровня назначения разрешений появилась большая глубина детализации и упростилось администрирование.

Еще одним важным изменением в безопасности стала возможность обезопасить ваши веб­сервисы с помощью сертификатов, вместо использования аутентификации с именем и паролем. Добавьте к этому возможность шифрования данных и управление ключами и это может стать причиной больших изменений в общей безопасности ваших данных. Вы должны внимательно проверить, что ваше приложение и доступ к данным имеют правильные настройки безопасности, но даже простое наличие возможности шифрования, если вы работаете с данными о кредитных картах, финансах или медицинскими данными, имеет огромное значение. SQL Server 2000 не имел функционала по обеспечению безопасности данных, позволяя администратору видеть всю информацию. Вы могли приобрести add­on сторонних разработчиков, но это было дорого и возникала необходимость в обучении персонала. Я не говорю, что для использования SQL Server 2005 не нужно обучать персонал, но это должны быть знания, которыми владеет большинство администраторов БД.

Высокая степень доступности становится все более важной в бизнесе любого масштаба. В прошлом вашим основным выбором были кластеризация или передача журналов (log shipping), но оба эти решения дороги и требуют использования Enterprise Edition. Поэтому эти решения были недоступны многим компаниям, или, по крайней мере, многим бюджетам администраторов. С SQL Server 2005 вы можете реализовать кластеризацию, log shipping или использовать возможность зеркалирования базы данных (Database Mirroring) даже со Standard edition. Возможность зеркалирования базы данных на обычных, недорогих серверах, которые даже не обязаны быть одинаковыми для основной и зеркальной баз данных, оправдывает стоимость такого решения практически для любого предприятия.

Добавлены также online­индексы, online­восстановления (online restores) и быстрое восстановление (fast recovery) в версии Enterprise Edition, что поможет уменьшить время простоя ваших систем. Быстрое восстановление может стать особенно полезной функцией, позволяя получить доступ к базе данных сразу после начала операции восстановления. Журнал открытых транзакций может сэкономить значительное количество времени при перезапуске базы данных. В SQL Server 2000 вам нужна была вся база данных целиком для того, чтобы кто­либо смог получить к ней доступ. Операции повторить/отметить (redo/undo) иногда занимают значительное время, это может увеличить время от загрузки Windows до момента, когда база данных станет доступной, на минуты.

Размеры данных всегда растут, и у большинства компаний возникают проблемы с производительностью на некоторых серверах. В SQL Server 2000 вы были ограничены 2 Гб ОЗУ и 4 ЦП в версии Standard Edition. Количество процессоров не изменилось, но теперь вы можете использовать столько ОЗУ, сколько поддерживает ваша операционная система. Кроме того снято ограничение на размер базы данных, тогда как в SQL Server 2000 ограничивала базу данных размером 1,048,516 TB. Поскольку ОЗУ обычно является ограничивающим фактором производительности базы данных, то переход на SQL Server 2005 может дать вам определенные преимущества. Кроме того, SQL Server 2005 обладает более богатыми возможно­стями на 64­битной платформе.

Зачем апгрейдить?

Это интересный вопрос и мне его задавали достаточно часто с момента выхода SQL Server 2005. Кратко говоря, если SQL Server 2000 удовлетворяет вашим потребностям, то нет никакой необходимости переходить на SQL Server 2005. SQL Server 2000 это мощная, стабильная платформа, которая работала хорошо на миллионах систем. Если она удовлетворяет вашим нуждам, вы не сталкиваетесь с ограничениями платформы и вы довольны своей системой, тогда апгрейд вам не нужен.

Однако есть одно предупреждение. Во­первых, время поддержки SQL Server 2000 окончилось в апреле 2008. Расширенная поддержка продолжается до 2013 года, но это дорогая услуга.

С другой стороны, с выходом новой версии , вы можете захотеть сделать апгрейд, даже если вы довольны своим SQL Server 2000. Если по плану новые версии выпускаются каждые 2–3 года, то для получения непрерывной поддержки, вы должны будете выполнять апгрейд каждые 5–6 лет.

При апгрейде вам нужно убедиться, что все приложения сторонних разработчиков поддерживают SQL Server 2005.

Наконец, если вы используете несколько серверов и вы предполагаете приобрести еще два или более, может иметь смысл приобретение одного большого 64­битного сервера и выполнение определенного объединения. Краткое описание различий представлено в табл. 1.

Заключение

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

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

Табл. 1

Трассировка по умолчанию. Руководство для начинающих

Все мы сталкивались с ситуацией, когда объект был изменен/создан/удален без нашего ведома и приложение со скрипом останавливается. После исправления проблемы ваш начальник задает вам определенные вопросы, например, что произошло, почему это произошло и кто в этом виноват? В SQL Server 2005 появился новый тип триггера, названный DDL-триггер, который может дать ответы на все интересующие нас вопросы; однако у вас не было возможности реализовать эту функциональность.
Итак… что же вам делать?

Некоторые ответят начальству: «Я не знаю, но смогу найти причину». После чего примутся неистово искать утилиты сторонних разработчиков для чтения журнала транзакций, надеясь на немедленное спасение. Но они не знают, что то, что им нужно тихо выполняется в фоне. SQL Server 2005 обладает встроенной возможностью, которая дает администраторам ответы на все эти вопросы.

Ответы находятся в новой фоновой трассировке, названной «трассировка по умолчанию». Трассировку по умолчанию полностью характеризует ее имя — это трассировка. Трассировка по умолчанию всегда выполняется в фоне, записывая события, которые администраторы могут использовать для исправления проблем. Трассировка по умолчанию включена по умолчанию и не обременяет систему, поскольку является достаточно легковесной. Вероятно, вы никогда даже не обращали внимания на то, что она выполняется в вашей системе. Людям, озабоченным накладными расходами: да, трассировка приводит к определенным издержкам производительности, но, на мой взгляд, полученные выгоды гораздо важнее минимальных накладных расходов. Трассировка по умолчанию не предназначена для замены функций DDL­триггера и должна использоваться в качестве возможности мониторинга состояния экземпляра SQL или для срочного получения информации о проблемных событиях.

Трассировка по умолчанию не собирает все события, но получает достаточно информации для того, чтобы стать мощным средством в вашем арсенале. Трассировка по умолчанию получает основную информацию: события аудита, события базы данных, события ошибок, события полнотекстового поиска, создание, удаление и изменение объекта. По моему опыту и наблюдениям на форумах, я сконцентрируюсь на событиях уровня объекта. Похоже, что большинство людей хотят знать ответ на вопрос «кто это сделал?» для DDL­событий объекта.

Мониторинг резервного копирования баз данных при помощи Operations Manager

Томас ЛаРок демонстрирует, как Operations Manager помогает администраторам баз данных, — тем из них, кто готов засучить рукава, поплевать на ладони и немного «попрограммировать», — осуществлять всесторонний мониторинг вверенных им систем. «Возможности поистине безграничны», — заявляет Томас.

Введение

В рамках доклада по Operations Manager на PASS 2008 я предложил слушателям новый собственный монитор, недавно разработанный и развернутый мною в среде Data Server нашей организации. К этому моменту мною был реализован поражающий — как мне казалось — воображение монитор Operations Manager, призванный оповещать о созданных или измененных в течение прошедшего дня заданиях SQL Agent. Но мой восторг был разделен лишь немногими, и тогда я пришел к выводу, что коллеги ждут от мониторов Ope­ra­tions Manager в первую очередь простоты и надежности.

С этим нельзя было не согласиться. Несмотря на все приложенные усилия я раз за разом с огорчением обнаруживал, что, по всей видимости, Operations Manager функционирует не совсем так, как я предполагал. Например, если некое задание завершится неудачей, но не сформирует соответствующего сообщения (что вполне вероятно), то Operations Manager и не предупредит о сложившейся ситуации. Скорее всего причиной подобного поведения является неудачно прописанная обработка ошибок, но представьте, что задание SQL Agent — это задание по резервному копированию вашей базы данных! Вы останетесь без свежей резервной копии базы и даже не узнаете об этом!

Все обдумав и сам с собою «посоветовавшись», я понял, что есть два пути, — либо следует вначале перебрать и перерыть все задания, добавляя корректную обработку всех мыслимых и немыслимых ошибок, а затем убедиться, что Operations Manager настроен на тщательную проверку журналов ошибок и событий, и при необходимости отправит нам предупреждение. Либо (и этот путь показался мне предпочтительным) я разработаю в Operations Manager монитор, который сможет заглянуть в системную базу данных msdb, чтобы определить, когда в последний раз полное резервное копирование было выполнено успешно.

А по­вашему, что лучше? Меня заинтересовал второй вариант, позволяющий построить еще один настраиваемый монитор, который (как я предвкушал), может войти в стандартный пакет управления Manage­ment Pack от Microsoft (либо от стороннего распространителя продукта). Поведав свою идею коллегам на PASS, я почувствовал, что на сей раз действительно «попал в яблочко». Насколько мне известно, администраторам часто приходится увязывать между собой множество отчетов о копировании, чтобы удостовериться, что резервные копии баз данных действительно созданы. Я предпочитаю отслеживать события в режиме реального времени, а не обращаться к ежедневным отчетам, и мне кажется, что подобный настраиваемый монитор, будучи чем­то вроде программы Hello World, которую каждый желающий способен разработать для себя сам, на самом деле привлечет внимание к Operations Manager.

Operations Manager как большой конструктор

Чтобы продемонстрировать замечательные возможности Systems Center Operations Manager 2007, Томас шаг за шагом вместе с вами проходит процесс создания настраиваемого монитора для заданий SQL Agent и делает вывод, что Operations Manager — ни что иное, как большой конструктор, из деталей которого создаются инструменты, призванные облегчить ваш повседневный труд.

Шесть преимуществ использования отказоустойчивых кластеров на основе SQL Server 2008

Отказоустойчивые кластеры на основе SQL Server 2008 обладают несколькими улучшениями в надежности и доступности. В списке перечисляются подробности наиболее важных и новых преимуществ перехода на SQL Server 2008 Failover Clustering.

Надежная установка

Процесс установки SQL Server 2008 Failover Clusters значительно изменился. По существу, у нас есть два альтернативных способа установки: интегрированная (integrated) или расширенная (advanced/enterprise) установка. Интегрированная установка включает в себя инсталляцию экземпляра отказоустойчивого кластера SQL Server 2008 с одним узлом. Если вы хотите, чтобы этот экземпляр мог переходить на другие узлы при отказе, то должны провести инсталляцию «add node» на каждом узле.

Расширенная инсталляция отличается от интегрированной тем, что вы подготавливаете каждый узел, устанавливая двоичные файлы и службы SQL, затем выбираете активный узел, которому будет принадлежать общий диск SQL Server, а после этого запускаете созданный экземпляр SQL Server.

Расширенная инсталляция предназначена для промышленных разработчиков, а также чтобы предоставить возможность подготовки каждого узла перед конфигурированием Windows Cluster. Вы можете использовать расширенный вариант, но в целом, интегрированная инсталляция выполняется за меньшее количество шагов и позволит создать экземпляр SQL Server быстрее.

С точки зрения количества шагов интегрированный вариант инсталляции требует меньше усилий. Например, интегрированная инсталляция кластера, состоящего из двух узлов, потребует одного шага «Install» для первого узла, и одного шага «Add node» для добавления второго узла. Расширенная инсталляция потребует выполнения подготовки (два шага) для каждого узла, после чего потребуется третий шаг, завершающий конфигурацию экземпляра SQL Server и запускающий его.

На первый взгляд, это больше походит на работу администраторов, какая же польза от этого нововведения? В отличие от отказоустойчивых кластеров на основе SQL Server 2005, инсталляция SQL Server 2008 Failover Cluster не использует операций с удаленными узлами. Это приводит к тому, что шаги инсталляции становятся более изолированными, но помогает уменьшить количество проблем, возникающих из­за вопросов прав доступа к удаленным узлам, отключенных удаленных служб, подключений к терминальным службам и других коммуникационных проблем, которые могут стать причиной частичной или вовсе неудачной инсталляции. При переходе на SQL Server 2008 Failover Cluster, надежность инсталляций значительно увеличится, поскольку устранено несколько переменных удаленных узлов, препятствовавших надежной установке отказоустойчивого кластера SQL Server.

Улучшенная доступность при установке обновлений

В прежних версиях SQL Server установка пакета обновлений (service pack) или кумулятивного обновления могла потребовать отключения экземпляра SQL Server на несколько минут, поскольку для обновления экземпляра SQL Server, служба SQL Server должна быть остановлена, пока выполняется обновление.

При использовании отказоустойчивого кластера на основе SQL Server 2008, интервал времени, когда экземпляр будет отключен, существенно уменьшается, если вы правильно выполняете «rolling update». Вы можете избежать длительных отключений экземпляров SQL Server, если будете применять обновления к пассивным узлам отказоустойчивого кластера.

После применения обновлений к пассивным узлам, вы можете передать управление экземпляром недавно обновленному узлу.

После перехода на обновленный узел, экземпляр SQL Server оказывается обновленным, а вы можете приступать к обновлению узлов, которые прежде были активны.

В моем тестировании участвовал кластер из двух узлов с одним экземпляром SQL Server 2008. Я начал процедуру обновления с установки накопительного обновления (Cumulative Update) на пассивный узел кластера. Во время установки обновления, экземпляр SQL Server оставался запущенным. После применения накопительного обновления, я перевел выполнение экземпляра SQL Server 2008 на только что обновленный узел, а затем применил накопительное обновление на втором, теперь пассивном, узле. Общее время простоя при обновлении составило 15 секунд — именно столько понадобилось для перехода экземпляра SQL Server на обновленный узел.

Доступность при добавлении или удалении узлов

Как и в случае SQL Server 2005, добавление новых узлов в отказоустойчивый кластер SQL Server или их удаление не требует остановки работы экземпляра SQL Server. Как и для всех действий настройки кластера, AddNode (добавление узла) должен выполняться на том узле, который должен быть добавлен к кластеру, в отличие от SQL Server 2005, в котором это действие должно было производиться на активном узле. Это привело к увеличению надежности, поскольку AddNode в 2008 версии не основывается на удаленном планировании и выполнении. Все, что должен указать пользователь для выполнения AddNode в 2008 версии, это: нужный экземпляр, пароль учетной записи службы при использовании графического интерфейса (имя и пароль учетной записи службы при использовании командной строки), настройки отчетов об использовании и ошибках. Процесс выбора опций выполняется в существующем экземпляре, к которому добавляется текущий узел.

Кроме того, в процессе тестирования, при добавлении нового узла к отказоустойчивому кластеру, я получил следующее сообщение:

«The current node TX147913-3 is at patch level [10.0.1600.22], which is lower than that of active node TX147913-2: patch level [10.0.1763.0]. After completing setup, you must download and apply the latest SQL Server 2008 service pack and/or patch and bring all nodes to the same version and patch level»

(«Текущий узел TX147913­3 обновлен до уровня [10.0.1600.22], что ниже уровня активного узла TX147913­2: [10.0.1763.0]. После выполнения установки вы должны скачать и применить свежий пакет обновлений SQL Server 2008 и привести все узлы к одному уровню обновлений».)

Это полезное предупреждение дало знать, что мне нужно обновить добавленный узел отказоустойчивого кластера, чтобы он соответствовал уже существующим узлам. Обновление только что созданного пассивного узла не потребует рестарта отказоустойчивого кластера SQL Server 2008.

Использование SID служб вместо доменных групп в Windows Server 2008

Для многих администраторов очень болезненным моментом стало требование SQL Server 2005 Failover Clustering использовать доменные группы для служб SQL Server. Эти доменные группы использовались для управления разрешениями учетных записей служб SQL Server; однако каждая доменная группа должна содержать в себе учетные записи служб для установки.

Изменение доменной группы хотя и возможно, но сопряжено с определенными трудностями (см. KB 915846, «Best practices that you can use to set up domain groups and solutions to problems that may occur when you set up a domain group when you install a SQL Server 2005 failover cluster»).

Если вы создаете новый кластер SQL Server 2008 на Windows Server 2008, то можете избежать использования доменных групп, указав во время установки Service SIDs (идентификаторы безопасности службы). Возможность использования Service SID впервые появилась в Windows Vista и Windows Server 2008, что позволило назначить ACL (списки контроля доступа) к ресурсам сервера напрямую службе Windows. Вы все еще можете использовать доменные группы, выбрав соответствующие опции в диалоге «Cluster Security Policy» во время установки отказоустойчивого кластера, однако для SQL Server 2008 на Windows Server 2008 рекомендуемым выбором является «Use service SIDS», который позволяет вам избежать подготовки доменных групп и связанных с ними учетных записей служб перед установкой.

Улучшенная интеграция в Windows server 2008

Кроме уже описанных преимуществ, использование SQL Server 2008 на Windows Server 2008 предоставляет вам и другие значительные выгоды. Например, кластеры на Windows Server 2008 не требуют, чтобы все аппаратные средства в кластере были указаны в Hardware Compatibility List (HCL). Поиск и подтверждение вашей аппаратной конфигурации в HCL зачастую становились трудными задачами. В Windows Server 2008, вам больше не нужно подтверждать вашу конфигурацию в HCL. Вместо этого ваш Windows Server 2008 кластер должен пройти подтверждение с помощью Windows Server 2008 Cluster Validation Tool.

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

В Windows Server 2008 Failover Clustering были добавлены новые опции кворума (quorum options), что позволило перейти от модели единственной точки отказа (single­point­of­failure) к модели на основе консенсуса (consensus­based). Кроме того, Windows Server 2008 Failover Clustering предоставляет поддержку iSCSI дисков, до 16 узлов в кластере и протокола IPv6.

Автоматическое создание ConfigurationFile.ini

SQL Server 2008 Failover cluster позволяет использовать конфигурационный файл при установке из командной строки. Например, выполнение следующей команды инициирует интегрированную инсталляцию одноузлового отказоустойчивого кластера, ссылаясь на конфигурационный файл с помощью необходимых опций командной строки:

Setup.exe /q /ACTION=InstallFailoverCluster /Configurationfile="C:\temp\ConfigurationFile.ini"

Более того, выполнение инсталляции не из командной строки автоматически генерирует файл ConfigurationFile.ini, который сохраняется в следующую директорию:

<drive letter>:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\<YYYYMMDD_HHMMSS\ConfigurationFile.ini

Обратите внимание, что в ConfigurationFile.ini не указывается опция FAILOVERCLUSTERIPADDRESSES — однако это легко можно сделать вручную. Например:

FAILOVERCLUSTERIPADDRESSES="IPv4;172.29.10.160;Cluster Network 1;255.255.248.0"

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

(Возврат на основную страницу)