Последовательное выполнение исключает нежелательные взаимодействие

Конфликт транзакций не происходит, если они выполняются последовательно. Главное – побыстрее занять очередь. Если невыполнимая транзакция пользователя 1 заканчивается перед началом транзакции пользователя 2, то функция ROLLBACK (откат) возвращает все товары, заказанные пользователем 1, делая их доступными во время транзакции пользователя 2. Если бы во втором примере транзакции выполнялись последовательно, то у пользователя 2 не было бы возможности изменить количество единиц любого товара, пока не закончится транзакция пользователя 1. Только после окончания транзакции пользователя 1 пользователь 2 сможет увидеть, сколько есть в наличии единиц требуемого товара.

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

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

Уменьшение уязвимости данных

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

· Использовать транзакции SQL.

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

· Знать, когда и как запускать транзакции на выполнение, блокировать объекты базы данных и выполнять резервное копирование.

Теперь поговорим об этих принципах подробно.

Использование транзакций SQL

Одним из главных инструментов SQL, предназначенных для сохранения целостности баз данных, является транзакция. Транзакция SQL состоит из любых операторов SQL, которые могут воздействовать на базу данных. Транзакция SQL завершается одним из двух операторов: COMMIT (завершение) или ROLLBACK (откат).

· Если транзакция заканчивается оператором COMMIT, то действие всех ее операторов выполняется в виде одной "пулеметной очереди".

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

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

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

Начало приложения

Различные операторы SQL (SQL-транзакция-1)COMMIT или ROLLBACKРазличные операторы SQL (SQL-транзакция-2)COMMIT или ROLLBACKРазличные операторы SQL (SQL-транзакция-З)Конец приложения

Помни:
Термин "транзакция SQL" (или "SQL-транзакция") применяют из-за того, что приложение может использовать другие возможности ограничения одновременного доступа (например, связанные с сетевым доступом) и выполнять другие виды транзакций. Далее в этой книге под "транзакцией" подразумевается именно "транзакция SQL".

Обычная транзакция SQL может выполняться в одном из двух режимов: READ-WRITE (чтение-запись) или READ-ONLY (только чтение). Для нее можно задать один из следующих уровней изоляции: SERIALIZABLE (последовательное выполнение), REPEATABLE READ (повторяющееся чтение), READ COMMITTED (чтение подтвержденных данных) или READ UNCOMMITTED (чтение неподтвержденных данных). (Характеристики транзакций приводятся ниже, в разделе "Уровни изоляции".) Характеристиками по умолчанию являются READ-WRITE и SERIALIZABLE. Если нужно использовать любые другие характеристики, то их следует указать с помощью оператора SET TRANSACTION (задать транзакцию), например, такого:

SET TRANSACTION READ ONLY;

…или:

SET TRANSACTION READ ONLY REPEATABLE READ;

…или:

SET TRANSACTION READ COMMITTED;

В одном приложении может иметься множество операторов SET TRANSACTION, но в каждой транзакции можно указывать только один из них – и он обязательно должен быть первым оператором SQL в транзакции. Если нужно использовать оператор SET TRANSACTION, то его надо выполнять или в начале приложения, или после оператора COMMIT либо ROLLBACK. Этот оператор следует обязательно выполнять в начале каждой транзакции, для которой требуются установки, не совпадающие с предусмотренными по умолчанию. Дело в том, что после оператора COMMIT или ROLLBACK каждая новая транзакция автоматически получает характеристики по умолчанию.

Технические подробности:
В операторе SET TRANSACTION можно также задать значение параметра DIAGNOSTIC SIZE (размер диагностики), определяющего количество ошибочных условий, информацию о которых должна сохранять реализация. Такое ограничение необходимо, потому что при выполнении оператора SQL может произойти сразу много ошибок. Значение по умолчанию этого параметра определяется реализацией, и, как правило, лучше его не трогать.

Транзакция по умолчанию

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

Транзакция по умолчанию создается исходя из двух неявных допущений:

· база данных будет со временем изменяться;

· всегда лучше себя обезопасить, чем потом жалеть.

Эта транзакция задает режим READ-WRITE, и он, как можно ожидать, разрешает отправлять на выполнение операторы, изменяющие базу данных. Транзакция по умолчанию имеет уровень изоляции SERIALIZABLE, который является максимально безопасным. Значение параметра DIAGNOSTIC SIZE зависит от используемой реализации и приведено в ее документации.

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

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

"Черновое" чтение

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

Внимание:
Если вам нужны точные результаты, уровнем изоляции READ UNCOMMITED лучше не пользоваться.

Уровень READ UNCOMMITED можно использовать тогда, когда нужно статистически обрабатывать такие малоизменяющиеся данные:

· максимальная задержка в оформлении заказов;

· средний возраст продавцов, не выполняющих норму;

· средний возраст новых сотрудников.

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