on 12-13-2013 1:11 PM
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.
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:
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
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I use all three methods, depending on the customer needs.
Some customers do not have a second box for a parallel export/import.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Same for me: if 1 can be avoided, I use 2a. Don't have any experience with 2b and 2c.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.