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

Содержание номера за Январь 2009 год

SQL Server

Январь 2009
№ 1 (97)

DB Design & Warehousing

Ашиш Кумар Мехта

Спецификации аудита баз данных в SQL Server 2008

Other

Кевин С. Гофф

Чертова дюжина: 13 советов для работы с SQL Server 2008 и SSRS 2008. Часть 2
 

По материалам статьи Динеш Асанка

Репликация DDL в SQL Server 2000 и 2005
 

Одноранговая репликация транзакций в Microsoft SQL Server 2005
 

А. Гладченко

Использование динамических фильтров совместно с динамическими снимками

Спецификации аудита баз данных в SQL Server 2008

В версии SQL Server 2008 представлена новая возможность, которая называется подсистема аудита SQL Server. Аудит базы данных SQL Server заключается в отслеживании и фиксации в журнале событий, происходящих на уровне базы данных. Эта возможность позволяет администраторам баз данных выработать стратегию реагирования в случае возникновения конкретной угрозы  для БД SQL Server 2008.

Спецификация аудита баз данных

Объект спецификации аудита базы данных (Database Audit Specification) также принадлежит подсистеме аудита SQL Server (SQL Server Audit). Администратор БД может создать одну спецификацию аудита базы данных для каждого аудита каждой БД SQL Server.

Спецификация аудита БД образует набор дей­ствий аудита, выполняемых на уровне базы данных, наступление которых инициирует компонент расширенных событий (Extended Events). Также в спецификацию аудита базы данных можно добавлять или группы действий аудита, или события аудита. События аудита — это атомарные действия, которые может осуществлять механизм SQL Server. Тогда как группы действий аудита — это предопределенные группы стандартных действий. И события, и группы действий аудита принадлежат области базы данных SQL Server. Эти действия передаются подсистеме аудита, которая обеспечивает их регистрацию в целевом объекте. Пользователи, принадлежащие роли db_owner, могут модифицировать любые спецификации аудита базы данных.

Как использовать подсистему аудита SQL Server

Чтобы создать объект аудита, администратор БД может воспользоваться средой SQL Server Management Studio (SSMS) или средствами языка Transact SQL. После того как соответствующий объект создан, аудит необходимо включить, поскольку по умолчанию SQL Server его блокирует.

До тех пор пока аудит не включен, целевой объект не будет получать данные. Чтобы прочесть содержимое журнала событий безопасности Windows или журнала событий приложений Windows можно воспользоваться утилитой Event Viewer операционной системы Windows. Можно использовать для чтения целевого файла утилиту Log File Viewer, входящую в состав SQL Server Management Studio, или встроенную функцию FN_READ_AUDIT_FILE сервера SQL Server.

Шаги, из которых состоит процедура создания и использования объекта аудита, перечислены ниже:

•    Создать объект аудита и определить целевой объект, в котором будет накапливаться информация аудита.

•    Можно создать спецификацию аудита сервера или спецификацию аудита базы данных.

•    Подключить спецификацию аудита. По умолчанию SQL Server блокирует созданный объект аудита.

•    Проанализировать зарегистрированные события аудита с помощью утилит Windows Event Viewer, Log File Viewer или с помощью встроенной функции FN_READ_AUDIT_FILE.

Чертова дюжина: 13 советов для работы с SQL Server 2008 и SSRS 2008. Часть 2*

* См. Кевин С. Гофф. Чертова дюжина: 13 советов для работы с SQL Server 2008 и SSRS 2008. Часть 1 // SQL Server для профессионалов. 2008. № 12.

Репликация DDL в SQL Server 2000 и 2005

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

Одноранговая репликация транзакций в Microsoft SQL Server 2005

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

SQL Server 2000 предоставляет три типа репликации:

•    Репликация моментальных снимков (snapshot replication).

•    Репликация транзакций (transactional replication).

•    Репликация слиянием (merge replication).

В SQL Server 2005 к вышеперечисленным методам репликации добавился новый:

•    Одноранговая репликация транзакций (Peer­to­peer transactional replication).

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

Возможности репликации в различных выпусках SQL Server 2005

Все редакции SQL Server 2000 (за исключением SQL Server CE) поддерживали все типы репликации. В SQL Server 2005 ситуация несколько изменилась. Возможности репликации в различных редакциях SQL Server 2005 отражены в табл. 1.

Подписчики, отличные от SQL Server, публикация данных из Oracle и одноранговая репликация транзакций — новые возможности репликации в SQL Server 2005, но они доступны не во всех выпусках. Как видно из таблицы, одноранговая репликация транзакций доступна только в Enterprise и Developer редакциях SQL Server 2005.

Выпуск SQL Server 2005 Developer Edition включает в себя всю функциональность выпуска Enterprise. Однако этот выпуск предназначен только для разработки и тестирования, и не может использоваться в эксплуатационной среде. Следовательно, для того чтобы воспользоваться преимуществами одноранговой репликации транзакций, необходимо иметь выпуск Enterprise. Розничная цена процессорной лицензии для редакции Enterprise примерно в четыре раза выше, чем для редакции Standard, так что вопрос стоимости может быть одним из важных факторов в принятии решения.

Использование одноранговой репликации транзакций

Предположим, что у нас есть обычное приложение электронной коммерции. Для того чтобы избежать простоев и снизить нагрузку на отдельные серверы, база данных этого приложения располагается более чем в одном офисе. Поскольку это online­приложение и данные меняются (добавляются, изменяются, удаляются) в каждом офисе, то все модификации данных в одном офисе должны реплицироваться на серверы во всех остальных офисах. Предположим, что у нас есть базы данных в офисах A, B и C.

Чтобы реализовать подобную схему синхронизации данных в SQL Server 2000 мы должны использовать репликацию слиянием. Офис А — издатель, офисы B и C — подписчики.

Очевидным недостатком такого метода является то, что в нем присутствует «единая точка отказа» в конфигурации репликации. Если B откажет, то репликация между A и C будет продолжать работать и пользователи, подключенные к серверам A и C, не заметят никаких осложнений в работе. Однако если откажет узел A, то B и C будут «изолированы» от системы и изменения на них не будут видны.

Репликация SQL Server 2000 использует иерархию «издатель­подписчик». Успешное функционирование данной конфигурации требует, чтобы издатель был постоянно доступен.

В одноранговой (peer­to­peer) топологии репликации SQL Server 2005 каждый узел действует и как издатель, и как подписчик. Изменения (вставки, обновления и удаления) могут выполняться на всех узлах. Репликация распознает, что на заданном узле произошли изменения, но позволяет этим изменениям пройти по всем узлам только один раз.

Если один из узлов недоступен (например, А), осталь­ные узлы (B и C) продолжают участвовать в репликации. Когда узел A снова становится доступен, он может синхронизироваться с другими узлами (B и C) и получить те изменения, которые произошли после его отказа. Это возможно благодаря тому, что все узлы (A, B и C) функционируют и как издатели, и как подписчики.

Совершенствование репликации в SQL Server 2008 (кодовое название Katmai)

В новой версии MS SQL Server 2008 (Katmai) произведены некоторые изменения, облегчающие настройку и управление одноранговой репликацией транзакций.

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

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

Табл. 1. Типы репликации, поддерживаемые различными редакциями SQL Server (источник: BOL)

Использование динамических фильтров совместно с динамическими снимками

Динамические фильтры в репликации позволяют использовать возвращаемые системными функциями SUSER_SNAME() и HOST_NAME() значения для выделения собственных разделов данных каждому подписчику. Кроме этих функций, динамическую фильтрацию можно построить на определяемых пользователем функциях — UDF.

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

Поскольку динамический фильтр подразумевает наличие разных наборов данных, которые передаются подписчикам, создаваемый для первоначальной синхронизации моментальный снимок отличается от стандартного снимка. В таком снимке отсутствует файл BCP, который содержит данные. Данные передаются после применения схемы и указанного в свойствах статей публикации набора реплицируемых объектов. Стандартный моментальный снимок в сжатом виде доставляется подписчику, распаковывается, после чего данные из BCP файла с помощью команды BULK INSERT загружаются в таблицы подписчика. Создаваемый же для содержащей динамический фильтр публикации снимок будет очень маленьким, т. к. не содержит данных, но применяться будет существенно дольше стандартного снимка. Данные будут загружаться таким же образом, как реплицируется вставка, и вставляться будут все значения из таблиц издателя, на основании которых построена публикация. Для больших и даже для средних баз данных такая первоначальная синхронизация или повторная инициализация подписчика может занять много времени.

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

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

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

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