Oracle DBA Forum  

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

Ответ
 
Опции темы Опции просмотра
  #11  
Старый 02.10.2009, 19:44
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Копия образа



Особенности копии образа

Копия образа представляет собой копию одного файла данных, архивного журнала или управляющего файла. Копия образа может быть создана по команде BACKUP AS COPY утилиты RMAN или с помощью команды операционной системы.

При создании копии образа по команде BACKUP AS COPY утилиты RMAN сеанс сервера проверяет блоки файла и помещает запись о полученной копии в управляющий файл.

Копирование образа характеризуется следующими особенностями:

Может производиться только на диск. Поэтому копирование больших файлов может занять длительное время, однако время восстановления (restore) сокращается, так как копии доступны на диске.
При хранении файлов на диске они могут использоваться немедленно (т.е. нет необходимости восстанавливать их с других носителей). Это обеспечивает быстрый способ восстановления посредством команды RMAN SWITCH, которая эквивалентна команде SQL ALTER DATABASE RENAME FILE.
Оно подобно резервированию средствами операционной системы, так как копирует все блоки вне зависимости от того, содержат они данные или нет. Но не полностью совпадает с ним, так как серверный процесс Oracle копирует файлы и осуществляет такие дополнительные действия, как проверка на повреждение блоков и регистрация копии в управляющем файле. Для ускорения процесса копирования можно использовать параметр NOCHECKSUM.
Может являться частью полного резервирования или резервирования с инкрементальным уровнем 0, так как копия файла содержит все его блоки. Если копия будет использоваться вместе с инкрементальным резервным набором, необходимо указать параметр "level 0".


Пример создания копии образа:

В примере, приведенном на слайде, создается две копии образов:

копия файла данных users01_db01. dbf под именем usersOl. dbf помещается в директорию /BACKUP ;
копия архивного журнала номер 1060.

В примере предполагается, что используется автоматическое выделение канала. Чтобы выделить канал вручную, включите команду COPY в выполняемый блок команды RUN:

__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 02.10.2009 в 19:46.
Ответить с цитированием
  #12  
Старый 02.10.2009, 19:50
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Тэги для резервных наборов и копий образов



Тэги для резервных наборов и копий образов

Тэгом (tag) является значимое имя, присваиваемое резервному набору или копии образа.

Преимуществами пользовательских тегов являются:

предоставление полезной ссылки на коллекцию копий файла или резервный набор;
может использоваться в команде LIST для простого поиска резервных файлов;
может использоваться в командах RESTORE и SWITCH;
один и тот же тег может использоваться для нескольких резервных наборов или копий файла.

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


Пример:

Полное резервирование файлов данных 1, 2, 3 и 4 осуществляется ежемесячно. Тег в управляющем файле для такого резервного набора monthly_f ull_backup (ежемесячноеполное_резерви рование), хотя для физического файла генерируется
имя df_DB00_8 63_l.dbf.

Код:
RMAN> BACKUP TAG  'month_full_backup'   DATAFILE 1,2,3,4;

Полное резервирование файлов данных 3 и 4 осуществляется еженедельно. Для него имя тэга - weekly_full_backup (еженедельное_полное_резер ирование).

Код:
RMAN> BACKUP TAG  'week_full_backup'   DATAFILE 3,4;
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #13  
Старый 02.10.2009, 19:53
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Опции команды BACKUP



Опции команды BACKUP

Во время операции резервирования процесс сервера Oracle вычисляет контрольную сумму каждого блока, чтобы обнаружить повреждения. RMAN проверяет контрольную сумму при восстановлении копии. Такие проверки принято называть обнаружением физических повреждения (physical corruption detection). Параметр NOCHECKSUM отключает режим проверки и увеличивает скорость процесса резервирования. Если в базе данных уже выполняется проверка на основе контрольной суммы, данный параметр не оказывает никакого действия

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

Максимальное число логических и физических повреждений может быть задано с помощью параметра MAXCORRUPT. До тех пор, пока сумма обнаруженных физических и логических повреждений ниже указанного значения, RMAN выполняет резервирование, и по его окончанию Oracle заполняет представление V$DATABASE_BLOCK_CORRUPTION данными об обнаруженных поврежденных блоках. Когда число поврежденных блоков достигает порогового значения, заданного во фразе MAXCORRUPT, процесс прекращается без заполнения представлений.

Можно использовать опцию VALIDATE для проверки наличия физических и логических ошибок в файлах базы данных. При использовании опции VALIDATE в команде BACKUP RMAN полностью просматривает заданные файлы и проверяет их содержимое, выявляя возможность резервирования файла. По этой команде на самом деле резервирование заданных файлов не выполняется.

Шифрование файлов, получаемых при резервировании , рассматривается в уроке "Безопасность базы данных".

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

Для выполнения дублирования резервных наборов используются следующие команды:

. BACKUP COPIES
. SET BACKUP COPIES
. CONFIGURE . . . BACKUP COPIES

RMAN не создает несколько резервных наборов, он создает идентичные копии каждого резервного фрагмента в наборе. Эту возможность нельзя использовать в команде BACKUP AS COPY для создания нескольких копий образов.

Параметр REUSE разрешает RMAN переписывать уже существующий резервный набор или копию образа с таким же именем файла, как и у создаваемого текущей командой
BACKUP.

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

Программа управления носителем (media manager) (а не RMAN) решает как и когда перемещать данные.

По команде BACKUP с опцией PROXY RMAN выполняет следующие шаги:

1. Ищет канал с заданным типом устройства и функциональными возможностями прокси. Если такой канал не найден, RMAN выдает предупреждение и пытается выполнить обычное (не прокси) резервирование заданных файлов.
2. При обнаружении канала с функциональными возможностями прокси RMAN вызывает программу управления носителем и проверяет, может ли она создать прокси-копии файлов. Если программа управления носителем не может выполнить прокси-копирование, тогда RMAN использует режим обычного резервирования файлов.

Чтобы RMAN не пытался выполнить обычное копирование в случае аварийного завершения прокси-копирования, задайте опцию ONLY.

Поскольку копии образов создаются только на диске, нельзя указывать опцию PROXY в команде BACKUP AS COPY.

Примечание: вместе с опцией PROXY в строке формата (параметр FORMAT) необходимо указывать переменную %р явно или неявно через переменную %U.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #14  
Старый 02.10.2009, 19:55
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Резервные наборы архивных журналов



Резервные наборы архивных журналов

Общей проблемой, с которой сталкиваются АБД, является отсутствие информации о завершении копирования архивного журнала в место хранения до начала его резервирования. Recovery Manager имеет доступ к управляющему файлу или информации в каталоге восстановления. Таким образом, известно, какой журнал архивирован и может быть скопирован из бэкапа для операции восстановления

Резервирование архивных журнальных файлов может быть выполнено по команде BACKUP ARCHIVELOG или вместе с резервированием файлов данных и управляющих файлов по команде BACKUP . . . PLUS ARCHIVELOG. Архивные журналы всегда заносятся в отдельный резервный набор, даже если используется фраза PLUS ARCHIVELOG (в этом случае создается несколько резервных наборов). Для резервирования определенных архивных журнальных файлов можно указать диапазон их номеров. Во всех случаях архивные журналы всегда размещаются в отдельных резервных наборах, не содержащих других файлов.

Дополнительно в команде BACKUP ARCHIVELOG можно использовать фразу NOT BACKED UP целое TIMES для того, чтобы зарезервировать только те журналы, которые не резервировались заданное целое число раз. Это обычный способ резервирования архивных журналов на заданном носителе (например, вам необходимо иметь три копии каждого журнала на ленте).

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

В примере, приведенном на слайде, все архивные журналы, начиная с 234, помещаются в резервный набор. После завершения копирования архивных журналов они удаляются с диска и помечаются как удаленные в представлении V$ARCHIVED_LOG.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #15  
Старый 02.10.2009, 19:57
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Копирование всей базы данных



Копирование всей базы данных

Recovery Manager позволяет простым образом получать копии образов всех файлов базы данных. Дополнительно можно скопировать SPFILE и архивные журналы. Для этого надо смонтировать базу данных, запустить RMAN и ввести команду BACKUP, показанную на слайде.

Однако такое возможно, когда до этого уже были выполнены следующие команды CONFIGURE:

CONFIGURE DEFAULT DEVICE TYPE TO disk;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
CONFIGURE CONTROLFILE AUTOBACKUP ON;

Можно также создать бэкап (резервный набор или копии образов), полученный в результате резервирования созданных ранее копий образов всех файлов данных и управляющих файлов базы данных:

Код:
RMAN> BACKUP COPY OF DATABASE;
По умолчанию RMAN выполняет каждую команду BACKUP последовательно. Но операцию можно распараллелить, когда:

была выполнена команда CONFIGURE DEVICE TYPE DISK PARALLELISM n, где n - требуемый уровень параллелизма;
выделено несколько каналов;
одна команда BACKUP AS COPY используется для нескольких файлов.

Примечание: Высокая степень распараллеливания приводит к потреблению большего количества машинных ресурсов, но при этом выполнение команды может происходить быстрее.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #16  
Старый 02.10.2009, 20:00
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Типы резервирования в RMAN



Типы резервирования в RMAN

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


Инкрементальное резервирование
Инкрементальный бэкап (incremental backup) может быть либо уровня 0 (тогда в него включаются все блоки файла данных, кроме тех, которые никогда не использовались), либо уровня 1 (в него включаются только блоки, измененные с момента предыдущего резервирования). Инкрементальный бэкап на уровне 0 физически схож с полным бэкапом. Единственное отличие в том, что бэкап на уровне 0 может использоваться в качестве базы для резервирования на уровне 1, а полный бэкап - нет.
Инкрементальное резервирование определяется в команде BACKUP с помощью ключевого слова INCREMENTAL. Пользователь задает INCREMENTAL LEVEL =[0 | 1].



В RMAN могут быть созданы многоуровневые инкрементальные бэкапы:

Дифференциальный (Differential).
Действующий по умолчанию режим инкрементального резервирования, при котором копируются все блоки, измененные после самого последнего инкрементального резервирования либо на уровне 1, либо на уровне 0.
Кумулятивный (Cumulative)
Резервируются все блоки, измененные после самого последнего резервирования на уровне 0.


Примеры:
Для инкрементального резервирования на уровне 0 используйте команду:

Код:
RMAN> BACKUP INCREMENTAL LEVEL 0  DATABASE;
Чтобы выполнить дифференциальное инкрементальное резервирование, введите команду:

Код:
RMAN> BACKUP INCREMENTAL LEVEL  1  DATABASE;
Чтобы выполнить кумулятивное инкрементальное резервирование, введите команду:

Код:
RMAN> BACKUP  INCREMENTAL LEVEL  1  CUMULATIVE  DATABASE;

RMAN по умолчанию выполняет полное резервирование, если не указаны ни опция FULL, ни INCREMENTAL. При этом в процессе резервирования и копирования файлов данных в наборы пропускаются блоки, в которые никогда ничего не писалось (сжатие неиспользуемых блоков - unused block compression). Так происходит даже при полном резервировании.


Полное резервирование не оказывает влияния на последующее инкрементальное резервирование и не рассматривается как часть инкрементальной стратегии, хотя полная копия образа может быть инкрементально обновлена путем применения инкрементальных бэкапов по команде RECOVER (это будет рассмотрено далее в этом уроке).
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 04.03.2010 в 08:52.
Ответить с цитированием
  #17  
Старый 02.10.2009, 20:01
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Выбор между дифференциальным и кумулятивным резервированием



Выбор между дифференциальным и кумулятивным резервированием

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

Сравнение инкрементального и кумулятивного резервирования:

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

На представленном графике показана стратегия резервирования компании, основанная на инкрементальном и кумулятивном резервирование. Каждое воскресенье выполняется инкрементальное резервирование уровня 0. Дважды в неделю (в среду и пятницу) производится кумулятивное резервирования с целью снижения времени восстановления БД. В остальные дни выполняется инкрементальное резервирование, чтобы уменьшить время, необходимое для резервирования, и требования к пространству хранения.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #18  
Старый 02.10.2009, 20:03
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Отслеживание измененных блоков



Отслеживание измененных блоков

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

Фоновый процесс записи отслеживаемых изменений (change tracking writer - CTWR) заносит информацию о физическом расположении всех изменений, сделанных в базе данных, в файл нового типа, называемый файлом отслеживания изменений (change tracking file). После включения возможности отслеживания изменений первое инкрементальное резервирование уровня 0 все же вызывает полный просмотр всего файла данных, так как в файле для отслеживания изменений еще не отражается статус блоков.

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

Его размер пропорционален:

размеру БД и количеству включенных потоков (threads) в среде RAC;
числу старых резервных объектов, сопровождаемых с помощью такого файла.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #19  
Старый 02.10.2009, 20:04
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Включение отслеживания измененных блоков



Включение отслеживания измененных блоков

Возможность отслеживания измененных блоков включается в Enterprise Manager (ЕМ) на странице Maintenance. Щелкните на ссылке Backup Settings, а затем на закладке Policy.
Чтобы сохранить установки резервирования, необходимо ввести имя пользователя и пароль для аутентификации на уровне ОС.

Минимальный размер файла для отслеживания изменений - 10 Мб и новое пространство выделяется с шагом 10 Мб. Не требуется указывать имя этого файла, когда задан параметр инициализации db_createf ile_dest; в этом случае создается файл, сопровождаемый сервером Oracle.

Для ручного конфигурирования быстрого инкрементального резервирования используются команды:

Код:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING; 
SQL> ALTER DATABASE DISABLE 3L0CK CHANGE TRACKING;

Если параметр db_create_file_dest не установлен, используйте фразу USING FILE, чтобы задать местоположение и имя файла для отслеживания изменений.

Представление V$BLOCK_CHANGE_TRACKING содержит текущие характеристики конфигурации функциональной возможности отслеживания измененных блоков.

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



Инкрементально-обновляемые резервные копии

Функциональная возможность инкрементально-обновляемые резервные копии (Incrementally Updated Backup) позволяет, используя RMAN, применять файлы, полученные в результате инкрементального резервирования, к копиям образов файлов данных. С помощью такого метода RMAN подкатывает вперед копию образа к определенному моменту времени (восстанавливает копию файла данных ). В копию вносятся все изменения, сделанные до момента, определяемого системным номером (SCN), при котором был получен инкрементальный бэкап.

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

Две различные команды используются с инкрементально-обновляемыми бэкапами:

Команда BACKUP INCREMENTAL LEVEL 1. . . FOR RECOVER OF COPY WITH TAG . . . создает инкрементальные резервные наборы, которые можно инкрементально обновить с помощью команды BACKUP. Если не существует инкрементальный резервный объект на уровне 0, он создается по этой команде с заданным тегом.
По команде RECOVER COPY . . .WITH TAG К множеству копий образов с заданным тегом применяются инкрементальные резервные объекты. При отсутствии копий файлов данных или инкрементальных резервных объектов команда выдает сообщение, но не генерирует ошибку.

Теги необходимо использовать для идентификации инкрементальных резервных объектов и копий файлов данных, к которым применяется рассматриваемая стратегия восстановления, так чтобы не было пересечений с другими стратегиями резервирования.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ

Метки
recovery manager, rman
Опции темы
Опции просмотра

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

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

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


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


Powered by vBulletin®