Транзакции и восстановление

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

Системными сбоями называются сбои, которые влияют на все выполняемые в данный момент транзакции, но не наносят физического ущерба самой базе данных. Физический ущерб базе данных может быть нанесен сбоем носителя информации; защитой от этого вида сбоя является регулярное получение резервных копий базы данных и ведение системного журнала транзакций (transaction log). Команды SQL, используемые для этих целей, обсуждаются ниже в этой главе.

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

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

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

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

Транзакции, определяемые пользователем

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

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

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

Некоторые команды SQL нельзя включать в транзакции, определяемые пользователем. Более подробно об этом вы узнаете из справочных руководств по своей системе.

Работа с транзакциями. Между командами SQL, отмечающими начало и конец транзакций, может помещаться любое количество операторов SQL. В зависимости от синтаксиса, который поддерживает ваща система, это может выглядеть примерно так:

[оператор начала транзакции]

SQL оператор

SQL оператор

SQL оператор оператор конца транзакции

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

В большинстве систем синтаксис команды транзакции ROLLBACK выглядит примерно так:

[оператор начала транзакции]

SQL оператор

SQL оператор

SQL оператор оператор отката транзакции

Получение резервной копии и восстановление

Процедуры получения резервной копии и восстановления существенно зависят от конкретной системы. Ниже приведен краткий обзор того, как это делается в одной из систем (Sybase). В вашей системе эти вопросы могут решаться совершенно по-другому.

Каждое изменение в базе данных, является ли оно результатом выполнения одного оператора SQL UPDATE (системно-определяемая транзакция) или сфуппи-рованной совокупности операторов SQL (транзакция, определяемая пользователем), автоматически фиксируется в журнале транзакций, который (в системе Sybase) представляет собой таблицу в словаре данных.

Запросы модификации данных (операторы UPDATE, INSERT или DELETE) фиксируются в журнале транзакций по принципу от момента к моменту . Когда транзакция начинается, в журнале фиксируется событие начала (BEGIN) транзакции. В момент приема каждого очередного оператора модификации данных он также фиксируется в журнале транзакций.

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

После сбоя все транзакции, зафиксированные в журнале, можно выполнить повторно. Команды SQL, предназначенные для получения резервных копий и восстановления баз данных с помощью журналов транзакций, обычно называются DUMP DATABASE, DUMP TRANsaction, LOAD DATABASE, LOAD TRANsaction или что-то вроде того. После того как будут заданы соответствующие команды LOAD, система баз данных выполнит процесс восстановления.

ПРОИЗВОДИТЕЛЬНОСТЬ

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

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

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

Качество проектирования базы данных может существенно сказаться на производительности системы.

Способ структурирования ваших запросов может повлиять на производительность системы.

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

Производительность - необъятная тема. В этой книге у нас есть возможность лишь слегка коснуться ее, главным образом, чтобы подвести вас к проблемам, которые вам потребуется изучить глубже, когда вопрос производительности станет перед вами со всей остротой.

Сравнение с эталоном

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

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

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

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