Оптимизация процесса дублирования
Рассмотренный выше процесс дублирования у нас начинался с создания резервной копии целевой базы данных на хосте 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 (в статье это описано). Ошибка больше не возникала.