4-10. Создание сжатых резервных наборов по умолчанию

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

RMAN> configure device type disk backup type to compressed backupset;

using target database control file instead of recovery catalog
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
new RMAN configuration parameters are successfully stored

И на ленту:

RMAN> configure device type sbt backup type to compressed backupset;

new RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
new RMAN configuration parameters are successfully stored

Для того чтобы вернуться к несжатому резервному набору по умолчанию, достаточно в вышеприведённых командах опустить ключевое слово compressed:

RMAN> configure device type disk backup type to backupset;

old RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET PARALLELISM 1;
new RMAN configuration parameters are successfully stored

RMAN использует бинарное сжатие для резервных сжатых наборов. Это позволяет уменьшить передаваемый трафик по сети в момент резервного копирования. К тому же, когда идёт восстановление из сжатого резервного набора, нет необходимости предварительно распаковывать его, всё происходит на «лету». Это сильно экономит время, в отличии от упаковщиков операционной системы.

Для версии Oracle 11G функция сжатия не ограничивается использованием только одного алгоритма. Можно запросить представление V$RMAN_COMPRESSION_ALGORITHM для просмотра доступных алгоритмов сжатия:

SQL> select algorithm_name, algorithm_description, is_default from 
v$rman_compression_algorithm;
 
ALGORITHM_NAME ALGORITHM_DESCRIPTION                       IS_DEFAULT
-------------- ------------------------------------------- ----------
BZIP2          good compression ratio                      NO        
BASIC          good compression ratio                      YES       
LOW            maximum possible compression speed          NO        
ZLIB           balance between speed and compression ratio NO        
MEDIUM         balance between speed and compression ratio NO        
HIGH           maximum possible compression ratio          NO   

Как видно, алгоритм BZIP2 обеспечивает хорошее сжатие но меньшую скорость. В то же время алгоритм ZLIB обеспечиватет баланс между скоростью и сжатием.

Посмотреть используемый текущий алгоритм сжатия можно с помощью следующей команды:

RMAN> show compression algorithm;

RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE 
; # default

В версии 11.2 это базовый алгоритм BASIC не требующий опции Advanced Compression.

4-11. Конфигурация множественных резервных копий

В процессе резервного копирования, RMAN создаёт на одном устройстве части резервного набора в единственном экземпляре. Это режим по умолчанию. Однако в RMAN имеется возможность записи частей резервного набора сразу в несколько копий.

Следующая команда определяет, что при резервном копировании (архивные журналы, файлы данных, контрольные файлы) на диск должны быть сделаны две копии частей резервного набора: RMAN> configure datafile backup copies for device type disk to 2;

new RMAN configuration parameters:
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
new RMAN configuration parameters are successfully stored 

RMAN> configure archivelog backup copies for device type disk to 2;

new RMAN configuration parameters:
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
new RMAN configuration parameters are successfully stored

То же самое можно определить и для резервного копирования на ленту:

RMAN> configure datafile backup copies for device type sbt to 2;

new RMAN configuration parameters:
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE 'SBT_TAPE' TO 2;
new RMAN configuration parameters are successfully stored

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

RMAN> configure channel device type disk format '/backup1/%U','/backup2/%U';

new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/backup1/%U',   '/backup2/%U';
new RMAN configuration parameters are successfully stored

Выполним резервное копирование:

RMAN> backup database;

Starting backup at 06-JAN-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u02/oradata/orcl/system01.dbf
input datafile file number=00002 name=/u02/oradata/orcl/sysaux01.dbf
input datafile file number=00005 name=/u02/oradata/orcl/example01.dbf
input datafile file number=00003 name=/u02/oradata/orcl/undotbs01.dbf
input datafile file number=00004 name=/u02/oradata/orcl/users01.dbf
channel ORA_DISK_1: starting piece 1 at 06-JAN-13
channel ORA_DISK_1: finished piece 1 at 06-JAN-13 with 2 copies and tag 
TAG20130106T210251
piece handle=/backup1/04nuovbr_1_1 comment=NONE
piece handle=/backup2/04nuovbr_1_2 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:56
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 06-JAN-13
channel ORA_DISK_1: finished piece 1 at 06-JAN-13 with 2 copies and tag 
TAG20130106T210251
piece handle=/backup1/05nuovdj_1_1 comment=NONE
piece handle=/backup2/05nuovdj_1_2 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 06-JAN-13

Как видно, при выполнении команды BACKUP вначале были получены две копии первого резервного набора. Одна копия была помещена в каталог /backup1, вторая в /backup2. Затем были получены две копии второй резервного набора, которые были помещены в те же каталоги.

Для ленточного канала, если поддерживается версия 2 SBT API, RMAN автоматически поместит каждую копию на отдельную ленту.


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


Множественные резервные копии можно получить только из резервных наборов. Нельзя получить множественные копии сразу для нескольких копий-отображения. Для начала надо создать одну копию-отображение, и только лишь потом из неё можно будет сделать сразу несколько копий.


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

Для файлов данных:

RMAN> show datafile backup copies;

RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE 'SBT_TAPE' TO 2;

Для архивных журнальных файлов:

RMAN> show archivelog backup copies;

RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default

4-12. Пропуск ранее скопированных в файлов

Резервное копирование большой по объёму базы данных может занимать довольно значительное время. Если имеются ранее сделанные резервные копии файлов данных, то этот промежуток времени можно сильно сократить, осуществив пропуск этих файлов в процессе резервного копирования. Реализацию этого механизма в RMAN организует функция оптимизации резервного копирования (backup optimization). По умолчанию она выключена. Её включение осуществляется следующей командой:

RMAN> configure backup optimization on;

new RMAN configuration parameters:
CONFIGURE BACKUP OPTIMIZATION ON;
new RMAN configuration parameters are successfully stored

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

  • Должны выполняться команды BACKUP DATABASE и BACKUP ARCHIVELOG с опциями ALL или LIKE, BACKUP BACKUPSET с опцией ALL, BACKUP RECOVERY AREA, BACKUP RECOVERY FILES и BACKUP DATAFILECOPY.
  • Все каналы для команд резервного копирования должны иметь один и тот же тип.

Для примера, выполним резервное копирование архивных журнальных файлов:

RMAN> backup archivelog all;

Starting backup at 12-MAR-13
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=20 RECID=14 STAMP=809884374
input archived log thread=1 sequence=21 RECID=15 STAMP=809884377
input archived log thread=1 sequence=22 RECID=16 STAMP=809884398
channel ORA_DISK_1: starting piece 1 at 12-MAR-13
channel ORA_DISK_1: finished piece 1 at 12-MAR-13
piece 
handle=/u01/app/oracle/fast_recovery_area/ORCL/backupset/2013_03_12/o1_mf_annnn_TAG201
30312T155318_8my5sgsp_.bkp tag=TAG20130312T155318 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-MAR-13

Было скопировано три файла с sequence от 20 до 21. Переключим несколько раз текущий журнал и снова выполним ту же команду:

SQL> alter system archive log current;

System altered.

SQL> alter system archive log current;

System altered.

RMAN> backup archivelog all;

Starting backup at 12-MAR-13
current log archived
using channel ORA_DISK_1
skipping archived logs of thread 1 from sequence 20 to 22; already backed up
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=23 RECID=17 STAMP=809884497
input archived log thread=1 sequence=24 RECID=18 STAMP=809884501
input archived log thread=1 sequence=25 RECID=19 STAMP=809884569
channel ORA_DISK_1: starting piece 1 at 12-MAR-13
channel ORA_DISK_1: finished piece 1 at 12-MAR-13
piece 
handle=/u01/app/oracle/fast_recovery_area/ORCL/backupset/2013_03_12/o1_mf_annnn_TAG201
30312T155609_8my5ysxl_.bkp tag=TAG20130312T155609 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-MAR-13

Как видно, RMAN пропустил сохранённые ранее в другом наборе архивные журналы с sequence от 20 до 22, и добавил новые с sequence от 23 до 25.

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

RMAN> backup archivelog all force;

Starting backup at 12-MAR-13
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=20 RECID=14 STAMP=809884374
input archived log thread=1 sequence=21 RECID=15 STAMP=809884377
input archived log thread=1 sequence=22 RECID=16 STAMP=809884398
input archived log thread=1 sequence=23 RECID=17 STAMP=809884497
input archived log thread=1 sequence=24 RECID=18 STAMP=809884501
input archived log thread=1 sequence=25 RECID=19 STAMP=809884569
input archived log thread=1 sequence=26 RECID=20 STAMP=809884861
channel ORA_DISK_1: starting piece 1 at 12-MAR-13
channel ORA_DISK_1: finished piece 1 at 12-MAR-13
piece 
handle=/u01/app/oracle/fast_recovery_area/ORCL/backupset/2013_03_12/o1_mf_annnn_TAG201
30312T160102_8my67y6x_.bkp tag=TAG20130312T160102 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-MAR-13

В данном примере RMAN осуществил полное резервное копирование всех журналов с sequence от 20 до 26, несмотря на то, что оптимизация включена в настройках RMAN.

RMAN использует определенные правила для каждого типа пропускаемого файла, чтобы определить, идентичен ли текущий файл ранее скопированной версии. Например, у файла данных должны быть тот же самый DBID и контрольная точка SCN. Точно так же у архивных журналов должны быть равны DBID, номер потока и порядковый номер. У резервного набора должны быть равны ID записи и штамп.

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

Файлы данных

  • Если используется политика сохранения на основе окна, то тип резервных носителей определяет, пропустит ли RMAN файл данных. Если резервное копирование осуществляется на ленту и последняя резервная копия является более старой чем сконфигурированное окно восстановления, RMAN сделает резервное копирование, даже не смотря на то, что файл будет идентичен. Таким образом, RMAN игнорирует настроенную политику оптимизации. Если резервное копирование будет осуществляться на диск, то если имеется идентичная резервная копия, файл будет пропущен, даже несмотря на то, что последняя копия будет старее окна восстановления. Поясним это на примере. Допустим, имеется копия табличного пространства только для чтения, сделанная две недели назад. По идее оно не должно меняться. Определено окно сохранения длительностью 7 дней. Если делается резервное копирование на ленту, то RMAN сделает копию, несмотря на то, что файлы не изменились. Если резервирование будет осуществляться на диск, то резервирование файлов будет пропущено, даже несмотря на то, что копия явно старее определённого окна сохранения.

  • Если будет использоваться политика сохранения, основанная на избыточности (например, избыточность равна r), то RMAN пропустит копирование файла, если n (определённое как r + 1) копий этого файла будут существовать на указанном устройстве.

  • Если политики сохранения нет, RMAN пропустит резервное копирование файла, если n число копий это файла существует на указанном устройстве. RMAN определяет значение n в порядке следующего приоритета:

    1. Число резервных копий при использовании команды BACKUP ... COPIES n
    2. Число резервных копий при использовании команды SET BACKUP COPIES n
    3. Число резервных копий при использовании КОМАНДЫ CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE ... TO n
    4. n=1

Архивные журналы

В случае архивных журналов RMAN определит значение n в порядке следующего приоритета:

  1. Число резервных копий при использовании команды BACKUP ... COPIES n
  2. Число резервных копий при использовании команды SET BACKUP COPIES n
  3. Число резервных копий при использовании команды CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE ... TO n
  4. n=1

Резервные наборы

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

  1. Число резервных копий при использовании команды BACKUP ... COPIES n
  2. Число резервных копий при использовании команды SET BACKUP COPIES n
  3. n=1

Чтобы два резервный комплекта в режиме оптимизации считались идентичным, у них должны соответствовать ID записи и штамп.

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

4-13. Определение имен файлов частей резервных копий

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

RMAN> backup tablespace users format = '/backup/users_%u%p%c';

Starting backup at 30-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00004 name=/u02/oradata/orcl/users01.dbf
channel ORA_DISK_1: starting piece 1 at 30-MAY-13
channel ORA_DISK_1: finished piece 1 at 30-MAY-13
piece handle=/backup/users_23oauglb11 tag=TAG20130530T144354 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 30-MAY-13

[oracle@ora11g ~]$ cd /backup
[oracle@ora11g backup]$ ls 
users_23oauglb11

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

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

4-14. Определение имен файлов для копий-отображения

Кроме задания имен файлов резервных частей, в RMAN можно так же изменять и имена файлов копий-отображения. Делается это всё с помощью той же опции format. Синтаксис опции аналогичен синтаксису, задаваемому для резервных частей, но есть небольшие различия, касающиеся переменных замены. Формат по умолчанию %U отображается по разному для копий- отображения файлов данных, архивных журналов и контрольных файлов. Следующая таблица демонстрирует это:

Тип файлаЗначение %U
Файл данных data-D-%d_id-%I_TS-%N_FNO-%f_%u
Архивные файлы arch-D_%d-id-%I_S-%e_T-%h_A-%a_%u
Контрольные файлы cf-D_%d-id-%I_%u

В команде можно определить до четырех строк опции формата, но со второго по четвёртое значение они используются, если делаются множественные резервные копии. Таким образом, вторые, третьи, и четвертые значения опций формата используются, когда выполняются команды backup copies, set backup copies или configure ... backup copies.

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

RMAN> backup as copy
2> db_file_name_convert=('/u02/oradata/orcl/users','/backup/users_ts')
3> tablespace users;

Starting backup at 30-MAY-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=/u02/oradata/orcl/users01.dbf
output file name=/backup/users_ts01.dbf tag=TAG20130530T144953 RECID=5 
STAMP=816792594
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 30-MAY-13

Как видно, при копировании табличного пространства users, из файла /u02/oradata/orcl/users01.dbf, на который ссылался первый префикс опции db_file_name_convert, была получена копия- отображение с именем указанным во втором префиксе.

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

RMAN> backup as copy
2> db_file_name_convert=('/u02/oradata/orcl/users','/backup1/users_ts',
3> '/u02/oradata/orcl/example','/backup2/example_ts')
4> tablespace users, example;

Starting backup at 30-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00005 name=/u02/oradata/orcl/example01.dbf
output file name=/backup2/example_ts01.dbf tag=TAG20130530T151225 RECID=6 
STAMP=816793959
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=/u02/oradata/orcl/users01.dbf
output file name=/backup1/users_ts01.dbf tag=TAG20130530T151225 RECID=7 
STAMP=816793960
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 30-MAY-13

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