Транзакция 5

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

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

в СУБД SQL Server в основном для обеспечения совместимости с другими важными системами реляционных СУБД, такими как Oracle или DB2, предусмотрена возможность организации работы с помощью так называемых неявных транзакций. По умолчанию поддержка неявных транзакций в СУБД SQL Server не применяется, но может быть введена в действие. В режиме работы с использованием неявных транзакций не требуются операторы BEGIN TRAN, поскольку в качестве оператора начала транзакции рассматривается первый же оператор, вызываемый на выполнение в базе данных, и транзакция запускается автоматически. Неявная транзакция ос)тцествляет-ся до тех пор, пока на выполнение не будет вызван оператор COMMIT TRAN или ROLLBACK TRAN. Затем со следующего оператора начинается очередная транзакция.

Очевидно, что такая организация работы применяется для обеспечения того, чтобы каждый оператор вошел в состав одной из транзакций. Функционирование СУБД SQL Server также организовано таким образом, чтобы каждый оператор был охвачен одной из транзакций, но по умолчанию применяется другой подход, основанный на том, что при отсутствии операторов BEGIN TRAN в СУБД SQL Server принимается предположение, что транзакция состоит только из одного оператора, поэтому с началом выполнения оператора автоматически начинается транзакция, а после завершения его выполнения так же автоматически заканчивается. Тем не менее в некоторых СУБД применяется подход, основанный на неявных транзакциях. Эти системы действуют на основе предположения, что любой оператор, кроме оператора фиксации или отката, может служить только для обозначения начала транзакции, поэтому к программному обеспечению предъявляется требование, чтобы в нем было предусмотрено явное завершение каждой транзакции с помощью оператора COMMIT или ROLLBACK.

По умолчанию опция IMPLICIT TRANSACTIONS отменена (и каждое соединение с базой данных находится в режиме автоматической фиксации транзакции). Применение режима явных транзакций можно разрешить с помощью следующей команды:

SET IMPLICIT TRANSACTIONS ON

После этого к инициализации транзакции приводит применение любого из следующих операторов:

CREATE

ALTER TABLE

GRANT

REVOKE

SELECT

UPDATE

DELETE

INSERT

TRUNCATE TABLE

DROP

OPEN

FETCH

Транзакция продолжается до тех пор, пока не будет выполнен оператор COMMIT или ROLLBACK. Следует отметить, что действие опции IMPLICIT TRANSACTIONS, обеспечивающей применение неявных транзакций, распространяется только на текущее соединение; для всех прочих пользователей, которые не вызвали на выполнение приведенную выше команду SET, эта опция будет по-прежнему отменена.

В ходе эксплуатации СУБД с применением опции IMPLICIT TRANS ACT IONS могут возникать сложные непредвиденные ситуации, поэтому настоятельно рекомендуется не разрешать ее использование, если нет весомых оснований для принятия иного решения (таких как обеспечение совместимости с кодом, предназначенным для эксплуатации в другой системе).

Например, при эксплуатации СУБД с применением опции IMPLICIT TIANSACTIONS часто возникает такая ситуация: пользователь осуществляет вставку данных в течение продолжительного времени, скажем, больше получаса, но изменения, внесенные в базу данных, не обнаруживаются в выходной форме. Пользователь сообщает об этом администратору базы данных, который вызывает на выполнение команду DBCC OPENTRAN (см. главу 24) и обнаруживает, что пользователь на протяжении всего этого времени работает в составе открытой транзакции; это позволяет сразу же понять причины сложившейся ситуации. Транзакция, в рамках которой работает пользователь, остается открытой, поэтому внесенные им изменения остаются в журнале и не записываются в базу данных. Возможно, пользователь намеренно перешел в режим неявных транзакций, выполнив оператор BEGIN TRANS, или вызвал на вьшолнение какой-то код, в котором неявные транзакции были разрешены, а затем не отменены. В связи с этим возникло указанное нарушение в работе.

Блокировки и параллельная организация работы

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

Как правило, в среде OLTP (OnLine Transaction Processing- оперативная обработка транзакций) наиболее важным требованием к организации работы является обеспечение параллельного вьшолнения всех операций. Именно на этом основана структура большинства объектов баз данных, которые рассматриваются в настоящей книге. (Обычно аналогичный способ организации работы в полной мере применяется и в среде оперативной аналитической обработки (OnLine Analytical Processing -

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

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

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

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