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

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

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

Машинный сбой

Когда машина, на которой выполняется сервер базы данных, дает сбой и выключается (например, при выключении питания), экземпляр Oracle останавливает выполнение. Если никакие файлы базы данных не потеряны, единственное действие, требуемое от администратора базы данных, - перезапустить экземпляр Огасle. Когда эта операция выполнится, фоновый процесс SMON считает оперативные журнальные файлы и повторно применит все изменения для фиксированных транзакций. Незафиксированные изменения аннулируются.

Оператор COMMIT пишет изменения только в журнальные файлы; он не записывает блоки данных на диск в момент, когда выполняется фиксация транзакции. Если блоки базы данных с зафиксированными изменениями записаны в файлы базы данных перед машинным сбоем, фоновый процecc SMON, очевидно, не должен повторять изменения для этих блоков.

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

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

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

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

Дата добавления: 2013-12-12