MS SQL Server 6.5

Тип целостности 

Пояснения 

Механизмы контроля 

Entity 

Определяет запись как уникальную для таблицы сущность 

Primary key, 

Unique key, 

Identity 

Domain 

Определяет область  допустимых значений для поля 

Default, Check, 

Foreign key 

Referential 

Поддержка ссылочной  целостности связей 

Check, Foreign key, 

Trigger 

User-defined 

Все прочие бизнес-правила  на уровне столбца и таблицы 

Trigger, Rule, 

Stored procedure 
 

Таблица 2. 

Вся информация об ограничениях, наложенных на таблицу, может быть просмотрена при помощи хранимой процедуры sp_helpconstraint. Ограничения всегда вызываются перед триггерами. Последовательность обработки выглядит следующим образом: rules, references, check, referenced by и затем triggers. Подробная характеристика черт Transact-SQL сама по себе могла бы составить отдельную статью или даже несколько статей, поэтому мы ограничимся констатацией лишь некоторых его новшеств по сравнению с предыдущей версией MS SQL Server: 

• операторы CUBE и ROLLUP для создания аналитических  запросов при построении систем поддержки  принятия решений; 

• оператор CREATE SCHEMA (создание концептуального контейнерного  объекта); 

• возможность  временной отмены ограничений при  тиражировании; 

• дополнительные хранимые процедуры для настройки процесса тиражирования; 

• возможность  тиражирования данных типа text и image; 

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

• возможность  использования операторов DDL внутри транзакции; 

• новые опции DBREINDEX, PROCCACHE, ROWLOCK, UPDATEUSAGE для DBCC; 

• оператор INSERT-EXEC позволяет осуществить непосредственную вставку результатов выполнения процедуры; 

• поддержка  распределенных транзакций. 

Помимо обычных  хранимых процедур MS SQL Server предоставляет возможность динамической загрузки и выполнения функций, которые называются расширенными хранимыми процедурами и выполнены в виде dll-библиотек. Пример такой библиотеки, содержащий расширенные процедуры для работы с электронной почтой, мы видели, когда рассматривали интеграцию MS SQL Server с MS Exchange. Расширенные процедуры объединены в dll-библиотеки в целях повышения производительности по сравнению с оформлением в виде отдельных процессов. Кроме расширенных процедур, входящих в Transact-SQL, MS SQL Server позволяет создавать пользовательские расширенные процедуры c использованием кода на C при помощи MS Open Data Service (ODS) API. MS ODS является мощным средством разработки и применяется также для создания шлюзов к неподдерживаемым штатно пользовательским ресурсам, программирования задач аудита, извещения о событиях и пр. Добавление новых расширенных процедур осуществляется командой sp_addextendedproc 'xp_proc', 'xp.dll', где xp_proc - новая процедура, содержащаяся в библиотеке xp.dll. Удаление ненужных процедур производит команда sp_dropextendedproc. Так как расширенная процедура исполняется в адресном пространстве MS SQL Server, право на ее добавление имеет только системный администратор. Дополнительный уровень защиты обеспечивается обработчиком исключений MS SQL Server, который предотвращает сервер от сбоя в случае нарушений защиты памяти в расширенной процедуре.

В версии 6.5 в Transact-SQL вошли хранимые процедуры для  работы с объектами OLE Automation. Таким  образом, фактически появилась возможность писать расширенные хранимые процедуры на любом языке программирования, поддерживающем создание cерверов OLE Automation: Visual Basic версии 4 и выше, Visual FoxPro 5.х и т. д. Экземпляр соответствующего объекта создается непосредственно в коде Transact-SQL при помощи хранимой процедуры sp_OACreate. Доступ к свойствам осуществляется через sp_OAGet-Property, sp_OASetProperty. Вызов метода организует процедура sp_OAMethod. sp_ OAGetErrorInfo сообщает информацию о последней произошедшей ошибке, наконец, sp_OADestroy высвобождает объект после его использования. 

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

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

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

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

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) не допускает аналогичные блокировки на протяжении периода своего действия по отношению к блокированным им данным.