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

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

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

Май 2008
№ 5 (23)

Мафесами Ананта Кумар

Командная оболочка Microsoft Windows PowerShell и объектная модель SMO сервера SQL Server 2005. Часть 5

Салим Хакани, Дэн Каролло

Вопросы и ответы по SQL. Часть 2

Лео Пейсахович

Поиск неиспользуемых объектов в базе данных

Шон Маккоун

Практический подход к зеркальному отображению баз данных

Стоит ли вам предпочесть зеркальное отображение баз данных?

Рави С. Маньям

Declarative Management Framework: SQL Server 2008

Кимберли Л. Трипп

Структура базы данных и повышение производительности. Часть 1

Командная оболочка Microsoft Windows PowerShell и объектная модель SMO сервера SQL Server 2005. Часть 5*

В части 1 и 2 серии обсуждалось, как установить PowerShell и как использовать простые командлеты SMO и WMI. В части 3 рассказывалось о том, как писать скрипты PowerShell и подключаться к SQL Server. В части 4 говорилось, как использовать скрипт для прохождения по содержимому файла в цикле и для соединения с различными серверами. В данном фрагменте мы продемонстрируем, как использовать PowerShell и скрипт PowerShell для создания баз данных.

Вопросы и ответы по SQL. Часть 2*

Некластеризованные индексы и сохранение полномочий

Поиск неиспользуемых объектов в базе данных

Недавно, когда я обсуждал проблемы SQL Server, я получил письмо следующего содержания: «Кто-нибудь знает какие-либо бесплатные/условно бесплатные утилиты для определения неиспользуемых объектов в базе данных? Мне досталась база данных от предыдущего разработчика, и, похоже, в ней много неиспользуемых объектов. Я знаю, что Apex SQL Clean может справиться с такой задачей, но мой босс не согласится купить эту утилиту. Буду признателен за любые предложения». Как много раз мы получали такой ответ от босса!

Итак, я начал искать способы определения неиспользуемых объектов без каких­либо утилит. Я понимаю, что утилиты могут сделать эту работу лучше, но мне было интересно сделать это собственными силами хотя бы просто для изучения этого вопроса и из «спортивного интереса».

Вы знаете, что во многих случаях удаление неиспользуемых объектов упрощает и ускоряет сопровождение разработки и может увеличить эффективность и производительность базы данных. Существует множество методов, которые могут быть использованы. В конце концов, основная задача — определить, что объект не использовался месяц или два. Я говорю «месяц или два» потому, что база данных может использоваться не только приложениями, но и backend­процессами. Например, в моей компании есть ежедневные, еженедельные и ежемесячные процессы, что и определяет, как часто объект может использоваться. Эта задача может быть решена несколькими способами, один из них — использование SQL Profiler, но для этого нужно, чтобы эта утилита была непрерывно запущена в течение длительного времени, что не очень практично и может даже понизить производительность системы.

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

1.  Найти неиспользуемые хранимые процедуры и удалить их.

2.  Найти объекты, на которые не ссылается ни одна хранимая процедура и которые не являются таблицами поиска (lookup table).

Основная идея моего решения заключается в постоянном выполнении запросов к системному кешу для поиска процедур, не имеющих плана исполнения в течение длительного периода времени. Для этого можно использовать системную таблицу syscacheobjects, которая содержит информацию об использовании кеша и находится в базе данных master. Возможно, на первый взгляд, трудно оценить значение этой техники и информации, полученной из отчета, но этот метод очень прост и предоставляет очень точную картину неиспользуемых хранимых процедур. Этот способ не так безупречен, как может показаться, но проверка планов исполнения базы данных — это хороший способ для администраторов найти неиспользуемые хранимые процедуры, функции и другие объекты.

Практический подход к зеркальному отображению баз данных

Организуйте и поддерживайте зеркальное отображение как средство достижения высокой доступности своими силами

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

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

Стоит ли вам предпочесть зеркальное отображение баз данных?

Стремление добиться высокой доступности сервера SQL Server способно завести в труднопроходимое болото. Вряд ли удастся легко выбрать верное, отвечающее потребностям решение, если вам не известны все нюансы различных вариантов, если вы не представляете, как они реализуются, и не осознаете уровень необходимой для них DBA-поддержки. Зеркальное отображение баз данных — вот решение, которое позволяет обеспечить постоянные обновления репликации транзакций (transactional replication), отказоустойчивость кластерной структуры и легкость управления доставкой журналов. Подробное обсуждение всех различий, существующих между этими технологиями, выходит за рамки данной публикации, но я попытаюсь затронуть некоторые из наиболее важных соображений.

Понимание того, когда надо использовать зеркальное отображение, является ключом к успешной реализации, и на первый взгляд трудно понять, какие преимущества обеспечивает вам зеркалирование в сравнении с другими технологиями, позволяющими добиться высокой доступности. С функциональной точки зрения зеркальное отображение базы данных лучше рассматривать как доставку отдельных журнальных записей. Сторонние поставщики рынка средств интеллектуального резервирования приняли в свой арсенал зеркальное отображение, поэтому я также склонен отнести эту технологию в категорию инструментов для интеллектуального резервирования. Решения от сторонних поставщиков, такие, например, как WANSynchHA фирмы XOsoft, SonaSafe фирмы SonaSoft и инструментальные средства достижения высокой доступности фирмы Double­Take Software расчистили дорогу для использования таких решений интеллектуального резервирования, которые позволяют дистанционно осуществить в случае отказа перехват управления в автоматическом режиме. Эти решения обеспечивают способ, позволяющий поддерживать два сервера в синхронном состоянии, за счет постоянного отслеживания внесенных изменений в файлы базы данных и копирования изменившихся битов на резервный сервер. Такие решения не могут перенаправлять клиентов в случае отказа, но способны изменить DNS­записи и выполнить другие задачи, чтобы гарантировать подключение клиентов к соответствующему серверу, если вдруг основной сервер выйдет из строя. Такого рода решения могут оказаться сложными, поэтому вы должны провести тщательный анализ, чтобы разобраться в их возможностях. Далее, когда пытаетесь решить, стоит ли использовать зеркальное отображение, задайте себе вопрос: типична ли для вас ситуация, когда вы обращаетесь за решением к одному из сторонних поставщиков; если так, вам станет ясно, что зеркальное отображение базы данных может обеспечить подходящее решение.

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

Вам также необходимо понимать различия между зеркальным отображением и репликацией. Репликация позволяет вспомогательной базе данных постоянно находиться в online­режиме, тогда как при зеркалировании вспомогательная база данных по существу находится в offline­режиме. Репликация позволяет вам задать интервалы обновления вспомогательной базы данных; зеркалирование лишено такой возможности. Однако подобно приложениям от сторонних поставщиков, репликация не обеспечивает нуль­потери данных. К тому же, зеркалирование обеспечивает автоматический перехват управления при отказе, чего не делает репликация.

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

Declarative Management Framework: SQL Server 2008

В глубоком раздумье, о чем бы написать, я подумал, почему бы не написать о Declarative Management Framework. Чудное решение для DBA-администраторов, которые без устали латают и закрывают «мышиные» дыры, создаваемые нарушителями некоторых принятых стандартов, будь то соглашение о наименовании таблиц или создание хранимой процедуры не в той схеме. Следовательно, если вам интересно, что такое «Declarative Management Framework», тогда соблаговолите оставить сомнения и скачайте последний доступный релиз SQL Server 2008 фераль 2008 (http://www.microsoft.com/downloads/info.aspx?na=22&p=16&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamilyID%3d749bd760-f404-4d45-9ac0-d7f1b3ed1053%26DisplayLang%3den), инсталлируйте его, прочтите эту статью и приступайте к практической деятельности. Обещаю, вам понравится.

Что такое декларативная среда управления (Declarative Management Framework)

Декларативная среда управления (Declarative Manage­ment Framework) — это система управления одним или несколькими экземплярами сервера SQL Server 2008, основанная на применении политик (policy). Это значит, что теперь для эффективного администрирования баз данных вместо того, чтобы нажимать/отжимать физические кнопки, вы можете использовать логические кнопки, которые даже можно было бы экспортировать в файл для последующего использования, и применить этот файл к группе из нескольких серверов SQL Server.

DBA­администраторам не следует волноваться, это не есть еще один каркас вроде каркаса .Net Framework, для работы с которым необходимо попасть в среду Visual Studio и программировать пользовательский код, тестировать, распространять и сопровождать его. Использовать декларативную среду управления очень просто, и все политики отлично можно было бы создать в среде SQL Server 2008 Management Studio.

Компоненты каркаса Declarative Management Framework

Каркас Declarative Management Framework образуют три компонента:

1.  Управление политиками (Policy management).

2.  Явное администрирование (Explicit admini­stra­tion).

3.  Автоматизированное администрирование (Auto­mated administration).

Управление политиками

Администраторы политик создают политики.

Явное администрирование

Администраторы выбирают один или несколько объектов управления (managed target) и явно проверяют соблюдение этими объектами конкретной политики или явно заставляют эти объекты подчиняться конкретной политике.

Автоматизированное администрирование

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

•    Предотвращение нарушений политики при попытке внести изменения. В этом режиме для предотвращения нарушений политики используются DDL­триггеры.

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

•    В журнале фиксируется нарушение политики в указанное время. В этом режиме используется задание SQL Server Agent, чтобы периодически вычислять политику.

Если автоматизированные политики запрещены, среда Declarative Management Framework не будет влиять на производительность системы. Если они разрешены, система будет испытывать лишь незначительное падение производительности в зависимости от числа политик, применяемых к конкретному объекту.

Среда Declarative Management Framework — ключевые термины и понятия

Объект управления (Managed Target)

Сущности, которыми управляет среда Declarative Management Framework, например экземпляр механизма SQL Server Database Engine, база данных, таблица или индекс. Все объекты управления сервера образуют иерархию объектов управления. Набор объектов управления — это набор объектов, полученный в результате применения набора фильтров к иерархии объектов управления, например все таблицы в базе данных, принадлежащие схеме HumanResources.

Образ (Facet)

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

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

Условие (Condition)

Логическое выражение, которое определяет набор разрешенных состояний объекта управления среды Declarative Management Framework, принадлежащего конкретному образу.

Политика (Policy)

Условие среды Declarative Management Framework и ожидаемое поведение, например режим выполнения, фильтры объектов управления и расписание (schedule). Политика может включать только одно условие. Политики могут быть разрешены или запрещены.

Категория (Category)

Определяемая пользователем категория, помогающая упорядочить политики. Пользователи могут классифицировать политики по разным категориям. Политика принадлежит одной или нескольким категориям.

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

Режим выполнения (Execution Mode)

Определяет, как будет выполняться политика. Режимами, обеспечивающими выполнение по требованию, являются Check и Configure. Режимы автоматизированного выполнения следующие:

1.  Предотвращение нарушений политики при попытке внести изменения.

2.  При попытке внести изменения нарушение политики фиксируется в журнале.

3.  В журнале фиксируется нарушение политики в указанное время.

Действующая политика (Effective Policy)

Действующие политики объекта управления — это политики, которые руководят этим объектом. Политика является действующей по отношению к объекту управления только в том случае, если выполняются все нижеследующие условия:

•    Политика разрешена.

•    Объект управления принадлежит целевому набору политик.

•    Объект управления или один из его «предков» (ancestors) подписаны на группу политик, в которую входит данная политика.

Сценарии применения: примеры

Среда Declarative Management Fra­me­work была бы полезна при разрешении проблем, описываемых следующими сценариями:

•    Идеология фирмы запрещает использование электронной почты Data­base Mail или SQL Mail. Создается политика для проверки состояния этих двух серверных возможностей. Администратор сравнивает состояние сервера с политикой. Если сервер находится в «неправильном» состоянии, администратор переходит в режим Configure и политика приводит сервер в надлежащее состояние.

•    База данных AdventureWorks имеет соглашение о наименовании, которое требует, чтобы имена всех хранимых процедур начинались с символов AW_. Создается политика для принудительного соблюдения этой стратегии. Администратор тестирует политику и получает список нарушающих ее хранимых процедур. Если новые хранимые процедуры нарушают соглашение о наименовании, предложения, создающие хранимые процедуры, не выполняются.

Структура базы данных и повышение производительности. Часть 1

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

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

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