Архивирование

Холодное резервное копирование

Дисковый сбой/потеря файла

Сбой распределенной транзакции

Сбой экземпляра

Сбой экземпляра происходит, когда сама машина работает, но терпит сбой непосредственно экземпляр Oгас1е (возможно, один из фоновых процессов уничтожен). Эта ситуация очень подобна машинному сбою в том смысле, что администратору базы данных требуется только перезапустить экземпляр; процесс SMON повторно применит изменения. При перезапуске экземпляра после этого вида сбоя нет никаких отличий от запуска после нормального закрытия.

 

Распределенная транзакция — это транзакция, которая выполняет изменения в нескольких БД. Если сбой происходит в ходе распределенной транзакции, фоновый процесс RECO (если он выполняется) автоматически синхронизирует откаты изменений транзакции по всем обрабатываемым базам данных. Опять же никакого ручного вмешательств не требуется, кроме наиболее серьезных случаев. Администраторы базы данных экземпляров, включаемых в распределенную транзакцию, могут вручную активировать фиксацию транзакции или откат изменений на их базах данных.

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

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

 

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

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

 

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

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

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