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

в базах данных компании IBM для явной блокировки целой таблицы применяется инструкция lock table, синтаксическая диафамма которой изображена на рис. 12.14 С помощью этой инсфукции можно установить один из двух режимов блокировки:

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

ш В режиме share осуществляется нежесткая блокировка таблицы. Другие транзакции могут извлекать данные из таблицы (т.е они тоже могут осуществлять нежесткую блокировку), но не могут обновлять ее Для того чтобы обновить часть таблицы, транзакция, выполнивщая инсфукцию lock table, должна жестко заблокировать требуемую часть таблицы Этот режим блокировки следует использовать также в том случае, если фебуется получить мгновенный снимок таблицы в какой-то определенный момент времени.

В СУБД Oracle, как и в DB2, тоже используется инсфукция lcck table В СУБД Ingres аналогичное действие выполняет другая инсфукция. В нескольких других СУБД, включая SQL Server и SQLBase, явная блокировка не применяется вообще, а вместо этого усоверщенствована методика применения неявной блокировки

Уровни изоляции *

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

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

может значительно сократить затраты на блокировку, если она будет наперед знать, каким образом профамма будет обращаться к базе данных во время транзакции Для этого в основных СУБД для мэйнфреймов компании IBM введено понятие задаваемого пользователем уровня изоляции, который позволяет найти некоторый компромисс между степенью изоляции и эффективностью работы. В спецификации стандарта SQL2 это понятие формализовано и расщирено: оно включает в себя четыре уровня (табл. 12.1). Уровни изоляции напрямую связаны с основными проблемами изменения данных в многопользовательской среде, которые были рассмотрены ранее в настоящей главе. По мере уменьшения уровня изоляции (в таблице - в направлении сверху вниз) сокращается число проблем, от которых СУБД защищает пользователя.

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

Уровень изоляции repeatable read является вторым по степени изоляции после уровня serializable. На этом уровне фанзакция не имеет доступа к промежуточным или окончательным результатам других транзакций, выполняющих обновления данных, поэтому такие проблемы, как пропавшее обновление, промежуточные или несогласованные данные, возникнуть не могут. Однако во время своей транзакции вы можете увидеть сфоку, добавленную в базу данных другой танзакцией. Поэтому один и тот же запрос к нескольким сфокам, выполненный дважды в течение одной фанзакции, может возвратить различные таблицы результатов (проблема строк-призраков). Если профамме не фебуется повторять запрос, возвращающий набор записей в течение одной фанзакции, то для повышения производительности СУБД можно установить уровень изоляции repeatable read, не рискуя при этом нарушить целостность данных. Этот уровень изоляции поддерживается в СУБД, используемых на мэйнфреймах компании IBM.

уровень read committed является третьим по степени изоляции. На этом уровне транзакция не имеет доступа к промежуточным результатам других транзакций, поэтому проблемы пропавшего обновления и промежуточных данных возникнуть не могут. Однако окончательные результаты других, параллельно выполняемых транзакций, могут быть доступны вашей транзакции. Программа могла бы, например, дважды в течение транзакции выполнить одиночную инструкцию select и обнаружить, что некоторая строка была изменена другим пользователем. Если программе не требуется повторно извлекать одну и ту же строку в течение транзакции и она не накапливает итоги и не выполняет других вычислений, для которых необходимы непротиворечивые данные, можно безо всяких опасений применять уровень изоляции read committed. Обратите внимание на следующее: если профамма попытается обновить сфоку, которую уже обновил другой пользователь, то транзакция будет автоматически отменена во избежание возникновения проблемы пропавшего обновления

Уровень read uncommitted является наиболее низким уровнем изоляции в стандарте SQL2. В этом режиме на выполнение фанзакции могут повлиять как окончательные, так и промежуточные результаты других фанзакгшй, поэтому могут возникнуть проблемы как сфок-призраков, так и промежуточных и несогласованных данных. Однако СУБД по-прежнему предотвращает проблему пропавшего обновления В общем случае уровень read uncommitted подходит только для некоторых приложений со специальными запросами, где пользователь может позволить, чтобы результаты запроса содержали фязные данные. Если для вас важно, чтобы результаты запроса представляли только ту информацию, которая является окончательной на текущий момент для базы данных, то не следует использовать этот режим в своих профаммах

В стандарте SQL2 описана инструкция set transaction, представленная на рис. 12.15. Она используется для установки уровня изоляции текущей транзакции. В этой инсфукции можно также указать, операции какого типа осуществляет транзакция выполняет ли она только запросы на выборку информации из базы данных (афибут read only) или можст выполнять запросы как на выборку, так и на изменение (атрибут read write). СУБД использует эту информацию наряду со сведениями об уровне изоляции для оптимизации работы базы данных. По умолчанию устанавливается уровень изоляции serializable. Если задан уровень read uncommitted, то предполагается, что транзакция имеет атрибут read only, поэтому афибут read write задать нельзя. В остальных случаях по умолчанию считается, что транзакция имеет атрибут read write. Установки по умолчанию обеспечивают максимальную безопасность фанзакции, пусть даже ценой некоторой потери производительности. Это оберегает неопытных профаммистов от нечаянного столкновения с рассмофенными ранее проблемами обработки данных в многопользовательской среде.

\- SET TRANSACTiON

I-iSOLATiON LEVEL т- SERIALIZABLE

- REPEATABLE READ -

- READ COMMITTED -

- READ UNCOMMITTED

- READ WRITE-

- READ ONLY-

Рис. 12.15. Синтаксическая диаграмма инсгрукки SET TRANSACTION