Oracle DBA Forum  

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

Ответ
 
Опции темы Опции просмотра
  #21  
Старый 03.10.2009, 03:39
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Неполное восстановление и сигнальный файл



Неполное восстановление и сигнальный файл

Во время восстановления информация о выполнении хранится в сигнальном файле.
Этот файл необходимо всегда проверять до и после восстановления.

Например:


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



Точки восстановления

При создании обычной точки восстановления (normal restore point) задается имя для определенного момента времени или SCN. Оно служит в качестве закладки или псевдонима, которым можно воспользоваться в командах, распознающих фразу RESTORE POINT.

Перед выполнением операции, результаты которой, возможно, придется отменить, вы можете создать обычную точку восстановления. Имя точки восстановления и SCN записываются в управляющий файл. Если позднее, вам понадобиться сослаться на этот момент времени в команде RECOVER DATABASE, это можно будет сделать без указания временной метки или значения SCN.

При использовании таких возможностей, как Flashback Database, Flashback Table и восстановление на момент времени, можно ссылаться на целевое время с помощью имени точки восстановления, а не временного выражения или SCN. Определение обычной точки восстановления перед операцией, которая будет после завершения отменена, устраняет необходимость предварительной ручной записи SCN, а также поиск корректного SCN с помощью Flashback Query.

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

Примечание: использование точек восстановления в командах FLASHBACK рассматривается в уроке "Флэшбэк".
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #23  
Старый 03.10.2009, 03:41
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Неполное восстановление: указания



Неполное восстановление: указания

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

Это поможет в следующих случаях:

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

Примечание: Если резервирование всей базы данных не было выполнено, нужно, по крайней мере, выполнить архивирование текущего журнала:

Код:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT
и резервирование управляющего файла:
Код:
SQL> ALTER DATABASE BACKUP CONTROLFILE TO  '/uOl/data/backup.ctl';
Необходимо производить резервирование всей базы данных при закрытой базе данных после успешного восстановления. Резервная копия сэкономит много часов, если до следующего планового резервирования потребуется восстановление. При использовании базы данных Oracle 10g этот шаг стал необязателным.
Перед открытием системы для доступа пользователей необходимо убедиться, что в результате восстановления сбой был устранен, на случай, если восстановление завершится неудачно и потребуется его повторение.


Рассмотрим следующий прмер:

У базы данных при номере журнала 14 имеются архивные журналы с номерами от 2 (arch_2.rdo) до 13 (arch_l3.rdo) .
После выполнения неполного восстановления создается новая инкарнация базы данных, номер журнала устанавливается на 0.
Архивные журналы от arch_2 . rdo до archil 3 . rdo теперь являются частью старой инкарнации базы данных.
После нескольких переключений журнала архивный журнал arch_2.rdo будет перезаписан и будет заархивирован вместе со всеми остальными архивами (включая старые архивные журналы, начиная с arch_3 . rdo до arch_13 . rdo).
На более поздней стадии, если восстановление потребует архив arch 6.rdo, то потребуется архивный журнал, полученный путем восстановления из резервной копии, соответствующей правильной инкарнации базы данных, иначе произойдет ошибка.


Для предотвращения такого перемешивания архивных журналов используйте шаблон %r в параметре инициализации log archive_format.

Это:

приводит к автоматическому включению идентификатора сброса журналов (Resetlogs ID) в имена архивных журнальных файлов;
гарантирует уникальные имена архивных журналов в разных инкарнациях базы данных.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 03.10.2009 в 03:45.
Ответить с цитированием
  #24  
Старый 03.10.2009, 03:48
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Восстановление управляющего файла из автобэкапа



Восстановление управляющего файла из автобэкапа

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

Однако при использовании флэш-области восстановления RMAN неявно выполняет перекрестную проверку (crosscheck) резервных наборов и копий образов, перечисленных в управляющем файле, а также заносит (catalog) в извлеченный из бэкапа управляющий файл сведения об отсутствующих в нем файлах, которые он находит во флэш-области восстановления. В результате управляющий файл лучше подходит для восстановления остальной части базы данных.


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

Чтобы скопировать управляющий файл из автобэкапа, требуется перевести базу данных в состояние NOMOUNT, а затем выполнить команду RESTORE CONTROLFILE FROM AUTOBACKUP:


Код:
RMAN> SHUTDOWN IMMEDIATE; 
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;

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

Если каталог восстановления существует, тогда необязательно задавать DBID и использовать управляющий файл из автобэкапа для последующего восстановления.

Можно ввести команду RESTORE CONTROLFILE без параметров:

Код:
RMAN> RESTORE CONTROLFILE;

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


При потере SPFILE процедура его восстановления схожа с процедурой восстановления управляющего файла из автобэкапа. Сначала требуется задать DBID базы данных, а затем воспользоваться командой RESTORE SPFILE FROM AUTOBACKUP.

После запуска экземпляра с восстановленным файлом серверных параметров можно с помощью RMAN извлечь из автобэкапа управляющий файл. Затем смонтировать экземпляр с восстановленным управляющим файлом, в котором содержится информация, позволяющая выполнить операции restore и recover для базы данных.

После восстановления из бэкапа управляющих файлов необходимо выполнить полное восстановление после потери носителя, а затем открыть базу данных с опцией RESETLOGS.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #25  
Старый 03.10.2009, 03:50
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Создание нового управляющего файла



Создание нового управляющего файла

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

По команде ALTER DATABASE BACKUP CONTROLFILE TO TRACE генерируется пользовательский трассировочный файл, содержащий команды SQL для повторного создания управляющего файла. Скопируйте трассировочный файл в скрипт-файл, например, new_control.sql, удалите в нем заголовок с информацией о выполненной трассировке (до строки перед командой STARTUP NOMOUNT), а также внесите требуемые изменения, например, увеличьте значения параметров MAXDATAFILES, MAXLOGFILES и т.д. В этом файле два варианта скрипта для создания управляющего файла, отличающиеся опциями NORESETLOGS (сохранение старых оперативных журналов) и RESETLOGS (сброс и начало нумерации оперативных журналов с 1). Обычно выбирается первый вариант (до строки с комментарием начала второго варианта скрипта: Set #2. RESETLOGS case ).

Выполните скрипт, создающий новый управляющий файл. Для этого вы должны подсоединиться как пользователь с привилегиями SYSDBA к опущенной базе данных с правильно установленным параметром окружения ORACLE_SID, в котором задается имя запускаемого экземпляра.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #26  
Старый 03.10.2009, 03:51
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Создание нового управляющего файла (продолжение)



Создание нового управляющего файла (продолжение)

Database Control Console позволяет выполнять сопровождение управляющих файлов базы данных. На странице Administration выберите в секции Storage ссылку Control Files.

На странице Control Files General выводятся имена и места расположения зеркально сопровождаемых сервером Oracle копий управляющих файлов. Используйте кнопку Backup to Trace, чтобы создать трассировочный файл, содержащий скрипт для пересоздания управляющего файла.

Можно также самостоятельно написать команду CREATE CONTROLFILE, но при этом необходимо правильно указать:

полные имена и размеры оперативных журнальных файлов;
полные имена всех файлов данных базы данных, в том числе файлов табличных пространств SYSTEM и SYSAUX.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #27  
Старый 03.10.2009, 03:52
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Восстановление табличных пространств с доступом только на чтение



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

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

Табличные пространства 'только чтения' также защищают данные за прошлый период от изменений пользователей. Так как такие табличные пространства никогда не изменяются, их можно разместить на устройствах CD-ROM или WORM (write once, read many; однократная запись и многократное чтение).


Метод восстановления табличного пространства 'только чтения' зависит от того, какие резервные объекты доступны, а также от того, переводилось ли табличное пространство в состояние 'только чтения' или чтение-запись в рассматриваемом периоде.


Случай 1. Восстанавливаемое табличное пространство является доступным только на чтение, кроме того оно находилось в этом же состоянии при проведении последнего резервирования. В этом случае можно просто выполнить копирование табличного пространства из резервной копии. Нет необходимости в применении журнальной информации.

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


Случай 3. Восстанавливаемое табличное пространство является доступным только на чтение, но находилось в состоянии доступном на запись при проведении последнего резервирования. Так как всегда следует проводить резервирование табличного пространства после его перевода в состояние 'только чтения', такая ситуация не должна возникнуть. Тем не менее, если это случилось, нужно обязательно выполнить копирование табличного пространства из резервной копии и произвести его восстановление вплоть до момента времени, когда табличное пространство было переведено в состояние 'только чтения'.


Во всех трех случаях, когда недоступен текущий управляющий файл, звездочка означает, какой бэкап управляющего файла следует использовать для восстановления. Это необходимо, поскольку, когда используется бэкап управляющего файла, процесс восстановления требует открытия базы данных с параметром RESETLOGS. При таком открытии обновляются заголовки файлов данных, а писать в файлы данных в состоянии 'только чтение' нельзя.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #28  
Старый 03.10.2009, 03:56
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Вопросы восстановления табличных пространств с доступом только на чтение



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

Повторное создание управляющего файла

Если требуется заново создать управляющий файл по команде CREATE CONTROL FILE, а БД имеет табличные пространства с доступом только на чтение, нужно выполнить специальные действия. Поскольку табличное пространство находится в состоянии 'только чтение', в него не вносятся изменения и поэтому предполагается, что его не надо восстанавливать. Файлы такого табличного пространства не включаются в создаваемый управляющий файл. Вследствие этого, когда база данных запускается с новым управляющим файлом, производится перекрестная проверка с файлами, сведения о которых хранятся в словаре данных. Обнаруженные в словаре данных файлы, отсутствующие в управляющем файле, добавляются в управляющий файл с именами вида: MISSINGnnnnn.

После открытия базы данных такие файлы необходимо переименовать в управляющем файле, используя команду ALTER DATABASE RENAME FILE:


Код:
ALTER DATABASE RENAME FILE   'MISSING00005'
TO  '/uO1/арр/oracle/oradata/оrcl/example01.dbf';
ALTER TABLESPACE  "EXAMPLE" ONLINE;
Корпорация Oracle рекомендует включить в RMAN авторезервирование управляющего файла. Это устранит необходимость выполнения таких искусственных приемов при восстановлении управляющего файла, потребность в которых возникает, если резервирование было выполнено по команде ALTER DATABASE BACKUP CONTROLFILE TO TRACE.


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


Резервная копия управляющего файла
Операция восстановления с использованием фразы USING BACKUP CONTROLFILE при наличии табличного пространства 'только чтения' на носителе, доступном только на чтение, может отличаться низкой производительностью и сопровождаться ошибками.
Такая ситуация происходит, если в управляющем файле табличное пространство отражается как доступное на чтение-запись, так как таким оно было, когда выполнялось резервирование управляющего файла. В ходе операции восстановления после потери носителя будет сделана попытка записи в файлы табличного пространства. Для носителя, доступного только на чтение, база данных выдаст ошибку, в которой будет сообщено о невозможности записи в файлы.

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

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


Восстановление базы данных
Если файл в состоянии 'только чтение' в момент времени, к которому восстанавливается база данных, тогда RMAN не восстанавливает этот файл. Чтобы изменить такое функционирование и сделать так, чтобы RMAN проверил заголовки существующих в данное время файлов данных, задайте в команде RECOVER DATABASE опцию CHECK READONLY.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #29  
Старый 03.10.2009, 03:58
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию Итоги

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #30  
Старый 03.10.2009, 03:58
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,384
По умолчанию

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ
Опции темы
Опции просмотра

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

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

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


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


Powered by vBulletin®