downtime optimization for system copy

[#1]

Hi,

I am planning copy my source database to target database. Here my challenge is the source is a non-compression database and target is a compression database. How can i reach the optimize downtime. My sandbox database is 4TB. It is an system copy-> oracle->source system export-> based on as-abap-> table splitting

I did a system export it took me the system down time of 8 hours with 44 parallel jobs. I took 2 jobs for  r3load process for one cpu ( 22 cpus).

Now for optimizing I am going for table split preparation and I am very new to it. If you have any documents can you please share it to my email.

now I am planning to do table splitting preparation. For this table splitting preparation.

I downloaded the MIGCHECK_2, MIGMON, MIGTIME, ORABRCOPY and SPLIT as it suggested in note: 784118 - System Copy Tools for ABAP Systems

I also found the couple of notes 1875778 - Performance Optimization for System Copy Procedures and 936441 - Oracle settings for R3load based system copy.

I need some more stuff from the experts so i can go ahead and kick off the table splitting preparation.

Note: here my operating system and database are same for source and target.

O.S: Unix and database : oracle.

Thanks in advance.

[stefan_koehler]

Hi,

we should clarify something more important before thinking about table splitting details.

>> I did a system export it took me the system down time of 8 hours with 44 parallel jobs. I took 2 jobs for  r3load process for one cpu ( 22 cpus).

I guess you run the export on the database server, right? So the database processes and all R3load export processes are running on the same 22 CPUs. You even doubled the amount of parallel jobs regarding the CPUs. So i assume (from my experience) that the CPUs are fully loaded as long as the 44 parallel export jobs (and the database) are running. So a higher parallelism degree based on table splitting would not really beneficial here.

I guess you have to use distribution monitor _and_ table splitting to get a higher parallel degree with the corresponding throughput. Distribution monitor is for spreading the CPU load (= R3load processes) across several servers.

Regards

Stefan

[Former Member]

Hi Stefan,

Thanks for the reply and I really appreciate your time.

I should take this oppurtunity to thank you . I read very good blogs written by you and also I gain lot of knowledge by reading your suggestions in SDN blogs.

Yes, stefan as you mentioned that was my first method. I took the database export directly. I just logged in to my source system and just took the database Instance export to my local file system only to fasten the process. As my sandbox is of 4TB it took the downtime of 9 hours in total. The dump I got is 400GB in my ABAP directory of the export location.

In method 2. I approach of splitting my top size tables which I got from DB02 or ST04. I manually created a text file as follows tablename%number of splits

ex cdcls%5

     cdhdr%4

I saved the file in my system and when the installer asked I gave the txt file and run the table split.  But in this split I took only top 5 tables to check. I got the whr.txt file and I used that file when I am exporting the database instance. Figure as follows. 

fig1: The txt file i created manually with the top 5 table names

Fig: 2 I gave the whr.txt file while I am exporting the database instance export.

I did not run any migration monitor or distribution monitor here. When it asked me I just went with the default options.  

The downtime I met here was same to my direct export downtime.

[stefan_koehler]

Hi,

thanks for clarification, but you still run the export (R3load processes with table splitting) locally on the source database server, right?

>> The downtime I met here was same to my direct export downtime.

I do not doubt this as it seems like you are CPU bound based on your given amount of available CPUs and the provided configuration. Higher parallelism (with package and/or table splitting) would not speed it up dramatically as your CPUs on the source system are fully loaded anyway.

However you should also use the Time Analyzer for analyzing the R3load runtimes and split up accordingly. Sometimes the biggest tables are not causing the long overall-runtime.

It is usually essential to measure your OS load while exporting/importing for finding the right R3load / database configuration and export method. For example on AIX and Linux this can be done very easily with nmon and analyzed with nmon_analyzer afterwards.

4 TB is not really that huge and can be migrated much faster than 8 hours, if setup correctly. I usually use Distribution Monitor due to the client's system sizes and downtime requirements. You can also speed up the export for each R3load process with Oracle PX, but this is some kind of detailed configuration which can be made, if you know the bottleneck.

In my experience SAPinst GUI based migration is something for small and mid-sized SAP systems with no critical downtime requirements - otherwise you mostly have to use Distribution Monitor.

Regards

Stefan

[Former Member]

Hi Stefan,

Thank you for the reply. I will find and start working on distribution monitor. Will keep the thread open till that time.

I have a one more question, our production database is 20 TB by using the distribution monitoring can I  optimize the downtime to 20 hrs. At the end of the day we want to do it on prod. The downtime given to me is less than 24 hours for 20TB of data.

Is this achievable?

Thanks in advance.

[stefan_koehler]

Hi,

>> I have a one more question, our production database is 20 TB by using the distribution monitoring can I  optimize the downtime to 20 hrs.

This can not be answered in general. It depends on a lot of influencing factors, but mostly on your available resources (e.g. throughput of I/O subsystem, available CPUs and servers) and on your kind of SAP system (e.g. OLTP or OLAP/BI - it is important for splitting). There are some official real world R3load examples like 2 TB in 2.25 hours (= 888 Gb/h) on high-end hardware from 2010, but the hardware capabilities increased a lot since then.

>> At the end of the day we want to do it on prod. The downtime given to me is less than 24 hours for 20TB of data.

The biggest problem in your case is that you try to setup, configure and test the migration with a 4 TB database but your productive system is 5 times larger. The configuration and test migrations should be done with nearly the same amount of data and structure.

Regards

Stefan

P.S.: Please check out my profile / website, if you need further assistance by your migration. I offer such consulting services