-
1. Смысл восстановления
Когда мы используем базу данных, мы всегда надеемся, что ее содержимое надежно и правильно. Однако сбои компьютерной системы (сбои оборудования, сбои сети, сбои процессов и сбои системы) влияют на работу системы базы данных и точность. Сексуальным путем даже уничтожить базу данных, что приведет к потере всех или части данных в базе данных. Таким образом, при возникновении вышеуказанного сбоя можно надеяться, что можно будет восстановить полную базу данных. Этот процесс называется восстановлением базы данных. Подсистема восстановления является важной частью системы управления базой данных. Процесс восстановления варьируется в зависимости от структуры, на которую влияет тип произошедшего сбоя.
2. Способ восстановления
Метод ИМПОРТ:
Используйте ИМПОРТ, чтобы ИМПОРТировать последний файл данных, экспортированный в новую базу данных. Этот метод может восстановить любой объект базы данных до состояния, в котором он был экспортирован, и последующие изменения будут необратимыми. Команда IMPORT может выполняться в интерактивном режиме. Конкретное значение каждого параметра см. в подробном объяснении параметров ORACLE EXP/IMP. Этот метод подходит для сред, не использующих режим архивирования.
Безопасные методы восстановления:
Если база данных работает в режиме архива, то в случае повреждения базы данных ее можно восстановить до состояния точки останова с помощью холодного резервного копирования (горячего резервного копирования) и архивного резервного копирования.
Восстановление управляющего файла базы данных (при условии, что все управляющие файлы уничтожены):
База данных основана на файловой системе: достаточно использовать tar, cp и другие команды операционной системы.
База данных основана на необработанных устройствах: dd if=$ORACLE_BASE/con.bak of=/dev/rdrd/drd1 seek=12.
Восстановление файлов данных базы данных
Восстановление табличных пространств данных и индексов, а также системных табличных пространств:
Скопируйте обратно соответствующие файлы базы данных и все файлы логического журнала, созданные с момента резервного копирования файла данных, и выполните следующую команду:
svrmgrl > монтирование при запуске
svrmgrl > изменить автоматическое восстановление базы данных
Если управляющий файл поврежден, выполните следующие действия: svrmgrl > изменить восстановление базы данных с помощью резервного файла управления. Введите имя файла журнала и имя файла повторного журнала в соответствии с запросом.
svrmgrl > изменить журналы сброса открытия базы данных;
Восстановление временных файлов базы данных и откат табличных пространств: просто отключите их и перестройте.
Примечание. Если база данных не работает в режиме архива, восстановление может быть выполнено только до состояния последней резервной копии. Информацию о настройках режима архивирования и технологиях резервного копирования см. в разделе Технология резервного копирования баз данных ORACLE.
3. Решение для восстановления табличного пространства ORACLE.
(1) Явление ошибки домашнего табличного пространства:
При запуске базы данных возникает ошибка ORA-01157, ORA-01110 или уровня операционной системы.
Такие ошибки, как ORA-07360, при завершении работы базы данных (с использованием обычного или немедленного завершения работы) приведут к ошибкам ORA-01116, ORA-01110 и ошибке уровня операционной системы ORA-07368.
решать:
Ниже есть два решения:
Решение 1. Табличное пространство пользователя можно легко перестроить, то есть недавно экспортированные объекты доступны или объекты в табличном пространстве можно легко перестроить и т. д. В этом случае самый простой способ — отключиться и удалить файлы данных, удалить табличное пространство и перестроить табличное пространство и все объекты.
svrmgrl> монтирование при запуске
svrmgrl> изменить имя файла файла данных базы данных, удалить в автономном режиме;
svrmgrl> изменить базу данных, открытую;
svrmgrl> удалить табличное пространство имя_табличного_пространства, включая содержимое;
Перестройте табличное пространство и все объекты.
Решение 2. Табличное пространство пользователя невозможно легко восстановить. В большинстве случаев восстановление табличного пространства невозможно и требует слишком много усилий. Метод заключается в том, чтобы отменить резервную копию и выполнить восстановление с носителя. Только тогда. потерянные данные можно восстановить в онлайн-журнале повторов.
Шаги следующие:
1) Восстановите утерянный файл данных из резервной копии.
2)svrmgrl> монтирование при запуске
3)svrmgrl> выберите v1.group#,member,sequence#,first_change# из v$log v1,v$logfile v2, где v1.group#=v2.group#;
4) Если база данных работает в режиме NOARCHIVELOG: svrmgrl> select file#,change# from v$recover_file;
Если CHANGE# больше минимального FIRST_CHANGE#, файл данных можно восстановить.
Если CHANGE# меньше минимального FIRST_CHANGE#, файл данных не подлежит восстановлению. Восстановите самую последнюю полную резервную копию или используйте первый вариант.
5)svrmgrl> восстановить имя файла файла данных;
6) Подтвердите, что восстановление прошло успешно.
7)svrmgrl> изменить журналы сброса открытия базы данных;
Нет необходимости выполнять восстановление носителя для табличных пространств, доступных только для чтения, достаточно восстановить резервную копию. Единственными исключениями являются:
Табличное пространство было переведено в режим чтения и записи после последнего резервного копирования. Табличное пространство было переведено в режим только для чтения после последнего резервного копирования. В этом случае требуется восстановление с носителя.
(2) Временное табличное пространство Временное табличное пространство не содержит реальных данных. Метод восстановления заключается в удалении временного табличного пространства и его перестроении.
(3) Если резервная копия системного табличного пространства недоступна, единственным методом может быть перестроение базы данных.
(4) Существует две ситуации для отката табличного пространства:
1. База данных полностью отключена (используйте команду «Немедленное выключение» или «Выключение»).
1) Подтвердите, что база данных полностью закрыта.
2) Измените файл init.ora и прокомментируйте «rollback-segment».
3) svrmgrl> ограничение запуска при монтировании
4) svrmgrl> изменить имя файла файла данных базы данных, удалить его в автономном режиме;
5) svrmgrl> открыть базу данных;
На основании появившихся результатов: «оператор обработан» перейдите к (7) «ORA-00604,ORA-00376,ORA-01110» перейдите к (6);
6) svrmgrl> немедленное выключение
Измените файл init.ora и добавьте следующую строку: _corrupted_rollback_segments = (<roll1>,...<rolln>)
svrmgrl> ограничение запуска
7) svrmgrl> удалить табличное пространство имя_табличного_пространства, включая содержимое;
8) Перестроить табличное пространство и сегмент отката.
9) svrmgrl> изменить систему, отключить ограниченный сеанс;
10) Измените файл init.ora.
2. База данных не закрыта полностью (сбой базы данных или для закрытия базы данных используется команда завершения работы)
1) Восстановить резервную копию
2) svrmgrl> монтирование при запуске
3) svrmgrl> выберите номер файла, имя и статус из v$datafile;
svrmgrl> изменить имя файла файла данных базы данных онлайн;
4) svrmgrl> выберите v1.group#,member,sequence#,first_change# из v$log v1,v$logfile v2, где v1.group#=v2.group#;
5) svrmgrl> выберите файл#,измените# из v$recover_file #См. решение 2-4;
6) svrmgrl> восстановить имя файла файла данных;
7) svrmgrl> открыть базу данных;
3. База данных открыта
1) Удалить сегмент отката и табличное пространство.
2) Перестроить табличное пространство и сегмент отката (5), управлять восстановлением файлов.
1. Все управляющие файлы уничтожаются. Скопируйте резервные управляющие файлы в исходный каталог. Для RAW DEVICE (голое устройство) выполните: dd if='con.bak' of='/dev/rdrd/drd1' seek=128.
2. Не все управляющие файлы уничтожены. Используйте другие управляющие файлы для запуска базы данных (6), сохраните блоки данных и данные в них. Феномен: при выполнении операции ORACLE возникает ошибка ORA-01578. Анализ: при работе ORACLE возникает ошибка ORA-1578. считает, что блоки данных могут быть повреждены, что может произойти по следующим причинам:
Повреждение аппаратного обеспечения ввода-вывода или встроенного ПО. Операционная система. Сбой ввода-вывода или кэша. Ошибка памяти или подкачки страниц. Часть файла данных перезаписана. Попытка доступа к неформатированному блочному диску. Ремонт. Другие причины. Шаги по устранению:
Проверьте файлы журнала и трассировки, чтобы увидеть, есть ли какие-либо другие ошибки или ошибки позиционирования:
sql>select * from v$datafile, где file#=<F>;
sql> выберите владельца, имя_сегмента, тип_сегмента из dba_extents, где file_id=<F> и <B> между block_id и block_id+blocks-1;
На основе возвращенного типа_сегмента:
Тип сегмента является временным или кэшированным или не имеет возвращаемого значения. Проверьте правильность оператора SQL.
Если тип сегмента — сегмент отката, блок данных необходимо восстановить.
Тип сегмента — индексный, проверьте таблицу, в которой он расположен. Просто перестройте индекс.
sql> выберите владельца, имя_таблицы из dba_tables, где имя_кластера = имя_сегмента
Ошибка 1578 по-прежнему возникает, и базу данных необходимо восстановить.
Тип сегмента представляет собой таблицу и сохраняет данные в таблице.
Проанализируйте, имеет ли организация постоянное повреждение данных.
sql> проанализировать таблицу table.name проверить каскад структуры;
sql> проанализировать таблицу имя_кластера проверить каскад структуры;
База данных восстановления аппаратных ошибок, работающая в режиме АРХИВ.
OFFLINE соответствующий файл данных, копия резервного файла данных
переименуйте файл данных в новое место
восстановить файл данных с помощью архивного журнала
Онлайн-база данных файлов данных работает в режиме, отличном от АРХИВНОГО.
ОФЛАЙНСоответствующий файл данных копирует резервную копию файла данных, переименовывает файл данных и выводит его в онлайн-режим.
Сохраните данные в таблице, например: sql>select * from bigemp;
ОШИБКА: ORA-01578: блок данных ORACLE поврежден (файл № 8, блок № 8147) ORA-00110: файл данных 8: '/oracle/usr714.dbf' … … поврежденный идентификатор файла: 8 = 8 (шестнадцатеричный) поврежденный идентификатор блока : 8147=1fd3(hex) первый идентификатор строки в поврежденном блоке: 0000.1fd3.0000.0008 последний идентификатор строки в поврежденном блоке: 0000.1fd2.7fff.0008 первый идентификатор строки после этого блока: 0000.1fd4.0000.0008
sql > создать таблицу temp как select * from bigemp, где 1=2;
sql > вставить во временный выбор * from bigemp /*+rowid(bigemp) */ где rowid >='0000.1fd4.0000.0008';
sql > вставить во временный выбор * из bigemp, где rowid <='0000.1fd2.7fff.0008';
В версиях до ORACLE 7.1, когда сканирование диапазона строк не существует, той же цели, что и выше, можно достичь посредством индексации.
4. Постскриптум
Можно сказать, что технология резервного копирования и восстановления ORACLE обширна и глубока. Я знаю лишь небольшую ее часть, и я надеюсь, что эти статьи могут быть полезны всем. Вы также можете поделиться своим опытом резервного копирования. и восстановление. Расскажите мне о проблеме, я организую ее и опубликую здесь для справки всем друзьям-администраторам баз данных и администраторам данных, которые заинтересованы в этом. Возможно, ваши небольшие усилия спасут компанию!
В то же время я хотел бы напомнить всем своим друзьям, что резервное копирование очень, очень, очень, очень, очень, очень, очень, очень, очень важно. . . Главное, по возможности необходимо использовать режим АРХИВ, иначе что-то может пойти не так и вы даже заплакать не сможете.