Базы данных, на которых строятся информационные системы, должны обеспечить одновременный доступ к данным для многих, иногда сотен и тысяч, пользователей. Оказывается, при параллельной работе пользователей результаты вычислений могут зависеть от временных соотношений между действиями пользователей, от того, в какое время и в какой последовательности они выполняются. Как избежать этой зависимости? Как организовать чтение данных одним пользователем и одновременно их изменение другим? Как добиться, чтобы деньги, снятые с одного счета, и, из-за сбоя системы, не зачисленные на другой счет, не могли пропасть бесследно? Как восстановить данные при откатах и сбоях?
Все эти проблемы решаются за счет использования механизма транзакций, который должен работать в базах с любыми моделями данных.
Информационные системы, предназначенные для единственного пользователя, в настоящее время практического интереса не представляют. Но даже они нуждаются в транзакциях. Всегда существует наборы действий, такие что невыполнение некоторых из них приводит базу в противоречивое состояние. Кроме того, один пользователь может запустить несколько потоков вычислений, обращающихся, может быть, к одним данным. И тут ему потребуется механизм, обеспечивающий независимость работы этих потоков.
Транзакции обеспечивают:
· Сохранение целостности данных.
· Параллельную работу пользователей с базой данных.
· Восстановление данных при откатах и сбоях.
Пусть при выполнении двух последовательно выполняющихся действий после успешного выполнения первого из них возник сбой
В приведенном примере это означает, что сумма, снятая с первого счета не попала на второй счет. Хуже того, сам факт исчезновения денег никак не зафиксирован. Если вас этот неприятный факт не расстроил, и вы считаете, что можно повторить все с начала, то тут сказывается одна нехорошая привычка, вырабатываемая ориентированностью наших студентов, фактически, на научные вычисления. Скажем, складывал я две матрицы, а они у меня не сложились. Ну, бог с ними — я их сложу еще раз. Но, если вы написали систему, которая отправила миллиард долларов, и он никуда не пришел, то, скорее всего, усовершенствовать ее будет уже другой человек, а вы будете искать новую работу. Вот, собственно, в этом разница в отношении к надежности вычислений в науке и бизнесе. Вообще говоря, бизнес-приложения должны работать всегда, независимо от того, исправен ли компьютер или нет, заболели ли вы или еще что-то случилось, ночь сейчас или день. Ведь есть организации, работающие круглые сутки. Хорошим тоном считается обеспечивать работоспособность в самом тяжелом режиме, который принято называть "24/7" (двадцать четыре на семь). Это очень тяжелый режим, и без специальных мер он сам по себе не обеспечивается. Представьте, что в вашем домашнем компьютере нужно поменять или добавить жесткий диск. Как это сделать без останова системы?
?
Рис. 6.2. Возможные ошибки
Для рассмотрения параллельной работы двух пользователей вспомним, что "сальдо" —это остаток на счете. Посчитать сальдо по группе счетов — это, попросту говоря, сложить их остатки. Обычный арифметический цикл, который известен всем школьникам. На рисунке 6.2 слева показана работа такого цикла. Сначала сальдо С по группе счетов равно 0, потом прибавляем к нему остаток первого счета, второго счета и т.д., счета тысячного. Как учили в школе? Написали цикл, проверили его на примере. Дальше работает всегда правильно. Но у нас то пользователь не один. Транзакция изображенная слева выполняет циклическое суммирование. Но после того, как счет 1 уже учтен, и до того, как учтен счет 1000, вторая транзакция, изображенная справа, снимает 200 руб. со счета 1, и зачисляет их (то есть прибавляет 200 руб.) на счет 1000. Теперь в подсчете сальдо по группе счетов появится ошибка в 200р. Почему? Потому что счет 1 мы обрабатывали в неизмененном состоянии, а счет 1000 в измененном. А что будет, если во времени вторая транзакция будет сдвигаться? Ну, очевидно, если она будет выполнена до первой (левой на рисунке) транзакции или после нее, то ничего страшного не случится, все будет посчитано правильно. А если транзакции начнут выполняться на одном промежутке времени то, с какого-то момента появится ошибка. Обратите внимание, довольно странная, неожиданная для начинающих ситуация — арифметический цикл, оказывается, может считать данные неправильно, если одновременно идет некоторый другой процесс, имеющий доступ к тем же данным. Транзактный механизм должен подобные казусы исключить.
База находится в согласованном состоянии, если выполняются все записанные в ней ограничения целостности. Во время выполнения транзакции база может рассогласовываться.
Вернемся к рассмотренной ранее операции — переводу денег с одного счета на другой. Эта операция включает две атомарные (элементарные, неделимые) операции:
· снятие суммы с одного счета,
· зачисление суммы на другой счет.
Если СУБД будет выполнять (или не выполнять) эти две операции только вместе, то база будет всегда находиться в согласованном состоянии и не будут возникать ситуации, при которых суммы, снятые с одного счета, ни на какой другой счет не поступают.