Лекции по "Систе́ма управле́ния ба́зами да́нных "

 
Рис. 20.4.  Демонстрация работы автоинкрементного поля

Обратите внимание на то, что мы вносили значения только в поляNazvanieиStoimost. Значения для поля ID генерировались триггером автоматически. Не забудьте перед закрытием окна Interactive SQL закрыть транзакцию командой COMMIT.

В отличие от хранимых процедур, для триггеров не предусмотрен раздел в дереве серверов утилиты IBConsole. Однако увидеть наш триггер можно. Триггер создавался для таблицы Tovar. Выделите ее, нажмите правую кнопку мыши и в контекстном меню выберите команду Properties. Откроется окно свойств таблицы, в котором следует перейти на вкладку Metadata. В этом окне, после описания создания таблицы, вы увидите описание нашего триггера Tr_Tovar.

 

Лекция 4. Транзакции. Механизм транзакций

Мы упоминали, чтотранзакции- это  пакет  запросов,  который  последовательно  производит  изменения  БД  и  либо  принимается,  если  все  изменения  записи  подтверждены,  либо  отвергается,  если  хоть  один  запрос  завершился  неуспешно.  Запросы  могут  состоять  из  операторовSELECT  /  INSERT  /  UPDATE  /  DELETE,  причем  в  контексте  однойтранзакцииможет  быть  как  один  такой  запрос,  так  и  множество  запросов.  Однако  понятие  "транзакция"  гораздо  глубже  этого  короткого  определения.

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

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

Поясним  эту  суть  на  классическом  примере  перевода  денег  в  банке  с  одного  счета  на  другой.

Допустим,  наша  БД  работает  безтранзакций,  и  нам  нужно  произвести  упомянутый  перевод.  Тут  мы  можем  поступить  двумя  разными  способами:

1. Вначале  снимаем  деньги  с  одного  счета,  затем  добавляем  их  к  другому  счету.
2. Вначале  добавляем  деньги  к  другому  счету,  затем  снимаем  их  с  первого  счета.

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

Однако  всеSQL-серверы  баз  данных  работают  с  применениемтранзакций.  Еще  говорят,  что  все  изменения  базы  данных  происходят  в  контексте  одной  или  несколькихтранзакций.InterBaseне  исключение,  более  того,InterBaseпредоставляет  гораздо  более  гибкие  инструменты  для  управлениятранзакциями,  чем  многие  другиеSQL-серверы.  Если  произошел  какой  то  сбой  при  переводе  денег,  тотранзакцияне  получила  подтверждения,  а  база  данных  осталась  в  прежнем  состоянии  -  целостность  и  достоверность  БД  не  нарушились.

Более  20  лет  назад  исследователи  Тео  Хендер  и  Андреас  Рютер  опубликовали  обзор,  в  котором  описывали  принципы  поддержания  целостности  БД  в  много-клиентской  среде.  Эти  принципы  принято  называтьACID(Atomicity,Consistency,  Isolation,  Durability-Атомарность,Согласованность,  Изоляция  иУстойчивость).  Всетранзакциидействуют  по  этим  принципам.

Атомарность  (Atomicity)

Атомарностьподразумевает,  чтотранзакцияявляется  единицей  работы  с  базой  данных.  Внутритранзакцииможет  происходить  множество  модификаций  БД,  однакотранзакциядействует  по  принципу  "все  или  ничего".  Когдатранзакцияподтверждается  (Commit),  то  подтверждаются  все  изменения  данных,  сделанные  в  ее  контексте.  Когда  она  отвергается  (откатывается,Rollback),  то  отвергаются  и  все  изменения.  В  случае  возникновения  сбоя,  система,  восстанавливаясь,  ликвидирует  последствиятранзакций,  не  успевших  завершиться.

Согласованность  (Consistency)

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

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

Изолированность  (Isolation)

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

Устойчивость  (Durability)

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

Неявный  и  явный  старт  транзакций

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

Транзакциюможно  стартовать  и  явно.  Из  стандартных  механизмов  доступа  мы  будем  использовать,  в  основном,InterBase  Express  (IBX).  В  приложении  должен  присутствовать  как  минимум,  один  компонентIBTransaction.  С  помощью  этого  компонента  можно  явно  указать  параметрытранзакции,  управлять  стартом,  подтверждением  или  откатомтранзакции.  Делается  это  с  помощью  следующих  методов  компонента:

• StartTransaction-  Старттранзакции.
• Commit-  Подтверждениетранзакциис  последующим  ее  закрытием.
• CommitRetaining-  Подтверждениетранзакциибез  ее  закрытия.
• Rollback-  Откаттранзакциис  последующим  ее  закрытием.
• RollbackRetaining-  Откаттранзакциибез  ее  закрытия.

Впрочем,  компоненты  доступа  к  данным  неявно  производят  запусктранзакции,  поэтомуStartTransactionобычно  пропускают.  А  вот  подтверждение  или  откаттранзакциипроверяют,  как  правило,  в  блокеtry…exceptв  клиентском  приложении:

try

      //какие  то  действия  над  данными...

      IBTransaction1.Commit;  //подтверждаем

Except

      //произошла  ошибка

      ShowMessage('Невозможно  выполнить  операцию!');

IBTransaction1.Rollback;    //делаемоткаттранзакции

end;  //try

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

Как  транзакция  работает

В  базе  данных  имеется  специальная  область,  которая  называетсяTIP(Transaction  Inventory  Page-  Инвентарная  Страница  Транзакций).  При  стартетранзакции,  ей  присваивается  идентификатор  (TID,Transaction  ID)  -  инвентарный  номер,  который  сохраняется  вTIP.  При  этом  у  самой  последнейтранзакциибудет  наибольший  идентификатор.  ВTIP,  помимо  номера  стартовавшейтранзакции,  сохраняется  и  ее  состояние,  которое  может  бытьActive(В  работе),Committed(Подтвержденная),Rolled  Back(Отмененная,  откат)  иIn  Limbo(Неопределенная).

Активнойназываетсятранзакция,  которая  в  настоящий  момент  выполняется.

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

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

Неопределеннойтранзакцией  (Limbo)  называюттранзакцию,  которая  работает  одновременно  с  двумя  или  более  базами  данных.  При  завершении  такойтранзакции,  InterBase  совершает  двухфазное  подтверждениеCommit,  гарантируя,  что  изменения  будут  внесены  либо  во  все  БД,  либо  ни  в  одну.  При  этом  подтверждения  в  базах  данных  будут  даваться  по  очереди.  Если  в  это  время  возникнет  сбой  системы,  то  может  получиться,  что  в  каких  то  БД  изменения  были  сделаны,  а  в  каких  то  нет.  При  этомтранзакцияпереходит  в  неопределенное  состояние,  когда  сервер  не  знает,  следует  ли  подтвердить  этутранзакцию,  или  откатить.

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

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

Еслитранзакциязавершилась  неуспешно,  оригинал  записи  так  и  остается  оригиналом.

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

Однако  могут  возникать  и  конфликтытранзакций.  Предположим,  что  стартовалатранзакцияТ1.  Она  создала  версию  записи,  и  поменяла  ее  данные.  В  это  время  стартовала  конкурирующаятранзакцияТ2,  и  создала  версию  той  же  записи.  Поскольку  Т1  еще  не  завершилась,  Т2  при  старте  не  могла  видеть  изменения  данных,  сделанные  Т1,  а  значит,  создала  свою  версию  из  старого  оригинала.  Теперь  Т1  завершает  работу  поCommit.  Как  должен  поступитьInterBase?  Если  он  пометит  версию  записи  Т1  как  оригинал,  а  старую  запись,  как  удаленную,  то  в  версии  Т2  окажутся  ложные  данные!  ДействияInterBaseв  этом  случае  будут  зависеть  от  параметров  этихтранзакций,  о  чем  ниже  мы  поговорим  подробней.

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

Таким  образом,  говорят,  чтоInterBaseимеет  многоверсионную  архитектуру  (MGA-Multi  Generation  Architecture).  Такая  архитектура  позволяет  организовать  работу  с  базой  данных  так,  чтобы  читающие  пользователи  не  блокировали  пишущих.  Кроме  того,  при  возникновении  сбоев  в  системе,InterBaseочень  быстро  восстанавливается,  благодаря  именноMGA.  Кстати,InterBaseявляется  первымSQL-сервером,  который  поддерживает  многоверсионную  архитектуру.

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

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

Предположим,  что  стартовалатранзакцияТ1.  Этатранзакциясоздала  версию  записи  и  модифицировала  ее.  Позже  стартовалатранзакцияТ2,  которая  настроена  так,  чтобы  видеть  все  изменения  данных,  даже  не  подтвержденные.  Она  обратилась  к  той  же  записи,  а  поскольку  она  желает  видеть  последние  изменения,  ей  предоставляют  версиютранзакцииТ1.  Затем  Т1  завершила  свою  работу,  но  Т2  пока  еще  работает  с  ее  версией  записи,  следовательно,  эту  версию  удалять  нельзя.