Пак за преточването на данни

 Общи  Коментарите са изключени за Пак за преточването на данни
Сеп. 012009
 

Като ми следи някой постингите, може да си каже, че само претакам данни насам-натам като зелева чорба. Не е така, рядко се налага, за това пък е хем интересно, хем има достатъчно не-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

Това е всичко. Само две прости команди… 🙂

 Posted by at 9:02