Бэкап Данных

Рубрика: Oracle

Здравствуйте, уважаемые посетители сайта okITgo.ru! Продолжаем рассматривать основные понятия бэкапа и восстановления. Физические структуры базы данных и роль, которую каждая их них играет в процессе восстановления базы, определяют формы бэкапа и восстановления, доступные при пользовательских методах и посредством RMAN.


Физические Структуры БД, используемые в Восстановлении Данных

Файлы и другие структуры, которые составляют базу данных Oracle, хранят данные и защищают их от возможных сбоев. В этой статье я хочу рассмотреть каждую из этих физических структур, составляющих базы данных Оракл, а также их роль в воссоздании базы данных из бэкапа. К этим структурам относятся:

Файлы данных и Блоки данных

База данных Oracle состоит из одной или более логических единиц хранения, называемых табличными пространствами. Каждое табличное пространство в БД Оракл состоит из одного или более файлов данных – физических файлов операционной системы, которые вместе содержат данные, хранимые в табличном пространстве. Простейшая БД Oracle имела бы одно табличное пространство, хранимое в одном файле данных.

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

Изменяемые или новые данные не пишутся сразу в файлы данных. Обновления буферизуются в памяти и записываются в файлы данных через определенные интервалы времени. Если экземпляр базы данных не был завершен нормальным образом (т.е., если он был завершен аварийно, как при сбое экземпляра или выполнении команды SHUTDOWN ABORT), то как правило в памяти имеются изменения, которые не были записаны в файлы данных. Файлы данных, которые были восстановлены из бэкапа или не были закрыты во время согласованного завершения (consistent shutdown), обычно не являются полностью обновленными (или современными, т.е. содержащими в себе все последние изменения).

Копии файлов данных БД являются критической частью любого бэкапа.

Журналы Изменений

Redo-журналы (которые также называют журналами изменений, журналами обновлений, логами изменений и т.п.) записывают все изменения, сделанные с файлами данных БД. Каждый раз, когда данные базы изменяются, это изменение сначала записывается в онлайн журнал обновлений – прежде, чем оно будет применено к файлам данных.

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

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

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

Поэтому, сохранение журналов является главной частью большинства стратегий бэкапа. Первый шаг сохранения журналов изменений называется архивирование. База данных может копировать группы онлайн журналов обновлений, которые в настоящий момент не используются, в одну или более архивных директорий на диске, все вместе они называются архивным redo-журналом. Отдельные файлы называют архивными файлами redo-журнала. После того как redo-журнал заархивирован, он может быть сохранен в других местах на диске или на ленте – для долгосрочного хранения и использования в будущих операциях восстановления.

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

Контрольные Файлы

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

  • Информация БД (RESETLOGS SCN и отметка времени)
  • Записи табличных пространств и файлов данных (имена файлов, filenames, контрольные точки файлов данных, статус чтения/записи, оффлайн диапазоны)
  • Информация о redo потоках (текущий онлайн журнал изменений)
  • Журнальные записи (номера последовательности журналов, SCN диапазон в каждом журнале)
  • Запись прошедших RMAN бэкапов
  • Информация о испорченных блоках файлов данных

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

Сегменты Отката

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

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

Вам не надо самим что-либо делать с сегментами отката или управлять ими напрямую в процессе бэкапа и восстановления.

Спасибо за внимание! В следующий раз хочу подробнее остановиться на восстановлении данных из бэкапа, так что жду Вас, уважаемые читатели, на okITgo.ru.

Рубрика: Oracle