ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ
ГЛАВА 19
----------------------------------------------------------------
ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ
Эта глава объясняет, как выполнять восстановление базы данных.
Темы этой главы включают обсуждение следующих вопросов:
* рекомендации по восстановлению носителя
* восстановление от сбоя носителя
* реставрация полной копии
* полное восстановление носителя
* частичное восстановление носителя
* примеры восстановления носителя
Восстановление базы данных 19-1
----------------
Рекомендации и условия для восстановления от сбоя носителя
Следующие секции дают указания и обсуждают предпосылки, которые
необходимо рассмотреть перед восстановлением поврежденной базы
данных от сбоя носителя.
Отладьте стратегии копирования и восстановления
-----------------------------------------------
Вы должны проверить ваши стратегии копирования и восстановления
на тестовом окружении, прежде чем переходить на производственную
систему, и продолжать регулярно тестировать вашу систему. В
процессе этой отладки вы можете проверить, насколько тщательно
проработаны ваши стратегии, и свести к минимуму проблемы, прежде
чем столкнетесь с ними в реальной ситуации. Регулярное
выполнение тестовых восстановлений поможет гарантировать, что
ваши процедуры архивирования и копирования работоспособны. Оно
также поможет вам лучше познакомиться с процедурами
восстановления, так что вы с меньшей вероятностью будете
ошибаться в критических ситуациях.
Решите, какой тип восстановления вам подходит
---------------------------------------------
После того, как сбой носителя повредит вашу базу данных,
ответьте на следующие три вопроса:
1. Какие операции восстановления возможны?
Ответ на первый вопрос определяется тем, архивирует ли ваша
база данных журналы повторения:
* Если база данных работает в режиме NOARCHIVELOG, то
обычно единственной возможностью восстановления от сбоя
носителя является реставрация наиболее свежей полной
копии базы данных и повторный ввод всей работы, которая
была выполнена после этой копии. (Если вы использовали
экспорт в дополнение к регулярному копированию базы
данных, вы можете вместо этого реставрировать данные с
помощью импорта.) Несколько оставшихся потерь данных
восстановить будет легче.
* Если база данных работает в режиме ARCHIVELOG, то для
восстановления запорченной базы данных могут быть
применены несколько различных операций восстановления.
2. Какие операции восстановления подходят для вашей конкретной
проблемы?
Если база данных работает в режиме ARCHIVELOG, то несколько
различных операций восстановления могут быть применены для
восстановления запорченной базы данных в согласованное
состояние на момент, предшествующий сбою или ошибке
пользователя. См. секцию "Примеры сбоев носителя и
соответствующих процедур восстановления" на странице 19-27
для подробного перечня различных типов проблем, вызываемых
сбоями носителя, и соответствующих методов восстановления от
каждого типа проблемы.
19-2 Руководство администратора
3. Является ли поврежденная база данных частью распределенной
базы данных?
Если это так, то может потребоваться координация
восстановления между узлами распределенной базы данных. См.
ниже секцию "Координируйте распределенное восстановление" для
дополнительной информации.
Исправьте проблему с диском или избавьтесь от нее
-------------------------------------------------
Цель восстановления базы данных - как можно скорее открыть ее
для нормальной работы. Если сбой носителя был вызван проблемой
оборудования, эта проблема должна быть устранена как можно
скорее; однако восстановление базы данных не зависит от того,
сколько времени может занять исправление ошибок оборудования.
Файлы, хранившиеся на сбившемся устройстве, могут быть
восстановлены на другие устройства памяти, и это перемещение
файлов может быть учтено в базе данных с помощью процедур,
которые описаны в следующих секциях этой книги:
г====================T==============================T==========¬
¦ Тип файла ¦ Название секции ¦ Страница ¦
¦====================+==============================+==========¦
¦ Файл данных ¦ Переименование и перемещение ¦ 7-13 ¦
¦ ¦ файлов данных ¦ ¦
¦--------------------+------------------------------+----------¦
¦ Файл онлайнового ¦ Переименование и перемещение ¦ 5-7 ¦
¦ журнала повторения ¦ членов онлайнового журнала ¦ ¦
¦--------------------+------------------------------+----------¦
¦ Управляющий файл ¦ Создание дополнительных копий¦ 6-4 ¦
¦ ¦ управляющих файлов, переиме- ¦ ¦
¦ ¦ нование и перемещение управ- ¦ ¦
¦ ¦ ляющих файлов ¦ ¦
L====================¦==============================¦==========-
Координируйте распределенное восстановление
-------------------------------------------
Архитектура распределенной базы данных по своей природе
автономна. Поэтому, в зависимости от типа операции
восстановления, выбранного для любой одиночной базы данных,
операции восстановления должны или не должны быть
скоординированы среди всех баз данных в системе распределенной
базы данных. Табл.19-1 суммирует различные типы операций
восстановления и показывает, необходима ли координация между
узлами распределенной базы данных для каждого типа операции.
Восстановление базы данных 19-3
Табл.19-1
Восстановление базы данных в системе распределенных баз данных
г==============================T===============================¬
¦ Тип операции восстановления ¦ Требования в распределенной ¦
¦ ¦ базе данных ¦
¦==============================+===============================¦
¦ Реставрация полной копии базы¦ Используйте нескоординирован- ¦
¦ данных, к которой никогда не ¦ ное, автономное восстановление¦
¦ обращались (не обновляли и не¦ базы данных. ¦
¦ опрашивали) с удаленных узлов¦ ¦
¦------------------------------+-------------------------------¦
¦ Реставрация полной копии базы¦ Остановите все базы данных и ¦
¦ данных, к которой были обра- ¦ реставрируйте их, используя ¦
¦ щения с удаленных узлов ¦ одни и те же скоординированные¦
¦ опрашивали) с удаленных узлов¦ полные копии ¦
¦------------------------------+-------------------------------¦
¦ Полное восстановление носите-¦ Используйте нескоординирован- ¦
¦ ля одной или нескольких баз ¦ ное, автономное восстановление¦
¦ данных в распределенной базе ¦ базы данных. ¦
¦ данных ¦ ¦
¦------------------------------+-------------------------------¦
¦ Частичное восстановление но- ¦ Используйте скоординированное ¦
¦ сителя базы данных, к которой¦ частичное восстановление носи-¦
¦ были обращения с удаленных ¦ теля к одной и той же глобаль-¦
¦ узлов ¦ ной точке времени для всех баз¦
¦ ¦ данных в распределенной базе ¦
¦ ¦ данных. ¦
L==============================¦===============================-
Координируйте восстановление распределенной базы данных
до момента времени и до номера изменения
-------------------------------------------------------
В особых обстоятельствах, один из узлов в распределенной базе
данных может требовать восстановления к состоянию на
определенный момент времени в прошлом. Чтобы сохранить
глобальную согласованность данных, часто бывает необходимо,
чтобы все остальные узлы в системе также были восстановлены к
тому же самому моменту времени. Это называется
"координированным восстановлением распределенной базы данных к
моменту времени".
Процедуры для осуществления автономного восстановления до
момента времени и до номера изменения приведены в последующих
секциях этой главы. Однако, координированное восстановление к
моменту времени для распределенной базы данных требует некоторых
дополнительных шагов, чтобы скорректировать отклонения во
времени, обычно наблюдаемые между разными компьютерами.
Поэтому, в сочетании с нормальными процедурами восстановления к
моменту времени и к номеру изменения, используйте следующие шаги
для координации распределенного восстановления к моменту времени
между разными узлами в распределенной системе баз данных:
1. Восстановите ту базу данных, которая требует восстановления к
моменту времени. Например, если база данных требует
восстановления из-за ошибки пользователя (скажем, случайного
удаления таблицы), восстановите эту базу первой, используя
процедуру восстановления к моменту времени. Не
восстанавливайте пока других баз данных.
19-4 Руководство администратора
2. После того, как вы восстановите базу данных и откроете ее с
опцией RESETLOGS, отыщите в файле ALERT этой базы данных
сообщение, относящееся к RESETLOGS.
Если это сообщение гласит: "RESETLOGS after complete recovery
through change nnnnnnnn", то вы применили к базе данных все
изменения, и, по существу, выполнили полное восстановление.
Не восстанавливайте никаких других баз данных в
распределенной системе, - в противном случае вы без
необходимости удалите изменения, выполненные в них.
ВОССТАНОВЛЕНИЕ ЗАКОНЧЕНО.
Если это сообщение гласит: "RESETLOGS after incomplete
recovery UNTIL CHANGE nnnnnnnn", то вы успешно выполнили
частичное восстановление. Запишите системный номер изменения
из этого сообщения, и перейдите к следующему шагу.
3. Восстановите все остальные базы данных в распределенной
системе, используя процедуру восстановления до номера
системного изменения и специфицируя номер изменения, который
вы узнали на шаге 2.
Восстановление баз данных со снимками
Если главная база данных независимо восстанавливается к
прошедшему моменту времени (т.е. координированное восстановление
распределенной системы к моменту времени не выполняется), то
любой зависимый удаленный снимок, который освежался за
потерянный период времени, будет не согласован со своей главной
таблицей. В этом случае, администратор главной базы данных
должен сообщить удаленным администраторам о необходимости
выполнить полное освежение каждого несогласованного снимка.
----------------
Выполнение восстановления носителя
Следующие секции объясняют шаги, необходимые для восстановления
от сбоев носителя путем реставрации полной копии или операций
полного или частичного восстановления носителя.
Приведенные ниже описания операций восстановления носителя не
зависят от типа сбоя носителя или от типов файлов, поврежденных
этим сбоем. Поэтому для понимания процедур восстановления
носителя недостаточно использовать эти секции сами по себе;
используйте также секцию "Примеры сбоев носителя и
соответствующих процедур восстановления" на странице 19-27, в
которой описаны пооходящие методы восстановления от каждого типа
проблем.
Вопросы, общие для всех операций восстановления носителя
--------------------------------------------------------
Следующие секции обсуждают вопросы, общие для всех операций
полного и частичного восстановления носителя (но не реставрации
полной копии). Эти вопросы необходимо понимать, прежде чем
приступать к последующим секциям.
Восстановление базы данных 19-5
Сообщения, указывающие на сбои носителя
Следующие сообщения указывают, что вам необходимо восстановление
носителя:
ORA-00204 "error in reading control file 'ИМЯ' (block НОМЕР,
#blocks ЧИСЛО)"
ORA-01113 "file ИМЯ needs recovery"
ORA-01168 "file ИМЯ: bad physical block size of ЧИСЛО bytes
expecting ЧИСЛО"
ORA-01178 "file ИМЯ created before last CREATE CONTROLFILE,
cannot recreate"
Обратитесь к документу ORACLE7 Server Messages and Codes Manual
для дополнительной информации об этих и других сообщениях,
возвращаемых ORACLE.
Определение файла, нуждающегося в восстановлении
Чтобы определить файл, нуждающийся в восстановлении, вы часто
можете использовать таблицу V$RECOVER_FILE. Эта таблица
показывает все файлы, для которых требуется восстановление,
вместе с информацией о том, почему требуется восстановление.
Замечание: Таблица V$RECOVER_FILE наиболее полезна, когда база
данных закрыта, потому что при открытой базе данных она содержит
информацию лишь об офлайновых файлах. Эта таблица бесполезна,
если текущий используемый управляющий файл является
реставрированной копией или заново создан после сбоя носителя;
реставрированный и пересозданный управляющий файл не содержит
информации, необходимой ORACLE для правильного заполнения
таблицы V$RECOVER_FILE.
Например, следующий запрос выдает идентификационные номера
файлов данных, требующих восстановления:
SELECT file#, online, error
FROM v$recover_file;
FILE# ONLINE ERROR
------------------------------------------------------
0014 ONLINE
0018 ONLINE FILE NOT FOUND
0032 OFFLINE OFFLINE NORMAL
...
Чтобы определить имя файла по его идентификационному номеру,
используйте обзор словаря данных V$DATA_FILE, который содержит
столбцы FILE# и NAME.
Выбор процедуры восстановления
Табл.19-2 показывает, что делать для восстановления от потери
файлов, вызванной одиночным сбоем носителя. Указанные в этой
таблице процедуры детализируются в последующих секциях. В
таблице используются следующие обозначения поврежденных файлов
базы данных: "Д" - файл данных, "Ж" - файл онлайнового журнала,
"А" - файл архивированного журнала, "У" - управляющий файл.
19-6 Руководство администратора
Табл.19-2
Восстановление от потери файлов
г===============T======================================================¬
¦ Тип файла ¦ Режим архивирования ¦
¦---T---T---T---+------------------------------T-----------------------¦
¦(Д)¦(Ж)¦(А)¦(У)¦ ARCHIVELOG ¦ NOARCHIVELOG ¦
¦===+===+===+===+==============================+=======================¦
¦ + ¦ ¦ ¦ ¦Полное восстановление носителя¦Реставрация полной ¦
¦ ¦ ¦ ¦ ¦(стр.19-17) ¦копии (стр.19-16) ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ ¦ + ¦ ¦ ¦Восстановление потерянных ¦Восстановление потерян-¦
¦ ¦ ¦ ¦ ¦файлов (стр.19-29) ¦ных файлов (стр.19-29) ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ ¦ ¦ + ¦ ¦Сделайте новые резервные копии¦(неприменимо) ¦
¦ ¦ ¦ ¦ ¦всех файлов данных (стр.19-34)¦ ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ ¦ ¦ ¦ + ¦Восстановление потерянных ¦Восстановление потерян-¦
¦ ¦ ¦ ¦ ¦файлов (стр.19-34) ¦ных файлов (стр.19-34) ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ + ¦ + ¦ + ¦ + ¦Восстановление управляющих ¦(неприменимо) ¦
¦ ¦ ¦ ¦ ¦и прочих файлов (стр.19-34) ¦ ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ + ¦ + ¦ + ¦ ¦Частичное восстановление ¦(неприменимо) ¦
¦ ¦ ¦ ¦ ¦носителя (стр.19-29) ¦ ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ + ¦ ¦ + ¦ + ¦Восстановление управляющих ¦(неприменимо) ¦
¦ ¦ ¦ ¦ ¦файлов и файлов данных (19-34)¦ ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ + ¦ + ¦ ¦ + ¦Восстановление управляющих ¦Реставрация полной ¦
¦ ¦ ¦ ¦ ¦и прочих файлов (стр.19-34) ¦копии (стр.19-16) ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ + ¦ + ¦ ¦ ¦Частичное восстановление ¦Реставрация полной ¦
¦ ¦ ¦ ¦ ¦носителя (стр.19-29) ¦копии (стр.19-16) ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ + ¦ ¦ + ¦ ¦Частичное восстановление ¦(неприменимо) ¦
¦ ¦ ¦ ¦ ¦носителя (стр.19-34) ¦ ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ + ¦ ¦ ¦ + ¦Восстановление управляющих ¦Реставрация полной ¦
¦ ¦ ¦ ¦ ¦файлов и файлов данных ¦копии (стр.19-16) ¦
¦ ¦ ¦ ¦ ¦(стр.19-34) ¦ ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ ¦ + ¦ + ¦ + ¦Восстановление управляющих ¦(неприменимо) ¦
¦ ¦ ¦ ¦ ¦файлов, сброс номеров журнала ¦ ¦
¦ ¦ ¦ ¦ ¦(стр.19-34) ¦ ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ ¦ + ¦ + ¦ ¦Частичное восстановление ¦(неприменимо) ¦
¦ ¦ ¦ ¦ ¦носителя (стр.19-34) ¦ ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ ¦ + ¦ ¦ + ¦Восстановление управляющих ¦Если база данных была ¦
¦ ¦ ¦ ¦ ¦файлов, сброс номеров журнала ¦остановлена нормально, ¦
¦ ¦ ¦ ¦ ¦(стр.19-34) ¦пересоздайте управляю- ¦
¦ ¦ ¦ ¦ ¦ ¦щий файл (стр.19-34). ¦
¦ ¦ ¦ ¦ ¦ ¦В противном случае - ¦
¦ ¦ ¦ ¦ ¦ ¦реставрация полной ¦
¦ ¦ ¦ ¦ ¦ ¦копии (стр.19-16) ¦
¦---+---+---+---+------------------------------+-----------------------¦
¦ ¦ ¦ + ¦ + ¦Восстановление управляющих ¦(неприменимо) ¦
¦ ¦ ¦ ¦ ¦файлов, используя частичное ¦ ¦
¦ ¦ ¦ ¦ ¦восстановление носителя ¦ ¦
¦ ¦ ¦ ¦ ¦(стр.19-34) ¦ ¦
L===¦===¦===¦===¦==============================¦=======================-
Восстановление базы данных 19-7
Реставрация поврежденных файлов данных
Если сбой носителя необратимо запортил один или несколько файлов
данных в базе данных, то вы должны реставрировать резервные
копии этих файлов данных, прежде чем сможете восстановить их.
ПЕРЕРАЗМЕЩЕНИЕ ПОВРЕЖДЕННЫХ ФАЙЛОВ. Если поврежденные файлы не
могут быть восстановлены на свое первоначальное место (например,
диск должен быть заменен, так что файлы реставрированы на
альтернативный диск), то новые местоположения этих файлов должны
быть отражены в управляющем файле базы данных. Поэтому
используйте процедуру, описанную в секции "Переименование и
перемещение файлов данных" на странице 7-13, как требуется.
(Эта процедура неоднократно встречается в данной главе.)
ВОССТАНОВЛЕНИЕ ФАЙЛА ДАННЫХ БЕЗ КОПИИ. Если файл данных
поврежден, а резервной копии этого файла нет, то его все же
можно восстановить, при условии, что доступны все файлы журнала,
записанные с момента первоначального создания файла данных, и
что управляющий файл содержит имя поврежденного файла (т.е.
управляющий файл либо текущий, либо реставрирован из копии,
взятой после того, как этот файл данных был добавлен к базе
данных).
Используйте фразу CREATE DATAFILE команды ALTER DATABASE, чтобы
создать новый, пустой файл данных, заменяющий запорченный файл,
для которого нет резервной копии. Например, предположим, что
файл данных "disk1:users1" был поврежден, а резервной копии не
существует. Следующее предложение пересоздает оригинальный файл
данных (такого же размера) на диске 2:
ALTER DATABASE CREATE DATAFILE 'disk2:users1' AS 'disk1:users1';
Замечание: Старый файл данных неявно переименовывается в новый
файл данных, когда выдается предложение ALTER DATABASE CREATE
DATAFILE.
Это предложение заставляет ORACLE создать пустой файл,
совпадающий с потерянным файлом. (ORACLE получает информацию об
этом файле, включая его размер, из управляющего файла и словаря
данных.) Затем вы должны выполнить восстановление носителя на
этом пустом файле данных. Все архивированные файлы журнала,
записанные после создания оригинального файла данных, должны
быть смонтированы и применены к новой, пустой версии файла
данных во время восстановления. Если база данных была создана в
режиме NOARCHIVELOG, то первоначальные файлы данных табличного
пространства SYSTEM не могут быть реставрированы с помощью
команды ALTER DATABASE CREATE DATAFILE, так как необходимые
архивные журналы недоступны.
Реставрация необходимых архивных файлов журнала
Все архивные файлы журнала повторения, требуемые для
восстановления носителя, которое вы собираетесь выполнять,
должны быть заблаговременно сброшены на диск, чтобы они были
достапны для ORACLE.
Чтобы определить, какие архивные файлы журнала вам нужны, часто
можно использовать таблицы V$LOG_HISTORY и V$RECOVERY_LOG.
19-8 Руководство администратора
V$LOG_HISTORY перечисляет все архивированные журналы, включая
имена, которые они должны иметь согласно текущей схеме
формирования имен файлов архива (как установлено параметром
LOG_ARCHIVE_FORMAT). V$RECOVERY_LOG перечисляет лишь те
архивированные журналы, которые, по мнению ORACLE, требуются для
выполнения восстановления; здесь также представлены имена
архивных файлов в соответствии с форматом LOG_ARCHIVE_FORMAT.
(См. приложение B для дополнительной информации об этих
таблицах.)
Если у вас достаточно свободной памяти, реставрируйте все
требуемые архивные файлы журнала в назначение, которое
специфицировано текущим значением параметра LOG_ARCHIVE_DEST.
Таким путем вы позволите ORACLE автоматически находить нужный
архивный файл журнала во время восстановления носителя. Если в
назначении, указываемом параметром LOG_ARCHIVE_DEST, не хватает
места, вы можете реставрировать некоторые или все архивные файлы
журнала на любой диск, к которому ORACLE имеет доступ. В этом
случае вы сможете специфицировать местоположение архивных файлов
журнала перед восстановлением носителя или во время него.
После того как архивный файл журнала применен, вы можете удалить
его реставрированную копию с диска, чтобы освободить место.
Однако убедитесь, что копия каждой архивированной группы журнала
по-прежнему существует на офлайновом носителе (например, на
ленте).
Запуск восстановления носителя
Если поврежденная база данных работает в режиме ARCHIVELOG, она
является кандидатом на операции либо полного, либо частичного
восстановления носителя. Чтобы начать операции восстановления
носителя, используйте одну из следующих опций SQL*DBA:
* диалоговое окно Recover Closed Database
* диалоговое окно Recover Offline Tablespaces
* диалоговое окно Recover Data File
* команду SQL*DBA RECOVER
* команду SQL ALTER DATABASE
* диалоговое окно Start Up Instance (или команду SQL*DBA
STARTUP) с опцией RECOVER
Эта секция предоставляет примеры по всем перечисленным опциям.
(Для информации о SQL*DBA обратитесь к документу ORACLE7 Server
Utilities User's Guide. Для полной информации о команде ALTER
DATABASE обратитесь к документу ORACLE7 Server SQL Language
Reference Manual.)
ВОССТАНОВЛЕНИЕ ЗАКРЫТОЙ БАЗЫ ДАННЫХ. После того, как база
данных смонтирована, но закрыта, запустите восстановление
закрытой базы данных (полное или частичное) с помощью либо
диалогового окна Recover Closed Database SQL*DBA, либо команды
RECOVER с параметром DATABASE. Рис.19-1 показывает диалоговое
окно Recover Closed Database, которое начинает восстановление до
момента времени, используя резервную копию управляющего файла.
Восстановление базы данных 19-9
Рис.19-1
Диалог Recover Closed Database
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ г======== Recover Closed Database ==========¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ ( ) Complete Database Recovery ¦ ¦
¦¦ ¦ ( ) Incomplete Database Recovery ¦ ¦
¦¦ ¦ ( ) Until User Cancel ¦ ¦
¦¦ ¦ ( ) Until Change: -------------------- ¦ ¦
¦¦ ¦ (o) Until Time: '1992-12-31:12:47:30 ¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ [X] Using Backup of Control File ¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦-------------------------------------------¦ ¦
¦¦ ¦ (OK) (Cancel) ¦ ¦
¦¦ L===========================================- ¦
¦L-------------------------------------------------------------+
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Следующее предложение является командным эквивалентом
диалогового окна Recover Closed Database, показанного на
рис.19-1:
RECOVER DATABASE
UNTIL '1992-12-31:12:47:30' USING BACKUP CONTROLFILE;
ВОССТАНОВЛЕНИЕ ОФЛАЙНОВОГО ТАБЛИЧНОГО ПРОСТРАНСТВА В ОТКРЫТОЙ
БАЗЕ ДАННЫХ. После того, как нужные табличные пространства
переведены в офлайн (см. "Перевод табличных пространств в
офлайн" на странице 7-10), вы можете запустить восстановление
офлайнового табличного пространства в открытой базе данных,
используя либо диалоговое окно Recover Offline Tablespaces
SQL*DBA, либо команду SQL*DBA RECOVER с параметром TABLESPACE.
Любая из этих опций начинает полное восстановление носителя
одного или нескольких офлайновых табличных пространств;
остальная часть базы данных может быть открыта и доступна для
нормальной работы базы данных. Рис.19-2 показывает диалоговое
окно Recover Offline Tablespaces.
19-10 Руководство администратора
Рис.19-2
Диалог Recover Offline Tablespaces
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ г======= Recover Offline Tablespaces =======¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Offline Tablespace: ¦ ¦
¦¦ ¦ ----------------------------------------¬ ¦ ¦
¦¦ ¦ ¦ TS1-----------------------------------¦ ¦ ¦
¦¦ ¦ ¦ TS2-----------------------------------¦ ¦ ¦
¦¦ ¦ ¦ TS3 ¦ ¦ ¦
¦¦ ¦ ¦ TS4 ¦ ¦ ¦
¦¦ ¦ L---------------------------------------- ¦ ¦
¦¦ ¦-------------------------------------------¦ ¦
¦¦ ¦ (OK) (Cancel) ¦ ¦
¦¦ L===========================================- ¦
¦L-------------------------------------------------------------+
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Следующее предложение является командным эквивалентом
диалогового окна Recover Offline Tablespaces, показанного на
рис.19-2:
RECOVER DATABASE ts1, ts2;
После того, как табличные пространства, содержащие поврежденные
файлы данных, переведены в офлайн, и вы уверены, что
ассоциированные файлы данных также в офлайне (опросите
V$DATAFILE, чтобы увидеть состояние файлов), восстановите
выбранные файлы данных, используя диалоговое окно Recover Data
File либо SQL*DBA RECOVER с параметром DATAFILE. Рис.19-2
показывает диалоговое окно Recover Data File.
Рис.19-3
Диалог Recover Data File
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ г========= Recover Data File ===============¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Data Files: ¦ ¦
¦¦ ¦ ----------------------------------------¬ ¦ ¦
¦¦ ¦ ¦ FILENAME1-----------------------------¦ ¦ ¦
¦¦ ¦ ¦ FILENAME2-----------------------------¦ ¦ ¦
¦¦ ¦ ¦ ¦ ¦ ¦
¦¦ ¦ L---------------------------------------- ¦ ¦
¦¦ ¦-------------------------------------------¦ ¦
¦¦ ¦ Mandatory (OK) (Cancel) ¦ ¦
¦¦ L===========================================- ¦
¦L-------------------------------------------------------------+
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Восстановление базы данных 19-11
Следующее предложение является командным эквивалентом
диалогового окна Recover Data File, показанного на рис.19-3:
RECOVER DATAFILE 'filename1', 'filename2';
Командным эквивалентом любой из опций восстановления носителя
SQL*DBA является команда SQL ALTER DATABASE с фразой RECOVER. В
большинстве случаев восстановление базы данных следует выполнять
через SQL*DBA; его интерфейс запрашивает у вас необходимую
информацию и возвращает сообщения от системы. Однако, если вы
хотите разработать свою собственную утилиту восстановления,
используйте команду SQL ALTER DATABASE.
ЗАПУСК ВОССТАНОВЛЕНИЯ ВО ВРЕМЯ ЗАПУСКА ИНСТАНЦИИ. Полное
восстановление носителя можно запустить через диалоговое окно
Start Up Instance с включенным переключателем Recover или
командой SQL*DBA STARTUP с опцией RECOVER. Когда инстанция
стартует и монтирует базы данных, она выполняет полное
восстановление носителя, как описано в секции "Полное
восстановление носителя" на странице 19-17. Обратитесь к главе
3 и документу ORACLE7 Server Utilities User's Guide для
дополнительной информации о диалоговом окне Start Up Instance и
команде SQL*DBA STARTUP.
ПРИВИЛЕГИИ, ТРЕБУЕМЫЕ ДЛЯ ЗАПУСКА ВОССТАНОВЛЕНИЯ НОСИТЕЛЯ.
Чтобы запустить любой тип восстановления носителя, вы должны
быть соединены как INTERNAL. Все сессии восстановления должны
быть совместимы; нельзя в одной сессии запускать полное
восстановление носителя, в то время как другая сессия выполняет
частичное восстановление носителя. Кроме того, вы не можете
запустить восстановление носителя, если вы соединены с базой
данных через процесс многоканальгого сервера. Обратитесь к
главе 4 для дополнительной информации о процессах
многоканального сервера.
Применение файлов журнала повторения
Во время полного или частичного восстановления носителя, файлы
журнала повторения (как онлайновые, так и архивные) применяются
к файлам данных на фазе прокрутки вперед восстановления
носителя. Когда требуется очередной файл журнала, ORACLE
подсказывает его имя. Например, если вы используете SQL*DBA, вы
получите следующие информационные сообщения и подсказку:
ORA-00279: Change #### generated at DD/MM/YY HH:MM:SS needed for
thread #
ORA-00289: Suggestion : имя_файла
ORA-00280: Change #### for thread # is in sequence #
Specify log: [ for suggested | AUTO | FROM logsource |
CANCEL ]
Замечание: Аналогичные сообщения возвращаются при использовании
предложения ALTER DATABASE ... RECOVER; однако запрос на ввод
имени файла при этом не выдается.
Следующие секции описывают, как файлы журнала применяются в
различных окружениях.
ПОДСКАЗКА ИМЕНИ ФАЙЛА. ORACLE подсказывает имя файла журнала,
сцепляя текущие значения параметров инициализации
19-12 Руководство администратора
LOG_ARCHIVE_DEST и LOG_ARCHIVE_FORMAT и используя некоторую
информацию из управляющего файла. Поэтому, если все требуемые
архивные файлы журнала смонтированы в назначении
LOG_ARCHIVE_DEST, и значение LOG_ARCHIVE_FORMAT никогда не
изменяется, ORACLE может формировать имена архивных файлов
журнала и применять эти файлы автоматически, без вмешательства
со стороны администратора. Если местоположение, специфицируемое
параметром LOG_ARCHIVE_DEST, недоступно (например, из-за сбоя
носителя), то вы можете перед тем, как начинать восстановление
носителя, изменить значение этого параметра, смонтировать файлы
журнала в новом назначении и запустить новую инстанцию.
В некоторых случаях, вы можете захотеть перекрыть текущее
значение LOG_ARCHIVE_DEST как источника для файлов журнала.
Например, предположим, что база данных открыта, и должно быть
восстановлено офлайновое табличное пространство, но в
назначении, специфицированном значением параметра
LOG_ARCHIVE_DEST, не хватает места для размещения файлов
журнала. В этом случае необходимые файлы журнала можно
смонтировать в другом месте, и сообщить это место ORACLE для
операции восстановления. Чтобы указать место, в котором
находятся требуемые журнальные файлы, используйте параметр
LOGSOURCE команды SQL*DBA SET, или параметр RECOVER ... FROM
команды SQL ALTER DATABASE.
Замечание: Перекрытие источника архивного журнала не затрагивает
назначение архивирования журнала, которое используется для
архивирования заполненных групп онлайнового журнала повторения.
Рассмотрите необходимость перекрытия текущего значения параметра
LOG_ARCHIVE_DEST, если в этом назначении не хватает места для
монтирования всех требуемых файлов журнала. В этом случае вы
можете установить источник файлов журнала через переменную
операционной системы (такой как логическая переменная или
переменная окружения), которая могла бы выступать как путь
поиска для нескольких местоположений; однако такие возможности
зависят от операционной системы; обратитесь к вашему руководству
по инсталляции [IUG].
ПРИМЕНЕНИЕ ФАЙЛОВ ЖУРНАЛА ПРИ ИСПОЛЬЗОВАНИИ SQL*DBA. Если
подсказываемое системой имя архивного файла журнала корректно,
вы можете принять его, нажав клавишу Enter или Return; вы не
обязаны вводить имя файла, если оно корректно. Обратитесь к
вашему руководству по инсталляции за примерами такой процедуры.
После принятия имени файла журнала ORACLE применяет его для
прокрутки вперед реставрированных файлов данных.
При использовании SQL*DBA, вы можете заставить ORACLE
автоматически применять предлагаемые им файлы журнала повторения
с помощью одной из следующих опций:
Восстановление базы данных 19-13
* Перед запуском восстановления носителя выдайте следующую
команду SQL*DBA, чтобы включить автоматическое
восстановление:
SET AUTORECOVERY ON;
Автоматическое применение предлагаемых файлов журнала
начнется сразу же после запуска восстановления.
* После запуска восстановления носителя введите "auto" в
ответ на запрос очередного имени файла журнала.
Автоматическое применение предлагаемых файлов журнала
начнется с этого момента и продолжится для всех
последующих файлов.
Предполагаемые файлы журнала повторения автоматически
применяются до завершения восстановления или до тех пор, пока не
будет обнаружен некорректный файл журнала. Специфицирование
имен файлов журнала вручную может потребоваться лишь в случае
восстановления до снятия, или если используется резервная копия
управляющего файла.
ПРИМЕНЕНИЕ ФАЙЛОВ ЖУРНАЛА ПРИ ИСПОЛЬЗОВАНИИ КОМАНД SQL.
Применение файлов журнала аналогично тому, что было описано в
предыдущей секции. Однако после запуска восстановления носителя
запрос на ввод имени файла журнала не выдается. Вместо этого вы
должны предоставить корректное имя журнального файла, используя
предложение ALTER DATABASE RECOVER LOGFILE. Например, если
подсказка предагает применение файла LOG1.ARC, то вы можете
выполнить это, используя следующее предложение:
ALTER DATABASE RECOVER LOGFILE 'log1.arc';
Как следствие, восстановление табличного пространства требует
нескольких предложений SQL, как показывает следующий пример
(ввод администратора помечен значком ">"):
> ALTER DATABASE RECOVER TABLESPACE users;
ORA-00279: Change #### generated at DD/MM/YY HH:MM:SS needed for
thread #
ORA-00289: Suggestion : logfile1
ORA-00280: Change #### for thread # is in sequence #
> ALTER DATABASE RECOVER LOGFILE 'logfile1';
ORA-00279: Change #### generated at DD/MM/YY HH:MM:SS needed for
thread #
ORA-00289: Suggestion : logfile2
ORA-00280: Change #### for thread # is in sequence #
> ALTER DATABASE RECOVER LOGFILE 'logfile2';
(Повторяйте это, пока не будут применены все файлы журнала.)
Statement processed.
> ALTER TABLESPACE users ONLINE;
Statement processed.
Замечание: Этот пример предполагает, что резервные копии файлов
уже реставрированы, а пользователь соединен как INTERNAL.
Автоматическое применение файлов журнала также может быть
инициировано при использовании SQL, с помощью следующих
предложений, перед запуском и после запуска восстановления
соответственно:
19-14 Руководство администратора
ALTER DATABASE RECOVER AUTOMATIC ...;
ALTER DATABASE RECOVER AUTOMATIC LOGFILE предлагаемое_имя;
Ниже приведен пример использования первого свособа:
> ALTER DATABASE RECOVER AUTOMATIC TABLESPACE users;
Statement processed.
> ALTER TABLESPACE users ONLINE;
Statement processed.
Замечание: Этот пример предполагает, что резервные копии файлов
уже реставрированы, а пользователь соединен как INTERNAL.
Ниже приведен пример использования второго способа:
> ALTER DATABASE RECOVER TABLESPACE users;
ORA-00279: Change #### generated at DD/MM/YY HH:MM:SS needed for
thread #
ORA-00289: Suggestion : logfile1
ORA-00280: Change #### for thread # is in sequence #
> ALTER DATABASE RECOVER AUTOMATIC LOGFILE 'logfile1';
Statement processed.
> ALTER TABLESPACE users ONLINE;
Statement processed.
Замечание: Этот пример предполагает, что резервные копии файлов
уже реставрированы, а пользователь соединен как INTERNAL.
УСПЕШНОЕ ПРИМЕНЕНИЕ ЖУРНАЛОВ ПОВТОРЕНИЯ. Если вы используете
опции восстановления SQL*DBA (не предложения SQL), то каждый
раз, когда ORACLE заканчивает применение очередного файла
журнала повторения, он возвращает следующее сообщение:
Log applied.
Проверяйте, чтобы сообщение "Log applied" возвращалось после
каждого применения журнального файла. Если предлагаемый файл
оказался некорректным или вы специфицировали некорректное имя
файла, то вместо этого сообщения будет выдано сообщение об
ошибке. В этом случае файл журнала, необходимый для
восстановления, не был применен, и восстановление не может быть
продолжено, пока не будет применен требуемый файл.
Если после ввода имени файла журнала возвращается сообщение об
ошибке, то вид этого сообщения зависит от типа обнаруженной
ошибки:
Восстановление базы данных 19-15
* Если сообщение говорит, что файл не найден, то вы,
возможно, ввели неправильное имя файла. Введите вновь
правильное имя файла.
* Если файл журнала повторения найден, но не может быть
открыт, он, возможно, заблокирован. После
разблокирования журнального файла введите его имя заново.
* Если файл журнала повторения найден и открыт, но не может
быть прочитан, то имеет место ошибка ввода-вывода. В этом
случае журнальный файл, возможно, был записан лишь
частично либо был запорчен. Если вы можете найти
незапорченную или полную копию этого файла, просто
примените эту копию; не требуется перезапускать
восстановление. В противном случае, если не существует
копии этого файла журнала, но вы знаете время последней
действительной записи повторения в этом файле, то вы
можете выполнить восстановление до момента времени или до
изменения; в этом случае вы должны перезапустить
восстановление с начала, включая повторную реставрацию
резервных копий файлов.
Прерывание восстановления носителя
Если вы запускаете операцию восстановления носителя, а потом
вынуждены приостановить ее по какой-нибудь причине (например, в
связи с концом рабочего дня, чтобы продолжить на следующее
утро), то вы можете прервать восстановление в любой момент любым
из следующих способов:
* Введите слово CANCEL в ответ на запрос ввода имени файла
журнала повторения.
* Если вы должны снять процедуру в процессе восстановления
индивидуального файла, или вы работаете в режиме
автоматического восстановления, то воспользуйтесь
сигналом прерывания вашей операционной системы.
После того как восстановление снято, оно должно быть завершено,
прежде чем база данных сможет быть открыта для нормальной
работы. Чтобы возобновить восстановление, запустите его снова;
оно продолжится с той точки, в которой оно было снято. Если вы
хотите перезапустить восстановление, начиная с более раннего
файла журнала повторения или с другой резервной копии, то
повторите весь процесс восстановления, начиная с повторной
реставрации необходимых резервных копий.
Реставрация полной копии
------------------------
Если база данных работает в режиме NOARCHIVELOG, и сбой носителя
повреждает всю базу данных или ее часть, то обычно единственной
возможностью восстановить базу данных является реставрация самой
последней полной копии. (Если вы использовали экспорт в
дополнение к регулярному копированию базы данных, вы можете
вместо этого реставрировать данные с помощью импорта; см.
"Применение утилит Export и Import для дополнительной защиты
базы данных" на странице 18-17.)
Замечание: Если сбой носителя повреждает базу данных, работающую
в режиме ARCHIVELOG, то ее также можно восстановить с помощью
реставрации самой последней полной копии; однако благодаря тому,
19-16 Руководство администратора
что онлайновый журнал повторения архивируется, в этом режиме
обычно применяется полное или частичное восстановление носителя,
чтобы минимизировать количество теряемой работы при
реконструировании базы данных.
Для восстановления базы данных путем реставрации последней
полной резервной копии используйте следующие шаги:
1. Если база данных открыта, закройте ее, используя любую из
следующих опций SQL*DBA: опцию Abort Instance меню Shut Down
или команду SHUTDOWN с опцией ABORT.
2. Исправьте проблемы оборудования, которые вызвали сбой базы
данных. Если проблема может быть исправлена быстро,
перейдите к шагу 3a; если проблема затягивается, а база
данных должна быть открыта как можно быстрее, то следуйте
шагам с 3b по 3e.
3. ЕСЛИ ПРОБЛЕМА ОБОРУДОВАНИЯ ИСПРАВЛЕНА, ПЕРЕЙДИТЕ К ШАГУ 3a.
ЕСЛИ ПРОБЛЕМА ОБОРУДОВАНИЯ НЕ ИСПРАВЛЕНА, И ДЛЯ РЕСТАВРАЦИИ
БАЗЫ ДАННЫХ НЕОБХОДИМО ИСПОЛЬЗОВАТЬ АЛЬТЕРНАТИВНЫЕ ДИСКИ, ТО
ПЕРЕЙДИТЕ К ШАГАМ С 3b ПО 3e.
a. Реставрируйте последнюю полную резервную копию базы данных,
включая ВСЕ файлы данных, файлы онлайнового журнала
повторения и управляющие файлы. Не ограничивайтесь ТОЛЬКО
файлами, поврежденными сбоем носителя; из резервной копии
должны быть реставрированы ВСЕ файлы, чтобы гарантировать,
что вся база данных согласована по отношению к одной точке
времени. После этого перейдите к шагу 4.
b. Реставрируйте все файлы данных, файлы онлайнового журнала
повторения и управляющие файлы базы данных на работоспособные
диски, как вам удобно.
c. Отредактируйте реставрированный файл параметров, чтобы
указать соответствующие новые местоположения управляющих
файлов.
d. Запустите инстанцию, используя реставрированный и
отредактированный файл параметров, и смонтируйте базу данных,
но не открывайте ее.
e. Немедленно выполните шаги, необходимые для регистрации
местоположения реставрированных файлов данных и файлов
онлайнового журнала повторения (из шага 3b), как описано в
секции "Переименование и перемещение файлов данных" на
странице 7-13 и в секции "Переименование и перемещение членов
онлайнового журнала" на странице 5-7.
4. Откройте базу данных.
Полное восстановление носителя
------------------------------
Эти секции описывают шаги, необходимые для выполнения операций
различных типов полного восстановления носителя. Для понимания
процедур восстановления от сбоев носителя недостаточно
использовать эти секции сами по себе; используйте также секцию
"Примеры сбоев носителя и соответствующих процедур
Восстановление базы данных 19-17
восстановления" на странице 19-27, в которой описаны подходящие
методы восстановления от каждого типа проблем.
Ниже описаны следующие типы процедур полного восстановления
носителя:
* восстановление закрытой базы данных
* восстановление офлайнового табличного пространства при
открытой базе данных
Выполнение восстановления закрытой базы данных
Используйте следующие шаги, чтобы выполнить восстановление
закрытой базы данных, - как всех поврежденных файлов данных за
одну операцию, так и индивидуального восстановления каждого
поврежденного файла данных отдельной операцией.
1. Если база данных открыта, закройте ее, используя любую из
следующих опций SQL*DBA: опцию Abort Instance меню Shut Down
или команду SHUTDOWN с опцией ABORT.
2. Исправьте проблему оборудования, которая вызвала сбой
носителя. Если проблема не может быть исправлена быстро,
восстановление базы данных может быть продолжено путем
реставрации поврежденных файлов на альтернативное устройство
памяти.
3. Если файлы необратимо запорчены, реставрируйте из последних
резервных копий (взятых как часть полного или частичного
копирования) ТОЛЬКО файлы данных, поврежденные сбоем носителя
- не реставрируйте никаких неповрежденных файлов данных или
файлов онлайнового журнала. Если проблема оборудования была
исправлена, и поврежденные файлы данных можно реставрировать
на их старое место, - сделайте это, и пропустите шаг 6 данной
процедуры; если проблема оборудования осталась, реставрируйте
файлы данных на альтернативное устройство памяти сервера базы
данных, и выполните шаг 6, когда до него дойдет очередь.
Замечание: Если у вас нет резервной копии конкретного файла
данных, то, возможно, вы можете создать вместо него пустой
файл, который можно будет восстановить. См. секцию
"Реставрация поврежденных файлов данных" на странице 19-8 для
дополнительной информации о создании файлов данных.
4. Запустите SQL*DBA и соединитесь с ORACLE как INTERNAL.
5. Запустите новую инстанцию и смонтируйте базу данных, но не
открывайте ее. Эту операцию можно выполнить с помощью любой
из следующих опций SQL*DBA: диалогового окна Start Up
Instance с включенной кнопкой Mount, или команды STARTUP с
опцией MOUNT.
19-18 Руководство администратора
6. Если на шаге 3 один или несколько поврежденных файлов данных
были реставрированы не на свое старое место, то перемещение
этих файлов необходимо отразить в управляющем файле базы
данных. Для этого выполните операцию, описанную в секции
"Переименование и перемещение файлов данных" на странице
7-13.
7. Все восстанавливаемые файлы данных должны находиться в
состоянии онлайн во время полного восстановления носителя.
Вы можете определить имена всех файлов данных по списку,
приложенному к текущему управляющему файлу (если у вас есть
этот список; см. "Вывод файлов базы данных перед
копированием" на странице 18-6 для дополнительной информации
о таких списках), либо опросить обзор V$DATAFILE. Затем
используйте команду ALTER DATABASE с опцией DATAFILE ONLINE,
чтобы перевести все файлы данных базы данных в онлайн.
Например, чтобы гарантировать, что файл данных с именем
USERS1 (имя должно быть специфицировано полностью) находится
в онлайне, введите следующее предложение:
ALTER DATABASE DATAFILE 'users1' ONLINE;
Если указанный файл данных уже в онлайне, ORACLE игнорирует
это предложение.
8. В ЗАВИСИМОСТИ ОТ НУЖНОГО ТИПА ВОССТАНОВЛЕНИЯ ЗАКРЫТОЙ БАЗЫ
ДАННЫХ, ПЕРЕЙДИТЕ ЛИБО К ШАГУ 8a, ЛИБО К ШАГУ 8b.
a. Используйте одну из следующих опций SQL*DBA, чтобы запустить
восстановление закрытой базы данных для всех поврежденных
файлов данных за один шаг: диалоговое окно Recover Closed
Database, либо эквивалентное предложение RECOVER DATABASE.
Перейдите к шагу 9, чтобы продолжить операцию восстановления
базы данных.
b. Используйте одну из следующих опций SQL*DBA, чтобы запустить
восстановление закрытой базы данных для индивидуального
поврежденного файла данных: диалоговое окно Recover Offline
Data Files, либо эквивалентное предложение RECOVER DATAFILE.
Замечание: Можно запустить одновременно несколько сессий,
каждая из которых будет восстанавливать индивидуальный
поврежденный файл данных. Если восстановления требуют много
файлов данных, этот метод может потенциально ускорить процесс
восстановления носителя. Если вы используете эту
возможность, не забудьте проверить, чтобы были восстановлены
все поврежденные файлы данных. Каждая сессия ведет себя так,
как описано в шагах 9 и 10.
9. Теперь ORACLE начинает фазу прокрутки вперед процесса
восстановления носителя, применяя необходимые файлы журнала
повторения (архивные и онлайновые) для реконструирования
реставрированных файлов данных. Эта фаза может
осуществляться как в автоматическом режиме, когда
предлагаемые файлы журнала применяются автоматически, так и в
неавтоматическом режиме, когда ORACLE запрашивает имена
требуемых файлов журнала. Для дополнительной информации см.
"Применение файлов журнала повторения" на странице 19-12.
Восстановление базы данных 19-19
ORACLE продолжает применять архивные файлы журнала до тех
пор, пока все они не будут применены к восстанавливаемым
файлам данных. После этого автоматически применяются файлы
онлайнового журнала повторения, и процесс восстановления
носителя завершается, о чем указывает сообщение:
Media recovery complete.
Замечание: Если для полного восстановления носителя не
требуется архивных файлов журнала повторения, то ORACLE не
запрашивает ни одного из этих файлов. Вместо этого сразу
применяются все необходимые файлы онлайнового журнала, после
чего выдается сообщение "Media recovery complete".
После выполнения всех описанных выше шагов закрытая база данных
восстановлена в состояние на момент сбоя носителя. Вы можете
теперь открыть базу данных, используя команду SQL ALTER DATABASE
с опцией OPEN.
Выполнение восстановления офлайнового табличного
пространства в открытой базе данных
Используйте приведенные ниже шаги для выполнения восстановления
офлайнового табличного пространства (или индивидуальных файлов
офлайнового табличного пространства) в открытой базе данных.
Исходным моментом служит момент сбоя носителя; база данных
остается открытой, все неповрежденные файлы данных остаются в
онлайне и доступны для использования, а все поврежденные файлы
данных автоматически переведены в офлайн самим ORACLE.
Замечание: Никакие из описанных здесь процедур не могут быть
использованы для выполнения полного восстановления носителя для
файлов данных табличного пространства SYSTEM. Если сбой
носителя повреждает любой файл данных в табличном пространстве
SYSTEM, ORACLE автоматически останавливает базу данных. Чтобы
выполнить полное восстановление носителя в этом случае, следуйте
процедуре, описанной в предыдущей секции, "Выполнение
восстановления закрытой базы данных".
1. Начальный момент этого восстановления может варьироваться, в
зависимости от того, оставили ли вы базу данных открытой
после того, как произошел сбой носителя.
a. ЕСЛИ БАЗА ДАННЫХ БЫЛА ЗАКРЫТА, запустите новую инстанцию,
смонтируйте базу данных и откройте ее. Эту операцию можно
выполнить с помощью любой из следующих опций SQL*DBA:
диалогового окна Start Up Instance с выбранной кнопкой Open,
или команды STARTUP с опцией OPEN. После того, как база
данных будет открыта, переведите в офлайн все табличные
пространства, содержащие поврежденные файлы данных. Для
этого следуйте процедуре, описанной в шаге 1b.
19-20 Руководство администратора
b. ЕСЛИ БАЗА ДАННЫХ открыта (лишь поврежденные файлы данных
переведены в офлайн), переведите в офлайн все табличные
пространства, которые содержат поврежденные файлы данных.
ORACLE должен сообщить вам о поврежденных файлах данных,
выдавая соответствующие сообщения об ошибках. Чтобы
перевести табличные пространства в офлайн, используйте либо
диалоговое окно SQL*DBA Set Tablespace Offline, либо команду
SQL ALTER TABLESPACE с опцией OFFLINE, как описано в секции
"Перевод табличных пространств в офлайн" на странице 7-10.
Если можно, переведите табличные пространства в офлайн с
временным приоритетом (TEMPORARY), чтобы минимизировать
требуемое восстановление. Кроме того, обратите внимание на
специальные указания в упомянутой секции главы 7, касающиеся
тех табличных пространств, которые содержат активные сегменты
отката. После того, как этот шаг выполнен, перейдите к шагу
2.
2. Исправьте проблему оборудования, которая вызвала сбой
носителя. Если проблема не может быть исправлена быстро,
восстановление базы данных может быть продолжено путем
реставрации поврежденных файлов на альтернативное устройство
памяти.
3. Если файлы необратимо запорчены, реставрируйте из последних
резервных копий (взятых как часть полного или частичного
копирования) ТОЛЬКО файлы данных, поврежденные сбоем носителя
- не реставрируйте никаких неповрежденных файлов данных или
файлов онлайнового журнала. Если проблема оборудования была
исправлена, и поврежденные файлы данных можно реставрировать
на их старое место, - сделайте это, и пропустите шаг 4 данной
процедуры; если проблема оборудования осталась, реставрируйте
файлы данных на альтернативное устройство памяти сервера базы
данных, и выполните шаг 4.
Замечание: Если у вас нет резервной копии конкретного файла
данных, то, возможно, вы можете создать вместо него пустой
файл, который можно будет восстановить. См. секцию
"Реставрация поврежденных файлов данных" на странице 19-8 для
дополнительной информации о создании файлов данных.
4. Если на шаге 3 один или несколько поврежденных файлов данных
были реставрированы не на свое старое место, то перемещение
этих файлов необходимо отразить в управляющем файле базы
данных. Для этого выполните операцию, описанную в секции
"Переименование и перемещение файлов данных" на странице
7-13.
5. СОЕДИНИТЕСЬ КАК INTERNAL, И, В ЗАВИСИМОСТИ ОТ НУЖНОГО ТИПА
ПРОЦЕДУРЫ ПОЛНОГО ВОССТАНОВЛЕНИЯ НОСИТЕЛЯ, ПЕРЕЙДИТЕ ЛИБО К
ШАГУ 5a, ЛИБО К ШАГУ 5b.
a. Используйте одну из следующих опций SQL*DBA, чтобы запустить
восстановление всех поврежденных файлов данных в одном или
нескольких офлайновых табличных пространствах за один шаг:
диалоговое окно Recover Offline Tablespaces, либо
эквивалентное предложение RECOVER TABLESPACE. Перейдите к
шагу 6, чтобы продолжить операцию восстановления базы данных.
Восстановление базы данных 19-21
b. Используйте одну из следующих опций SQL*DBA, чтобы запустить
восстановление индивидуального поврежденного файла данных в
офлайновом табличном пространстве: диалоговое окно Recover
Offline Data Files, либо эквивалентное предложение RECOVER
DATAFILE.
Замечание: Можно запустить одновременно несколько сессий,
каждая из которых будет восстанавливать индивидуальный
поврежденный файл данных. Если восстановления требуют много
файлов данных, этот метод может потенциально ускорить процесс
восстановления носителя. Если вы используете эту
возможность, не забудьте проверить, чтобы были восстановлены
все поврежденные файлы данных. Каждая сессия ведет себя так,
как описано в шагах 6 и 7.
6. Теперь ORACLE начинает фазу прокрутки вперед процесса
восстановления носителя, применяя необходимые файлы журнала
повторения (архивные и онлайновые) для реконструирования
реставрированных файлов данных. Эта фаза может
осуществляться как в автоматическом режиме, когда
предлагаемые файлы журнала применяются автоматически, так и в
неавтоматическом режиме, когда ORACLE запрашивает имена
требуемых файлов журнала. Для дополнительной информации см.
"Применение файлов журнала повторения" на странице 19-12.
ORACLE продолжает применять архивные файлы журнала до тех
пор, пока все они не будут применены к восстанавливаемым
файлам данных. После этого автоматически применяются файлы
онлайнового журнала повторения, и процесс восстановления
носителя завершается, о чем указывает сообщение:
Media recovery complete.
Замечание: Если для полного восстановления носителя не
требуется архивных файлов журнала повторения, то ORACLE не
запрашивает ни одного из этих файлов. Вместо этого сразу
применяются все необходимые файлы онлайнового журнала, после
чего выдается сообщение "Media recovery complete".
7. После выполнения всех описанных выше шагов поврежденные
табличные пространства в открытой базе данных восстановлены в
состояние на момент сбоя носителя. Вы можете теперь
перевести восстановленные табличные пространства в онлайн,
используя либо диалоговое окно SQL*DBA Set Tablespace Online,
либо команду SQL ALTER TABLESPACE с опцией ONLINE.
Частичное восстановление носителя
---------------------------------
Эти секции описывают шаги, необходимые для выполнения операций
различных типов операций частичного восстановления носителя: до
момента времени, до номера изменения и до снятия. Для понимания
этих процедур восстановления от сбоев носителя недостаточно
использовать эти секции сами по себе; используйте также секцию
"Примеры сбоев носителя и соответствующих процедур
восстановления" на странице 19-27, в которой описаны подходящие
методы восстановления от каждого типа проблем.
19-22 Руководство администратора
Выполнение восстановления до снятия,
до момента времени или до номера изменения
Используйте следующие шаги, чтобы выполнить восстановление до
снятия, до момента времени или до номера изменения:
1. Если база данных еще открыта, и было решено, что необходимо
выполнить частичное восстановление носителя, то остановите
базу данных с помощью любой из следующих опций SQL*DBA:
опции Abort Instance меню Shut Down, или команды SHUTDOWN с
опцией ABORT.
2. В целях предосторожности, сделайте полное резервное
копирование базы данных (всех файлов данных, файлов
онлайнового журнала повторения, управляющего файла и файла
параметров базы данных), на случай, если во время процедуры
восстановления будет допущена ошибка. (Это защищает вас от
потенциальных проблем, которые могут возникнуть при
реставрации копий на шаге 5.)
3. Если имел место сбой носителя, исправьте проблему
оборудования, которая вызвала этот сбой.
4. Если текущие управляющие файлы на соответствуют физической
структуре (набору файлов) базы данных на тот момент времени,
к которому вы хотите восстановить базу данных (например,
если новый файл данных был добавлен уже после того момента,
к которому вы хотите восстанавливаться), то вы должны
реставрировать ту резервную копию управляющего файла,
которая отражает физическую структуру базы данных на
желаемый момент времени (в частности, содержит имена файлов
данных и файлов журнала на тот момент времени). Просмотрите
списки файлов, соответствующие текущему управляющему файлу и
всем его резервным копиям, чтобы определить правильный
управляющий файл, и, если необходимо, замените все текущие
управляющие файлы базы данных копиями соответствующего
(выбранного) резервного управляющего файла. (Альтернативно,
вы можете создать новый управляющий файл взамен текущего;
см. секцию "Создание дополнительных копий управляющих
файлов, переименование и перемещение управляющих файлов" на
странице 6-4.)
Замечание: Если один из управляющих файлов базы данных
неработоспособен и не может быть заменен резервной копией
из-за неустранимого сбоя оборудования, то вы должны
отркдактировать файл параметров, ассоциированный с базой
данных, чтобы соответственно модифицировать параметр
CONTROL_FILES. Обратитесь к описанию этой процедуры на
странице 6-4.
5. Реставрируйте ВСЕ файлы данных базы данных из резервных
копий (взятых как часть полного или частичного копирования
базы данных), которые были созданы до того момента времени,
к которому вы хотите восстановить базу данных. Например,
если вы намереваетесь восстановиться к порядковому номеру
журнала 38, реставрируйте все файлы данных из резервных
копий, взятых до порядкового номера журнала 38.
Замечание: Если у вас нет резервной копии конкретного файла
данных, вы можете создать взамен него пустой файл, который
можно будет восстановить из журнала. См. "Реставрация
Восстановление базы данных 19-23
поврежденных файлов данных" на странице 19-8 для
дополнительной информации о создании файлов данных.
Замечание: Если файл данных был добавлен к базе данных уже
после желаемого момента восстановления, его не нужно
реставрировать, потому что после восстановления этот файл не
будет использоваться.
Если проблема оборудования, вызвавшая сбой носителя, была
исправлена, и поврежденные файлы данных можно реставрировать
на их старое место, - сделайте это, и пропустите шаг 8
данной процедуры; если проблема оборудования осталась,
реставрируйте файлы данных на альтернативное устройство
памяти сервера базы данных, и выполните шаг 8, когда до него
дойдет очередь.
6. Запустите SQL*DBA и соединитесь с ORACLE как INTERNAL.
7. Запустите новую инстанцию и смонтируйте базу данных. Эту
операцию можно выполнить с помощью любой из следующих опций
SQL*DBA: диалогового окна Start Up Instance с включенной
кнопкой Mount, или команды STARTUP с опцией MOUNT.
8. Если на шаге 5 один или несколько поврежденных файлов данных
были реставрированы не на свое старое место, то перемещение
этих файлов необходимо отразить в управляющем файле базы
данных. Для этого выполните операцию, описанную в секции
"Переименование и перемещение файлов данных" на странице
7-13.
9. Все файлы данных базы данных должны находиться в состоянии
онлайн во время восстановления до момента времени или
восстановления до снятия (кроме офлайновых табличных
пространств, которые были переведены в офлайн с нормальным
приоритетом). Вы можете определить имена всех файлов данных
по списку, приложенному к текущему управляющему файлу (если
у вас есть этот список; см. "Вывод файлов базы данных перед
копированием" на странице 18-6 для дополнительной информации
о таких списках), либо опросить обзор V$DATAFILE. Затем
используйте команду ALTER DATABASE с опцией DATAFILE ONLINE,
чтобы перевести все файлы данных базы данных в онлайн.
Например, чтобы гарантировать, что файл данных с именем
USERS1 (имя должно быть специфицировано полностью) находится
в онлайне, введите следующее предложение:
ALTER DATABASE DATAFILE 'users1' ONLINE;
Если указанный файл данных уже в онлайне, ORACLE игнорирует
это предложение.
10. В ЗАВИСИМОСТИ ОТ НУЖНОГО ТИПА ЧАСТИЧНОГО ВОССТАНОВЛЕНИЯ
НОСИТЕЛЯ, ПЕРЕЙДИТЕ ЛИБО К ШАГУ 10a, ЛИБО К ШАГУ 10b, ЛИБО К
ШАГУ 10c.
a. Если для этого частичного восстановления используется
резервная копия управляющего файла (т.е. управляющий файл на
шаге 4 был реставрирован или пересоздан), то укажите этот
факт в диалоговом окне или команде, используемой для запуска
восстановления (т.е. специфицируйте фразу USING BACKUP
CONTROLFILE).
19-24 Руководство администратора
a. Используйте одну из следующих опций SQL*DBA, чтобы запустить
восстановление до снятия: диалоговое окно Recover Closed
Database с выбранной кнопкой Until User Cancel, либо
эквивалентное предложение RECOVER DATABASE UNTIL CANCEL.
b. Используйте одну из следующих опций SQL*DBA, чтобы запустить
восстановление до момента времени: диалоговое окно Recover
Closed Database с выбранной кнопкой Until Time, либо
эквивалентное предложение RECOVER DATABASE UNTIL TIME. В
любом случае значение времени заключается в апострофы и
специфицируется в формате: 'YYYY-MM-DD:HH24:MI:SS'.
c. Используйте одну из следующих опций SQL*DBA, чтобы запустить
восстановление до номера изменения: диалоговое окно Recover
Closed Database с выбранной кнопкой Until Change, либо
эквивалентное предложение RECOVER DATABASE UNTIL CHANGE. В
любом случае системный номер изменения (SCN) специфицируется
как десятичное число без кавычек или апострофов.
11. Теперь ORACLE начинает фазу прокрутки вперед процесса
восстановления носителя, применяя необходимые файлы журнала
повторения (архивные и онлайновые) для реконструирования
реставрированных файлов данных. Эта фаза может
осуществляться как в автоматическом режиме, когда
предлагаемые файлы журнала применяются автоматически, так и
в неавтоматическом режиме, когда ORACLE запрашивает имена
требуемых файлов журнала. Для дополнительной информации см.
"Применение файлов журнала повторения" на странице 19-12.
ORACLE продолжает применять архивные файлы журнала. В
зависимости от типа частичного восстановления, проводимого
вами, выполните один из следующих шагов:
a. Если вы выполняете восстановление до снятия, продолжайте
применять файлы журнала повторения до пор, пока последний
неповрежденный файл журнала не будет применен к
восстанавливаемым файлам данных.
b. Если вы выполняете восстановление до момента времени или до
номера изменения, продолжайте применять файлы журнала
повторения до пор, пока последний требуемый файл журнала не
будет применен к восстанавливаемым файлам данных.
12. В зависимости от типа частичного восстановления, проводимого
вами, выполните один из следующих шагов:
a. Если вы выполняете восстановление до снятия, введите CANCEL,
чтобы снять восстановление после того, как все
неповрежденные файлы журнала применены к восстанавливаемым
файлам данных. Восстановление до снятия на этом закончено.
b. Если вы выполняете восстановление до момента времени или до
номера изменения, то ORACLE автоматически закончит операцию
восстановления, когда достигнет заданного момента времени
или номера изменения.
Восстановление базы данных 19-25
В любом случае окончание частичного восстановления
отмечается сообщением. Если восстановление было
действительно частичным (т.е. часть информации повторения не
была применена), то в файл ALERT записывается следующее
сообщение:
Incomplete recovery done UNTIL CHANGE scn
Однако, если восстановление оказалось полным (т.е. была
применена вся информация повторения), то в файл ALERT
записываются следующюе сообщения:
Incomplete recovery applied all redo ever generated.
Recovery completed through change nnnnnnnn
13. При первом открытии базы данных после частичного
восстановления вы должны явно специфицировать, требуется ли
сбросить порядковые номера журнала, включив опцию RESETLOGS
или NORESETLOGS. Сброс нумерации журнала приводит к потере
любой информации повторения, которая не была применена во
время восстановления, и гарантирует, что эта информация
никогда не будет применена; эта опция также заново
инициализирует информацию в управляющем файле о группах
онлайнового журнала повторения и потоках повторения, очищает
содержимое файлов онлайнового журнала, создает файлы
онлайнового журнала, если они не существуют, и сбрасывает в
1 порядковый номер журнала. Используйте следующие правила,
чтобы решить, какую опцию, RESETLOGS или NORESETLOGS,
следует выбрать:
* Сбрасывайте нумерацию журнала, если вы использовали при
восстановлении резервную копию управляющего файла,
независимо от типа восстановления (полное или
частичное).
* Сбрасывайте нумерацию журнала, если восстановление было
действительно частичным (см. сообщение на шаге 12),
например, если вы специфицировали предыдущий момент
времени или SCN, а не будущий.
* Не сбрасывайте нумерацию журнала, если восстановление
было полным (и вы не использовали резервную копию
управляющего файла). Это относится и к тем случаям,
когда вы преднамеренно выполняли полное восстановление,
и к тем случаям, когда вы запускали частичное
восстановление, но оно оказалось полным. (См.
объяснение на шаге 12 о том, как проверять файл ALERT
для того, чтобы определить, было ли восстановление
полным.)
Чтобы сохранить нумерацию журнала повторения при открытии
базы данных после восстановления, используйте команду SQL
ALTER DATABASE с опцией NORESETLOGS. Чтобы начать с начала
нумерацию журнала повторения при открытии базы данных после
восстановления, используйте команду SQL ALTER DATABASE с
опцией RESETLOGS. (Если вы попытаетесь сбросить нумерацию
журнала, когда вы не должны этого делать, или забудете
сбросить журнал, когда должны это сделать, ORACLE возвратит
19-26 Руководство администратора
ошибку и не откроет базу данных. Исправьте ошибку и
повторите операцию.)
Если нумерация журнала сбрасывается при открытии базы
данных, то, в зависимости от того, было восстановление
полным или частичным, возвращаются разные сообщения. Если
восстановление было полным, в файл ALERT посылается
следующее сообщение:
RESETLOGS after complete recovery through change scn
Если восстановление было частичным, в файл ALERT посылается
следующее сообщение:
RESETLOGS after incomplete recovery UNTIL CHANGE scn
14. Если вы сбрасываете нумерацию журнала при открытии базы
данных, то немедленно остановите базу данных с нормальным
приоритетом и сделайте полную резервную копию базы данных.
(См. "Полное копирование базы данных" на странице 18-7.) В
противном случае вы не сможете восстанавливать изменений,
которые будут сделаны после сброса журнала; единственным
способом восстановления будет повторение всех процедур,
которые вы только что закончили, вплоть до сброса журнала.
(Вы не обязаны делать копию базы данных, если вы не
сбрасывали нумерацию журнала.)
----------------
Примеры сбоев носителя и соответствующих процедур восстановления
Следующие секции описывают типичные сбои носителя, последствия
этих сбоев и соответствующие шаги, необходимые для
восстановления базы данных в каждой ситуации.
Типы сбоев носителя
-------------------
Сбои носителя могут быть разделены на две общих категории:
постоянные и временные. Постоянные сбои носителя - это
серьезные проблемы оборудования, которые приводят к необратимой
потере данных на диске. Потерянные данные нельзя восстановить
иным способом, чем починка или замена сбившегося устройства и
реставрация резервных копий файлов, хранившихся на поврежденном
устройстве. Временные сбои носителя - это проблемы
оборудования, которые не приводят к потере данных. Следующие
примеры показывают ситуации, которые могут быть определены как
временные сбои носителя:
* Сбивается контроллер диска. После замены контроллера все
данные на этом диске становятся вновь доступны.
* Отключается питание устройства памяти. После включения
питания само устройство и все данные на нем снова
доступны, как обычно.
Восстановление базы данных 19-27
Потеря файлов данных
--------------------
Если сбой носителя затрагивает файлы данных базы данных,
соответствующая процедура восстановления зависит от режима
архивирования базы данных, типа сбоя носителя, а также того,
какие файлы повреждены этим сбоем. Следующие секции объясняют
соответствующую страгегию восстановления в каждой ситуации.
Потеря файлов данных, режим NOARCHIVELOG
Если постоянный или временный сбой носителя затрагивает ЛЮБЫЕ
файлы данных базы данных, работающей в режиме NOARCHIVELOG, то
ORACLE автоматически останавливает базу данных. В зависимости
от типа сбоя носителя, может использоваться один из двух путей
восстановления:
* Если сбой носителя временный, исправьте проблему и
перезапустите базу данных. В большинстве случаев
восстановление инстанции возможно, и все подтвержденные
транзакции могут быть восстановлены через онлайновый
журнал повторения.
* Если сбой носителя постоянный, то для восстановления
следуйте шагам, описанным в секции "Реставрация полной
копии" на странице 19-16.
Потеря файлов данных, режим ARCHIVELOG
Если постоянный или временный сбой носителя затрагивает файлы
данных базы данных, работающей в режиме NOARCHIVELOG, то
возможны следующие ситуации.
* Если постоянный или временный сбой носителя затрагивает
любые файлы данных в табличном пространстве SYSTEM или
любые файлы данных в табличном пространстве, содержащем
активные сегменты отката, то база данных становится
неработоспособной и должна быть немедленно остановлена,
если она еще не остановлена самим ORACLE.
Если проблема оборудования временная, исправьте ее и
перезапустите базу данных. В большинстве случаев
восстановление инстанции возможно, и все подтвержденные
транзакции могут быть восстановлены через онлайновый
журнал повторения.
Если проблема оборудования постоянная, то для
восстановления следуйте шагам, описанным в секции
"Выполнение восстановления закрытой базы данных" на
странице 19-18.
* Если постоянный или временный сбой носителя затрагивает
лишь файлы данных, не названные в предыдущем пункте, то
затронутые файлы данных становятся недоступными, но база
данных продолжает работать.
19-28 Руководство администратора
Если не затронутые сбоем участки базы данных должны
оставаться доступными, не останавливайте базу данных.
Сначала переведите в офлайн (с временным приоритетом) все
табличные пространства, содержащие затронутые файлы
данных. Затем следуйте процедуре, описанной в секции
"Выполнение восстановления офлайнового табличного
пространства в открытой базе данных" на странице 19-20.
ЕСЛИ ПРОБЛЕМА, ВЫЗВАВШАЯ СБОЙ, ВРЕМЕННАЯ, ТО НЕ
ВЫПОЛНЯЙТЕ ШАГ 3; восстановление может продолжаться,
используя незатронутые файлы данных, и часто требует
только файлов онлайнового журнала повторения.
Потеря файлов онлайнового журнала повторения
--------------------------------------------
Если сбой носителя затронул онлайновый журнал базы данных, то
соответствующая процедура восстановления зависит от конфигурации
онлайнового журнала (зеркальный или не зеркальный), типа сбоя
носителя (постоянный или временный), а также типов онлайновых
файлов, затронутых сбоем носителя (текущий, активный, еще не
архивированный или неактивный). Следующие секции объясняют
соответствующую страгегию восстановления в каждой ситуации.
Потеря членов зеркального журнала повторения
Если онлайновый журнал повторения базы данных зеркализуется, и
хотя бы один член в каждой группе онлайнового журнала не
затронут сбоем носителя, то ORACLE позволяет базе данных
продолжать нормальную работу (сообщения об ошибках записываются
в файл трассировки процесса LGWR и в файл ALERT базы данных).
Возникшая проблема может быть обработата одним из следующих
способов:
* Если проблема оборудования временная, исправьте ее.
После этого процесс LGWR будет по-прежнему работать с
ранее недоступными файлами журнала, как будто сбоя не
было.
* Если проблема оборудования постоянная, используйте
следующую процедуру:
1. Убедитесь, что в каждой группе онлайнового журнала
повторения осталось хотя бы по два члена, чтобы
обезопаситься от возможного нового сбоя. Если в
какой-либо группе остался лишь один член после сбоя,
создайте для этой группы дополнительные файлы журнала.
2. Удалите поврежденные файлы онлайнового журнала.
3. Почините или замените сбойное устройство, если нужно.
После этого вы можете заново создать файлы журнала,
которые были повреждены, и удалить файлы, которые вы
создали на шаге 1 этой процедуры.
Восстановление базы данных 19-29
Замечание: Если сбой носителя привел к потере всех членов группы
зеркального онлайнового журнала повторения, то обратитесь к
следующей секции.
Потеря всех членов группы зеркального журнала повторения
Если сбой носителя привел к потере всех членов группы
зеркального онлайнового журнала повторения, то могут возникнуть
различные ситуации, в зависимости от того, какой тип группы был
затронут сбоем, и от режима архивирования базы данных. Чтобы
определить, в каком состоянии находилась запорченная группа
журнала, опросите обзор V$LOG:
SELECT group#, members, status, archived
FROM v$log
;
GROUP# MEMBERS STATUS ARCHIVED
--------------------------------------------------
0001 log1a INACTIVE YES
0001 log1b INACTIVE YES
0002 log2a ACTIVE YES
0002 log2b ACTIVE YES
0003 log3a CURRENT NO
0003 log3b CURRENT NO
Следующие секции объясняют различные ситуации:
ПОТЕРЯ НЕАКТИВНОЙ, АРХИВИРОВАННОЙ ГРУППЫ ЖУРНАЛА. Если
повреждены все члены неактивной (но архивированной, если вы
используете режим ARCHIVELOG) группы журнала, то могут
возникнуть несколько ситуаций:
* Независимо от режима архивирования, если временный сбой
носителя затронул лишь неактивную группу журнала,
исправьте проблему; после этого LGWR сможет повторно
использовать эту группу, когда потребуется.
* Если постоянный сбой привел к потере лишь неактивной
группы журнала, то в конце концов это приведет к
остановке нормальной работы базы данных.
ЕСЛИ ВЫ ЗАМЕТИЛИ ПРОБЛЕМУ ДО ОСТАНОВКИ БАЗЫ ДАННЫХ, то
либо удалите поврежденную группу журнала (добавив другую
группу, если необходимо), либо, если вы в режиме
ARCHIVELOG, реставрируйте онлайновый журнал из архивной
копии, создав для группы достаточное количество членов и
выполнив переименование онлайнового журнала на новое
местоположение.
ЕСЛИ БАЗА ДАННЫХ УЖЕ ОСТАНОВИЛАСЬ, используйте следующие
шаги, чтобы разрешить эту проблему:
19-30 Руководство администратора
1. Немедленно снимите текущую инстанцию, используя либо
опцию Abort Instance в меню Shut Down SQL*DBA, либо
команду SHUTDOWN с опцией ABORT.
2. Запустите новую инстанцию и смонтируйте базу данных,
но не открывайте ее. Эту операцию можно выполнить с
помощью любой из следующих опций SQL*DBA: диалогового
окна Start Up Instance с включенной кнопкой Mount, или
команды STARTUP с опцией MOUNT.
3. Если вы в режиме ARCHIVELOG, выключите режим
архивирования базы данных с помощью команды ALTER
DATABASE с опцией NOARCHIVELOG:
ALTER DATABASE NOARCHIVELOG;
4. Создайте новую группу онлайнового журнала повторения
взамен утерянной, используя диалоговое окно Add Online
Redo Log Group SQL*DBA или команду SQL ALTER DATABASE
с параметром ADD LOGFILE, или реставрируйте потерянную
группу журнала из архивной копии.
5. Удалите поврежденную группу журнала, используя либо
диалоговое окно Drop Online Redo Log Group SQL*DBA,
либо команду SQL ALTER DATABASE с параметром DROP
LOGFILE.
6. Если вы ранее были в режиме ARCHIVELOG, восстановите
режим архивирования базы данных с помощью команды
ALTER DATABASE с опцией ARCHIVELOG:
ALTER DATABASE ARCHIVELOG;
7. Немедленно сделайте резервную копию базы данных;
скопируйте также управляющий файл базы данных с
помощью команды ALTER DATABASE с опцией BACKUP
CONTROLFILE.
Теперь вы можете открыть базу данных.
ПОТЕРЯ НЕАРХИВИРОВАННОЙ ГРУППЫ ЖУРНАЛА. Если вы работаете в
режиме ARCHIVELOG, и сбой носителя повредил все члены еще не
архивированной группы журнала, то могут возникнуть несколько
ситуаций:
* Если сбой носителя временный, исправьте проблему; после
этого LGWR сможет повторно использовать эту группу, когда
потребуется.
* Если постоянный сбой привел к недоступности
неархивированной группы журнала, то в конце концов это
приведет к остановке нормальной работы базы данных, когда
Восстановление базы данных 19-31
процесс ARCH не сможет архивировать эту группу, и
постепенно все группы начнут ожидать архивирования.
Используйте следующие шаги, чтобы разрешить эту проблему:
1. Остановите базу данных нормально, используя либо опцию
Normal в меню Shut Down SQL*DBA, либо команду SHUTDOWN
с опцией NORMAL. Если вы не можете остановить базу
данных нормально, остановите ее с помощью опции
IMMEDIATE или ABORT, затем перезапустите инстанцию с
опцией RECOVER, смонтируйте базу данных, а потом
остановите ее нормально.
2. Запустите восстановление "до снятия", и снимите его
немедленно, до применения любых журналов повторения.
3. Переименуйте поврежденную группу онлайнового журнала
на новое место. (Вы не обязаны создавать файлы.)
4. Откройте базу данных с опцией RESETLOGS.
5. Немедленно сделайте копию управляющего файла базы
данных с помощью команды ALTER DATABASE с параметром
BACKUP CONTROLFILE.
Поврежденный журнал теперь исправлен.
ПОТЕРЯ АКТИВНОЙ ГРУППЫ ЖУРНАЛА. Если повреждены все члены
активной группы онлайнового журнала повторения, то могут
возникнуть несколько ситуаций:
* Если сбой носителя временный, исправьте проблему; после
этого LGWR сможет повторно использовать эту группу, когда
потребуется.
* Если база данных работает в режиме NOARCHIVELOG, и
постоянный сбой носителя сделал недоступной активную
группу журнала, выполните восстановление базы данных из
полной резервной копии.
* Если база данных работает в режиме ARCHIVELOG, и
постоянный сбой носителя сделал недоступной активную
группу журнала, то остановите базу данных нормально (если
она уже не остановлена); способ восстановления зависит от
того, была ли архивирована активная группа журнала, как
объясняется ниже:
ЕСЛИ АКТИВНАЯ ГРУППА ЖУРНАЛА УЖЕ БЫЛА АРХИВИРОВАНА,
реставрируйте ее из архивной копии, выполните ее
переименование на новое место и перезапустите базу
данных. ORACLE продолжит использовать восстановленную
группу.
19-32 Руководство администратора
ЕСЛИ АКТИВНАЯ ГРУППА ЖУРНАЛА ЕЩЕ НЕ БЫЛА АРХИВИРОВАНА,
используйте процедуру, описанную в секции "Выполнение
восстановления до снятия, до момента времени или до
номера изменения" на странице 19-23, восстановив базу
данных до номера журнала, предшествующего поврежденному,
и видоизменив следующие шаги:
8. Переименуйте поврежденную группу онлайнового журнала
на новое место. (Вы не обязаны создавать файлы.)
14. Помимо взятия полной копии базы данных, немедленно
сделайте копию управляющего файла базы данных с
помощью команды ALTER DATABASE с параметром BACKUP
CONTROLFILE.
Поврежденный журнал теперь исправлен.
ПОТЕРЯ ТЕКУЩЕЙ ГРУППЫ ЖУРНАЛА. Если повреждены все члены
текущей группы онлайнового журнала повторения, то могут
возникнуть несколько ситуаций:
* Если сбой носителя временный, исправьте проблему; после
этого LGWR сможет повторно использовать эту группу, когда
потребуется.
* Если база данных работает в режиме NOARCHIVELOG, и
постоянный сбой носителя сделал недоступной текущую
группу журнала, выполните восстановление базы данных из
полной резервной копии.
* Если база данных работает в режиме ARCHIVELOG, и
постоянный сбой носителя сделал недоступной текущую
группу журнала, то база данных будет снята. Используйте
процедуру, описанную в секции "Выполнение восстановления
до снятия, до момента времени или до номера изменения" на
странице 19-23, восстановив базу данных до номера
журнала, предшествующего поврежденному, и видоизменив
следующие шаги:
8. Переименуйте поврежденную группу онлайнового журнала
на новое место. (Вы не обязаны создавать файлы.)
14. Помимо взятия полной копии базы данных, немедленно
сделайте копию управляющего файла базы данных с
помощью команды ALTER DATABASE с параметром BACKUP
CONTROLFILE.
Поврежденный журнал теперь исправлен.
ПОТЕРЯ НЕСКОЛЬКИХ ГРУПП ЖУРНАЛА. Если вы потеряли сразу
несколько групп онлайнового журнала повторения, используйте для
восстановления метод, определяемый самым тяжелым случаем.
Порядок тяжести, от наиболее тяжелого к наиболее легкому,
следующий: текущая группа, активная группа, неархивированная
группа, неактивная группа.
Восстановление базы данных 19-33
Потеря архивных файлов журнала повторения
-----------------------------------------
Если база данных работает в режиме архивирования заполненных
групп онлайнового журнала повторения, и сбой носителя повредил
лишь архивные копии журнала, то этот сбой не затрагивает текущей
работы базы данных. Однако в будущем, если потребуется
восстановление носителя, могут возникнуть следующие проблемы:
* Если для ВСЕХ файлов данных были сделаны резервные копии
после того, как была записана группа онлайнового журнала
(впоследствии архивированная, а сейчас поврежденная), то
эта архивированная группа вообще не нужна; она не
потребуется ни для какой операции полного восстановления
носителя.
* Предположим, что последняя резервная копия файла данных
была сделана после того, как была записана группа
онлайнового журнала (впоследствии архивированная, а
сейчас поврежденная). В какой-то момент в будущем этот
файл данных повреждается неустранимым сбоем носителя. В
этом случае должна использоваться последняя резервная
копия поврежденного файла данных, и частичное
восстановление может восстановить базу данных лишь до
поврежденного архивного файла журнала повторения.
* Если необходимо восстановление до момента времени, то
поврежденный архивный файл журнала может потребоваться,
если используются старые резервные копии файлов данных,
которые были взяты до записи первоначальной группы
онлайнового журнала. В этом случае частичное
восстановление может восстановить базу данных лишь до
поврежденного архивного файла журнала повторения.
[!] Если вы узнали, что архивная группа журнала повреждена,
немедленно сделайте резервные копии всех файлов данных, чтобы в
будущем при восстановлении вам не понадобилась эта поврежденная
архивная группа журнала.
Потеря управляющих файлов
-------------------------
Если сбой носителя затрагивает управляющие файлы базы данных
(независимо от того, зеркальные они или нет), то база данных
продолжает работать лишь до тех пор, пока ORACLE очередной раз
не понадобится обратиться к управляющим файлам; в этот момент
база данных и инстанция будут немедленно остановлены.
Если сбой носителя временный, и база данных еще не остановлена,
то путем немедленного исправления проблемы вы избежите
автоматического останова базы данных. Однако, если база данных
остановлена до того, как вы устранили сбой, вы можете
перезапустить базу данных после исправления ошибки (и
возобновления доступности управляющих файлов).
В случае постоянного сбоя, процедура восстановления зависит от
того, поддерживаете ли вы зеркальные управляющие файлы.
Следующие секции описывают соответствующие процедуры
восстановления для каждого случая.
19-34 Руководство администратора
Потеря не всех управляющих файлов
Если один или несколько (зеркальных) управляющих файлов базы
данных повреждены сбоем носителя, но хотя бы один управляющий
файл не затронут этим сбоем, используйте следующие шаги для
восстановления базы данных:
Замечание: Если сбой повредил все управляющие файлы базы данных,
следуйте процедуре, описанной в следующей секции.
1. Если база данных открыта, немедленно закройте ее, используя
любую из следующих опций SQL*DBA: опцию Abort Instance меню
Shut Down или команду SHUTDOWN с опцией ABORT.
2. Исправьте проблемы оборудования, которые вызвали сбой
носителя. Если проблема не может быть исправлена быстро, вы
можете продолжить восстановление путем реставрации копий
управляющего файла на альтернативное устройство памяти;
перейдите к шагу 3.
3. Используйте неповрежденную копию управляющего файла как
источник для восстановления запорченных копий. Если можно,
скопируйте неповрежденную копию поверх поврежденных; если это
не получается, скопируйте неповрежденную копию в другие
места. Если вы реставрировали ВСЕ поврежденные управляющие
файлы на их старых местах, перейдите к шагу 5; если
реставрированы не все управляющие файлы, или они
реставрированы не на старых местах, то перейдите к шагу 4.
4. Если реставрированы не все управляющие файлы, или не все
управляющие файла реставрированы на своих старых местах, то
необходимо отредактировать параметр CONTROL_FILES в файле
параметров базы данных, чтобы отразить текущие адреса
управляющих файлов и удалить из списка те управляющие файлы,
которые не были реставрированы.
5. Теперь вы можете запустить инстанцию, смонтировать и открыть
базу данных.
Потеря всех управляющих файлов
Если постоянный сбой носителя привел к потере всех управляющих
файлов базы данных, полное восстановление носителя может быть
выполнено с использованием резервной копии управляющего файла.
Замечание: Если резервная копия управляющего файла недоступна,
то вы должны создать новый управляющий файл для базы данных; см.
секцию "Создание нового управляющего файла" на странице 6-4.
Если резервная копия управляющего файла доступна, используйте
процедуру, описанную в секции "Выполнение восстановления
закрытой базы данных" на странице 19-18, со следующими
модификациями:
Восстановление базы данных 19-35
* Между шагами 2 и 3, реставрируйте управляющий файл из
резервной копии, отражающей текущую структуру базы
данных. Если вы реставрируете управляющий файл на новое
место, отредактируйте соответственно параметр
CONTROL_FILES в файле параметров базы данных, прежде чем
запускать инстанцию на шаге 5 (на странице 19-18).
* Если ни один из файлов данных не был поврежден, можно
пропустить шаги 3, 6 и 7.
* Выберите шаг 8a вместо шага 8b. Включите опцию USING
BACKUP CONTROLFILE. (Эта опция сообщает инстанции
ORACLE, что она обнаружит несоответствия между
управляющим файлом и заголовками файлов данных; эта опция
необходима каждый раз, когда при восстановлении
используется не текущий управляющий файл.)
* Когда вы будете готовы открыть базу данных, сначала
выполните полное офлайновое копирование базы данных; это
- предосторожность на случай проблем, которые могут
возникнуть при открытии базы данных с опцией RESETLOGS.
Затем откройте базу данных с опцией RESETLOGS. (Это
сбросит в 1 порядковый номер журнала повторения.)
Немедленно после открытия базы данных, ввиду того, что
нумерация журнала сброшена и вся старая информация
повторения отвергнута, выполните полное копирование базы
данных.
Восстановление от ошибок пользователя
-------------------------------------
Серьезные ошибки пользователей могут повредить базу данных и
вызвать необходимость ее восстановления. Восстановление базы
данных от ошибки пользователя можно осуществить так, что
практически никакие данные не будут потеряны. Используйте
следующие шаги:
Замечание: Если администратор базы данных назначает мощные
привилегии (такие как DROP ANY TABLE) лишь выбранным,
соответствующим пользователям, то вероятность ошибок
пользователей, требующих восстановления базы данных, сводится к
минимуму.
1. Сделайте копию существующей базы данных, ничего не меняя в
ней.
2. Оставьте существующую базу данных нетронутой, но, посредством
восстановления до момента времени, реконструируйте временную
копию базы данных в состояние до момента ошибки пользователя.
3. Экспортируйте данные, потерянные в результате ошибки
пользователя, из временной реконструированной копии базы
данных.
4. Импортируйте эти экспортированные данные в постоянную базу
данных.
5. Удалите файлы, ассоциированные с временной реконструированной
копией базы данных, чтобы освободить память на диске.
19-36 Руководство администратора
Например, следующие шаги восстанавливают случайно удаленную
таблицу:
1. База данных, в которой произошла ошибка пользователя, может
оставаться открытой и доступной для нормальной работы, но
может быть и закрыта. На случай ошибок во время остальных
шагов этой процедуры, сделайте копии всех файлов данных
существующей базы данных.
2. Создайте временную копию базы данных, восстановив ее в
состояние на момент, предшествующий ошибке, с помощью
восстановления до момента времени. Используйте процедуру,
описанную в секции "Выполнение восстановления до снятия, до
момента времени или до номера изменения" на странице 19-23;
однако не конфликтуйте с существующим управляющим файлом
постоянной базы данных. Реставрируйте единственную копию
управляющего файла на новое место на шаге 4 и соответственно
отредактируйте файл параметров, или создайте новый файл
параметров в новом месте (изменив имя базы данных, если
хотите). Кроме того, на шаге 5 реставрируйте копии всех
файлов данных на новые места, чтобы не затрагивать постоянную
копию базы данных.
3. С помощью утилиты экспорта экспортируйте потерянные данные из
временной, реставрированной версии базы данных. В данном
случае, экспортируйте нечаянно удаленную таблицу. (См.
документ ORACLE7 Server Utilities User's Guide.)
4. С помощью утилиты импорта импортируйте потерянные данные в
постоянную базу данных. (См. документ ORACLE7 Server
Utilities User's Guide.)
5. Удалите файлы, ассоциированные с временной реконструированной
копией базы данных, чтобы освободить память на диске.