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

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

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

MS Distributed Transaction Coordinator (DTC) и распределенные транзакции

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

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

HRESULT hr; ITransactionDispenser *pTxDispenser;

тогда hr = DtcGetTransactionManager(

NULL,

// имя хоста DTC, NULL

// означает данный хост

NULL,

// имя менеджера транзакций

IID_ITransactionDispenser,

// требуемый интерфейс

0,

// зарезервировано

0,

// зарезервировано

(void *)NULL,

// зарезервировано

(void **)&pTxDispenser);

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

ITransaction *pTx;

hr = pTxDispenser->BeginTransaction (

NULL,

// управляющий интерфейс

ISOLATIONLEVEL_BROWSE,

// уровень изоляции

0,

// флаги изоляции

NULL,

// зарезервировано

&pTx);

// Ptr на объект "транзакция"

Как видно из примера, приложение начинает распределенную транзакцию, вызывая метод BeginTransaction объекта "первичный менеджер транзакции". После этого оно может работать с менеджерами ресурсов. Первое обращение к менеджеру ресурсов из приложения однозначно идентифицирует текущую транзакцию. Менеджеры ресурсов, участвующие в данной транзакции, должны прописаться в объекте "транзакция" при помощи менеджеров транзакций.

RETCODE rc; HDBC hSrv1, hSrv2;•

rc = SQLSetConnectOption( hSrv1, SQL_COPT_SS_ENLIST_IN_DTC, pTx);

rc = SQLSetConnectOption( hSrv2, SQL_COPT_SS_ENLIST_IN_DTC, pTx);

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

DbExecSQL(hSrv1,"INSERT INTO...");

DbExecSQL(hSrv2,"INSERT INTO..."); ...

hr=pTx->Commit(0,0,0);•hr=pTx->Release()

Инициация распределенных транзакций сервером имеет ряд дополнительных преимуществ по сравнению с только что рассмотренной инициацией на стороне клиента. К ним относятся меньшие сетевые затраты при управлении транзакциями, а также то, что ошибка на клиенте не "подвешивает" транзакции в состоянии in-doubt. Кроме того, вызовы Transact-SQL достаточно просты в использовании. При явном определении все вызовы удаленных процедур наследуют контекст распределенной транзакции.

BEGIN DISTRIBUTED TRANSACTION

INSERT INTO ACCOUNTS VALUES (100,20)

EXEC RMTBRANCH.ACCOUNTS.DBO.DEPOSIT

100,20

COMMIT TRANSACTION

При неявном определении при помощи установок sp_configure "remote proc trans", 1 (уровень сервера) или set remote_ procedure_transactions on (уровень сессии) MS SQL Server по умолчанию рассматривает локальные транзакции, начатые begin transaction, как распределенные с подключением DTC, если в них содержатся вызовы удаленных хранимых процедур.

Корректное завершение транзакции выполняется при помощи протокола двухфазной фиксации. Когда приложение вызывает метод commit, менеджер транзакций оповещает зарегистрировавшиеся менеджеры ресурсов подготовиться к фиксации данной транзакции, и, после того как все они известили о своей готовности, менеджер транзакций рассылает широковещательное сообщение зафиксировать транзакцию. Если хотя бы один менеджер ресурсов не сообщил о готовности фиксировать транзакцию, она повсеместно откатывается. После сообщения о готовности менеджер ресурсов пребывает в состоянии сомнения (in-doubt) относительно общего исхода. Так как менеджеры ресурсов регистрируются в транзакции, то менеджеры транзакций имеют возможность отслеживать все их операции и хранят журналы о решениях фиксировать или откатить транзакцию. В свою очередь менеджер ресурсов также ведет у себя такой журнал. Следовательно, если имел место сбой в сети, то после его ликвидации менеджер транзакций связывается с вышестоящим менеджером транзакций и запрашивает его об исходах. После этого менеджер ресурсов идет на свой менеджер транзакций и получает у него информацию о том, что делать с зависшими транзакциями. Кроме этого, если исход транзакции известен, DTC предоставляет возможность "ручного" разрешения транзакций, чтобы слишком долго не держать данные блокированными.

MS DTC содержит компоненты клиентской и серверной настройки. Установка клиентского компонента требуется только в том случае, если данный клиент будет сам инициировать распределенные транзакции, а не использовать транзакции, начатые на серверной стороне как begin distributed transaction. MS DTC достаточно легок и удобен в настройке и управлении. Он имеет окна:

• в разных источниках он может также называться глобальным (global) или корневым (root);

• конфигурации, позволяющее задать темп обновления информации, транзакции какой давности должны показываться, место и емкость журнала, статус DTC;

• трассировки, отображающие сообщения от DTC;

• транзакций, отображающие статус текущих транзакций:

• статистики по текущим и суммарным транзакциям.

В рассмотренном примере инициации распределенной транзакции на стороне клиента мы проиллюстрировали использование интерфейсов, соответствующих стандарту OLE Transaction. OLE Transaction выгодно отличается от некоторых других распространенных стандартов тем, что построен на основе объектной модели и поддерживает приложения, работающие одновременно со многими потоками. OLE Transaction обладает улучшенными характеристиками по сравнению с ранее разработанными стандартами, лишенными, например, возможности восстановления (recovery), инициированного менеджером ресурсов. Тем не менее при помощи процесса XA Mapper MS DTC, выполняющего роль переводчика между XA и OLE Transaction, обеспечивается определенное взаимодействие с продуктами, совместимыми со стандартом X/Open DTP XA. MS DTC может участвовать в транзакциях, координируемых мониторами транзакций Encina, TopEnd и Tuxedo, для которых он выглядит как некоторый менеджер ресурсов. Стандарт OLE Transaction содержит возможности расширения для работы с широким спектром транзакционно защищенных ресурсов, к которым могут быть отнесены документы, образы, очереди сообщений и другие виды плохо структурированной информации.

Блокировки

MS SQL Server использует следующие типы блокировок:

shared - для операций, не изменяющих содержимое данных, например select;

update - когда сервер намеревается изменить данные, во время непосредственной записи обновлений этот тип блокировки изменяется на exclusive (для таблиц см.intent);

exclusive - при модификации данных (insert, update, delete).

Совместимость блокировок различных типов приводится в табл. 3. Основными типами являются shared и exclusive. Блокировку типа update можно рассматривать как некий механизм для сочетания первых двух типов блокировок в одной операции в целях предотвращения взаимного блокирования транзакций (deadlock). Как правило, большинство процессов, модифицирующих данные, состоят из двух частей: поиск (чтение) необходимой информации и внесение изменений. Заметим, что при наличии кластеризованного индекса на таблицу операция вставки тоже относится к подобным процессам - сервер должен сначала отыскать правильное местоположение новых записей. Разумно во избежание излишней конкуренции разрешить другим транзакциям читать данные во время первой фазы такого процесса. Тогда возникает вопрос: зачем вообще вводить дополнительный тип блокировки и почему нельзя обойтись первыми двумя? Ответ очевиден, если рассмотреть одновременно несколько таких процессов. Они будут прекрасно уживаться на стадии поиска, но ни один из них не сможет монопольно запереть данные для записи, так как другие в это время их читают. Для исключения взаимной блокировки в MS SQL Server при выполнении первой фазы вводится тип блокировки update, который (см. табл. 3) не допускает аналогичные блокировки на протяжении периода своего действия по отношению к блокированным им данным.

Таблица 3.

Уровень блокировки может распространяться на:

• запись (для операций insert);

• cтраницу - 2-килобайтный фрагмент данных или индексов;

• расширение (extent) - 8 последовательных страниц, используется при размещении или высвобождении страниц (например, в командах create/drop или когда операция вставки insert требует выделения новых страниц памяти);

• таблицу, включая все входящие в нее данные и индексы².

В следующей версии блокировка уровня записи будет возможна для всех типов транзакций. Блокировка уровня записи на операции вставки позволяет в первую очередь решить задачу уменьшения вероятности конкуренции в OLTP-системах с массированным одновременным вводом информации (типичный пример - операционный день банка), где таблицы содержат только некластерные индексы или кластерный индекс построен по монотонно возрастающему ключу. По умолчанию эта опция выключена. В текущей базе данных ее можно задействовать командой sp_tableoption , 'insert row lock', 'true'.

Существует диалектическое противоречие, с которым наверняка сталкивался каждый администратор базы данных или разработчик. С одной стороны, хочется уменьшить до минимума вероятность столкновения интересов пользователей при доступе к одним и тем же ресурсам и потому блокировать все на как можно более детальном уровне. С другой - очень не хочется перегружать менеджер блокировок, который фиксирует информацию о том, кто наложил блокировку, какого типа, кто ждет, пока она освободится и т. д. Например, в MS SQL Server 6.5 каждая блокировка обходится в 32 байта. Для разрешения этого противоречия сервер умеет автоматически повышать уровень блокировки в случае, если блокировок предыдущего уровня детализации становится слишком много (lock escalation). "Слишком много" - это LE Threshold Maximum в настройках конфигурации сервера, т. е. максимальная пороговая величина числа страничных блокировок, при достижении которой происходит эскалация до уровня таблицы. По умолчанию она равна 200. Для этих же целей используется настройка LE Threshold Percentage - в относительном выражении к размеру таблицы (но не меньше, чем LE Threshold Minimum, что полезно для небольших таблиц). В перспективе возможна обратная стратегия динамической деэскалации уровня блокировки, когда блокируется заведомо больший фрагмент данных, чем требуется, но, как только появляется транзакция, конкурирующая за данные внутри данного фрагмента, уровень первой транзакции будет автоматически уменьшен.

Управление уровнем изоляции транзакций на протяжении всего соединения (пользовательской сессии) осуществляется при помощи установки set transaction isolation level , где уровень изоляции может принимать значения:

read uncommitted соответствует уровню изоляции 0 стандарта ANSI, т. е. просто запрещает различным транзакциям изменять одни и те же данные в одно и то же время, но допускает грязное и неповторяющееся чтение и фантомы³;

read committed (устанавливается по умолчанию) соответствует уровню изоляции 1 стандарта ANSI, т. е. предотвращает грязное чтение;

repeatable read или serializable соответствует уровню 3 по стандарту ANSI - предотвращает грязное чтение, а также гарантирует, что два оператора select в разных местах одной транзакции будут возвращать одинаковый результат, т. е. исключает неповторяющееся чтение и фантомы.

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

nolock то же, что read uncommitted, - дает возможность чтения грязных (еще не зафиксированных) данных, которая перекрывает аналогичные параметры конфигурации пользовательской сессии. В операторе select можно также оговорить продолжительность блокировки данных;

holdlock инструктирует сервер держать блокировки до завершения транзакции (по умолчанию блокировки снимаются сразу же по прочтении требуемых данных;

Тип и уровень блокировки:

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

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