Перенос бд oracle на другой сервер windows

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

В этом примере имя моей тестовой базы данных dbase1 и она запущены на машине neptune. Целевая задача состоит в том, чтобы сделать резервную копию на машине neptune и залить эту копию на резервную машину saturn, и далее выполнить процесс восстановление экземпляра базы на машине saturn.

Шаг 1. На машине neptun делаем бэкап базы, выполняя команды в утилите RMAN:

RMAN> backup database;

Starting backup at 06-MAY-08
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=/oradata2/data1/dbase1/system01.dbf
input datafile fno=00003 name=/oradata2/data1/dbase1/sysaux01.dbf
input datafile fno=00005 name=/oradata2/DBASE1/datafile/o1_mf_tbs2_41vyzfrq_.dbf
input datafile fno=00006 name=/oradata2/DBASE1/datafile/o1_mf_after_on_420r4f9h_.dbf
input datafile fno=00002 name=/oradata2/data1/dbase1/undotbs01.dbf
input datafile fno=00004 name=/oradata2/data1/dbase1/users01.dbf
input datafile fno=00007 name=/oradata2/DBASE1/datafile/o1_mf_after_on_420r675z_.dbf
input datafile fno=00008 name=/oradata2/DBASE1/datafile/o1_mf_after_on_420x2yw8_.dbf
channel ORA_DISK_1: starting piece 1 at 06-MAY-08
channel ORA_DISK_1: finished piece 1 at 06-MAY-08
piece handle=/oradata2/flash_recovery_area/DBASE1/backupset/2008_05_06/
o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp tag=TAG20080506T150716 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:35
Finished backup at 06-MAY-08
Starting Control File and SPFILE Autobackup at 06-MAY-08
piece handle=/oradata2/flash_recovery_area/DBASE1/autobackup/2008_05_06/
o1_mf_s_654016132_421c64vl_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 06-MAY-08 

Шаг 2. Передаем созданные две части бэкапа на целевую машину (с сервера neptune на saturn), используем команды оболочки bash на unix-сервере:

bash-3.00$ scp /oradata2/flash_recovery_area/DBASE1/backupset/2008_05_06/
o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp oracle@saturn:/oradata2/

Password:
o1_mf_nnndf_TAG20080 100% |***********************************************| 525 MB 00:59

bash-3.00$ scp /oradata2/flash_recovery_area/DBASE1/autobackup/2008_05_06/
o1_mf_s_654016132_421c64vl_.bkp oracle@saturn:/oradata2/

Password:
o1_mf_s_654016132_42 100% |***********************************************| 6976 KB 00:00

Шаг 3.Определяем DBID базы на исходной машине Neptune, обращаясь к представлению v$database:

SQL> select dbid from v$database;
DBID
----------
3386862614

Шаг 4.Теперь выполняем команды на целевой машине Saturn. Прежде всего установим ORACLE_SID

-bash-3.00$ export ORACLE_SID=dbase1

...и подключимся к RMAN

-bash-3.00$ rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on Tue May 6 05:22:39 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database (not started)

Шаг 5. Установим DBID и восстановим spfile из файла pfile:

RMAN> set dbid 3386862614

executing command: SET DBID

RMAN> startup nomount

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/oracle/app/oracle/product/10.2.0/db_1/dbs/initdbase1.ora'
starting Oracle instance without parameter file for retrival of spfile
Oracle instance started
Total System Global Area 159383552 bytes
Fixed Size 2019224 bytes
Variable Size 67108968 bytes
Database Buffers 83886080 bytes
Redo Buffers 6369280 bytes

RMAN> restore spfile to pfile '/oracle/app/oracle/product/10.2.0/db_1/dbs/initdbase1.ora' from '/oradata2/o1_mf_s_654016132_421c64vl_.bkp';

Starting restore at 06-MAY-08
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: autobackup found: /oradata2/o1_mf_s_654016132_421c64vl_.bkp
channel ORA_DISK_1: SPFILE restore from autobackup complete
Finished restore at 06-MAY-08

Подсказка! Откройте pfile в редакторе, если хотите поменять расположение файлов базы данных

Шаг 6. Запускаем экземпляр с использованием pfile:

RMAN> STARTUP FORCE NOMOUNT PFILE='/oracle/app/oracle/product/10.2.0/db_1/dbs/initdbase1.ora';

Oracle instance started
Total System Global Area 209715200 bytes
Fixed Size 2019608 bytes
Variable Size 109055720 bytes
Database Buffers 92274688 bytes
Redo Buffers 6365184 bytes

Шаг 7. Восстанавливаем управляющие файлы (controlfile) и монтируем базу:

RMAN> RESTORE CONTROLFILE FROM '/oradata2/o1_mf_s_654016132_421c64vl_.bkp';

Starting restore at 06-MAY-08
using channel ORA_DISK_1
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output filename=/oradata2/DBase1/control01.ctl
output filename=/oradata2/DBase1/control02.ctl
output filename=/oradata2/DBase1/control03.ctl
Finished restore at 06-MAY-08

RMAN> ALTER DATABASE MOUNT;
database mounted
released channel: ORA_DISK_1

Шаг 8. С помощью SQL*Plus указываем файлы данных (data file) и имена журналов redo log:

SQL> COLUMN NAME FORMAT a70

SQL> 1 SELECT FILE# AS "File/Grp#", NAME FROM V$DATAFILE
2 UNION
3* SELECT GROUP#,MEMBER FROM V$LOGFILE

File/Grp# NAME
---------- ------------------------------------------------------------
1 /oradata2/data1/dbase1/redo01.log
1 /oradata2/data1/dbase1/system01.dbf
2 /oradata2/data1/dbase1/redo02.log
2 /oradata2/data1/dbase1/undotbs01.dbf
3 /oradata2/data1/dbase1/redo03.log
3 /oradata2/data1/dbase1/sysaux01.dbf
4 /oradata2/data1/dbase1/users01.dbf
5 /oradata2/DBASE1/datafile/o1_mf_tbs2_41vyzfrq_.dbf
6 /oradata2/DBASE1/datafile/o1_mf_after_on_420r4f9h_.dbf
7 /oradata2/DBASE1/datafile/o1_mf_after_on_420r675z_.dbf
8 /oradata2/DBASE1/datafile/o1_mf_after_on_420x2yw8_.dbf
11 rows selected.

Шаг 9. Каталогизируем бекапы:

RMAN> catalog backuppiece '/oradata2/o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp';

cataloged backuppiece
backup piece handle=/oradata2/o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp
recid=33 stamp=65398295

RMAN> list backup;

List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
32 Full 525.67M DISK 00:01:31 06-MAY-08
BP Key: 33 Status: AVAILABLE Compressed: NO Tag: TAG20080506T150716
Piece Name: /oradata2/o1_mf_nnndf_TAG20080506T150716_421c355f_.bkp
List of Datafiles in backup set 32
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 745212 06-MAY-08 /oradata2/data1/dbase1/system01.dbf
2 Full 745212 06-MAY-08 /oradata2/data1/dbase1/undotbs01.dbf
3 Full 745212 06-MAY-08 /oradata2/data1/dbase1/sysaux01.dbf
4 Full 745212 06-MAY-08 /oradata2/data1/dbase1/users01.dbf
5 Full 745212 06-MAY-08 /oradata2/DBASE1/datafile/o1_mf_tbs2_41vyzfrq_.dbf
6 Full 745212 06-MAY-08 /oradata2/DBASE1/datafile/o1_mf_after_on_420r4f9h_.dbf
7 Full 745212 06-MAY-08 /oradata2/DBASE1/datafile/o1_mf_after_on_420r675z_.dbf
8 Full 745212 06-MAY-08 /oradata2/DBASE1/datafile/o1_mf_after_on_420x2yw8_.dbf

Шаг 10. Если вы хотите использовать имена файлов, отличные от исходных, то создаем специальный скрипт с использованием SET NEWNAME:

RMAN> @/export/home/oracle/rman
RMAN> run{
2> set newname for datafile 1 to '/oradata2/DBase1/system01.dbf';
3> set newname for datafile 2 to '/oradata2/DBase1/undotbs01.dbf';
4> set newname for datafile 3 to '/oradata2/DBase1/sysaux01.dbf';
5> set newname for datafile 4 to '/oradata2/DBase1/users01.dbf';
6> set newname for datafile 5 to '/oradata2/DBase1/tbs201.dbf';
7> set newname for datafile 6 to '/oradata2/DBase1/after_01.dbf';
8> set newname for datafile 7 to '/oradata2/DBase1/after_02.dbf';
9> set newname for datafile 8 to '/oradata2/DBase1/after_03.dbf';
10> set newname for datafile 1 to '/oradata2/DBase1/system01.dbf';
11>
12> SET UNTIL SCN 745212;
13> RESTORE DATABASE;
14> SWITCH DATAFILE ALL;
15> RECOVER DATABASE;
16> }

Шаг 11.Открываем базу данных (переводим в состояние Open) с использование опции resetlogs:

RMAN> alter database open resetlogs;

database opened.

Глава 5

В этой главе…

·       
Запуск и останов БД

·       
Перенос БД на другой сервер (либо
временное удаление БД)

·       
Экспорт и импорт данных

·       
Резервное копирование и
восстановление

·       
Перевод БД на другую версию сервера
Oracle (upgrade и downgrade)

·       
Настройка БД Oracle

·       
Пути повышения производительности запросов СУБД Oracle

·       
Некоторые полезные команды SQL

·       
Использование встроенных модулей

·       
Что применять для ввода команд: SVRMGR30, SQL Plus
или SQL Worksheet?

·       
Описание ряда особенностей при
работе с Oracle

·       
Что делать при изменении сетевого
адреса сервера

·       
Возможные аварийные ситуации

Запуск и останов БД

Запуск БД

Процесс запуска БД проходит 3
стадии:

·        
NOMOUNT, когда открывается файл INIT<SID>.ORA и в ОЗУ компьютра создается экземпляр БД

·        
MOUNT, когда открываются управляющие файлы (CTL1<SID>.ORA и
т.д.)

·        
OPEN, когда открываются файлы табличных пространств

Если запустить утилиту SVRMGR30 и ввести команду

startup
pfile=%ORACLE_HOME%DATABASEINIT<SID>.ORA

то
произойдет запуск БД до состояния OPEN (по
умолчанию). Можно ввести команду ORASTART.NCF, что
приведет к аналогичному эффекту. Можно ввести эту же команду, но добавить
параметр NOMOUNT. При этим  произойдет запуск БД до первого состояния.
Чтобы затем ее открыть, нужно последовательно задать команды:

Останов БД

            Для
останова БД можно запустить ORASTOP.NCF, но при
этом БД будет останавливаться по технологии IMMEDIATE, что не очень желательно. Лучше в SVRMGR30 ввести команду SHUTDOWN NORMAL.

Перенос
БД на другой сервер (либо временное удаление БД)

            Если
не пользоваться механизмами экспорта / импорта или резервного копирования / восстановления,
то общая схема такова («сюрпризы» в MS Windows NT 4 здесь
не описаны):

            Для
временного удаления (например, перед форматированием диска):

·        
Остановите БД (можно запустить ORASTOP.NCF, лучше скомандовать SHUTDOWN NORMAL)

·        
Запакуйте разделы %ORACLE_HOME%DATABASE и %ORACLE_HOME% NET80ADMIN с
помощью архиватора, сохраняющего длинные имена файлов (например, PKZIP или WINZIP).

ВНИМАНИЕ !

Пакуйте с учетом скрытых файлов. Скопируйте
архивы в безопасное место (не на диск, который будет форматироваться).

·        
Если действительно предстоит
форматирование диска, то на всякий случай, чтобы система не кричала:

·        
Выгрузите Oracle
(запустите ORAUNLD.NCF)

·        
Деинсталлируйте Oracle Server

·        
Удалите каталог %ORACLE_HOME%

Для восстановления БД (после форматирования диска):

·        
Проинсталлируйте Oracle Server

·        
Верните на место файлы из архивов

·        
Загрузите Oracle
(запустите ORALOAD.NCF)

При переносе БД на другой сервер:

·        
Проинсталлируйте на нем Oracle Server

·        
Создайте тот же SID

·        
Установите в вышеупомянутые
каталоги файлы из архивов

·        
В файле %ORACLE_HOME%NET80ADMINTNSNAMES.ORA исправьте
адреса Ваших сервисов (лучше с помощью Oracle Net8 Easy Config). Кстати, это
необходимо делать также при изменении TCP/IP-адреса
сервера c Oracle.

Экспорт
и импорт данных

Экспорт данных

            Экспорт
данных выполняется утилитой командной строки EXP80 (Часть 1, Глава 6, Утилиты командной строки, EXP80.EXE …) либо утилитой Oracle Data Manager пакета OEM
(Часть 1, Глава 6: Утилиты из пакета Oracle Enterprise Manager, Oracle Data Manager).

Импорт данных

            Импорт
данных выполняется утилитой командной строки IMP80 (Часть 1, Глава 6, Утилиты командной строки, IMP80.EXE …) либо
утилитой Oracle Data Manager пакета
OEM (Часть 1, Глава 6: Утилиты из пакета Oracle Enterprise Manager, Oracle Data Manager).

Резервное
копирование и восстановление

            Это
самые необходимые операции, которые должен уметь использовать администратор БД.
Рекомендуется использовать не «горячее» (при запущенном экземпляре), а
«холодное» (после останова БД) резервное копирование средствами используемой
операционной системы.

            Резервное
копирование БД Oracle удобно
выполнять утилитой Oracle Backup Manager из
пакета OEM (см. Часть 1, Глава 6: Oracle Backup Manager (Var.exe)).

 

Перевод БД на другую версию сервера Oracle (upgrade и
downgrade)

            Перевод
БД на старую версию сервера Oracle называется
downgrade, на новую – upgrade. И
то и другое обычно описывается в технической документации. Например, перевод БД
с версии 8.0.3 на версию 8.0.4 сервера Oracle
для Novell Netware 5 в [13] (в
разделе Upgrading an Oracle8 Database) описывается слишком
упрощенным способом (используя который без опыта, можно иногда «запороть» БД):

·        
Шаг 1: Остановите БД
версии 8.0.3.

·        
Шаг 2: Создайте резервную копию БД версии 8.0.3.

·        
Шаг 3: Поправьте параметр compatible в файле INIT<SID>.ORA для БД версии 8.0.3. (Имеется ввиду – введите номер новой версии сервера Oracle).

·        
Шаг 4: Проинсталлируйте Oracle8 Enterprise Edition
Release 8.0.4 (имеется ввиду серверная часть).

·        
Шаг 5: Запустите скрипт CAT8004.SQL.

По-настоящему, все, конечно, значительно сложнее:
например, в документации забыли указать, что необходимо перекомпилировать все
модули, перезапустить некоторые постпроцедуры, перед запуском CAT8004.SQL необходимо запустить БД, причем она должна быть
открытой (в состоянии OPENED), а
присоединяться нужно как INTERNAL и
т.д. А вообще, это все тоже может не привести к ожидаемому результату, потому
что Словарь БД оказывается разрушенным, в результате чего Oracle не видит
пользователя SYSTEM, а целый ряд постпроцедур и важных скриптов из-за
этого не выполняется.

Существуют и другие способы для upgrade БД. Например,
сделать полный экспорт БД, инсталлировать новую версию сервера и сделать импорт
и пр.

Настройка
БД Oracle

            Настройка
БД Oracle включает
в себя, в частности, настройку конфигурационных параметров (в файле INIT<SID>.ORA) и настройку параметров заполнения таблиц и
расширения табличных пространств. Настройка конфигурационных параметров уже
описывалась в Главе 2 Части 1, здесь же будут приведены некоторые методы
определения их оптимальности. Далее эта глава будет постоянно дополняться и
уточняться.

Определение оптимальности некоторых
конфигурационных параметров

·        
Для определения, нужно ли изменять
размер буферного кэша, введите запрос:

Затем вычислите коэффициентт попадания в SGA по следующей
формуле:

HIT_RATIO =
1-(PHYSICAL READS / (DB BLOCK_GETS + CONSISTENT_GETS)

Если HIT_RATIO меньше 0.7 — увеличьте
параметр DB_BLOCK_BUFFERS

·        
Для определения, нужно ли изменять
размер разделяемого пула, введите запросы:

select sum(PINS)
PINS, sum(RELOADS) RELOADS from V$LIBRARYCACHE;

Если PINS / RELOADS больше 1 – увеличте параметр SHARED_POOL_SIZE

select sum(GETS)
GETS, sum(GETMISSES) GETMISSES from V$ROWCACHE;

Если GETS / GETMISSES больше 0.1 — увеличте параметр SHARED_POOL_SIZE

·        
Для определения, нужно ли изменять
размер области сортировки, введите запрос:

select NAME, VALUE from
V$SYSSTAT where NAME like ‘sort%’

Возможен
такой результат запроса:

Если
sorts (disk) больше 0, значит для параметра SORT_AREA_SIZE требуется
больше памяти

Для
параметра SORT_AREA_SIZE_RETAINED можно
установить минимальный размер

·        
Для определения, имеется ли
конкуренция за журнальные файлы, введите запрос:

Вычислите два значения:

Если
любое значение больше 1, то имеетсяся конкуренцияция за защелку.

·        
чтобы снизить конкуренцию за
защелку выделения журнального буфера – уменьшите параметр LOG_SMALL_ENTRY_MAX_SIZE

·        
чтобы снизить конкуренцию за
защелку копирования журнала – увеличьте параметр LOG_SIMULTANEOUS_COPIES

Некоторые рекомендации по настройке
объектов БД

1.     
Рекомендуемые
параметры для таблиц:

Параметр	По умолчанию	Общая рекомендация	Для относи-тельно статичных таблиц	Для таблиц с интенсив-ными изме-нениями
PCTFREE	10%	5-20% (15)	5 или меньше (но не 0)	Более 10
PCTUSED	40%	55-90% (60)	65 или даже 80	Даже 20
PCTINCREASE	50%	0%
INITIAL	10240 или 20480	Все даннае должны помещаться в 1 экстенте с небольшим запасом
NEXT	10240 или 20480	От 25% до размера INITIAL

ПРИМЕЧАНИЕ.

Должно
выполняться всегда следующее: PCTFREE + PCTUSED < 100

2.     
Рекомендации по количеству
сегментов отката:

·        
желательно на 5 пользователей 1 RBS;

·        
обязательно MINEXTENTS не менее 2 и PCTINCREASE не может быть указан

·        
Если количество одновременных
транзакций:

·        
меньше 16 — использовать 4 RBS

·        
16-32 — использовать 8
RBS

·        
более 32  использовать 1 RBS
на 4 транзакции, но меньше 50

3.     
Для определения, имеется ли
конкуренция за сегменты отката, введите запрос:

Возможен такой результат запроса:

Если
WAITS / GETS >= 2 — нужно сделать больше RBS

4.     
Другие настройки:

·        
Для определения, имеется ли
конкуренция за ввод-вывод, введите запрос:

Возможен такой результат запроса:

·        
Для определения степени
фрагментации, введите запрос:

Если count(TABLESPACE_NAME) >10 -15, то необходима
дефрагментация

·        
Для определения, происходит ли
чрезмерное динамическое расширение, введите запрос:

Рекомендации по уменьшению
количества записей на диск и др.

            Если
при эксплуатации БД Oracle происходят
интенсивные транзакции (например, более 10 000 удалений-добавлений-изменений за
1 транзакцию, и более 10 таких транзакций друг за другом при участии нескольких
таблиц с количеством записей 100 000 – 1 000 000), то для ускорения работы с
жестким диском помогут приведенные ниже рекомендации.

РЕКОМЕНДАЦИЯ 1.

Рекомендуется увеличить
размер (например, до 8-16 М) и количество журнальных файлов (например, до 4-8,
причем для повышения надежности сделать их 2-4 группами на разных дисках). При
этом уменьшится количество переключений журнальных файлов, а при включенной
архивации уменьшится количество записей архивных копий журнальных файлов.

РЕКОМЕНДАЦИЯ 2.

Рекомендуется для очень
больших таблиц с интенсивными транзакциями (в описываемой СИСТЕМЕ — BOOK, FEATURES, WORKS, PROFILES, KMCOL) установить режим прямой записи минуя журнальные
файлы. Это выполняется командой (ATbNolog.sql):

alter table BIGTABLE nologging

РЕКОМЕНДАЦИЯ 3.

Для этих же таблиц
рекомендуется отключить триггер на запись (ТАБЛИЦА_LOG) в Журнал изменений (EDITIONS). Это приведет как к уменьшению обращений к
диску, так и замедлению роста Журнала изменений. Отключение триггера
выполняется в утилите Oracle Schema Manager (см. Часть 1,
Глава 6: Oracle Schema Manager
(Vas.exe)) или с помощью команды (ATrigDis.sql):

alter trigger TABLE_LOG
disable

РЕКОМЕНДАЦИЯ 4.

Рекомендуется в
конфигурационном файле сделать установку для активизации всех сегментов отката
при запуске БД. Это приведет к уменьшению количества процессов по активизации
сегментов отката при большом количестве транзаций. Установка выполняется с
помощью параметра ROLLBACK_SEGMENTS следующим образом (R01..R10 – имена
сегментов отката):

ROLLBACK_SEGMENTS =
(R01,R02,R03,R04,R05,R06,R07,R08,R09,R10)

РЕКОМЕНДАЦИЯ 5.

Рекомендуется
установить параметр OPTIMAL для всех
сегментов отката не менее 4 М. Можно, например, по следующей схеме: для первого
сегмента 32, далее — 16, 16, 8, 8, 4, 4, 4, 4, 32 (если последний используется
для процесса PURGE в репликационном механизме). Это
приведет к тому, что после достижения данного размера, сегмент отката уже не
будет сокращаться процессом Oracle меньше данного значения, и в дальнейшем не будет
тратиться время на его расширение. Установку параметра удобно выполнять с
помощью утилиты Oracle Storage Manager (вкладка Extents, опция Optimal Size — см. Часть 1, Глава 6: Oracle Storage Manager (Vag.exe)) или с помощью команды:

alter rollback segment R01
storage (optimal 4M)

РЕКОМЕНДАЦИЯ 6.

Если количество записей
в БД постоянно увеличивается, рекомендуется заранее увеличить размер основного
табличного пространства.

РЕКОМЕНДАЦИЯ 7.

Рекомендуется
проанализировать транзакционную нагрузку таблиц и разделить их на группы,
установив для каждой группы свои параметры PCTUSED и PCTFREE, например (ATabPct.sql):

·        
Журнал изменений EDITIONS (большая таблица, много добавлений, удалений
(очисток), нет правок): PCTUSED = 20,
PCTFREE = 5;

·        
Некоторые «тяжелые» таблицы, указанные
в приведенных выше рекомендациях 2-3 (очень большие таблицы, очень много
добавлений, правок, удалений): PCTUSED = 20,
PCTFREE = 10;

·        
Рабочие таблицы и справочники
отдельных филиалов (среднее количество вводов, правок, удалений): PCTUSED = 30, PCTFREE = 30;

·        
Общие справочники (очень мало
ввода, правок, удалений): PCTUSED = 80,
PCTFREE = 10;

Установка данных
параметров выполняется с помощью утилиты Oracle Schema Manager (см. Часть 1, Глава 6: Oracle Schema Manager (Vas.exe)) или команды:

alter table ТАБЛИЦА pctused 20 pctfree 5

Пути
повышения производительности запросов СУБД   Oracle

Пути сокращения времени поиска
нужных записей в таблицах

Для улучшения временных характеристик процесса
соединения таблиц (или поиска записей в таблицах) необходимо индексировать
столбцы, на основании которых происходит соединение таблиц, или соединять
таблицы в кластеры (в этом случае индексирование выполняет Oracle).
Кроме того, во фразе FROM
таблицы нужно указывать в порядке
убывания числа строк таблиц (таблицу с наибольшим числом строк указывать первой,
таблицу с наименьшим числом строк — последней и т.д.)

Оптимизация запросов Oracle

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

1. Если во
фразах where встречается
много столбцов, то определение того, какой столбец или столбцы будут
“руководить” поиском в базе данных или служить отправной точкой для такого
поиска, ведется по определенной схеме. Каждое из выражений (предикатов) во
фразе where, связанных между через and, получает отдельную оценку в следующей
последовательности:

·        
where ROWID = константа;

·        
where уникальный
индексированный столбец = константа;

·        
where полный
уникальный составной ключ = константа;

·        
where полный
неуникальный составной ключ = константа;

·        
where полный
несжатый индекс >= нижняя граница;

·        
where полный
сжатый индекс >= нижняя граница;

·        
where неуникальный
индекс = константа

   and неуникальный
индекс = константа

      and…;

·        
where наибольший
несжатый индекс >= нижняя граница;

·        
where наибольший
сжатый индекс >= нижняя граница;

·        
where уникальный
индексированный столбец between нижнее значение and верхнее
значение или

·        
where индексированный
столбец like ‘С%’ (диапазон с границами);

·        
where неуникальный
индексированный столбец between нижнее значение and верхнее
значение или

·        
where индексированный
столбец like ‘С%’ (диапазон с границами);

·        
where уникальный
индексированный столбец <или> константа (диапазон без границ);

·        
where неуникальный
индексированный столбец <или> константа (диапазон без границ);

·        
order
by полный индекс;

·        
where max или min от
одного индексированного столбца;

·        
where неиндексированный
столбец = константа или

·        
where столбец
is NULL или

·        
where столбец
like ‘%С%’ (поиск по всей таблице).

ПРИМЕЧАНИЕ.

Термин «составной ключ» означает либо ключ, состоящий
из многих столбцов одной и той же таблицы, либо ключ кластера.

2. Использование
несжатых индексов иногда способно существенно ускорить выборку соединений и
обработку фраз where, в которых
указан полный ключ. (Это обусловлено тем, что Oracle может
считывать полное значение ключа из индексного блока, не тратя времени на чтение
и поиск его в блоке данных).

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

4. Предикаты,
связанные друг с другом через or , обрабатываются
отдельно. Это означает, что предикаты, связанные через or или
выражения in (список значений) будут обрабатываться медленнее, чем вложенные запросы.

ПРИМЕР:  

Запрос с индексированным DEPTNO:

select ENAME, SAL from EMP
where DEPTNO in (10,20,40);

выполняются значительно медленнее, чем запрос :

select ENAME, SAL from EMP
where DEPTNO in

  (select DEPTNO from
TEMTABLE);

где таблица TEMTABLE содержит значения DEPTNO:10,20,40.

5. В данной
версии все предикаты равноправны и первая таблица во фразе from будет
“управляющей” таблицей. Если одна из таблиц в соединении значительно меньше, чем
другая, то самую маленькую таблицу следует указать первой.

Некоторые
полезные команды SQL

·        
После создания БД, дабы в этом
убедиться, можно выполнить запрос

select NAME from V$DATABASE;

(предварительно
нужно приконнектиться как SYSTEM)

·        
Если Вы хотите узнать версию
установленного сервера Oracle с
для установленной БД —  запустите утилиту Oracle SQL*Plus, присоединитесь к БД любым пользователем, и, при
успешном соединении с БД, в окне Oracle SQL*Plus появятся
сообщения с версией Oracle SQL*Plus и версией самой
БД. Один из распространенных случаев, когда необходимо уточнить версию сервера Oracle
– выдача сообщений утилитами экспорта/импорта о несовместимости версий. Это
происходит, когда серверная часть старее клиентской.

·        
Еcли с БД Oracle возникли
проблемы, требующие внимательного изучения конфигурационных параметров, а у Вас
нет доступа к файлу INIT<SID>.ORA, находящемуся на сервере в каталоге %ORACLE_HOME%DATABASE —
воспользуйтесь недокументированной командой утилиты SVRMGR30 – sh(ow)
parameters. При этом на экран отобразяться все настройки,
указанные явно в INIT<SID>.ORA и
используемые Oracle по
умолчанию. Удобнее предварительно задать команду SPOOL МойДиск.МойПуть.МойФайл.LST: тогда вывод будет дублирован в указанный протокол,
который Вы сможете не торопясь изучить и сделать свои пометки. Можно также
использовать команду show <параметр> для
определения конкретного параметра. Можно также просмотреть конфигурационные
параметры с помощью утилиты Oracle Instance Manager из
пакета OEM (см. Часть 1, Глава 6: Oracle Instance Manager (Vai.exe)).

·        
Запомните удобную команду spool <ФайлПротокола> – при этом не потребуется копировать результаты
запросов из окна Oracle SQL*Plus или Oracle SQL Worksheet в файл через буфер обмена. Не
забудьте только отключить спулинг после выполнения скрипта (spool off), т.к. файл протокола не будет закрыт и будет имееть
нулевой размер. И не нужно ставить «;» после этой команды (как и после set echo on), т.к. это не SQL-команда, а
команда самой утилиты.

·        
Если Вы, например, отлаживаете
хранимые процедуры в Oracle SQL*Plus
или Oracle SQL Worksheet, то очень поможет команда show errors, показывающая, в каких строках и какие ошибки имели
место. Имейте только ввиду: если процедура начинается с комментариев, они не
посчитаются за строки. Чтобы этого не произошло, рекомендуется не очень
красивый, но используемый профессионалами способ – сначала писать create procedure Процедура (…) as, затем вводить заголовочные комментарии, а затем
продолжать описание процедуры.

·        
После создания БД также удобно
просматривать ее на наличие таблиц, например, такими командами:

desc МояТаблица;

(при этом выводится описание структуры таблицы)

select TABLE_NAME
from USER_TABLES;  — (ИЛИ … from
TABS);

select
OBJECT_NAME from USER_OBJECTS where OBJECT_TYPE=’TABLE’;

(или
можно использовать представление OBJ вместо USER_OBJECTS)

·        
Запросы к Словарю БД для просмотра
описания или важных параметров пользовательских объектов:

·        
Просмотр параметра LAST NUMBER в последовательности:

·        
Просмотр текста триггера:

·        
Просмотр текста функции:

·        
Просмотр прав для пользователя:

select PRIVILEGE
from SESSION_PRIVS;

·        
Просмотр ролей для
пользователя:

select ROLE from
SESSION_ROLES;

·        
Просмотр прав для роли:

select
GRANTED_ROLE from ROLE_ROLE_PRIVS where ROLE=’DBA’;

·        
Просмотр ролей для
роли:

 

Использование
встроенных модулей

            В
Oracle 8 существуют следующие встроенные модули (подчеркнутые
– используемые в настоящей документации) [2, с.568]:

·        
DBMS_ALERT – Синхронное взаимодействие соединений (сеансов)

·        
DBMS_APPLICATION_INFO – Регистрация приложений для трассировки

·        
DBMS_AQ и DBMS_AQADM – Управление средством Oracle8 Advanced Queuing

·        
DBMS_DEFER, DBMS_QUERY и DBMS_DEFER_SYS – Создание отложенных вызовов удаленных процедур и
управление этими вызовами (используется в репликационном механизме Multimaster)

·        
DBMS_DDL – PL/SQL-эквиваленты для некоторых команд DDL

·        
DBMS_SESCRIBE – Описание хранимых подпрограмм

·        
DBMS_JOB – Планирование выполнения процедур PL/SQL

·        
DBMS_LOB – Работа с объектами LOB в Oracle8

·        
DBMS_LOCK – Блокировки,
определяемые пользователями

·        
DBMS_OUTPUT – Вывод информации на экран

·        
DBMS_PIPE — Асинхронное взаимодействие соединений (сеансов)

·        
DBMS_REFRESH и DBMS_SNAPSHOT – Работа с моментальными снимками

·        
DBMS_REPCAT, DBMS_REPCAT_ADMIN, DBMS_REPCAT_AUTH – Работа со средством симметричного тиражирования Oracle
(используется в репликационном механизме Multimaster)

·        
DBMS_ROWID – Получение информации из идентификаторов строк (ROWID). Преобразование ROWID Oracle7 в ROWID Oracle8 и наоборот

·        
DBMS_SESSION – PL/SQL-эквивалент команды alter session

·        
DBMS_SHARED_POOL – Управление разделяемым пулом

·        
DBMS_SQL – Динамические PL/SQL и SQL (пример
в Главе 3 Части 1)

·        
DBMS_TRANSACTION – Команды
управления транзакциями

·        
DBMS_UTILITY – Дополнительные служебные процедуры

·        
UTL_FILE – Файловый ввод-вывод

Эти модули иногда бывают очень полезны (вывод на
экран, обмен сообщениями), а в ряде случаев без них не обойтись. Например, при
импорте схемы в БД для замены устаревших данных в таблицах данного пользователя
необходимо сначала отключить все триггеры и ограничения для этих таблиц, затем удалить
все данные, и только после этого производить импорт. Затем нужно опять включить
ограничения и триггеры. Чтобы в скрипте не перечислять имена всех таблиц,
триггеров и ограничений, можно их выбрать из Словаря данных (USER_OBJECTS и
др.) и затем использовать как параметры. Это достигается с помощью модуля DBMS_SQL (в Главе 5 Части 1 это будет подробно описано).

Что
применять для ввода команд: SVRMGR30, SQL Plus или SQL Worksheet ?

            Указанные
в заголовке утилиты предназначены для ввода команд SQL (DML и DDL),
запуска скриптов, просмотра ошибок выполнения команд и ввода других команд,
необходимых для управления БД. Следует отметить, что большинство «ручных»
действий (т.е. выполняемых фактически в режиме командной строки), можно проще,
нагляднее и быстрее осуществить в диалоговом режиме с помощью утилит пакета Oracle Enterprise Manager и других. В то же время,
наиболее «тонкое» управление БД, также как и самую исчерпывающую информацию
(находящуюся в Словаре БД, состоящим из многих групп таблиц и представлений),
можно получить только в режиме командной строки.

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

·        
SVRMGR30. Главное удобство – можно пользоваться на сервере Novell Netware. Имеется также удобная команда show parameters для
просмотра конфигурационных параметров. Удобна для запуска больших скриптов
(например, генерации БД или запроса к большой таблице), т.к. не имеет буфера
для хранения исполненных команд. Недостатки – обычные недостатки утилит
командной строки, где все действия нужно определять вводом команд. Но это также
является  мощным достоинством – эту утилиту можно использовать в командных
файлах (BAT и NCF), что позволяет набор однотипных действий выполнить
одним нажатием клавиши. Впрочем, был обнаружен более существенный недостаток – выполняемый
в этой утилите скрипт ломался на комментариях более 1000 символов (в Oracle SQL*Plus все
прошло нормально). Следовательно, и слишком длинные SQL-выражения (часто
встречающиеся в insert и  update) также
не пройдут.

·        
Oracle SQL*Plus. Главные удобства: имеется везде; можно использовать для запуска
больших скриптов (т.к. буфер ограничен); выводит после соединения версию БД. Неудобства:
никаких удобств (нельзя «ползать» по вводимой строке для ее правки; нельзя повторить
предыдущий ввод и т.д.). Еще один недостаток – при соединении нельзя указывать as dba (как в Oracle SQL Worksheet) – для этого нужно явно вводить команду (как и вообще
последующие команды connect). И еще неудобство
– по умолчанию длинные строки переносятся (в отличие от Oracle SQL Worksheet).
Впрочем, при определенном навыке, работа с Oracle SQL*Plus перестает казаться неудобной.

·        
Oracle SQL Worksheet.
Это наиболее удобный «командный» пульт. Имеет неограниченный буфер выполненных
команд и их результатов, имеет историю команд (Ctrl—P – ввод предыдущей комнды, Ctrl—N – ввод следующей команды), позволяет редактировать
вводимую строку. Запуск команды осуществляется кнопкой с молнией или клавишей Ctrl—Enter (в SVRMGR30 и Oracle SQL*Plus надо
было вводить «;», затем нажимать Enter).
Имеется также кнопка для соединения с БД. Утилитой можно пользоваться только на
клиенте, где установлен пакет OEM. Главный недостаток (запомните!) – нельзя
использовать для запуска больших скриптов (например, генерации Словаря БД),
т.к. при заполнении буфера происходит пропорциональное замедление обработки
следующих команд. Если Вам не повезет и в голову придет идея запустить скрипт
генерации БД (да еще без спулинга), то через несколько часов Вы все равно
снимите эту задачу, а потом потратите не известно сколько времени, чтобы
понять, что было создано, а что еще нет (и что надо удалять и заново
пересоздавать). Еще один недостаток – если скрипт большой или запрос
выполняется долго, а Вы переключились в другое окно, то, вернувшись, кроме
песочных часов можете обнаружить белый экран. В Oracle SQL*Plus такая
проблема возникает реже — Вы почти всегда видите весело бегущие строчки. Так
что — да здравствует неудобный Oracle SQL*Plus. А если и он немеет – посмотрите, не «отвалилась» ли
сетка. Такое, к сожалению,
часто бывает.

 

Описание
ряда особенностей при работе с Oracle

Некоторые особенности

ВНИМАНИЕ !

Прежде чем менять пароль основного пользователя в
распределенной БД учтите  следующее:

·        
Свойства связи между БД определены
в объекте dblink, среди которых есть и пароль пользователя для
основной схемы БД (которой принадлежат все таблицы). Смена этого пароля сделает
dblink неверным.

·        
Попытка обновления снимков от
таблиц БД, где произошла описанная смена пароля будет, естесственно, неудачной,
что может привести к зацикливанию таких попыток и приведению всей
распределенной БД в нерабочее состояние.

Обнаруженные некорректности

·        
Неточности и подводные камни в
технической документации:

·        
Никогда не делайте просто shutdown (как сплошь и рядом написано в документации) –
компьютер виснет надолго, а, может, и навсегда (до перезагрузки, что чревато).
Всегда указывайте конкретно, например, shutdown normal или shutdown
immediate.

·        
Для останова БД рекомендовано запускать
ORASTOP.NCF, а для запуска – ORASTART.NCF. Посмотрите вызываемые в них файлы STOPDB.SQL и STARTDB.SQL – и Вы не всегда будете пользоваться этими командными
файлами, либо их откорректируете:

·        
в останове БД выполняется immediate (хотя при отсутствии сервисов лучше делать normal);

·        
БД запускается как nomount (потом надо делать alter database open либо
«переключить светофор» в Oracle Instance Manager из OEM).

·        
Хотя и декларируется, что Novell Netware 5 допускает
длинные имена файлов (и это на самом деле так), но при генерации БД имена
файлов для табличных пространств следует задавать все-таки 8-значными
(например, не INDX1ORCL.ORA, а IND1ORCL.ORA), иначе файл не будет создан.

·        
Неприятности с версиями Oracle:

·        
Если БД создана в Oracle Enterprise Edition
8.0.3. for Novell Netware 5, а на
рабочем месте установлен Oracle Client
8.0.3. for Novell Netware, то Вы сможете лицезреть некорректную работу Oracle ODBC Driver: если
в MS Access 97 в присоединяемой к Oracle
таблице имеются пустые поля типа даты, то
соответствующие записи могут отображаться как ошибочные (метка «Ошибка» в
каждом поле такой записи), запросы к таким таблицам выполняться не будут, а
формы, источниками строк в которых являются эти запросы, будут падать.

·        
Если БД создана в Oracle Enterprise 8.0.3. for Novell Netware 5, а на рабочем месте установлен Oracle Client 8.0.4. for Novell Netware, то
работа Oracle ODBC Driver исправляется, но утилиты EXP80.EXE и IMP80.EXE, а также Oracle Data Manager из
пакета OEM выдают
при работе ошибку: Не могу выполнить экспорт/импорт с БД устаревшей версии.

·        
Единственная корректная версия Oracle для Novell Netware 5 – 8.0.4. Установите
сервер и клиент именно этой версии и затем генерите БД. Не стоит создавать БД
на сервере 8.0.3, а затем делать ее upgrade, т.к.
этот процесс более трудоемкий, чем об этом написано в сопроводительной
документации (в частности, там ничего не говорится о необходимости
перекомпиляции хранимых процедур, модулей и других объектов).

·        
Существуют свои засады и с
версиями Oracle, серверная часть которого установлена на сервере MS Windows NT 4.0, а клиентская – на MS Windows NT 4.0, MS Windows
95 и MS Windows 98.

Что
делать при изменении сетевого адреса сервера

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

Возможные
аварийные ситуации

Молния вывела из строя маршрутизатор

            При
этом вышла из строя связь по TCP/IP-протоколу. Если другие протоколы работоспособны,
введите их описание в файл TNSNAMES.ORA (см. Часть
1, Глава 2: Создание строки соединения TNS  (корректировка
TNSNAMES.ORA)), причем
строку описания работающего протокола переместите на первое место, а аварийного
– на последнее.

Создание резервных копий с помощью утилиты RMAN (Recovery Manager)

Восстановление из резервной копий с помощью утилиты RMAN (Recovery Manager)

На ПК1 сделайте бекап в указаный каталог:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP OFF;
RMAN> backup as COMPRESSED backupset tag DB_BACKUP 
  database format '/tmp/%D_%M_%Y_%u_bkp_%d' plus 
  archivelog format '/tmp/%D_%M_%Y_%u_arc_%d';
RMAN> delete noprompt obsolete;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

На ПК2 сделайте востановление:

RMAN> startup nomount;
RMAN> restore controfile '%path%';

где %path% путь к файлу бекапа хранящего control-файлы (обычно первый по времени созданный, во время бекапа, если не угадали перебираем по очереди), например restore controfile ‘/tmp/20_02_2020_3USJOS2M_BKP_DB’;

RMAN> alter database mount;
RMAN> catalog start with '%path%';

где %path% путь к папке хранящий файлы бекапа, в нашем случае’/tmp/.

RMAN> restore database;
RMAN> recover database;

Если выдало ошибку, что не хватает сегмента базы данных из следующего архивлога, то восстанавливаем по этот сегмент:

RMAN> recover database until sequence=segment;

где segment – номер первого сегмента последующего не хватающего архивлога, на который выдало ошибку при выполнении команды recover database;

RMAN> alter database open reset logs;

Время прочтения
9 мин

Просмотры 5.1K

В последние годы межплатформенная миграция Oracle Database перестала быть уникальной задачей. Компании, как правило, переезжают с рисковых платформ на x86, хотя бывает и наоборот. В этом посте поделимся нашим опытом межплатформенных миграций и подробнее остановимся на описании относительно нового способа физической миграции — расширении TTS.

Первый вопрос — Endian-формат

При межплатформенной миграции базы данных Oracle «переезжают» с одной платформы на другую. Платформы имеют разный порядок байт в файлах, который называется Endian-формат. У рисковых платформ этот формат — Big, у x86 — Little. Здесь приведены данные по различным платформам согласно Metalink-ноте 733205.1 (см. support.oracle.com).

В последних версиях Oracle Database задача миграции между платформами с одинаковым Endian-форматом стала заметно проще. Как правило, работа Oracle Data Guard (Physical Standby) между такими платформами сертифицирована. Миграция через Standby хорошо документирована, требует минимального простоя базы данных и имеет прозрачную процедуру отката (обратный Switchover), если что-то пошло не так. Обычно такую миграцию компании выполняют самостоятельно.

Второй вопрос — сайзинг

Миграция Oracle Database между платформами с разным Endian-форматом значительно сложнее и связана со многими дополнительными аспектами. Например, в сообществе широко обсуждаются вопросы сайзинга. Несколько лет назад мы провели масштабное исследование производительности Oracle Database на самых распространенных рисковых платформах Power/AIX и Sparc/Solaris в сравнении с платформой x86.

Для тестирования мы выбрали нагружающие скрипты Silly Little Oracle Benchmark (SLOB), разработанные Кевином Клоссоном. В отличие от большинства генераторов синтетической нагрузки с «вшитыми» запросами, эти скрипты в несколько потоков запускают собственные запросы к базе данных. Запросы мы разработали так, чтобы избежать влияния дисковой подсистемы (все данные были в прогретом кеше) и конкуренции за внутренние ресурсы экземпляра Oracle (у каждого потока свои данные). Мы измеряли число логических чтений в секунду при растущем объеме параллельных неконкурирующих потоков SLOB. В исследовании участвовали 16-ядерные домены рисковых серверов с актуальными на момент исследования процессорами Power8 и Sparc M7 в сравнении с 16-ядерным x86 сервером Intel. На рисунке показан характерный результат, полученный при сравнении платформ (ось X — потоки SLOB, ось Y — логические чтения в секунду).

На невысоких нагрузках лучшую производительность показывает x86 сервер, в том числе за счет аппаратных возможностей процессора Intel. При росте количества сессий SLOB (после 32) происходит перелом и рисковые серверы выходят вперед — начинает работать многопоточность (в ядре процессора Intel два треда, в ядре процессоров Power8 и Sparc M7 до восьми тредов). Следует заметить, что запросы к Oracle были разработаны таким образом, чтобы утилизировать все треды — в реальных системах это бывает далеко не всегда. Именно многопоточность объясняет окончательную «победу» сервера Sparc. В процессоре Power8 режим SMT=8 (восемь тредов на ядро) работал настолько своеобразно, что даже сам вендор рекомендовал использовать режим SMT=4 (четыре треда на ядро).

Результаты сравнительного исследования оказались неоднозначными. Для себя мы сделали вывод, что получить точный сайзинг можно, только тестируя работу конкретной базы данных на новой платформе. Но для этого базу нужно мигрировать. Поэтому часто требуется предварительный сайзинг, для которого мы используем принцип «ядро в ядро», несмотря на разнообразие сравнительных синтетических тестов типа SpecInt. Этот принцип серьезно усложняет обоснование, почему нужно мигрировать на Power/AIX. Нередко приходится искать дополнительные аргументы со стороны заказчика, а то и с помощью вендора. Дело в том, что оракловый коэффициент многоядерности (Core Factor) для процессоров IBM вдвое выше. И при одинаковом количестве ядер лицензирование Oracle получается вдвое дороже:

Третий вопрос — окно простоя

Вернемся к теме миграции. Есть три принципиально разных подхода к переносу Oracle Database между платформами:

1. Логическая миграция. Классический Export/Import, Data Pump, SQL-команды через Database Link. При этом способе между платформами переносятся не файлы данных, а сами данные. Этот вариант проверен временем и относительно несложный. Он имеет всего одно ограничение: время простоя базы данных получается очень большим.
2. Физическая миграция — Transportable Tablespace или TTS. При физической миграции между платформами переносятся файлы с данными, что значительно быстрее. Созданные на одной платформе файлы подключаются к базе данных на другой, поэтому необходимо тщательное тестирование, в том числе на предмет внутренних ошибок Oracle. TTS имеет сравнительно небольшое количество ограничений, а способы их обхода хорошо документированы.
3. Репликация. Как правило, используется Oracle Golden Gate, хотя это не единственное решение. В основе любой репликации лежит разбор транзакционных журналов на базе-источнике с последующим применением (возможно с трансформацией) на базе-приемнике. Несмотря на развитые средства верификации данных (Oracle вместе с Golden Gate предлагает специальное ПО Veridata), остается серьезный риск потерять данные и не заметить это. Получается, что за целостность перенесенных данных в случаях логической и физической миграции отвечает Oracle, а в случае репликации — исполнитель.

Прошли времена, когда базы данных размером 1 Тб считались большими. Современные БД намного внушительнее, а ограничения на технологические окна со стороны бизнеса стали жестче. Логическая миграция при всей своей надежности оказывается слишком медленной. Миграцию через репликацию приходится долго и скрупулезно тестировать, чтобы в итоге не получить несогласованные данные. Таким образом, физическая миграция (TTS) чаще оказывается оптимальным способом переноса Oracle Database между платформами.

Миграция с помощью TTS создавалась, чтобы быстро переносить оракловые файлы в рамках одной платформы. Уже потом она была расширена функционалом конвертации из одного Endian-формата в другой (технология RMAN Convert). Такая миграция состоит из трех этапов:

• выгрузка метаданных из словаря старой базы;
• перенос файлов данных с конвертацией RMAN;
• загрузка метаданных в словарь новой базы.

Для большинства баз данных этап конвертации является самым долгим и лимитирует общее время миграции — время выгрузки и загрузки метаданных обычно не превышает получаса, а средняя скорость конвертации составляет примерно 1 Тб в час. Однако мы неоднократно сталкивались с исключениями из этого правила. Например, когда в базе данных из-за большого числа объектов словаря (например, в случае комплексного секционирования) выгрузка метаданных по длительности оказалась сопоставима с конвертацией.

Это важно по следующей причине. Начиная с 12 версии RMAN (сама БД при этом быть версии 11) появилась возможность переносить и конвертировать не файлы с данными (что требует недоступности базы на все время переноса), а файлы бекапа (Backup Set). Это позволяет сделать полный бекап и восстановить его на новой платформе без остановки базы данных, а в технологическое окно перенести инкрементальный бэкап — «сконвертировать дельту». Такой способ намного быстрее переноса целой базы. Более того, можно повторить перенос инкрементального бэкапа несколько раз, пока «конвертация дельты» не начнет умещаться в заданное бизнесом технологическое окно.

Такой относительно новый функционал RMAN получил несколько названий, самое точное из которых, на наш взгляд — Cross-Platform Backup/Restore. С его помощью можно сократить время простоя, необходимое для конвертации: особенно если конвертируемые файлы Backup Set расположить на специальной файловой системе Veritas, допускающей переключение между платформами. При этом время выгрузки и загрузки метаданных данный способ не уменьшает!

Новая старая миграция

Новый способ миграции по сути является расширением TTS и на сегодня недостаточно документирован. Чтобы изучить его, необходимо читать синтаксис конкретных команд RMAN. Поэтому поделимся общей процедурой Cross-Platform Backup-Restore, реализованной нами в нескольких конкретных проектах миграции с рисковых платформ на x86.

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

1. Проверки перед миграцией. Проверки для классического TTS изложены в Metalink-ноте 371556.1 и для Cross-Platform Backup/Restore они в целом такие же. Особое внимание следует обратить на пользовательские объекты в табличном пространстве SYSTEM, которое при TTS не переносится и на режим Block Change Tracking.
2. Создание базы данных на целевой платформе с правильной кодировкой и Timezone.
3. Выполнение на исходной базе полного бекапа (level0) с помощью RMAN-команд Backup Incremental Level 0 Datafile ‘номер_файла’ Format ‘формат_backup_set’.
4. Перенос пользователей с исходной базы в целевую базу: временное создание табличных пространств, перенос пользователей утилитами expdp/impdp, удаление табличных пространств (таким образом удается перенести пользователей до того, как табличные пространства будут перенесены TTS).
5. Генерация на исходной базе скрипта по раздаче привилегий пользователей.
6. Восстановление целевой базы из перенесенного полного бекапа (level0) с помощью RMAN-команд Restore From Platform ‘название_исходной_платформы’ All Foreign Datafiles Format ‘формат_backup_set’ From Backupset ‘имя_backup_set’. Название исходной платформы следует писать строго как в таблице Endian-форматов (см. начало статьи) — например, для Power/AIX это AIX-Based Systems (64-bit).
7. Выполнение на исходной базе инкрементального бекапа (level1) с помощью RMAN-команд Backup Incremental Level 1 Datafile ‘номер_файла’ Format ‘формат_backup_set’.
8. Применение на целевой базе перенесенного инкрементального бекапа level1 c помощью RMAN-команд Recover From Platform ‘название_исходной_платформы’ Foreign Datafilecopy ‘формат_backup_set’ From Backupset ‘имя_backup_set’. Шаги 1-8 можно делать вне технологического окна. Далее перечислены шаги процедуры миграции, требующие простоя.
9. Перевод табличных пространств исходной базы данных в режим READ ONLY с помощью SQL-команд Alter Tablespace имя Read Only.
10. Выполнение на исходной базе инкрементального бекапа (level1) с помощью RMAN-команд Backup Incremental Level 1 Datafile ‘номер_файла’ Format ‘формат_backup_set’.
11. Параллельно п. 10 выгрузка из исходной базы метаданных пользователей утилитой expdp. Мы используем параметры «content=metadata_only exclude=user,role,role_grant,profile»).
12. Параллельно п. 10 выгрузка из исходной базы метаданных табличных пространств утилитой expdp. Мы обычно используем параметры «exclude=table_statistics,index_statistics transport_full_check=no transport_tablespaces=список_табличных_пространств» т. к. выгрузка статистики оптимизатора часто оказывается долгой, особенно в базах данных 12 версии. В этом случае статистику нужно либо перенести пакетом DBMS_STATISTICS, либо частично собрать на целевой базе.
13. Применение на целевой базе перенесенного инкрементального бекапа level1 (это второй инкрементальный бекап, выполненный в окно простоя) c помощью RMAN-команд Recover From Platform ‘название_исходной_платформы’ Foreign Datafilecopy ‘формат_backup_set’ From Backupset ‘имя_backup_set’.
14. Загрузка в целевую базу метаданных табличных пространств, метаданных пользователей утилитой (оба действия — утилита impdp) и раздача пользователям привилегий (созданный в п. 5 скрипт).
15. Перевод табличных пространств целевой базы данных в режим READ WRITE с помощью SQL-команд Alter Tablespace имя Read Write.
16. Проверка INVALID объектов целевой базы данных и при необходимости их компиляция. Это последний шаг описанной процедуры. На этом межплатформенная физическая миграция с помощью Cross-Platform Backup/Restore завершена!

За последние полгода мы несколько раз прибегали к описанной выше процедуре миграции. Переносили базу данных системы лояльности (версия 12, размер порядка 5 Тб) с платформы Power/AIX на платформу x86/Linux в крупном банке. В ходе нескольких тестовых миграций мы зафиксировали следующие тайминги — 1,5 часа при «ручном» переносе статистики оптимизатора и 3,5 часа при ее переносе в рамках TTS (см. п. 12 процедуры миграции). Бизнес согласовал технологическое окно длительностью 6 часов. Поэтому банк при продуктивной миграции предпочел использовать более долгую, но более простую и надежную процедуру. Вместе с заказчиком она и была реализована.

Автор: Алексей Струченко, руководитель направления СУБД «Инфосистемы Джет»

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

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

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

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

В качестве тестовых мы возьмём две виртуальные машины alfa.alldba.ru и alfa2.alldba.ru с операционными системами Linux CentOS 5.4 и экземплярами базы данных Oracle 10.2. Структура каталогов файловых систем хостов одинакова. Перед нами стоит задача получения рабочего дубликата  целевой базы данных хоста alfa.alldba.ru, и размещение его в виртуальной машине alfa2.alldba.ru. Экземпляр Oracle расположенный на хосте alfa2.alldba.ru в дальнейшем будет называться вспомогательным (Auxiliary), и будет иметь только одно предназначение – это помощь в создании дублированной базы данных.

Для простоты примера, файлы Oracle в основной и дублированной базе данных будут иметь у нас одинаковые имена и местоположения, а дублирование будет производиться базовым методом.

Базовое дублирование

Создание резервной копии

Так как дублированная база создаётся из резервной копии основной базы данных, первым делом с помощью RMAN проводим полное резервное копирование целевой базы данных хоста alfa.alldba.ru:

RMAN> backup database;

Starting backup at 02-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 02-MAR-12
channel ORA_DISK_1: finished piece 1 at 02-MAR-12
piece 
handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/o1_mf_nnndf_TAG20120
302T092347_7o0svmmk_.bkp tag=TAG20120302T092347 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:06:57
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 02-MAR-12
channel ORA_DISK_1: finished piece 1 at 02-MAR-12
piece 
handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/o1_mf_ncsnf_TAG20120
302T092347_7o0t8plr_.bkp tag=TAG20120302T092347 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 02-MAR-12

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

RMAN> list backup;

List of Backup Sets
===================
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
108     Full    610.20M    DISK        00:06:55     02-MAR-12      
        BP Key: 119   Status: AVAILABLE  Compressed: NO  Tag: TAG20120302T092347
        Piece Name: 
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/o1_mf_nnndf_TAG20120302T092
347_7o0svmmk_.bkp
  List of Datafiles in backup set 108
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 658208     02-MAR-12 /u02/oradata/orcl/system01.dbf
  2       Full 658208     02-MAR-12 /u02/oradata/orcl/undotbs01.dbf
  3       Full 658208     02-MAR-12 /u02/oradata/orcl/sysaux01.dbf
  4       Full 658208     02-MAR-12 /u02/oradata/orcl/users01.dbf
  5       Full 657258     02-MAR-12 /u02/oradata/orcl/example01.dbf
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
109     Full    6.83M      DISK        00:00:02     02-MAR-12      
        BP Key: 120   Status: AVAILABLE  Compressed: NO  Tag: TAG20120302T092347
        Piece Name: 
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/o1_mf_ncsnf_TAG20120302T092
347_7o0t8plr_.bkp
  Control File Included: Ckp SCN: 658245       Ckp time: 02-MAR-12
  SPFILE Included: Modification time: 02-MAR-12

Перенос резервной копии

Так как одним из основных требований дублирования является наличие резервных копий и архивных файлов  на хосте, где будет создаваться дублированная база данных, нам необходимо перенести полученную копию и архивы на машину alfa2.alldba.ru, соблюдая при этом те же пути расположения файлов в файловой системе, что и на основном хосте. Для переноса будем использовать sft клиент.

Переходим на машину alfa2.alldba.ru и запускаем клиент, в котором подключаемся к хосту alfa.alldba.ru:

alfa.alldba.ru:
[oracle@alfa2 ~]$ sftp alfa.alldba.ru
Connecting to alfa.alldba.ru...
The authenticity of host 'alfa.alldba.ru (190.125.250.200)' can't be 
established.
RSA key fingerprint is 81:ab:40:5d:a3:e0:6f:7f:d8:b0:50:40:b9:fb:0e:34.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'alfa.alldba.ru,190.125.250.200' (RSA) to the list 
of known hosts.
Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.'s password:

Переходим на удалённой машине (alfa.alldba.ru) в каталог с файлом резервной копии:

sftp> cd /u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/

На локальной машине(alfa2.alldba.ru) создаём в флэш-области восстановления для резервной копии необходимые каталоги:

sftp> lmkdir /u01/app/oracle/flash_recovery_area/ORCL/backupset
sftp> lmkdir /u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/

Переходим  в созданный  каталог,проверяем одинаковость путей для резервной копии на обеих машинах и копируем файл резервной копии с alfa.alldba.ru:

sftp> lcd /u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/
sftp> pwd
Remote working directory: 
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02
sftp> lpwd
Local working directory: 
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02
sftp> mget *
Fetching 
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/o1_mf_ncsnf_TAG2
0120302T092347_7o0t8plr_.bkp to o1_mf_ncsnf_TAG20120302T092347_7o0t8plr_.bkp
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/o1_mf_ncsnf_TAG2
0120302 100% 7008KB   6.8MB/s   00:01    
Fetching 
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/o1_mf_nnndf_TAG2
0120302T092347_7o0svmmk_.bkp to o1_mf_nnndf_TAG20120302T092347_7o0svmmk_.bkp
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/o1_mf_nnndf_TAG2
0120302T092 100%  610MB   2.9MB/s   03:31    3

Копирование архивных журналов

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

sftp> pwd
Remote working directory: /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02
sftp> ls -l
-rw-r-----    1 oracle   oinstall  3846144 Mar  2 09:42 o1_mf_1_16_7o0ty7cb_.arc
-rw-r-----    1 oracle   oinstall   532992 Mar  2 09:42 o1_mf_1_17_7o0tyhox_.arc
-rw-r-----    1 oracle   oinstall  5256704 Mar  2 09:42 o1_mf_1_18_7o0tz0tp_.arc

Скопируем весь каталог 2012_03_02 с машины alfa.alldba.ru на машину alfa2.alldba.ru, не забывая при этом соблюдать одинаковость путей расположения файлов:

sftp> cd /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02
sftp> lmkdir /u01/app/oracle/flash_recovery_area/ORCL/archivelog
sftp> lmkdir /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02
sftp> lcd /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02
sftp> pwd
sftp> pwd
Remote working directory: 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02
sftp> lpwd
Local working directory: 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02
sftp> mget *
Fetching 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_16_7o0t
y7cb_.arc to o1_mf_1_16_7o0ty7cb_.arc
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_16_7o0t
y7cb_.arc                              100% 3756KB   1.2MB/s   00:03    
Fetching 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_17_7o0t
yhox_.arc to o1_mf_1_17_7o0tyhox_.arc
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_17_7o0t
yhox_.arc                              100%  521KB 520.5KB/s   00:01    
Fetching 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_18_7o0t
z0tp_.arc to o1_mf_1_18_7o0tz0tp_.arc
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_18_7o0t
z0tp_.arc                              100% 5134KB   1.7MB/s   00:03
sftp> bye

Старт вспомогательного экземпляра

Непосредственно перед проведением процесса дублирования необходимо перевести экземпляры в нужные состояния. Экземпляр целевой базы данных (Target) на терминале alfa.alldba.ru должен быть обязательно открыт или смонтирован. Вспомогательный (Auxiliary) экземпляр на машине alfa2.alldba.ru должен находиться в несмонтированном режиме:

oracle@alfa2 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Fri Mar 2 05:43:26 2012
Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
Connected to an idle instance.

SQL> startup force nomount;

ORACLE instance started.
Total System Global Area  285212672 bytes
Fixed Size                  1261372 bytes
Variable Size             268435652 bytes
Database Buffers           12582912 bytes
Redo Buffers                2932736 bytes

Подключение к экземплярам

Для проведения процесса дублирования нам надо иметь два подключения, одно к экземпляру целевой базы данных, другое к вспомогательному экземпляру. Место расположения клиента RMAN, из которого будут производиться эти подключения, большого значения не имеет. Дублирование можно производить с любого клиентского хоста. Но чтобы не сильно зависеть  от состояния сетевого соединения и клиентской машины,  процесс лучше организовать  на хосте, где будет располагаться дублированная база данных. В нашем случае это будет хост alfa2.alldba.ru.

Запускаем RMAN и для начала попытаемся подключиться к целевой базе данных под пользователем system.

RMAN> connect target system/Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.;
MAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
ORA-01031: привилегий недостаточно

Возникает ошибка. Оказывается для дублирования необходимо подключение пользователя SYS или пользователя обладающего правами SYS. Последнего мы сейчас и создадим в Oracle на сервере alfa.alldba.ru:

SQL> grant connect, sysdba to duser identified by pass;
Grant succeeded.

Пробуем снова подключиться, но уже под новым  пользователем DUSER:

RMAN> connect target duser/Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.;
connected to target database: ORCL (DBID=1265664822)

Подключение успешно. Теперь мы можем соединиться с вспомогательным экземпляром (не забываем, что мы находимся на хосте вспомогательного экземпляра):

RMAN> connect auxiliary /;
connected to auxiliary database: ORCL (not mounted)

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

Дублирование

Наберём в RMAN следующую команду:

RMAN> duplicate target database to orcl nofilenamecheck;

Данная команда запустит процесс дублирования целевой базы данных, в результате которого на хосте alfa2.alldba.ru будет получена новая база данных с именем orcl. Указанное в команде ключевое слово nofilenamecheck выключает проверку имён восстанавливаемых файлов. То есть, если на хосте дублированной базы данных во время процесса дублирования попадётся уже существующий файл, по тому же пути и с тем же самым именем, то  ошибка сгенерирована не будет, и файл будет заменён (не забываем, что старые файлы базы данных на хосте alfa2.alldba.ru всё ещё существуют).

Рассмотрим более подробно отчет, который выдает команда DUPLICATE.

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

Starting Duplicate Db at 02-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

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

contents of Memory Script:
{
   set until scn  658802;
   set newname for datafile  1 to 
 "/u02/oradata/orcl/system01.dbf";
   set newname for datafile  2 to 
 "/u02/oradata/orcl/undotbs01.dbf";
   set newname for datafile  3 to 
 "/u02/oradata/orcl/sysaux01.dbf";
   set newname for datafile  4 to 
 "/u02/oradata/orcl/users01.dbf";
   set newname for datafile  5 to 
 "/u02/oradata/orcl/example01.dbf";
   restore
   check readonly
   clone database
   ;
}

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

executing Memory Script
executing command: SET until clause
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 02-MAR-12
using channel ORA_AUX_DISK_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 
/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/o1_mf_nnndf_TAG20120302T092
347_7o0svmmk_.bkp
channel ORA_AUX_DISK_1: restored backup piece 1
piece 
handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_03_02/o1_mf_nnndf_TAG20120
302T092347_7o0svmmk_.bkp tag=TAG20120302T092347
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:46
Finished restore at 02-MAR-12

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

sql statement: CREATE CONTROLFILE REUSE SET DATABASE "ORCL" RESETLOGS ARCHIVELOG 
  MAXLOGFILES     16
  MAXLOGMEMBERS      3
  MAXDATAFILES      100
  MAXINSTANCES     8
  MAXLOGHISTORY      292
 LOGFILE
  GROUP  1 ( '/u02/oradata/orcl/redo01.log' ) SIZE 50 M  REUSE,
  GROUP  2 ( '/u02/oradata/orcl/redo02.log' ) SIZE 50 M  REUSE,
  GROUP  3 ( '/u02/oradata/orcl/redo03.log' ) SIZE 50 M  REUSE
 DATAFILE
  '/u02/oradata/orcl/system01.dbf'
 CHARACTER SET CL8ISO8859P5

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

contents of Memory Script:
{
   switch clone datafile all;
}
executing Memory Script
released channel: ORA_AUX_DISK_1
released channel: ORA_AUX_SBT_TAPE_1
datafile 2 switched to datafile copy
input datafile copy recid=1 stamp=776843437 filename=/u02/oradata/orcl/undotbs01.dbf
datafile 3 switched to datafile copy
input datafile copy recid=2 stamp=776843437 filename=/u02/oradata/orcl/sysaux01.dbf
datafile 4 switched to datafile copy
input datafile copy recid=3 stamp=776843437 filename=/u02/oradata/orcl/users01.dbf
datafile 5 switched to datafile copy
input datafile copy recid=4 stamp=776843437 filename=/u02/oradata/orcl/example01.dbf

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

contents of Memory Script:
{
   set until scn  658802;
   recover
   clone database
    delete archivelog
   ;
}

Ниже приведён результат выполнения этого скрипта:

executing Memory Script
executing command: SET until clause
Starting recover at 02-MAR-12
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: sid=155 devtype=DISK
starting media recovery
archive log thread 1 sequence 16 is already on disk as file 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_16_7o0ty7cb_.arc
archive log thread 1 sequence 17 is already on disk as file 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_17_7o0tyhox_.arc
archive log thread 1 sequence 18 is already on disk as file 
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_18_7o0tz0tp_.arc
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_16_7o0ty7
cb_.arc thread=1 sequence=16
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_17_7o0tyh
ox_.arc thread=1 sequence=17
archive log 
filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2012_03_02/o1_mf_1_18_7o0tz0
tp_.arc thread=1 sequence=18
media recovery complete, elapsed time: 00:00:02
Finished recover at 02-MAR-12

Дублированная база данных восстановлена до актуального состояния. Следующие две команды нового скрипта перезагружают вспомогательный экземпляр (auxiliary) в режим без монтирования:

contents of Memory Script:
{
   shutdown clone;
   startup clone nomount ;
}
executing Memory Script
database dismounted
Oracle instance shut down
connected to auxiliary database (not started)
Oracle instance started
Total System Global Area     285212672 bytes
Fixed Size                     1261372 bytes
Variable Size                268435652 bytes
Database Buffers              12582912 bytes
Redo Buffers                   2932736 bytes
sql statement: CREATE CONTROLFILE REUSE SET DATABASE "ORCL" RESETLOGS ARCHIVELOG 
  MAXLOGFILES     16
  MAXLOGMEMBERS      3
  MAXDATAFILES      100
  MAXINSTANCES     8
  MAXLOGHISTORY      292
 LOGFILE
  GROUP  1 ( '/u02/oradata/orcl/redo01.log' ) SIZE 50 M  REUSE,
  GROUP  2 ( '/u02/oradata/orcl/redo02.log' ) SIZE 50 M  REUSE,
  GROUP  3 ( '/u02/oradata/orcl/redo03.log' ) SIZE 50 M  REUSE
 DATAFILE
  '/u02/oradata/orcl/system01.dbf'
 CHARACTER SET CL8ISO8859P5

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

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

contents of Memory Script:
{
   set newname for tempfile  1 to 
 "/u02/oradata/orcl/temp01.dbf";
   switch clone tempfile all;
   catalog clone datafilecopy  "/u02/oradata/orcl/undotbs01.dbf";
   catalog clone datafilecopy  "/u02/oradata/orcl/sysaux01.dbf";
   catalog clone datafilecopy  "/u02/oradata/orcl/users01.dbf";
   catalog clone datafilecopy  "/u02/oradata/orcl/example01.dbf";
   switch clone datafile all;
}
executing Memory Script
executing command: SET NEWNAME
renamed temporary file 1 to /u02/oradata/orcl/temp01.dbf in control file
cataloged datafile copy
datafile copy filename=/u02/oradata/orcl/undotbs01.dbf recid=1 stamp=776843459
cataloged datafile copy
datafile copy filename=/u02/oradata/orcl/sysaux01.dbf recid=2 stamp=776843459
cataloged datafile copy
datafile copy filename=/u02/oradata/orcl/users01.dbf recid=3 stamp=776843460
cataloged datafile copy
datafile copy filename=/u02/oradata/orcl/example01.dbf recid=4 stamp=776843460
datafile 2 switched to datafile copy
input datafile copy recid=1 stamp=776843459 filename=/u02/oradata/orcl/undotbs01.dbf
datafile 3 switched to datafile copy
input datafile copy recid=2 stamp=776843459 filename=/u02/oradata/orcl/sysaux01.dbf
datafile 4 switched to datafile copy
input datafile copy recid=3 stamp=776843460 filename=/u02/oradata/orcl/users01.dbf
datafile 5 switched to datafile copy
input datafile copy recid=4 stamp=776843460 filename=/u02/oradata/orcl/example01.dbf

И наконец, последний скрипт содержит всего одну команду, которая открывает полученную новую базу данных с опцией RESETLOG. Команда сбрасывает текущий SCN в единицу, архивирует незаархивированные журнальные файлы, в том числе и текущий журнал, и отбрасывает всю REDO информацию неприменённую во время восстановления. Этой же командой пересоздаются и текущие онлайн журналы:

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

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

Устранение ошибок

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

Cannot re-create tempfile /u02/oradata/orcl/temp01.dbf, the same name file 
exists

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

SYSTEM@ALFA2> SELECT member FROM v$logfile;
 
MEMBER                                                                  
------------------------------------------------------------------------
/u01/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_3_75do5wbp_.log
/u01/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_2_75do5vhv_.log
/u01/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_1_75do5thj_.log

В чём причины этих «ошибок» и как их исправить?

Начнём с неудачной попытки пересоздания файла временного табличного пространства. Как известно, в резервную копию, которую делает RMAN на целевой базе данных, не включаются файлы временных табличных пространств и файлы оперативного журнала. Подразумевается, что они будут пересозданы во время дублирования. Местоположение файлов временного табличного пространства заносится в новый контрольный файл во время выполнения скрипта, устанавливающего новые имена  для этих файлов (команда SET NEWNAME FOR TEMPFILE). Следующая за этим команда переключения SWITCH переводит  временные файлы в статус текущих, попутно пересоздавая их. Так как файл временного табличного пространства не заменяется,  а  пересоздаётся, возникает конфликт с файлом temp01.dbf, который уже до этого находился в каталоге /u01/opt/oracle/oradata/orcl. В процессе дублирования, во время перезагрузки экземпляра, этот старый файл пытается пройти тест на принадлежность к базе данных и не проходит его, выдавая ошибку ORA-01186. Следующая за тестом попытка пересоздания файла temp01.dbf тоже терпит неудачу. Похоже, опция NOFILENAMECHECK не действует на файлы временного табличного пространства. Впрочем, вполне возможно в будущих релизах Oracle это будет исправлено.

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

alter database tempfile '/u02/oradata/orcl/temp01.dbf' drop including 
datafiles;
alter tablespace temp add tempfile '/u02/oradata/orcl/temp01.dbf' size 82m;

Можно так же удалить файл temp01.dbf,  предшествующей базы данных хоста  alfa2.alldba.ru до начала дублирования. Тогда пересоздание файла временного табличного пространства пройдёт автоматически, без ошибок, ведь физически этого файла уже не будет.

Третий  вариант  немного экзотический. Его суть состоит в использовании параметра инициализации db_file_name_convert. Хотя этот параметр используется в основном для файлов данных, когда надо переименовать имя или расположение файла в дублированной базе данных, для файлов временного табличного пространства его можно тоже использовать.  Изменяем вышеуказанный параметр. В качестве его значения перечислим  местоположение файлов временного табличного пространства в основной и дублированной базе данных. Имена у этих файлов будут разные:

SQL> alter system set db_file_name_convert='/u02/oradata/orcl/temp01.dbf',
'/u02/oradata/orcl/temp02.dbf' SCOPE=SPFILE;
System altered.

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

[oracle@alfa2 orcl]$ ls –l
…
-rw-r----- 1 oracle oinstall  85991424 Авг 26 12:56 temp01.dbf
-rw-r----- 1 oracle oinstall  85991424 Мар  2 11:08 temp02.dbf
…

В процессе дублирования произошло изменение имени файла temp01.dbf на temp02.dbf, после чего он был благополучно создан и добавлен во временное табличное пространство:

SYSTEM@ALFA2> select status, name from v$tempfile;
 
STATUS NAME                        
------ ----------------------------
ONLINE /u02/oradata/orcl/temp02.dbf

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

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

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

SYSTEM@ALFA2> show parameters db_recovery_file_dest

Параметр                   Тип     Значение                            
-------------------------- ------- ------------------------------------
db_recovery_file_dest      string  /u01/app/oracle/flash_recovery_area/

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

SQL> alter system set 
log_file_name_convert='/u02/oradata/orcl/','/u02/oradata/orcl/' SCOPE=SPFILE;
System altered.

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

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

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

• Создание в RMAN резервной копии целевой базы данных.
• Копирование резервной копии и необходимых архивных журнальных файлов с хоста целевой базы данных на хост вспомогательного экземпляра.
• Установка значения параметра log_file_name_convert во вспомогательном экземпляре;
• Старт вспомогательного экземпляра в несмонтированном режиме.
• Запуск RMAN на хосте вспомогательного экземпляра.
• Подключение из RMAN к экземпляру целевой базы данных и вспомогательному экземпляру.
• Запуск из RMAN процесса дублирования целевой базы данных.
• Удаление и создание файла временного табличного пространства в дублированной базе данных.

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