Migration Monitor - How Are You Using It?

[BorisZarske]

Hello!

In this short discussion, you can help us to better understand how you are using the Migration Monitor – this better understanding would help the team responsible for this tool to adapt their automated tests accordingly and would also influence the future development decisions in this area.

What is the Migration Monitor?

The Migration Monitor is part of the software provisioning manager as of SAP NetWeaver 2004 SR1, but can also be executed manually. It uses the EXT, WHR, STR, TPL files to control the unload and load, to accelerate the load by automatic parallelization, and to generate the R3load task and command files (TSK and CMD files).The Migration Monitor does the following:

• Creates R3load command files
• Creates R3load task files if required
• Starts R3load processes to unload the data
• Transfers packages from source to target host if required
• Starts R3load processes to load data as soon as a package is available
• Informs the person performing the system copy in case of errors

How Do You Use the Migration Monitor?

1. Only for sequential unload and load - that is, you first unload to a local system, transfer the export directory to the target host, and then load using this directory.
2. For parallel unload and load:
   a) Unload and load using a shared network directory
   b) Unload and load using transfer by FTP
   c) Unload and load using sockets

In your reply, please just name your preferred option (1, 2a, 2b, or 2c) – and why you prefer it.

Thanks a lot for your support!

Boris

[SK-EA]

Boris,

Options - All three but mainly Option # 2.

Option # 1 - To dynamically increase the number of parallel process from Source system. But in case of homogeneous system copies with massive database sizes, the database proprietary methods comes in handy than the R3load procedures.

Option # 2 - To reduce downtime in migrations (hetero combinations) thru parallel export/import of data loads.

Hope it helps.

Regards,

Srinivas K.

[Raphael_M]

I'm using 2a and 2b and never tried 2c (sockets). If the customer is changing the datacenter or outsourcing is the scope, then often FTP is used. Network however is the most common option in my projetcs.

The FTP option is still missing support for SFTP or SCP which has been a problem in almost all cases. Customers did not want to use an unsecured transfer but we still have no other optoin until today (as of my knowledge). It would be great if SFTP or SCP could be implemented here.

Thanks and happy new year to all 🙂

Raphael

[Former Member]

You can always build a SSH tunnel and use regular FTP over it but agreed there should be support for secure transfers out-of-the-box.

[Former Member]

Hi Samuli,

We want to use SSH tunnel as FTP is not working in our case.

So could you please let me know how we can use existing SSH tunnel to transfer files using MIGMON.

Regards,

Amit

[Former Member]

Let me google that for you.

[former_member525904]

Hi Amit

Instead of FTP you can use the socket option for export/import.

Before one year in migmon I implemented reuse of sockets.

Improratns is the correct preparation

For example

If you configure the import monitor with

socket

port=6678

jobNum=10

The preparation is:

Ensure that ports from 6678 to 6688 are free (one control port 6678 + next 10 ports for data transfer).

You have to tunnel these 11 ports: 6678 till 6688

Best Regards,

Rosen Chaushev

[Tobias_Heitfeld]

Whenever possible I try to avoid sequential export import if additional hardware and a connection between source and target is available.

For parallel load prefer to use a shared network directory if this is accessible from the source and target side. Secondly I use the ftp transfer option if a switch of datacenters is required.

Seldom I use the socket option, it does not have the requirement to provision space for the dump and is a 'realtime' parallel export import. The downside in opinion is that if errors occur during export import or connectivity always for the affected tables the entire export import would need to be restarted.

[D051872]

I use all three methods, depending on the customer needs.

Some customers do not have a second box for a parallel export/import.

[former_member236391]

I think that 2a, 2b are commonly used for many customers.
I didn't see a customer who is using 2c from my experience.

P.S can I ask why secured FTP is not supported with MigMon ? is it difficult to be implemented ?

A few customers have complaint about the restriction.

[frank_beimfohr]

Same for me: if 1 can be avoided, I use 2a. Don't have any experience with 2b and 2c.

[ronald_halmen]

Whenever options 1 and 2b can be avoided I use 2a for speed reasons with the shared network directory being a local filesystem on the server where the (writing!) R3load export processes run. No experience with option 2c so far.