Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Oracle University Official Study Notes (RUS) > База данных Oracle 10g Администрирование > База данных Oracle 10g Администрирование I

Ответ
 
Опции темы Опции просмотра
  #1  
Старый 26.09.2009, 22:04
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию 16 Восстановление базы данных

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #2  
Старый 26.09.2009, 22:05
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Рассматриваемые вопросы

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #3  
Старый 26.09.2009, 22:08
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Открытие базы данных



Открытие базы данных

На каждом шаге перехода базы данных из остановленного (shutdown) состояния к полностью открытому проверяется внутренняя согласованность.

NOMOUNT
Для того, чтобы перейти в состояние NOMOUNT (также называемое STARTED), экземпляр должен прочитать файл параметров инициализации. Никакой проверки файлов данных при достижении состояния NOMOUNT не производится.

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

OPEN
При переходе из состояния MOUNT в состояние OPEN:

- Проверяется, что во всех, указанных в управляющем файле журнальных группах, присутствует хотя бы один элемент. Сообщение о всех потерянных журнальных файлах записывается в сигнальный файл.
- Проверяется присутствие всех файлов данных, находящихся в оперативном состоянии. Автономные файлы проверяются только при выполнении перевода в оперативное состояние. При смонтированной базе данных администратор может перевести любой файл данных, не принадлежащий табличным пространствам SYSTEM и UNDO, в автономное состояние и затем открыть базу данных. При попытке открыть базу данных, когда какие-то файлы потеряны, возвращается сообщение об ошибке, содержащее имя первого такого файлы, а экземпляр остается в состоянии MOUNT. Чтобы выяснить, какие файлы необходимо восстановить, запросите динамическое представление производительности v$recover_flie:



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

Код:
ORA-01113:  file 4 needs media recovery
ORA-01110: data file 4:   '/oracle/oradata/orcl/usersOl.dbf'
Представление v$recover_file показывает полный перечень файлов, которые необходимо восстановить. При этом в столбце ERROR не выводится сообщение об ошибке, когда файл существует, но не синхронизирован с управляющим файлом.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #4  
Старый 26.09.2009, 22:09
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Изменение состояния экземпляра



Изменение состояния экземпляра

По умолчанию экземпляр стартует в режиме OPEN. Экземпляр можно запустить в других режимах, например, для того, чтобы решить проблемы базы данных. В окне Advanced Startup Options предоставляется возможность выбора состояния экземпляра при запуске или переходе экземпляра из одного состояния в другое. Изменить состояние экземпляра можно также вручную, используя команды SQL :


__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #5  
Старый 26.09.2009, 22:10
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Поддержка открытого состояния базы данных



Поддержка открытого состояния базы данных

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

Во многих случаях после сбоя экземпляр полностью не останавливается, но не в состоянии продолжить работу. Восстановление в таких случаях следует начать с остановки базы данных по команде SHUTDOWN ABORT.

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

Ошибки, возникающие в таких ситуациях, можно найти в сигнальном файле.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #6  
Старый 26.09.2009, 22:11
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Потеря управляющего файла



Потеря управляющего файла

Восстановление после потери управляющего файла (пока остается целым хотя бы одна его копия) можно произвести следующим образом:

1. Если экземпляр еще аварийно не остановился, выполните команду SHUTDOWN ABORT.
2. Скопируйте один из оставшихся управляющих файлов на место, в котором располагался потерянный файл. Если причина сбоя носителя в повреждении дисковода или контроллера, скопируйте один из оставшихся управляющих файлов на новое место и отразите это в файле параметров инициализации. В крайнем случае можно просто удалить ссылку на потерянный управляющий файл в параметре инициализации. Однако Oracle рекомендует иметь хотя бы два используемых управляющих файла.
3. Запустите экземпляр.


Восстановление после потери всех управляющих файлов рассматривается в курсе Oracle Database IOg: Администрирование II.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #7  
Старый 26.09.2009, 22:12
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Потеря журнального файла



Потеря журнального файла

Восстановление после потери одного члена журнальной группы не влияет на работу экземпляра.

1. Определите, какой файл утерян, просмотрев для этого сигнальный файл.
2. Восстановите потерянный файл путем копирования одного из оставшихся файлов той же самой группы.
3. Если причина сбоя носителя в повреждении дисковода или контроллера, переименуйте потерянный файл.
4. Если журнальная группа уже заархивирована или же БД в режиме noarchivelog, можно решить проблему, выполнив очистку журнальной группы, в результате чего воссоздается потерянный файл или файлы. В ЕМ выберите необходимую группу и операцию Clear Logfile (как показано на слайде). Вручную это же действие можно выполнить по команде :

Код:
SQL> ALTER DATABASE CLEAR LOGFILE GROUP <номер группы>;
Примечание: Database Control не позволит очистить еще незаархивированную группу. Такое действие разрывает цепочку журналов. Если же это необходимо, то сразу же после этого требуется выполнить полное резервирование всей базы данных. Иначе после следующего сбоя будут потеряны данные. Чтобы очистить незаархивированную группу, выполните команду:

Код:
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP <номер группы>;
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #8  
Старый 26.09.2009, 22:13
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Потеря файла данных в режиме NOARCHIVELOG



Потеря файла данных в режиме NOARCHIVELOG

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


Для базы данных в режиме NOARCHIVELOG восстановление возможно только на момент времени последнего резервирования. Поэтому пользователи должны повторить все изменения, сделанные ими с момента резервирования.

1. Остановите экземпляр, если он еще не остановлен.
2. Щелкните на ссылке Perform Recovery, находящейся на странице Maintenance.
3. Выберите вид восстановления "Whole Database".
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #9  
Старый 26.09.2009, 22:14
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Потеря несущественного файла данных в режиме ARCHIVELOG



Потеря несущественного файла данных в режиме ARCHIVELOG

Для базы данных в режиме ARCHIVELOG потеря любого ее файла данных, не принадлежащего к табличным пространствам SYSTEM и UNDO, повлияет только на объекты, хранимые в потерянном файле. Остальная часть базы данных останется доступной для пользователей, продолжающих работать.

Чтобы восстановить потерянный файл:

1. Щелкните на ссылке Perform Recovery, находящейся на странице Maintenance.
2. Выберите вид восстановления "Datafiles" и "Restore to current time".
3. Добавьте все файлы, которые необходимо восстановить.
4. Укажите, куда должны быть скопированы из резерва файлы: на старое место или на новое (в случае потери диска или контроллера).
5. Передайте на выполнение работу утилиты RMAN по копированию из резерва и восстановлению потерянных файлов.

Так как база данных в режиме ARCHIVELOG, возможно восстановление до момента последней фиксации и пользователям не нужно будет повторно вводить данные.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #10  
Старый 26.09.2009, 22:15
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Потеря важного для системы файла данных



Потеря важного для системы файла данных

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

1. Остановите экземпляр, если он еще не остановлен.
2. Смонтируйте базу данных.
3. Щелкните на ссылке Perform Recovery, находящейся на странице Maintenance.
4. Выберите вид восстановления "Datafiles" и "Restore to current time."
5. Добавьте все файлы, которые необходимо восстановить.
6. Укажите, куда должны быть скопированы из резерва файлы: на старое место или на новое (в случае потери диска или контроллера).
7. Передайте на выполнение работу утилиты RMAN по копированию из резерва и восстановлению потерянных файлов.
8. Откройте базу данных. Пользователям не требуется повторно вводить данные, так как восстановление было произведено до момента последней фиксации.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 17:08. Часовой пояс GMT +3.


Powered by vBulletin®