Homogenous system copy Solman 7.2

[former_member206857]

Hi everyone,

Recently we upgraded our SOLMAN 7.1 dual stack to SOLMAN 7.2 and dual stack split on Windows/MSSQL. I now need to move our Dev server to new hardware. Looking at how I should do this now that it's split and technically MCOD. I checked SWPM and I see 2 separate options for 7.2 for ABAP and for JAVA. Has anyone done this yet? Any suggestions?

[former_member206857 · Accepted solution]

Spoke to SAP support about this particular scenario.

Because of the MCOD, the only supported method is doing an Homo System copy and exporting each ABAP and JAVA independently.

However, the only supported model is doing a DB independent method. The database method using backup tools will not work.

[Matt_Fraser · Accepted solution]

Hi Joshua,

So even though you've done the dual-stack split and now have separate ABAP and Java instances, you have them both running on the same host and sharing a database? Is that correct? Since you're migrating to new hardware, what about separating the instances onto individual hosts? The Java instance shouldn't need much in the way of resources, far less than the ABAP instance, so a relatively small VM could probably handle it. It seems to me this would make life easier going forward.

I'm interested here mainly because we still haven't upgraded our SolMan system, so it currently remains a (technically unsupported) 7.1 dual-stack system. But, I'm going to have to tackle that later this year, as soon as I can find some non-existent time in my project schedule. 😉

FYI, I'm going to add the Software Logistics tag to this, even though it's already solved, as system copies, etc, fall under that label, and so people may be searching there for guidance on this kind of procedure.

Cheers,
Matt

[former_member206857 · Accepted solution]

Hi Matt, You are correct, technically if I export out each instance and when I rebuild on new hardware, I could potentially do that. But SAP fully supports the current setup since it was done from an upgrade not new install. I also want to keep my landscape identical meaning all my sandboxes, QA and PRD are all the same as DEV today. Also, Yogesh speaks to it here as well.

https://blogs.sap.com/2016/03/06/solution-manager-72-upgrade-iii-dual-stack-split/

Matt, are you All windows/SQL? If you want, I did a great job at documenting my entire upgrade process. I could share with you all my docs. Might change by now because those central notes are hot cakes and we also had CHARM so I was required to do export/import of document management. Anyways, let me know. I will prepare soon for a trial run of the homo system copy to a sandbox.

[Matt_Fraser · Accepted solution]

We are indeed a Windows/SQL shop. However, it's likely to be several months before I get to this task. However, I appreciate the offer of your documentation! I may take you up on that when we get there. I do the same, I document the heck out of almost everything I do, at least in the SBX, DEV, and QAS stages, so that when I do it in PRD it's pretty much on autopilot, just follow the steps (which is good, because usually at that stage it's 3am and I'm sleep-deprived, so rational thought is not always the best).

Also, we don't (yet) use CHARM, or anything else but basic landscape monitoring, in our SolMan scenario, so it's relatively simple. I could still even choose to implement 7.2 as a new system from scratch at this point, though I probably won't.

Anyway, elsewhere I saw Boris Rubarth commenting about dual-stack splits, and he seemed to imply that separating out to true separate instances would save hassle for the administrator down the road, which makes sense to me. He was referring to multi-tenant HANA instances, however, but nevertheless the general advice should still be applicable.

I agree, I wouldn't do this in DEV unless you also intended to follow up with your QAS and PRD landscapes, keeping them all relatively similar in structure.

[former_member206857]

So looking at this in more detail.

The process...I have 2 methods here, using database independent export/import or database dependent import.

The DB dependent is basically a restore of my DB, however..if the process to install is each engine separate. If I use that method, I bring in the schema of the other instance no matter what because its MCOD. Example, On the new hardware, I install DB software, ready to run SWPM, install SOLMAN 7.2 ABAP target from backup. All good but by restoring that DB, I just brought in my SID info from my JAVA instance. When I turn around and do the same SWPM JAVA target from backup, I already have it in the system. Will that method overwrite? I think so.

For this reason, I think I need to use the DB independent method, export to a directory, then do the same with JAVA using Jload to a directory then import each.

Not sure if anyone out there who did the split into MCOD has done this yet?

[former_member206857]

I was planning on using the exact same hostname and IP addresses.

[patelyogesh]

This will be better option as mentioned below.

-Yogesh

[patelyogesh]

Hello Joshua Lacroix,

Export both systems separately and import them on new hardware.

If you are changing host names you need to configure your system again.

I recommend you to use old server names as virtual names on new hardware (This will make your life easy)

Please look in to SAP notes below

1564275 - Install SAP Systems Using Virtual Host Names on Windows
2109662 - Windows returns wrong IP address as source IP

Regards,

Yogesh