cancel
Showing results for 
Search instead for 
Did you mean: 

Testing the migration key for OS/DB migration

symon_braunbaer
Participant
0 Kudos

Dear Experts,

I was thinking, that testing the migration key in advance isn't a bad idea. But I am really struggling

to perform this in practice. Looking through the different system copy guides and other documentation,

I can't find a real example on how exactly to do that, hence I am posting a couple of questions, to

which I didn't find the answers nowhere:

1) On what system one has to test the migration key ? Source or target ? (I think, on the target system)

2) Is it necessary to already have the export files ? Meaning - is it possible to test the migration key even

before performing the export of the source system ?

3) What is the EXACT COMMAND, meaning a REAL syntax example, without any placeholders like

<TASK_FILE>, etc. ?

4) If testing is performed on the target system, what do we need to have there, in order to test it ? Installed

database ? Unpacked R3load binary ? Unpacked kernel ? Installed NetWeaver system ? .CMD file ?

.TPL file ? Data file (.000), TEST_MIGKEY.CMD ?? Nobody says exactly what has to be done...

Many thanks for clarifying this to me!

Accepted Solutions (0)

Answers (1)

Answers (1)

Matt_Fraser
Active Contributor
0 Kudos

Hi Symon,

First off, are you migrating to a new platform? New OS or DBMS, or to HANA, that sort of thing? Or are you just copying the system to make a duplicate, or perhaps for an OS or DBMS upgrade, but not changing the overall type of OS/DBMS?

If it's the latter, it's a homogeneous system copy, and no OS/DB migration key is required. Also, you can use database-specific methods to do the system copy, which for some platforms, at least, means you can do it without incurring any downtime on the source system (i.e., you can take a backup of the database and use that to install the copy on the target system).

If you are changing OS and/or DBMS, however, then it's a heterogeneous system copy, aka OS/DB migration, and you will need a key. Also, you'll use database-independent methods (also known as r3load-based).

For this latter, if I recall correctly, the screen in SWPM where it asks for the key is during the system export on the source system. Also, for this type of export, your source system does need to be down.

So, if you want to test it, my recommendation is to first create a homogeneous copy of the system (via backup/restore, so no source system downtime required), and then test/practice your heterogeneous copy using that newly-created test system.

If it's just the key you're testing, I'm not sure this works, however, because I believe the key is system-specific. You generate it online, and it will either be accepted by the tool (SWPM) or it won't.

There isn't any command syntax -- it's done with a tool that has its own GUI. That tool is SWPM.

Finally, there is an entire space on SCN devoted to this topic, so you might want to browse through the topics and posts there. That's over at , and specifically the Category System Copy & Migration. While there, have a look at the document , and also my own blog at .

Hope this helps to answer your questions.

Cheers,

Matt

symon_braunbaer
Participant
0 Kudos

Dear Matt,

many thanks for your detailed answer, but it's not quite what I have expected.

Also, I see that it's my fault as well, as I obviously didn't post the question clear enough.

Both OS and DB will be changed - so it's a heterogeneous system copy. And it will

be R3load based.

Furthermore, the key is not asked during the Export. It's asked during the import.

The key is not system specific, it's only tied to the installation number. Well, SAP asks

a lot more questions when generating the key, but as they say, that's for their own

statistical information.

And testing the key is not only a GUI function. As per the book for OS/DB migrations

certification, the R3load -k option is used to provide the key on the command line, and

R3load -K is used to test the key. They also mention test_MIGKEY.log as being the log

file of the verification and there is also some test_MIGKEY.cmd file.

But they don't say HOW exactly to test the key.

Anyway, today I have generated our migration key and just wanted to test it, in order

to make sure that it works, before we start the import tomorrow, but I couldn't figure out

how exactly to test it and I formulated and posted the questions above.

Many thanks anyway!

Matt_Fraser
Active Contributor
0 Kudos

Ok, that makes more sense. Myself, I haven't done an OS/DB migration, but I have performed many system copies, and Unicode migrations, using both backup/restore and r3load-based methods. But, none of them required a key, so I was going from memory of when I have seen the field that asks for the key.

SWPM does have such a field, so testing may not be GUI-based, but actually performing the migration, and entering the key, can certainly be done in the GUI. I don't know if that's what's taught for certification, but that is how the tool should work. If no key is required, one simply leaves the field blank, but if it's heterogeneous, then you can enter it in this field, no command-line required.

Based on how other similar tools have operated for me, and upon looking at the options for r3load, I think that "r3load -K" option is simply a way of determining that the key is valid for your installation number. You would simply type "r3load -K <key>". I think it's unlikely you need to have already performed the export and or have done much of the installation of the target system. You probably just need to run it while logged onto your source system console as sidadm.

The logfile seems to just go to stderr by default, i.e. to console output. I just experimented a little on on my sandbox system to see what would happen. I don't have a key to test, of course, so I was just looking to see what log messages were generated.

Anyway, have a look, and/or rephrase the question, over at the Software Logistics space that I linked earlier. That's where the support experts and the developers of these tools hang out.

andreas_herzog
Active Contributor
0 Kudos

You could use the command against a vaild export package as <sid>adm....such as:

R3load -i <PACKAGE>.cmd -dbcodepage 4102 -k <your_migration_key> -l <PACKAGE>.log

Create the CMD file using:

R3load -ctf I <PACKAGE>.STR DDL<DB>.TPL <PACKAGE>.TSK <DB> -l <PACKAGE>.log

and be sure to edit the <PACKAGE>.TSK setting the import to IGN:

D <PACKAGE> IGN

to prevent R3load from starting to import the package

I on the other hand would just start the actual import..if the key is not vaild you can always use the key given in the SAPnote(s) 1768158 or 1738258 (depending on your NW release).

GreetZ, AH

symon_braunbaer
Participant
0 Kudos

Hello Andi,

thanks for the very professional answer. I really hope that, this will work,

but I am a bit disappointed just at the first sentence - it looks like it's necessary

to have the source DB already exported, in order to be able to test the key ?

Or I am getting you wrong ?

Thank you!

Parthis
Participant
0 Kudos

Hello Symon, Did you find a way to test the migration key prior to actual migration? Please share your experience. Thank you!

andreas_herzog
Active Contributor
0 Kudos

You could go for a "fake" export package in order to test

Or create a real one using the above mentioned tools...

GreetZ, AH