Data Guard Support for Heterogeneous Configuration

 Useful links  Коментарите са изключени за Data Guard Support for Heterogeneous Configuration
Дек. 162008
 

Ако се налага да пуснете DataGuard Между различни платформи, тук са описани валидните комбинации:

Note:413484.1 Data Guard Support for Heterogeneous Primary and Standby Systems in Same Data Guard Configuration

Примерно от версия 10g се поддържа Primary база на Microsoft Windows (x86) да се резервира с Phisical Standby БД на Microsoft Windows (x86), Microsoft Windows (64-bit Itanium), Microsoft Windows (x86-64) и Linux x86.

 Posted by at 17:24
Дек. 162008
 

Преди седмица инсталирах 11.1.0.7 на една development база, с идеята после да го сложа и на тестовата по същия проект. Обаче на тази база се завихриха едни ora-600 грешки, които не успях да оправя навреме и закъснях с пачването на тестовата.

Днес претаках едни данни от development базата (11.1.0.7) в тестовата (11.1.0.6). Естествено, според принципа на Oracle „няма скука тука“, нещата не станаха много лесно. Импорта гръмна със следната грешка:

impdp system@XXXX schemas=XXXX directory=DATA_PUMP_DIR dumpfile=ESODPL_NEW_16122008_2.DMP

Import: Release 11.1.0.6.0 - 64bit Production on Tuesday, 16 December, 2008 9:08:34

Copyright (c) 2003, 2007, Oracle. All rights reserved.
Password:

Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39002: invalid operation
ORA-31694: master table "SYSTEM"."SYS_IMPORT_SCHEMA_01" failed to load/unload
ORA-02354: error in exporting/importing data
ORA-02373: Error parsing insert statement for table "SYSTEM"."SYS_IMPORT_SCHEMA_01".
ORA-00904: "ORIGINAL_OBJECT_NAME": invalid identifier

Веднага се усетих, че може да не му харесва версията. Със старите exp/imp беше относително лесно – пускаш exp от компютър, на който има по-старата от двете версии и всичко заспива. Сега, обаче, expdp и impdp са само клиенти, а самия експорт се прави от database сървъра. За такива случаи има предвидена клаузата version:

expdp system@XXXX schemas=XXXX directory=data_pump_dir dumpfile=esodpl_new_16122008_3.dmp version=11.1.0.6

Да, обаче… греда. И наистина, би било много лесно ако всичко просто си работи. Усетих миризмата на буболечки и реших да потърся какво пише по въпроса в MetaLink. Не ми отне много време да намеря Note:752374.1 „11.1.0.6 Datapump Import of an 11.1.0.7 Dump Fails With ORA-904 „Original_object_name“. Причината е много близа до това, което предположих:

This is caused by Bug 7590679.
The „ORIGINAL_TABLE_NAME“ column was introduced in 11.1.0.7 by the fix for unpublished Bug 5955150.

This issue reproduces when importing an 11.1.0.7 dump file into 11.1.0.6.

Bug 7590679 is currently being worked by Development who needs to decide between:
– a/ the target (11.1.0.6) also needs the fix from unpublished Bug 5955150.
In that case, One-off patches may be created later.
– b/ or whether 11.1.0.7 should be capable of creating a Dump files compatible with 11.1.0.6

Решението, обаче, не ме изкефи:

Having both source and target on 11.1.0.7 will avoid this issue.

To avoid this error, apply our 11.1.0.7 patchset also on the target database.

В момента не мога да скоча и да пачвам тестовата система, трябва да изчакам поне до вчерта. За това пробвах друго решение. Експортирах за най-старата версия, която се поддържа:

expdp system@XXXX schemas=XXXX directory=data_pump_dir dumpfile=esodpl_new_16122008_4.dmp version=10.1

Dump файла стана около два пъти по-голям. Но важното е, че импорта мина. Това решение ми се струва по-лесно, макар да има и странични ефекти.

Поздрави 🙂

 Posted by at 10:59