Проблема потери обновления. Две транзакции по очереди записывают некоторые данные в одну и ту же строку и фиксируют изменения.

Грязное чтение.

Транзакция B изменяет данные в строке. После этого транзакция A читает измененные данные и работает с ними. Транзакция B откатывается и восстанавливает старые данные.

Неповторяемое чтение.

Транзакция A дважды читает одну и ту же строку. Между этими чтениями вклинивается транзакция B, которая изменяет значения в строке.

Фантомы.

Транзакция A дважды выполняет выборку строк с одним и тем же условием. Между выборками вклинивается транзакция B, которая добавляет новую строку, удовлетворяющую условию отбора.

Ведение журнала

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

Откат и восстановление БД.

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

Архитектура «клиент-сервер»

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

Файловый сервер

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

На данный момент файл-серверная технология считается устаревшей.