37. Управление резервным копированием и восстановлением данных в субд.

СУДБ содержит специальные утилиты, с помощью которых администратор БД может выполнять регулярные и экстренные процедуры резервного копирования и восстановления данных.

Восстановление данных происходит в следующих 2-х случаях:

1. аварийный отказ аппаратуры (жесткий сбой системы)

В этом случае данные повреждаются физически.

2. После аварийного отказа ПО (мягкий сбой системы)

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

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

Журнал транзакций содержит перечень всех транзакций, выполненных после создания последней архивной копии данных с описанием всех деталей каждой транзакции.

Полная архивная копия БД создается практически с учетом скорости накопления журнала транзакций и, как правило, размещается на другом сетевом диске.

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

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

В результате БД восстанавливается в то состояние в котором, в котором она была перед повреждением.

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

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

Транзакции, подтвержденные до наступления сбоя, но результат выполнения которых не записан на диск, выполняются заново.

Транзакции, незавершившиеся из-за сбоя, и транзакции, результат которых записан на диск, откатываются.

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

Единственно, что можно сделать, это восстановить состояние БД на момент резервного копирования.

Чтобы не допустить возникновения такой ситуации, БД и журнал транзакций необходимо размещать на физически разных дисках, упр-х физически разными контролями.

37. Механизм тиражирования (репликации) данных в субд.

Работа распределенной БД базируется над синхронной фиксацией изменений сразу на нескольких узлах системы, что предъявляет жесткие требования к производительности и надежности каналов.

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

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

Его задача – автоматически синхронизировать БД, распр-ой системы и тем самым обеспечивать актуальность их копий, или как их называют реплик.

Поддержка репликации баз данных – одна из важнейших задач администратора: почти у каждой сколько-нибудь важной базы данных есть реплика, а то и не одна. Среди задач, решаемых репликацией, можно назвать как минимум

• поддержку резервной базы данных на случай потери основной;

• снижение нагрузки на базу за счёт переноса части запросов на реплики;

• перенос данных в архивные или аналитические системы. Можно выделить три подхода к репликации:

• Блочная репликация на уровне системы хранения данных;

• Физическая репликация на уровне СУБД;

• Логическая репликация на уровне СУБД.