Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

updlock заставляет применить блокировку update вместо обычной shared, используется, когда следом идет оператор update, основанный на прочитанных значениях, чтобы запретить update из других транзакций;

paglock заставляет сервер при любых условиях использовать блокировки уровня страницы;

tablock принудительно блокирует таблицу (shared);

tablockx принудительно блокирует таблицу (exclusive).

Просмотр текущих блокировок выполняется при помощи хранимой процедуры sp_lock или через включение флага трассировки 1200 на клиента: dbcc traceon (3604,1200). Также полезным являются флаги 1204 и 1205, которые выдают информацию о cитуациях взаимной блокировки (deadlocks). MS SQL Server обладает возможностью автоматического обнаружения deadlocks как циклов в цепочке блокировок. Он находит первый процесс, который мог бы разорвать цикл, убивает его и откатывает все транзакции этого процесса, находившиеся в стадии выполнения. Как правило, им оказывается тот самый процесс, который запросил блокировку, послужившую причиной зацикливания. После этого сервер генерирует сообщение об ошибке 1205. Если клиентское приложение имеет обработчик ошибок, отлавливающий ошибку 1205, то оно может предпринять соответствующие действия по исправлению ситуации, и конечный пользователь, скорее всего, даже не узнает, что имела место взаимная блокировка.

Надежность хранения информации

В критических для бизнеса приложениях, когда сервер СУБД должен быть постоянно доступен для клиентов, большинство профилактических работ по поддержке базы данных приходится выполнять фактически в режиме on-line. MS SQL Server обладает возможностями динамического резервного копирования данных, т. е. даже когда эти данные используются и изменяются клиентами. В случае сбоя оборудования, отключения питания и т. д. механизм автоматического восстановления MS SQL Server восстанавливает все базы данных до их последнего целостного состояния без вмешательства администратора. Все завершенные, но не отраженные в базе транзакции из журнала транзакций применяются к базе данных (это фактически то, что происходит при событии chekpoint), а незавершенные транзакции, т. е. те, которые были активными на момент сбоя , вычищаются из журнала.

Как мы уже отмечали, говоря о симметричной архитектуре, операции резервного копирования и восстановления могут распараллеливаться на несколько потоков и выполняться одновременно, используя преимущества асинхронного ввода/вывода. На каждое резервное устройство отводится свой поток. Параллельное резервное копирование поддерживает до 32 одновременных резервных устройств (backup devices), что позволяет быстро создавать страховочные копии баз данных даже очень большой емкости. Возможность резервного копирования и восстановления отдельных таблиц, о чем мы упоминали, рассматривая Transact-SQL, позволяет экономить место и время, не выполняя копирование всей базы ради только некоторых ее объектов. Однако резервное копирование отдельной таблицы требует наложения на нее блокировки exclusive в отличие от резервного копирования всей базы или журнала транзакций, которые могут выполняться независимо от степени активности пользователей. Резервным копиям может быть назначен предельный срок хранения или дата утраты актуальности, до наступления которой место, занятое на устройстве этими копиями, не может использоваться для размещения других резервных копий при инициализации устройства. В качестве резервных устройств могут также применяться временные устройства, не входящие в состав базы и не имеющие записей в системной таблице sysdevices:

DECLARE @tomorrow char(8)

SELECT @tomorrow = CONVERT(char(8), DATEADD(dd, 1, GETDATE()) , 1)

DUMP DATABASE pubs

TO DISK = '\\ntalexeysh\disk_d\sql_experiments\pubs.dmp'

WITH INIT, EXPIREDATE=@tomorrow, STATS

Для небольшой базы данных ее журнал транзакций обычно хранится на том же устройстве, что и сама база, и архивируется вместе с ней. Журналирование транзакций ведется по принципу write-ahead, что означает, что любое изменение сначала отражается в журнале транзакций и лишь потом попадает собственно в базу. В случае нахождения журнала транзакций на отдельном устройстве существует возможность отдельного резервного копирования журнала транзакций. Как правило, резервное копирование базы данных организуется с меньшей частотой, чем журнала транзакций. Например, сохранение журнала транзакций выполняется ежедневно, а страховая копия всей базы может делаться раз в неделю, так как архивирование журнала транзакций происходит значительно быстрее по времени и занимает меньше места, чем дамп целой базы. В отличие от резервирования базы данных дамп журнала транзакций очищает его неактивную часть, т. е. все завершившиеся (зафиксированные или абортированные) с момента последнего дампа транзакции, если только не использована опция NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY, очищающая журнал транзакций, полезна в случае его переполнения, которое можно контролировать, например, оператором DBCC SQLPERF (LOGSPACE). Если степень переполнения журнала очень высока, можно при его очистке отказаться от журналирования факта самого этого события: DUMP TRANSACTION NO_LOG. Если резервное копирование транзакций не представляет интереса, можно включить опцию очистки последних завершенных транзакций в базе по наступлению события checkpoint. Cмысл механизма checkpoint состоит в периодической записи данных из кэша на диск, чтобы не допускать грязных данных. Такого рода события постоянно генерируются MS SQL Server или возникают по инициативе пользователя. Включенная опция truncate log on checkpoint гарантирует выполнение с определенной частотой обработчиком события действий, приблизительно эквивалентных команде DUMP TRANSACTION TRUNCATE_ONLY.

При восстановлении журнала транзакций соответствующие транзакции применяются к базе данных. Это означает, что если в начале недели была сделана резервная копия всей базы, а потом ежедневно архивировались транзакции за каждый день, то при необходимости восстановления поднимается состояние базы на начало недели и на него последовательно накатываются дампы журнала транзакций за все дни, предшествующие моменту восстановления. MS SQL Server 6.5 имеет возможность восстановления данных из журнала транзакций на произвольный момент времени (разумеется, отраженный в журнале) при помощи команды LOAD TRANSACTION STOPAT или в окне database backup and restore выбором опции until time. Все содержащиеся в этом дампе транзакции, отмеченные завершившимися после этого момента, будут откачены.

Возможность планирования задач резервного копирования во времени и отсылки сообщений по e-mail в случае успешного/неуспешного завершения рассматривалась нами при обсуждении SQL Executive.

MS SQL Server 6.5 предусматривает возможность зеркалирования устройств, переключения на зеркальные устройства в качестве основных, выключения зеркалирования и уничтожения зеркального устройства также "на лету", т. е. без остановки штатной работы сервера по обслуживанию пользовательских запросов. Зеркалирование и дуплексирование устройств для работы с MS SQL Server может быть также выполнено средствами Windows NT, а также на аппаратном уровне (поддержка различных RAID-систем и т. д.). По-видимому, следует предполагать, что реализация первого этапа кластерной технологии WolfPack будет поддерживать MS SQL Server 6.5 в отказоустойчивых кластерах из двух узлов. Появление следующей версии MS SQL Server должно обеспечить работу серверов в кластере как единого виртуального сервера.

Transfer Manager используется для экспорта/импорта объектов и данных БД на MS SQL Server между разными аппаратными платформами, например между процессорами Intel и Alpha, а также между разными версиями MS SQL Server, в частности из более ранних в более поздние или между равноценными (имеются в виду 4.х и 6.х). Очень часто проектирование объектов базы ведется с помощью различных графических средств, но проектная документация может требовать структуру объектов с точностью до операторов DDL. Для получения скриптов, описывающих создание отдельного объекта базы данных, можно использовать команду transfer из контекстного меню объекта или выбрать соответствующий класс и имя объекта в Transfer Manager. Кроме этого, содержимое данных может быть выгружено/загружено при помощи утилиты bcp (см. табл. 1).

Тиражирование

Наличие развитого механизма тиражирования в любой серьезной системе управления базами данных обуславливается необходимостью приближения данных к местам их непосредственного потребления, что является особенно важным фактором при построении витрин данных в системах принятия решений, разгрузки приложений от избыточных функций чтения/поиска при создании отчетов и т. д. Создание распределенных приложений с использованием средств тиражирования положительно сказывается на относительной автономии сайтов, повышении масштабируемости и производительности. Традиционно в построении распределенных систем данных существуют два основных подхода. Один из них основан на плотной целостности данных (loose consistency) и рассматривался нами в пункте, посвященном MS Distributed Transaction Coordinator. Протокол двухфазной фиксации гарантирует идентичность данных в любой момент времени на всех узлах сети, однако необходимо иметь в виду, что этот подход требует наличия высокоскоростных каналов передачи данных и постоянной доступности каждого узла. Другой подход, основанный на слабой целостности (loose consistency), допускает, вообще говоря, некоторый временной интервал между внесением изменений в оригинал и их отражением в образе. Приложения, основанные на принципе слабой целостности, являются значительно менее чувствительными к доступности узлов, а также пропускной способности и надежности каналов передачи данных. Тиражирование в MS SQL Server построено на использовании именно второго подхода.

Основными действующими лицами в процессе тиражирования служат издатель (publisher), дистрибьютор (distributor) и подписчик (subscriber). Поскольку тиражирование является неотъемлемой составной частью MS SQL Server, последний может выступать в роли каждого из них. Конфигурирование и управление каждой ролью осуществляется из SQL Enterprise Manager через уже знакомые нам SQL-DMO или с помощью операторов и хранимых процедур языка Transact-SQL. Репликационной единицей в плане распространения и подписки является публикация (publication). Публикация состоит из одной или нескольких статей (articles). Статьей публикации называется отдельная таблица или ее вертикальный и/или горизонтальный фрагмент. Вертикальное фрагментирование осуществляется выбором соответствующих полей таблицы, горизонтальное - при помощи условия where или специальной процедуры горизонтальной фильтрации (CREATE PROCEDURE - FOR REPLICATION). Таблица обязана иметь первичный ключ. Как только на издателе созданы статьи, все тиражируемые объекты отмечаются специальным признаком в одном из полей системной таблицы sysobjects. Кроме этого, в тиражируемой базе ведется еще три справочные таблицы. Syspublications в отдельной строке хранит информацию о каждой новой публикации. Она связана отношением один-ко-многим с таблицей sysarticles, содержащей информацию о статьях и их принадлежностью публикациям. Наконец, последняя, в свою очередь, связана отношением один-ко-многим с таблицей syssubscriptions, где содержится информация о том, каким подписчикам адресована каждая статья.

Тиражирование в MS SQL Server основано на журнале транзакций (log-based). На каждую тиражируемую базу данных на дистрибьюторе запускается процесс под названием log reader, который читает журнал транзакций на издателе, выбирает оттуда все завершенные транзакции, помеченные к тиражированию и передает их дистрибьютору, на который с того момента возлагается вся дальнейшая ответственность по доведению этих транзакций до подписчика. Издатель, таким образом, высвобождается от всякой заботы по распространению транзакций и не расходует на это свои ресурсы. Каждый подписчик обслуживается отдельным потоком дистрибьютора. Клиент, первым запустивший sp_replcmds на публикуемой базе данных, рассматривается ею как log reader, все остальные попытки это сделать вызовут сообщение об ошибке. Процедура sp_repltrans позволяет получить список завершенных транзакций базы данных, еще не переданных дистрибьютору (идентификатор ряда, страница и отметка времени поступления). sp_replcmds содержит еще информацию о самих командах, связанных с этой транзакцией, и к какой статье публикации она относится. Log reader читает эти операции, определяет соответствующие им sql-команды и пишет их в базу данных распространения (distribution database) на дистрибьюторе. База данных распространения имеет таблицы MSjobs, содержащую информацию о транзакциях для тиражирования, связанную как один-ко-многим с таблицей MSjob_commands, которая разбивает каждую транзакцию на отдельные команды. Каждая команда должна быть передана определенному подписчику, что определяется в таблице MSsubscriber_jobs. На издателе прочитанные транзакции отмечаются как переданные на распространение, и только после этого они могут быть оттуда уничтожены при резервном копировании журнала транзакций (см. выше). Например, процедура sp_repldone, определяя транзакцию в журнале базы издателя по ряду и странице, помечает ее как распространенную. Процесс синхронизации (sync task), один на публикацию, всякий раз при появлении нового подписчика создает мгновенный снимок (snapshot) данных на издателе, подлежащих тиражированию этому подписчику. При этом создаются файлы схем данных и, собственно, содержания (bcp-типа), которые будут переданы подписчику при распространении для обеспечения первоначальной идентичности данных.

На дистрибьюторе существуют еще два вида процесса: распространение и очистка. Задача распространения создается для каждой пары "тиражируемая база/подписавшаяся база", а задача очистки - для пары "издатель/подписчик". Распространение (distribution task) применяет прочитанные из базы данных распространения sql-команды к базе данных подписчика. Процесс очистки (cleanup task) уничтожает все выполненные работы (т. е. транзакции) из базы данных распространения через некоторый настраиваемый интервал (retention period) после того, как они были доведены до подписчика. Задача очистки может быть создана вручную при помощи sp_addsubscriber, a задача распространения - как sp_addsubscription (sp_subscribe). Несмотря на то что организация всего процесса тиражирования может быть записана в кодах при помощи вызовов специальных хранимых процедур, эта черта используется на практике крайне редко и главным образом в целях отладки. В обычных ситуациях настройка и управление тиражированием осуществляются из графической среды SQL Enterprise Manager и планировщика задач SQL Executive.

Все задачи репликации на дистрибьюторе работают под управлением SQL Executive (msdb...systasks) и под его контекстом безопасности. Процесс выполнения любой из них можно контролировать в окне task history. Дополнительным средством контроля служит SQL Performance Monitor, куда передается необходимая статистическая информация о тиражировании (sp_replcounters). Соединение дистрибьютора с издателем происходит на основе DB-Library, а с подписчиком - через ODBC. Таким образом, в качестве подписчиков MS SQL Server может выступать широкий спектр ODBC-достижимых ресурсов, к которым, например, относятся другой Access, Sybase, Oracle, DB2 и т. д. Тиражирование в MS SQL Server основано на интегрированном режиме безопасности (см. Безопасность), следовательно, между дистрибьютором и подписчиком должны быть установлены доверительные соединения (trusted connections) с использованием поименованных каналов (named pipes) или мультипротокола. Если серверы находятся в разных доменах, между доменами должны быть установлены двусторонние доверительные отношения. В случае небольших объемов тиражируемых данных издатель часто совмещает с дистрибьютором на одном MS SQL Server. Отметим также, что серверы, участвующие в тиражировании, должны использовать одни и те же кодовые страницы.

MS SQL Server обладает обширными возможностями настройки процесса тиражирования. Мы уже упоминали о горизонтально-вертикальных фрагментах таблиц в качестве статей публикаций. Отметим, что для каждой статьи имеется возможность назначить к тиражированию только необходимые типы транзакций. Например, можно запретить передачу подписчикам транзакции типа "delete" в рамках данной статьи. Более того, на каждый тип транзакций можно настроить вид пользовательских действий на стороне подписчика. Например, при поступлении подписчику транзакций вставки и удаления они будут отрабатываться, как обычно, а по приходе транзакции типа "update" на подписчике будет вызываться некоторая хранимая процедура. Некоторые ограничения в тиражируемых данных бывает нецелесообразно передавать подписчику. В этом случае они помечаются как not for replication. Процесс синхронизации как самый дорогой в смысле трафика предусматривает возможность ручного выполнения синхронизации или полного отказа от синхронизации данных и передачу исключительно транзакций. Существует и обратная возможность: подписчику с определенной периодичностью будут поступать только мгновенные снимки данных, а не их изменения.

В зависимости от административного акцента MS SQL Server позволяет организовать подписку на стороне издателя либо на стороне подписчика. Первый вид подписки (push subscription) используется при централизованном распространении, когда подписки создаются "выталкиванием" статей на те или иные серверы-подписчики, которые могут не иметь своих администраторов. Второй вид (pull subscription) предполагает известную автономию сервера-подписчика, администратор которого определяет, какие публикации ему принимать. По умолчанию все публикации создаются со статусом безопасности "неограничено", они видны и на них могут подписаться любые зарегистрированные серверы подписки. Ограниченная публикация может быть выписана только теми серверами, которые имеют на это соответствующие права.

Вопросы безопасности доступа

Как мы уже отмечали, говоря о преимуществах интеграции с операционной системой, MS SQL Server использует в своей работе сервисы безопасности Windows NT. Напомним, что Windows NT на сегодня сертифицирована по классам безопасности С2/Е3. MS SQL Server может быть настроен на работу в одном из трех режимах безопасности. Интегрированный режим предусматривает использование механизмов аутентификации Windows NT для обеспечения безопасности всех пользовательских соединений. В этом случае к серверу разрешаются только трастовые, или аутентифицирующие, соединения (named pipes и multiprotocol). Администратор имеет возможность отобразить группы пользователей Windows NT на соответствующие значения login id MS SQL Server при помощи утилиты SQL Security Manager. В этом случае при входе на MS SQL Server login name и пароль, переданные через DB-Library или ODBC, игнорируются. Стандартный режим безопасности предполагает, что на MS SQL Server будут заводиться самостоятельные login id и соответствующие им пароли. Смешанный режим использует интегрированную модель при установлении соединений по поименованным каналам или мультипротоколу и стандартную модель во всех остальных случаях.

Характеристики

Список файлов реферата