Блокирование объектов базы данных

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

· Заблокированной может быть табличная строка, с которой вы работаете в данный момент времени. Пока вы ее используете, никто другой не имеет к ней доступ.

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

· Блокируется запись, а чтение табличных данных допускается. Иногда же блокируется и чтение, и запись.

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

Резервное копирование

Резервное копирование – комплекс мер, регулярно выполняемый администратором базы данных. Резервное копирование всех элементов системы должно проводиться через определенные интервалы, которые зависят от того, насколько часто обновляются эти элементы. Если ваша база данных обновляется ежедневно, то ее резервное копирование также следует проводить ежедневно. Приложения, формы и отчеты также могут меняться, хотя и не так часто. Администратор должен успевать создавать и их резервные копии тоже.

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

Есть много разных способов резервного копирования.

· Создавать резервные таблицы и копировать в них данные с помощью SQL.

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

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

Технические подробности:
Возможно, вы слышали от проектировщиков баз данных, что базам данных нужна АСID (означает "кислота"). Нет, конечно, они не собираются одурманить свои творения психоделией из 1960-годов или растворить в пузырящемся месиве хранящиеся в базах данные. АСID– это аббревиатура, образованная от слов Atomicity (атомарность), Consistency (согласованность), Isolation (изоляция) и Durability (долговечность). Эти четыре характеристики необходимы для защиты базы данных от искажения данных.

· Атомарность. Транзакции в базах данных должны быть атомарными в классическом смысле этого слова, т.е. вся транзакция считается неделимой единицей. Или она выполняется целиком (завершается оператором COMMIT), или база данных восстанавливается в том состоянии, в котором она была бы, если бы транзакция не выполнялась (происходит откат с помощью оператора ROLLBACK).

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

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

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