In a project I have to move an Oracle 11.2.0.4-DB (around 7TB in size) from Sparc Solaris (called Source in the remainder of this Blog) to Linux x86-64 (called Target in the remainder of the Blog). I.e. a platform migration from Big Endian to Little Endian. A good method to do that is described in My Oracle Support Note 1389592.1:<\/p>\n
11G – Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup<\/p>\n
Basically I copy the DB-Files using dbms_file_transfer.get_file, which also does the conversion from Big to Little Endian. Afterwards incremental Backups are applied to the transferred files and in a final step the files are attached to the Target DB using the metadata-import of transportable tablespaces.<\/p>\n
Following the steps mentioned in that Note 1389592.1 I ran into 2 Bugs:<\/p>\n
1.) Bug 19574653 – ORA-7445 [sxorchk] and call stack has function krhcvt_filhdr_v10 (Doc ID 19574653.8)
\n2.) Bug 19566227 (base bug 20563128) described in MOS Note 2015883.1: Cross Platform Migration Using XTT Method With RMAN<\/p>\n
The first bug 19574653 could be resolved easily, because I was allowed to install that associated patch on the target system. The second bug was more difficult, because it requires the patch 20563128 to be installed on the source and the target system. As no downtime was possible, I couldn’t install that patch on the source system.<\/p>\n
Bug 19574653 actually shows the following behavior:<\/p>\n
During transfer ($ORACLE_HOME\/perl\/bin\/perl xttdriver.pl -G) the following error happens for a couple of files:<\/p>\n
The nasty thing is that the process of transferring files stops and you have to manually adjust the files xttnewdatafiles.txt and getfile.sql to be able to continue from the point where it failed. That’s difficult in a 7TB-DB with 875 Datafiles. <\/p>\n To get the failed file transferred, a workaround is described in MOS Note 2015883.1: E.g. assume DWH_BUB_DATA_P06_01.dbf couldn’t be transferred;<\/p>\n Source:<\/p>\n Target:<\/p>\n What I wanted to achieve was that the transfer of datafiles runs through without error and I do report the failed transfers in a table and use above workaround at the end of the whole transfer phase. <\/p>\n Here’s what I did:<\/p>\n On the target system I created a table system.transfer_errors to catch the affected files of bug 19574653\/20563128:<\/p>\n The workaround is to adjust the file xttdriver.pl:<\/p>\n Original:<\/p>\n Modified:<\/p>\n I.e. I wrote an exception to ignore any error and report the failed transfers in my table system.transfer_errors.<\/p>\n REMARK: The workaround could be more sophisticated by writing an exception handler for ORA-19504 only and write the full error-stack plus destination directories in the table system.transfer_errors:<\/p>\n And adjust the code in xttdriver.pl:<\/p>\n With above code in xttdriver.pl the transfer runs through and I just checked the table system.transfer_errors at the end to see what files I have to transfer manually. In a project I have to move an Oracle 11.2.0.4-DB (around 7TB in size) from Sparc Solaris (called Source in the remainder of this Blog) to Linux x86-64 (called Target in the remainder of the Blog). I.e. a platform migration from Big Endian to Little Endian. A good method to do that is described in […]<\/p>\n","protected":false},"author":35,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229,198,59],"tags":[1110,1111,1112,96,270],"type_dbi":[],"class_list":["post-10143","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","category-database-management","category-oracle","tag-cross-platform-migration","tag-endian","tag-incremental-backup","tag-oracle","tag-rman"],"acf":[],"yoast_head":"\n
\n$ more getfile_sourcedir2_dwh_bub_data_p06_01.dbf_34.sql
\nBEGIN
\n DBMS_FILE_TRANSFER.GET_FILE(
\n source_directory_object => 'SOURCEDIR2',
\n source_file_name => 'DWH_BUB_DATA_P06_01.dbf',
\n source_database => 'TTSLINK',
\n destination_directory_object => 'DESTDIR2',
\n destination_file_name => 'DWH_BUB_DATA_P06_01.dbf');
\n END;
\n \/
\nquit
\n
\n$ sqlplus \/ as sysdba
\nSQL> @getfile_sourcedir2_dwh_bub_data_p06_01.dbf_34.sql
\nBEGIN
\n*
\nERROR at line 1:
\nORA-19504: failed to create file \"\/DWHT\/u01\/oradata\/DWH_BUB_DATA_P06_01.dbf\"
\nORA-17502: ksfdcre:1 Failed to create file
\n\/DWHT\/u01\/oradata\/DWH_BUB_DATA_P06_01.dbf
\nORA-17501: logical block size 141558272 is invalid
\nORA-06512: at \"SYS.DBMS_FILE_TRANSFER\", line 37
\nORA-06512: at \"SYS.DBMS_FILE_TRANSFER\", line 132
\nORA-06512: at line 2
\n<\/code><\/p>\n
\nSQL> select file_id from dba_data_files where file_name like '%DWH_BUB_DATA_P06_01.dbf';
\n
\n FILE_ID
\n----------
\n 357
\n
\n$ rman target=\/
\n
\nRMAN> backup as copy datafile 357 format '\/tmp\/copy_df357.bck';
\nRMAN> quit
\n
\n$ scp \/tmp\/copy_df357.bck <target-system>:\/tmp\/copy_df357.bck
\n<\/code><\/p>\n
\n$ rman target=\/
\n
\nRMAN> Convert from platform 'Solaris[tm] OE (64-bit)' datafile '\/tmp\/copy_df357.bck' format '\/DWHT\/u01\/oradata\/DWH_BUB_DATA_P06_01.dbf';
\nRMAN> quit
\n<\/code><\/p>\n
\nsqlplus \/ as sysdba
\n
\ndrop table system.transfer_errors purge;
\ncreate table system.transfer_errors (sourcedir varchar2(128), file_name VARCHAR2(513));
\n<\/code><\/p>\n
\n my $sqlQuery =
\n \"BEGIN
\n DBMS_FILE_TRANSFER.GET_FILE(
\n source_directory_object => '\".$2.\"',
\n source_file_name => '\".$3.\"',
\n source_database => '\".$props{'srclink'}.\"',
\n destination_directory_object => '\".$4.\"',
\n destination_file_name => '\".$5.\"');
\n END;
\n \/
\n \";
\n<\/code><\/p>\n
\n my $sqlQuery =
\n \"BEGIN
\n DBMS_FILE_TRANSFER.GET_FILE(
\n source_directory_object => '\".$2.\"',
\n source_file_name => '\".$3.\"',
\n source_database => '\".$props{'srclink'}.\"',
\n destination_directory_object => '\".$4.\"',
\n destination_file_name => '\".$5.\"');
\n EXCEPTION
\n when others then
\n begin
\n insert into system.transfer_errors values ('\".$2.\"','\".$3.\"');
\n commit;
\n end;
\n END;
\n \/
\n \";
\n<\/code><\/p>\n
\ncreate table system.transfer_errors (error_code number, error_message varchar2(200), sourcedir varchar2(128), source_file_name VARCHAR2(513), targetdir varchar2(128), target_file_name VARCHAR2(513));
\n<\/code><\/p>\n
\n my $sqlQuery =
\n \"DECLARE
\n bug20563128 EXCEPTION;
\n PRAGMA EXCEPTION_INIT(bug20563128, -19504);
\n BEGIN
\n DBMS_FILE_TRANSFER.GET_FILE(
\n source_directory_object => '\".$2.\"',
\n source_file_name => '\".$3.\"',
\n source_database => '\".$props{'srclink'}.\"',
\n destination_directory_object => '\".$4.\"',
\n destination_file_name => '\".$5.\"');
\n EXCEPTION
\n when bug20563128 then
\n begin
\n insert into system.transfer_errors values (SQLCODE,substr(SQLERRM,1,200),'\".$2.\"','\".$3.\"','\".$4.\"','\".$5.\"');
\n commit;
\n end;
\n END;
\n \/
\n \";
\n<\/code><\/p>\n
\nI do hope that the workaround helps others to ease such a Cross Platform Migration.<\/p>\n","protected":false},"excerpt":{"rendered":"