cancel
Showing results for 
Search instead for 
Did you mean: 

OS migration option using standard oracle imp/exp

former_member198282
Participant
0 Kudos

Hi, all.

We are evaluating the approach of migrating the SAP server(ECC 6, Oracle 11g) from solaris to AIX.

I understand that the standard way is to use R3load. When I searched on the forum, everybody is talking about R3load. But what is the problem of using the oracle utility as the datapump or rman convert which is faster than R3load? Note that there is no unicode conversion involved as I understand imp/exp cannot handle the data conversion.

Please advise.

Thanks,

Jonathan.

Accepted Solutions (1)

Accepted Solutions (1)

stefan_koehler
Active Contributor
0 Kudos

Hello Jonathan,

We are evaluating the approach of migrating the SAP server(ECC 6, Oracle 11g) from solaris to AIX.

In this case (target and source system has the same endianness) - forget R3load and peform it with a RMAN feature called "Cross-Platform Transportable Database".

I already wrote a blog about that topic some time ago: /people/stefan.koehler/blog/2010/05/09/oracle-migrating-sap-systems-on-oracle-with-less-effort

You will get a great performance (the only limit by converting the data files is the I/O subsystem) and it is really easy.

Regards

Stefan

Answers (2)

Answers (2)

former_member198282
Participant
0 Kudos

Thank you very much for the great information, Volker and Stefan. Stefan, it is a great blog which is really helpful.

volker_borowski2
Active Contributor
0 Kudos

Hi,

well R3load is the standard supported procedure.

Many people did go that way, so it is a well known path.

Same is true for backup/restore (homogeneous)

In addition you might be able to include the new 11g features for the

target system directly, when doing the copy (compression).

If the source system is old you'll get additional benefit like

TS storage management conversion.

I was in a Solaris / AIX migration for a 35+ TB system, and we did it

with transportable tablespaces, because of the size and some VERY large tables involved.

It was a non-standard procedure, the number of capable supporters was limited,

We found new bugs in that transportable TS feature (that are partly fixed meanwhile),

We found problems with the implementation of SAPs "DB specific method" copy implementation

(Do not know if fixed meanwhile).

It is always a bad situation, if you are the first to find out.

In the end we had been able to work around the problems, but there had been some

pretty frightening moments in between.

I'd rather check, if the benefits of datapump outrun the possible downsides.

Volker