Heterogenous Unix migration - SAP note 1003028

[Former Member]

Hello,

We are thinking about an heterogeneous migration project on Unix where source and target databases are Oracle 10.2. Some databases are very large (several terabytes) so the method described in note 1003028 sounds very interesting. However the note is a bit minimalist and I'm looking for more informations and details if possible, and also about possible feedback and experiences about this methodology.

Thanks.

[stefan_koehler]

Hello,

i think what you are searching for is the "Distribution Monitor". You can download the guide and program from sapnote #855772.

If splitting the load packages over several servers is not enough (mostly it is not, because of the very big tables are the time consuming ones).. you have to use the table splitting feature that is described in sapnote #1043380.

I also used a pl/sql package called sap_r3load which was provided by SAP to speed up (parallelize or define specific access paths while unloading the data) the export, but right now i am not able to find the sapnote for this.

I used all these tools for an unicode conversion and tested it a few times before doing it in production. You have really to test it carefully, take a look at the performance and tune it.

In my environment i was able to speed up the export (and parallel import) from round about 72 hours to nearly 10 hours for a 2.5 TB database. The limitation in my environment was the I/O throughput from the database storage system and the amount of CPUs of the application servers for the distribution monitor. The system where the database was imported was not a performance bottleneck.

Regards

Stefan

[Former Member]

>

> In my environment i was able to speed up the export (and parallel import) from round about 72 hours to nearly 10 hours for a 2.5 TB database. The limitation in my environment was the I/O throughput from the database storage system and the amount of CPUs of the application servers for the distribution monitor. The system where the database was imported was not a performance bottleneck.
> 
> Regards
> Stefan

Stefan,

Even if its just indicative to get an idea, can you give a summary of the source and target systems: cpu, memory and storage subsystem?

Thanks.

[markus_doehr2]

> We are thinking about an heterogeneous migration project on Unix where source and target databases are Oracle 10.2.

If the endianess of source and target is not identical you can't use that feature (aside from using transportable tablespaces).

> Some databases are very large (several terabytes) so the method described in note 1003028 sounds very interesting. However the note is a bit minimalist and I'm looking for more informations and details if possible, and also about possible feedback and experiences about this methodology.

Which option are you talking about?

Markus

[Former Member]

Hello,

Thanks for this fast answer.

Seems it's possible even if the endianess is different? There's a method described at §"3.5. Converting the Endian format of the database files" in the sap note?

I'm talking about the new support for heterogeneous database copies described in chapter 3. The key is the time advantage, for example for a 5TB database. But I'm not sure I fully understand all the steps described. At which point do the tablespaces/datafiles get copied to the target system?

And looking for any experience return of this method.

Thanks.

[markus_doehr2]

Seems it's possible even if the endianess is different? There's a method described at §"3.5. Converting the Endian format of the database files" in the sap note?

Yes - it's technically possible to convert the endianess with Oracle tools.

I'm talking about the new support for heterogeneous database copies described in chapter 3. The key is the time advantage, for example for a 5TB database. But I'm not sure I fully understand all the steps described. At which point do the tablespaces/datafiles get copied to the target system?

And looking for any experience return of this method.

First advise: a heterogeneous system copy requires a certified migration consultant on-site, otherwise you will loose support for the migration and for the target system (see http://service.sap.com/osdbmigration --> FAQ).

I would use the normal R3load method to do heterogeneous migrations, they are proved to work and you can do many things in parallel (as already stated). Using those SAP can provide your with support and there may even be much experience outside. If you choose to use a database specific approach you're alone in case of problems.

Markus

[Former Member]

Many thanks for all those fast answers. So the parallel R3load option seems the best choice and fully supported. In any case, I think we'll have to test both methods to validate migration times.

[stefan_koehler]

Hello,

Seems it's possible even if the endianess is different? There's a method described at §"3.5. Converting the Endian format of the database files" in the sap note?

I have already done this with RMAN for non SAP systems and it works fine. Until now i didn't know, that SAP supports this now anyway (you will learn new stuff every day). Just keep in mind you need much more disk space for that and then you will need the time that it takes for a backup. If you have really large databases you usually don't do normal backups .. you use other technologies like snapshots, etc. So i don't think that it is even faster than R3load.

Even if its just indicative to get an idea, can you give a summary of the source and target systems: cpu, memory and storage subsystem?

Of course .. just some important information .. i have done a sorted export so it was more resource intensive.

Source database server:

p570 / 16 x p5+ CPUs / 100 GB Memory / 4 FC adapters / IBM DS8000 Storage / Average I/O throughput while reading and sorting data was round about 750 MB/s

Application servers for R3load:

p570 / 32 x p5 CPUs / 1 FC adapater for each application server / IBM DS8000 Storage

Target database server:

p570 / 16 x p5+ CPUs / 100 GB Memory / 4 FC adapters / IBM DS8000 Storage

Btw. keep in mind that the performance was limited by the average I/O throughput of 750MB/s on the source database server .. and after the data was sorted and delivered to the application servers .. then there was the CPU limit of the 2 p570 servers.

Regards

Stefan

[Former Member]

Thanks a lot for this detailed information. Why did you use R3load for an homogeneous migration from AIX to AIX instead of a physical database copy? Because the database needed reorganization?

[stefan_koehler]

Hello,

i have used this infrastructure/tools for unicode conversion of "normal" ERP SAP systems and also for BW/BI SAP systems.

Regards

Stefan

[Former Member]

OK I see, sort of heterogeneous too BTW, what were the network links between both database servers and the R3load application servers? And how many p570 application servers were used? (configurations mentions 1 fc adapter for "each" server, but how many of them?).

2.5TB in 10 hours is quite impressive.

[stefan_koehler]

Hello,

> What were the network links between both database servers and the R3load application servers?

Gigabit Fiber .. the communication itself only happens in the core network. The network traffic depends on the degree of parallelism.

> And how many p570 application servers were used?

As i already mentioned that a p570 and 32 x p5 CPUs were used for the application servers ... so in detail there were 2 p570 servers with 16 p5 CPUs each.

>2.5TB in 10 hours is quite impressive.

I think it was quite good )

Regards

Stefan

[Former Member]

Hello,

Still working on this.... seems the distribution monitor does not support lower than SAP basis 6.20, but we have some 4.6C systems to migrate, is there another way to optimize/parallelize the R3load processes then?

Thanks again in advance.

[markus_doehr2]

> Still working on this.... seems the distribution monitor does not support lower than SAP basis 6.20, but we have some 4.6C systems to migrate, is there another way to optimize/parallelize the R3load processes then?

If source and target is Oracle 10 you could check the (new)

Note 1367451 - Oracle 10g: Transportable Database

Markus

[Former Member]

Hello Markus,

Yes, the note is related to note 1003028 (topic) and 1035051, problem is that we don't have much experience with this new method and are not sure that all prerequisites will be met and this method possible. So at the beginning we will probably try both methods, or maybe be forced to use R3load that's why I'm wondering if there are other ways to parallelize the R3load processes than the distribution monitor since this one is not supported under 6.20.

Thanks