Като ми следи някой постингите, може да си каже, че само претакам данни насам-натам като зелева чорба. Не е така, рядко се налага, за това пък е хем интересно, хем има достатъчно не-custom, за да мога да го споделям в блога си. А това описание го правя както за споделяне с другите, така и за себе си – след време да не се чудя как го бях направил 🙂
И така, този път ще преточа няколко стотин гигабайта по най-бързия възможен начин: transportable tablespace. Използвам следните уточнения:
– БД-източник е на AIX и е версия 10.2.0.3. БД-приемник е на Linux x64 и е версия 11.1.0.7 (ужасно свежа с пачването, чак до последния CPU), т.е. имаме разлика както във версиите, така и в платформите
– данните в БД-източник са на файлова система, а на БД-приемник ще ги сложа на ASM.
– Имах щастието файловата система на БД-източник да бъде монтирана на сървърите на БД-приемник (read-only), за да мога да си изтакам файловете директно
И понеже има доста tablespaces и ще пренасям данните на порции, гледам да си направя стъпките някак хем прости и малко на брой, хем ефективни. За това си подготвих следните улеснения:
– както вече написах, системните администратори монтираха файловата система с data файловете от системата-източник на сървърите на системата-приемник (read-only!)
– в БД-приемник създадох database link към БД-източник. Напоследък съм много влюбен в използването на Data Pump през databse link (благодаря на Юлиян Дончев, че ми подсказа за това улеснение). По този начин си спестявам генерирането на dump file на едната система и пренасянето му до другата.
– конвертирането на tablespaces става с RMAN. Това е почти единственият начин за прехвърляне на много големи обеми от данни между различни платформи – логическият export/import, бил той по стария начин или с data pump, би отнел ужасно много време. За rman си подготвих скрипт за прехвърляне на данните, за да не набирам всичко всеки път
– прехвърлянето на метаданните, както вече загатнах, извършвам с Data pump. За този етап също си подготвих параметричен файл.
И ето така се достигна до следният сложен механизъм за прехвърляне в 2 стъпки:
1. Конвертиране на файловете от старата платформа към новата, едновременно с прехвърлянето им в ASM. Използвам следният файл:
$ cat ~/rman_convert.cmd
CONVERT DATAFILE '/mnt/oradata/old_db/data/local/big_tbs_01.dbf'
FROM PLATFORM 'AIX-Based Systems (64-bit)'
DB_FILE_NAME_CONVERT '/mnt/oradata/old_db/','+DATA/new_db/datafile/';
CONVERT DATAFILE '/mnt/oradata/old_db/data/local/big_tbs_02.dbf'
FROM PLATFORM 'AIX-Based Systems (64-bit)'
DB_FILE_NAME_CONVERT '/mnt/oradata/old_db/','+DATA/new_db/datafile/';
CONVERT DATAFILE '/mnt/oradata/old_db/data/local/big_tbs_03.dbf'
FROM PLATFORM 'AIX-Based Systems (64-bit)'
DB_FILE_NAME_CONVERT '/mnt/oradata/old_db/','+DATA/new_db/datafile/';
. . .
– За да сработи това трябва съответния tablespace да е read-only на БД-източник през цялото време. Има начини това време да се намали, но за щастие аз мога да си позволя по-дълъг период read-only.
– Както виждате RMAN няма нужда да се закача към БД-източник и не използва контролния и файл, а чете директно посочения datafile.
– Също така тук е интересно, че on-the-fly се случва едно конвертиране от Big endian в Little endian формат на данните.
– Параметърът db_file_name_convert указва как да се промени името на файла (заедно с пътя). По този начин файла се озовава върху ASM
Самото изпълнение се случва така (на новата система):
rman target / cmdfile=~/rman_convert.cmd
2. Прехвърляне на метаданните и „закачане“ на копираните tablespaces в новата БД. Използвам datapump със следния параметричен файл:
$ cat ~/transmore.par
NETWORK_LINK=OLD_DB
TRANSPORT_TABLESPACES=big_tbs_01,big_tbs_02,big_tbs_03, . . .
TRANSPORT_FULL_CHECK=n
TRANSPORT_DATAFILES='+DATA/new_db/datafile/data/local/big_tbs_01.dbf','+DATA/new_db/datafile/data/local/big_tbs_02.dbf','+DATA/new_db/datafile/data/local/big_tbs_03.dbf', . . .
NOLOGFILE=Y
EXCLUDE=STATISTICS
– Важно е пренасяните на един път tablespaces да съдържат всички взаимносвързани обекти – т.е. всички таблици, закачени с foreign keys, всичките им индекси и т.н. Понеже аз знам, че в моя случай съм изпълнил това изискване, инструктирам datapump да не проверява с TRANSPORT_FULL_CHECK=n. Всъщност това си е стойността по подразбиране, но нищо не вреди да я сложа изрично – да се замисля след години като видя същия скрипт
– Параметъра TRANSPORT_DATAFILES указва къде се намират новите файлове. Ако не се зададе това, data pump ще ги търси на същото място, на което са в БД-източник.
– понеже съм си леко мързелив по природа, пък и имам да пренасям десетки tablespaces, си генерирам TRANSPORT_DATAFILES от системата-източник така:
select ''''||replace(file_name, '/mnt/oradata/old_db/', '+DATA/new_db/datafile/')||''',' from dba_data_files;
Всъщност по аналогичен начин си генерирам и rman скрипта.
Самото извикване на Data pump е
$ impdp system@new_db PARFILE=~/transmore.par
Това е всичко. Само две прости команди… 🙂