Оптимизация процесса дублирования

Рассмотренный выше процесс дублирования у нас начинался с создания резервной копии целевой базы данных на хосте alfa.alldba.ru. При больших объёмах данных действие этот очень длительное, и может продолжаться несколько часов. Не меньше времени будет тратится и на дальнейший перенос резервной копии и журнальных файлов на сервер, где будет развёрнута дублированная база. К тому же, резервная копия, создаваемая для дублирования, может занимать значительное место на хосте целевой базы данных, а сам процесс создания дублированной базы данных может быть сильно растянут по времени.

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

Создание резервной копии на удалённом хосте

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

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

На самом деле такая возможность бывает не всегда. Поэтому, существует ещё один путь – это использование NFS. Суть его заключается в том, что на хосте целевой базы данных монтируется удалённый каталог хоста, на котором будет развёрнута дублированная база данных. В этот каталог с помощью RMAN пишется резервная копия целевой базы данных. Затем, из этой копии производится создание дублированной базы данных. В результате, мы объединяем два последовательных действия в одно, делая не нужным  ручной перенос резервной копии на другой хост.

Рассмотрим этот метод подробнее на примере. Для краткости, хост alfa.alldba.ru, на котором у нас располагается целевая база данных, будем называть локальным, а хост alfa2.alldba.ru вспомогательного экземпляра, удалённым. Первое, что нам надо сделать, это стартовать на обоих хостах службу netfs. Если службы NFS уже стартованы, то следующим шагом будет создание  удалённого каталога. Каталог будет иметь у нас имя export и располагаться по пути /mnt.

Для начала, войдём в систему как пользователь root:

[oracle@alfa2 /]$ su -
Пароль: 

Создадим указанный каталог export, сменим его владельца,  и предоставим каталогу все необходимые привилегии:

[root@alfa2 ~]# mkdir /mnt/export
[root@alfa2 ~]# chown -R oracle:oinstall /mnt/export
[root@alfa2 ~]# chmod -R 775 /mnt/export
[root@alfa2 /]# ls -l /mnt | grep export
drwxrwxr-x   2 oracle oinstall  4096 Мар  6 04:57 export

Тоже самое сделаем и на локальном хосте:

[root@alfa ~]# mkdir /mnt/export
[root@alfa ~]# chown -R oracle:oinstall /mnt/export
[root@alfa ~]# chmod -R 775 /mnt/export

Удалённый каталог создан. Теперь, выдадим разрешение на подключение к этому каталогу локальному хосту alfa.alldba.ru. Для этого внесём в файл /etc/exports на удалённом хосте следующую строчку:

[oracle@alfa2 ~]$ more /etc/exports
/mnt/export alfa.alldba.ru(rw)

Далее, смонтируем удалённый каталог, выполнив на локальном хосте команду mount со следующими опциями:

[root@alfa ~]# mount -t nfs -o hard,rw,rsize=32768,wsize=32768 
alfa2.alldba.ru:/mnt/export /mnt/export

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

ORA-19504: failed to create file "/mnt/export/backup_6fn58tc4_1_1.bkp"
ORA-27054: NFS file system where the file is created or resides is not mounted with 
correct options

Указываем  правильные опции и монтируем удалённый каталог.  Как видно из отчёта команды df, в нашем случае, всё прошло удачно:

[root@alfa ~]# df -h
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/mapper/VolGroup00-LogVol00
                      8,6G  5,2G  3,1G  64% /
/dev/sda1              99M   12M   82M  13% /boot
tmpfs                 506M     0  506M   0% /dev/shm
.host:/                75G   67G  8,1G  90% /mnt/hgfs
alfa2.alldba.ru:/mnt/export
                      8,6G  6,2G  2,0G  76% /mnt/export

Теперь необходимо выполнить резервное копирование целевой базы данных. Главным отличием этого копирования будет то, что резервная копия будет создаваться в удалённом каталоге хоста alfa2.alldba.ru. Чтобы изменить расположение файла резервной копии по умолчанию, используем опцию format команды backup database. В опции укажем путь к удалённому каталогу вместе с маской имени файла резервного набора.  Теперь, по команде backup database, RMAN должен создать в  указанном удалённом каталоге два резервных набора:

RMAN> backup database format=’/mnt/export/backup_%U.bkp’;
Starting backup at 07-MAR-12
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u02/oradata/orcl/system01.dbf
input datafile fno=00003 name=/u02/oradata/orcl/sysaux01.dbf
input datafile fno=00002 name=/u02/oradata/orcl/undotbs01.dbf
input datafile fno=00005 name=/u02/oradata/orcl/example01.dbf
input datafile fno=00004 name=/u02/oradata/orcl/users01.dbf
channel ORA_DISK_1: starting piece 1 at 07-MAR-12
channel ORA_DISK_1: finished piece 1 at 07-MAR-12
piece handle=/mnt/export/backup_6mn59518_1_1.bkp tag=TAG20120307T111448 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:17:44
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 07-MAR-12
channel ORA_DISK_1: finished piece 1 at 07-MAR-12
piece handle=/mnt/export/backup_6nn5962g_1_1.bkp tag=TAG20120307T111448 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:28
Finished backup at 07-MAR-12

Выведем отчёт RMAN по созданным резервным копиям:

RMAN> list backup;
List of Backup Sets
===================
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
115     Full    592.59M    DISK        00:17:42     07-MAR-12      
        BP Key: 126   Status: AVAILABLE  Compressed: NO  Tag: TAG20120307T111448
        Piece Name: /mnt/export/backup_6mn59518_1_1.bkp
  List of Datafiles in backup set 115
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 666037     07-MAR-12 /u02/oradata/orcl/system01.dbf
  2       Full 666037     07-MAR-12 /u02/oradata/orcl/undotbs01.dbf
  3       Full 666037     07-MAR-12 /u02/oradata/orcl/sysaux01.dbf
  4       Full 666037     07-MAR-12 /u02/oradata/orcl/users01.dbf
  5       Full 665577     07-MAR-12 /u02/oradata/orcl/example01.dbf
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
116     Full    6.83M      DISK        00:01:28     07-MAR-12      
        BP Key: 127   Status: AVAILABLE  Compressed: NO  Tag: TAG20120307T111448
        Piece Name: /mnt/export/backup_6nn5962g_1_1.bkp
  Control File Included: Ckp SCN: 666216       Ckp time: 07-MAR-12
  SPFILE Included: Modification time: 07-MAR-12
 -MAR-12

В отчёте видно, что резервные наборы действительно были созданы в удалённом каталоге /mnt/export и теперь, резервная копия целевой базы данных у нас находится на хосте вспомогательного экземпляра alfa2.alldba.ru.

Создание резервной копии архивных файлов

И так, почти всё готово к дублированию, за исключением наличия архивных журналов на хосте alfa2.alldba.ru. В нашем примере журналов всего три:

[oracle@alfa 2012_03_07]$ ls -l
итого 16324
-rw-r----- 1 oracle oinstall 6091776 Мар  7 11:45 o1_mf_1_24_7og80z9q_.arc
-rw-r----- 1 oracle oinstall 5272064 Мар  7 11:45 o1_mf_1_25_7og814k8_.arc
-rw-r----- 1 oracle oinstall 5292544 Мар  7 11:46 o1_mf_1_26_7og838pv_.arc

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

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

Для начала, определимся какие архивные файлы необходимо копировать в набор. Есть различные опции команды, но мы будем осуществлять выбор по серийному номеру изменения (SCN) . Для этого, среди отчёта RMAN о резервных копиях (list backup) в колонке «Ckp SCN» найдём наименьший SCN.  В команде backup archivelog укажем опцию "from scn=" и найденный нами номер SCN. Для того чтобы резервный набор у нас сформировался в удалённом каталоге хоста alfa2.alldba.ru используем опцию format, известную по предыдущему созданию резервной копии. В результате, при выполнении команды, на удалённом хосте должна образоваться резервная копия, включающая архивные файлы, имеющие SCN больший или равный значению, указанному в опции "from scn":

RMAN> backup archivelog from scn=665577 format='/mnt/export/arch_%U.arc';
Starting backup at 07-MAR-12
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=24 recid=76 stamp=777296719
input archive log thread=1 sequence=25 recid=77 stamp=777296724
input archive log thread=1 sequence=26 recid=78 stamp=777296792
input archive log thread=1 sequence=27 recid=79 stamp=777297033
channel ORA_DISK_1: starting piece 1 at 07-MAR-12
channel ORA_DISK_1: finished piece 1 at 07-MAR-12
piece handle=/mnt/export/arch_6on59749_1_1.arc tag=TAG20120307T115033 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:09
Finished backup at 07-MAR-12

Выведем в RMAN информацию обо всех резервных наборах данных сделанных нами:

RMAN> list backup;
List of Backup Sets
===================
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
115     Full    592.59M    DISK        00:17:42     07-MAR-12      
        BP Key: 126   Status: AVAILABLE  Compressed: NO  Tag: TAG20120307T111448
        Piece Name: /mnt/export/backup_6mn59518_1_1.bkp
  List of Datafiles in backup set 115
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 666037     07-MAR-12 /u02/oradata/orcl/system01.dbf
  2       Full 666037     07-MAR-12 /u02/oradata/orcl/undotbs01.dbf
  3       Full 666037     07-MAR-12 /u02/oradata/orcl/sysaux01.dbf
  4       Full 666037     07-MAR-12 /u02/oradata/orcl/users01.dbf
  5       Full 665577     07-MAR-12 /u02/oradata/orcl/example01.dbf
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
116     Full    6.83M      DISK        00:01:28     07-MAR-12      
        BP Key: 127   Status: AVAILABLE  Compressed: NO  Tag: TAG20120307T111448
        Piece Name: /mnt/export/backup_6nn5962g_1_1.bkp
  Control File Included: Ckp SCN: 666216       Ckp time: 07-MAR-12
  SPFILE Included: Modification time: 07-MAR-12
BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
117     15.93M     DISK        00:00:07     07-MAR-12      
        BP Key: 128   Status: AVAILABLE  Compressed: NO  Tag: TAG20120307T115033
        Piece Name: /mnt/export/arch_6on59749_1_1.arc
  List of Archived Logs in backup set 117
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    24      665577     07-MAR-12 666563     07-MAR-12
  1    25      666563     07-MAR-12 666679     07-MAR-12
  1    26      666679     07-MAR-12 666794     07-MAR-12
  1    27      666794     07-MAR-12 666880     07-MAR-12

В отчёте видно, что у нас появился новый резервный набор arch_6on59749_1_1.arc. RMAN включил в него все архивные журнальные файлы удовлетворяющие нашим условиям (с наименьшего SCN). Список этих журналов приведён в самом низу отчёта. Кстати, архивных журналов уже стало не три, а четыре. Это произошло из-за того, что команда backup archive перед  созданием копии делает переключение оперативных журналов, тем самым образовывая новый архивный журнал.

Выполнение дублирования

Проверим наличие файлов резервных наборов на хосте вспомогательного экземпляра alfa2.alldba.ru:

[oracle@alfa2 export]$ ls -l
итого 630780
-rw-r----- 1 oracle oinstall  16702976 Мар  7 03:54 arch_6on59749_1_1.arc
-rw-r----- 1 oracle oinstall 621379584 Мар  7 03:44 backup_6mn59518_1_1.bkp
-rw-r----- 1 oracle oinstall   7176192 Мар  7 03:44 backup_6nn5962g_1_1.bkp

Все файлы резервных копий присутствуют. Можно начинать дублирование:

RMAN> duplicate target database to orcl nofilenamecheck;

Для краткости приведена только часть вывода выполняемой команды.

Starting Duplicate Db at 07-MAR-12
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=156 devtype=DISK

Стартует восстановление файлов. Как видим, RMAN обратился к контрольному файлу целевой базы данных и нашёл там запись о сделанной нами последней резервной копии  базы данных:

Starting restore at 07-MAR-12
using channel ORA_AUX_DISK_1
using channel ORA_AUX_SBT_TAPE_1
channel ORA_AUX_DISK_1: starting datafile backupset restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /u02/oradata/orcl/system01.dbf
restoring datafile 00002 to /u02/oradata/orcl/undotbs01.dbf
restoring datafile 00003 to /u02/oradata/orcl/sysaux01.dbf
restoring datafile 00004 to /u02/oradata/orcl/users01.dbf
restoring datafile 00005 to /u02/oradata/orcl/example01.dbf
channel ORA_AUX_DISK_1: reading from backup piece /mnt/export/backup_6mn59518_1_1.bkp
channel ORA_AUX_DISK_1: restored backup piece 1
piece handle=/mnt/export/backup_6mn59518_1_1.bkp tag=TAG20120307T111448
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:56
Finished restore at 07-MAR-12

Файлы данных восстановлены. Теперь идёт восстановление базы данных до актуального состояния с помощью архивных файлов:

Starting recover at 07-MAR-12
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=155 devtype=DISK
starting media recovery
channel ORA_AUX_DISK_1: starting archive log restore to default destination
channel ORA_AUX_DISK_1: restoring archive log
archive log thread=1 sequence=24
channel ORA_AUX_DISK_1: restoring archive log
archive log thread=1 sequence=25
channel ORA_AUX_DISK_1: restoring archive log
archive log thread=1 sequence=26
channel ORA_AUX_DISK_1: restoring archive log
archive log thread=1 sequence=27
channel ORA_AUX_DISK_1: reading from backup piece /mnt/export/arch_6on59749_1_1.arc
channel ORA_AUX_DISK_1: restored backup piece 1
piece handle=/mnt/export/arch_6on59749_1_1.arc tag=TAG20120307T115033
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:02
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_07/o1_mf_1_24_7ofdvz
gn_.arc thread=1 sequence=24
channel clone_default: deleting archive log(s)
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_07/o1_mf_1_24_7ofdvz
gn_.arc recid=2 stamp=777268912
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_07/o1_mf_1_25_7ofdvz
kn_.arc thread=1 sequence=25
channel clone_default: deleting archive log(s)
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_07/o1_mf_1_25_7ofdvz
kn_.arc recid=4 stamp=777268912
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_07/o1_mf_1_26_7ofdvz
hk_.arc thread=1 sequence=26
channel clone_default: deleting archive log(s)
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_07/o1_mf_1_26_7ofdvz
hk_.arc recid=3 stamp=777268912
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_07/o1_mf_1_27_7ofdvz
ly_.arc thread=1 sequence=27
channel clone_default: deleting archive log(s)
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_07/o1_mf_1_27_7ofdvz
ly_.arc recid=1 stamp=777268911
media recovery complete, elapsed time: 00:00:06
Finished recover at 07-MAR-12

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

contents of Memory Script:
{
   Alter clone database open resetlogs;
}
executing Memory Script
database opened
Finished Duplicate Db at 07-MAR-12

Дублирование завершено. Осталось только пересоздать файлы временного табличного пространства и дублированная база готова к использованию. Резервные копии, находящиеся в каталоге export можно удалить. Правда, делать это лучше с помощью RMAN командой DELETE BACKUPSET на хосте целевой базы данных (не забываем, что эти резервные копии относятся к экземпляру целевой базы, несмотря на их расположение на удалённом хосте).

Что ещё можно сделать  для оптимизации

Несмотря на то, что оптимизировать процесс дублирования кажется уже некуда, есть ещё несколько моментов, которые могут помочь ускорить этот процесс или сэкономить при этом дисковое пространство. Как было сказано ранее, в больших базах данных и резервная копия получается большого размера. И хотя в нашем примере мы создаём резервную копию прямо на хосте вспомогательного экземпляра, бывает, что и на нём может не хватать дискового пространства. В этом случае нам может помочь сжатие резервного набора налету, то есть непосредственно в момент образования  резервной копии. Чтобы создать такую копию необходимо определить её как сжатый резервный набор. Делается это, с помощью добавления в команду backup database служебных слов as compressed backupset.

Попробуем создать такую резервную копию на удалённом хосте:

RMAN> backup as compressed backupset database format=’/mnt/export/backup_%U.bkp’;
Starting backup at 16-MAR-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=158 devtype=DISK
channel ORA_DISK_1: starting compressed full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u02/oradata/orcl/system01.dbf
input datafile fno=00003 name=/u02/oradata/orcl/sysaux01.dbf
input datafile fno=00002 name=/u02/oradata/orcl/undotbs01.dbf
input datafile fno=00005 name=/u02/oradata/orcl/example01.dbf
input datafile fno=00004 name=/u02/oradata/orcl/users01.dbf
channel ORA_DISK_1: starting piece 1 at 16-MAR-12
channel ORA_DISK_1: finished piece 1 at 16-MAR-12
piece handle=/mnt/export/backup_6un60k7h_1_1.bkp tag=TAG20120316T085512 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:57
channel ORA_DISK_1: starting compressed full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 16-MAR-12
channel ORA_DISK_1: finished piece 1 at 16-MAR-12
piece handle=/mnt/export/backup_6vn60kd2_1_1.bkp tag=TAG20120316T085512 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 16-MAR-12

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

RMAN> backup as compressed backupset archivelog from scn=669981 
format='/mnt/export/arch_%U.arc';
Starting backup at 16-MAR-12
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting compressed archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=28 recid=80 stamp=778064576
channel ORA_DISK_1: starting piece 1 at 16-MAR-12
channel ORA_DISK_1: finished piece 1 at 16-MAR-12
piece handle=/mnt/export/arch_70n60km1_1_1.arc tag=TAG20120316T090256 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 16-MAR-12

Посмотрим  размер резервных наборов в операционной системе:

[oracle@alfa2 export]$ ls -l
итого 746852
-rw-r----- 1 oracle oinstall  16702976 Мар  7 03:54 arch_6on59749_1_1.arc
-rw-r----- 1 oracle oinstall   2085888 Мар 16 00:34 arch_70n60km1_1_1.arc
-rw-r----- 1 oracle oinstall 621379584 Мар  7 03:44 backup_6mn59518_1_1.bkp
-rw-r----- 1 oracle oinstall   7176192 Мар  7 03:44 backup_6nn5962g_1_1.bkp
-rw-r----- 1 oracle oinstall 115482624 Мар 16 00:31 backup_6un60k7h_1_1.bkp
-rw-r----- 1 oracle oinstall   1146880 Мар 16 00:31 backup_6vn60kd2_1_1.bkp

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

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

Рассмотрим этот вариант на примере. В качестве табличного пространства «только для чтения» у нас будет выступать табличное пространство EXAMPLE. Для этого, переведём его в статус READ ONLY на экземплярах целевой базы данных и вспомогательного экземпляра:

SQL> alter tablespace EXAMPLE read only;
Tablespace altered.

Теперь табличное пространство EXAMPLE в статусе «только для чтения»:

SQL> SELECT tablespace_name, status FROM dba_tablespaces;
 
TABLESPACE_NAME STATUS   
--------------- ---------
SYSTEM          ONLINE   
UNDOTBS1        ONLINE   
SYSAUX          ONLINE   
TEMP            ONLINE   
USERS           ONLINE   
EXAMPLE         READ ONLY

Добавим к команде дублирования DUPLCATE опцию SKIP READONLY. Теперь при дублировании все табличные пространства только для чтения будут пропущены. Выполним команду:

RMAN> duplicate target database to orcl nofilenamecheck skip readonly;
Starting Duplicate Db at 16-MAR-12
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=155 devtype=DISK

RMAN явно написал, что файл номер 5 табличного пространства EXAMPLE не участвует в процессе, потому что имеет статус «только для чтения»:

datafile 5 not processed because file is read-only

В дальнейшем он будет исключён из всех скриптов дублирования до его окончания.

После создания дублированной базы данных и её открытия в журнале сообщений alert, появиться интересная запись:

Dictionary check beginning
Tablespace 'EXAMPLE' #6 found in data dictionary,
but not in the controlfile. Adding to controlfile.
File #5 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00005' in the controlfile.

Oracle сообщает, что табличное пространство найдено в словаре базы данных, но информация о нём отсутствует в контрольном файле. Объясняется это просто. Словарь данных при дублировании у нас переноситься вместе с табличным пространством SYSTEM, а вот контрольный файл пересоздаётся заново. С учётом того, что при дублировании табличное пространство EXAMPLE было пропущено, запись о его файлах в контрольный файл так и не попала.

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

SQL> SELECT file_name, tablespace_name, online_status  FROM dba_data_files
 
FILE_NAME                                            TABLESPACE_NAME ONLINE_STATUS
---------------------------------------------------- --------------- -------------
/u02/oradata/orcl/system01.dbf                       SYSTEM          SYSTEM       
/u02/oradata/orcl/undotbs01.dbf                      UNDOTBS1        ONLINE       
/u02/oradata/orcl/sysaux01.dbf                       SYSAUX          ONLINE       
/u02/oradata/orcl/users01.dbf                        USERS           ONLINE       
/u01/app/oracle/product/10.2.0/db_1/dbs/MISSING00005 EXAMPLE         OFFLINE 

Подведение итогов

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

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

P.S.

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

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oradata/orcl/System01.dbf'

Можно конечно вручную догнать базу с помощью команды RECOVERY, а затем открыть её с помощью RESETLOGS. Но, ошибка эта обычно устойчивая и создает определённые неудобства. Восстановление на определённый момент времени с помощью RMAN кляузы UNTIL ошибку не устаняло. Положение спасло только создание архивной копии архивных файлов с помощью RMAN (в статье это описано). Ошибка больше не возникала.