cancel
Showing results for 
Search instead for 
Did you mean: 

Can we use SAP SLT for platform migration ?

Former Member
0 Kudos

Hi Gurus,

We are doing a platform migration and followed by SAP release upgrade(including dual stack split).  As per our experience EHP7 upgrade(ECC 6.0 EHP2 to ECC 6.0 EHP7) take around 60 hours overall execution time and H/W platform migration takes around 37 hours(using backup/restore & RMAN conversion. We proposed for two cutover: one for H/W migration and another for SAP Upgrade including dual stack split. The customer is not willing to afford two separate production downtime. We are finding some alternative solution to minimize H/W platform migration(old H/W to new H/W) time.

Current  Platform:

Hardware: IBM P -570 logically portioned (10 Core/74GB)

OS: SuSE Linux Enterprise Server 10 on Power

Oracle: 10.2.0.5

Target  Platform:

Hardware: IBM HS23 (16 Core/256 GB)

OS: SuSE Linux Enterprise Server 11.2 (x86_64)

Oracle : 11.2.0.3

System in scope:

1.    SAP ISU :ECC 6.0 EHP2 – ECC 6.0 EHP7, Database size 10 TB

2.    SAP CRM :CRM 2007 –  CRM 7.0 EHP3, Database size 800 GB

3.    SAP BW :BW 7.02 –  BW 7.4, Database size 6 TB

I am wondering whether we can use SAP SLT for replicating from source system to target system, and make a logical cutoff and then start dual stack split and upgrade.

It will be great if anyone can through some light on it.

Many thanks in advance

SP

Accepted Solutions (0)

Answers (2)

Answers (2)

stefan_koehler
Active Contributor
0 Kudos

Hi Maity,

i may misunderstand the scenario, but how can a RMAN cross-platform transportable tablespace conversion (as the endianness changes) take so long?

10 TB x 1024 x 1024 10485760 MB

37 h x 60 x 60 ≈ 133200 seconds

≈ 78 MB/s


RMAN (cross-platform) transportable tablespaces are usually used to speed up and utilize full hardware capacity. On which system do you perform the conversion? It seems like there is something seriously wrong with your planning or system. You can also use some LVM splitting techniques (depending on the used storage layer) to speed up the copy process of the data files. In consequence you just need to convert the data files after mounting that LVM split on the target system (or convert it right before on the source system).


There is also a possibility called "Transportable Tablespace / Cross Platform Incremental Backups" which minimizes the downtime to just a few mins (even if you need to copy the data files). Unfortunately it is only officially supported for Exadata migrations, but it works smoothly for non-Exadata migrations as well (already tested). This limitation seems to be a "political / marketing" restriction and maybe by-passed with some good contact to your Oracle account manager.


Regards

Stefan

Former Member
0 Kudos


Hi Stefan,

Thanks for your response.

We are planning for a POC for "Transportable Tablespace / Cross Platform Incremental Backups"

In the mean time we are exploring possible options as well.

Thanks

SP

former_member188883
Active Contributor
0 Kudos

Hi Maity,

Using of SLT tools will definitely help to reduce the downtime but it comes with additional cost of license as well as implementation.

You need to check how much business downtime is permissible in your environment with addition of CPU and RAM , with various mocks try to achieve the desired results.

One suggestion is to combine upgrade as well as platform migration back to back to help reduce downtime.

Hope this helps.

Regards,

Deepak Kori

former_member188883
Active Contributor
0 Kudos

Hi Maity,

Need to understand the following

1) 60hrs of downtime is for upgrade ? specify what is the exact downtime

2) Does the system involves unicode migration as well ?

3) The hours specified is for which SAP system out of the list shared by you

Regards,

Deepak Kori

Former Member
0 Kudos

Hi Deepak,

Many thanks for your query.

Please find my response below:

  1. In ISU the execution time of SUM is around 55-60 hrs including 6-8 hrs technical downtime(Execution phase). However, we are doing platform migration and them SAP upgrade. Hence anything and everything  we perform will be coming under business downtime. That is the reason we are trying to get some alternative solution.
  2. No Unicode migration involved, but there is change in code page as we are moving from SUSE Linux Enterprise Server 10 on Power to SUSE Linux Enterprise Server 11.2 (x86_64).
  3. SAP ISU :ECC 6.0 EHP2 – ECC 6.0 EHP7, Database size 10 TB

Thanks

SP