System refresh of only ECC and not Portal and PI in MCOD

[Former Member]

Hello,

Our QA landscape has ECC, Portal and PI installed in separate servers, but belong to the same MCOD DB. Its the same in Production too.

Now we want to refresh just the ECC in QA from ECC in Production. We don't want anything to change in the PI and Portal QA?

How can we do this?

Cheers

Ajay

[Former Member · Accepted solution]

Hi Ajay,

You Can Export the System using the SAP Inst Tool that will be best way to Do system Copy.

As you can select which system you want to export during the export.

Thanks & Regards,

Balaji.S

[Former Member · Accepted solution]

Yes Markus, we have one database server for all these instances. Its an MCOD. It has tablespaces for all these instances.

Balaji, can you please explain in detail what you mean and in which system? The ECC db is almost 500gb, so that will take a long time to create the export. Also using sapinst, wouldn't it touch the PI and Portal instances since everything resides on the same mcod db?

Thanks,

Ajay

[markus_doehr2 · Accepted solution]

> Yes Markus, we have one database server for all these instances. Its an MCOD. It has tablespaces for all these instances.

Ok.

In that case you can't do a system copy using backup/restore (detach/attach) but you need to a real export (using R3load). This will require quite some time (depending on your hardware, number of R3load processes, table splitting used....). On the target system you'll need to delete the respective named instance first and then "install" a new system using the export you did on the source.

All in all it's not something I'd expect to do in a day or two, especially if you've never done it before.

Markus

[Former Member · Accepted solution]

Hi Markus,

I have done backup restore in Oracle, but never attempted it on an MCOD. Also have done system copy using sapinst in the past for single instances on single database. I am not sure how to proceed on the method you have suggested. Do you have any doc on this? Can I use sapinst for this by selecting the System Copy option? Doesn't R3load do the same thing as sapinst system copy option?

If I do a complete backup restore of the database, will it also replace PI and Portal data? If so, is it a better option to create an export of the existing portal and PI and install a fresh installation of PI and portal using the export created?

Really appreciate your help.

Thanks,

Ajay

[markus_doehr2 · Accepted solution]

> I have done backup restore in Oracle, but never attempted it on an MCOD. Also have done system copy using sapinst in the past for single instances on single database. I am not sure how to proceed on the method you have suggested. Do you have any doc on this? Can I use sapinst for this by selecting the System Copy option? Doesn't R3load do the same thing as sapinst system copy option?

Sapinst uses R3load - yes.

> If I do a complete backup restore of the database, will it also replace PI and Portal data? If so, is it a better option to create an export of the existing portal and PI and install a fresh installation of PI and portal using the export created?

The concept of MCOD is that you have one named database and different schemas/users. If you copy the database you also copy the other schemas/users so yes, all systems will be replaced.That's one reason why MCOD systems are, from an administrative point of view, tedious, because you can't only copy one system but all if you use a database copy.

If you want to stay with MCOD I'd export the ERP system (to be 100 % consistent it has to be shut down), run the "uninstallation" of sapinst on the target system and then reinstall the ERP with the export you created.

Another, in my opinion better approach, could be, that you export all three systems and set them up new, all on the same server but all with separate Oracle installations (so multiple ORACLE_HOMEs). That's a bigger project (for the source systems) but gives you in the future the option to use a (quick) database copy instead of a long R3load with all its culprits.

Markus

[Former Member · Accepted solution]

Hi Markus,

Thanks a ton for that answer!

For info sake, from your experience how long does the export of a 500gb database take in sapinst?

We are doing this exercise also to test our DR strategy, and to see if the backup taken in tape is actually working. So sapinst is out of question, and all I have left is a full DB copy. Replacing an MCOD with individual instances is also not in the plan as of now.

Could you please tell me what will be the additional steps to be performed to make sure that the Portal and PI is working after a full db refresh with production?

Usually in a db refresh, when i create the controlfiles, I replace the source <sid> with the the target <sid> in the control_file.sql (that I get from the trace in source system). After a DB refresh I just recreate the sapdba role, recreate the ops$ user for the specific target SID. Is it any different in case of MCOD?

Thanks,

Ajay

[markus_doehr2 · Accepted solution]

> For info sake, from your experience how long does the export of a 500gb database take in sapinst?

SAP migrated their HR system (of several TB) on a weekend, however, this was highly tuned with lots of test runs in front. I can't say how long it takes, you have to do a run to see and to optimize.

> Usually in a db refresh, when i create the controlfiles, I replace the source <sid> with the the target <sid> in the control_file.sql (that I get from the trace in source system). After a DB refresh I just recreate the sapdba role, recreate the ops$ user for the specific target SID. Is it any different in case of MCOD?

This procedure does not work as soon as Java comes into place. If you copy a system with Java you must use sapinst. Java stores tons of information not in the database (as ABAP) but on the filesystem. Some of the information is synced on startup, some of them are only read on the filesystem.

Especially in case of a PI (which itself is very complex) this does not work.

In any case you would need to (after the full DB copy)

- run sapinst on your QA system to "save" your current state (sapinst Java export for the EP and sapinst Java + ABAP (R3load) export for the PI)

- uninstall PI and EP on the target system

- reinstall EP and PI by using the export you did

but

if you'd do it that way and you have then only a database with your ERP and you reinstall the other two systems anyway I would not do MCOD but two new database installations (so separate the instances).

There is no other way of doing that copy and preserving the other system in an MCOD case, that's one reason why MCOD is no more recommended.

Markus

[Former Member · Accepted solution]

Hi Markus,

Shouldn't this step be done before the DB copy to QA?

- run sapinst on your QA system to "save" your current state (sapinst Java export for the EP and sapinst Java + ABAP (R3load) export for the PI)

And these steps after DB copy?

- uninstall PI and EP on the target system

- reinstall EP and PI by using the export you did

or doesn't it make any difference?

Thanks,

Ajay

[markus_doehr2 · Accepted solution]

> Shouldn't this step be done before the DB copy to QA?

yes of course - I was a bit confusing; sure you have to "save" before you copy

Markus

[markus_doehr2]

> Our QA landscape has ECC, Portal and PI installed in separate servers, but belong to the same MCOD DB. Its the same in Production too.

So you say you have only one database server for all those instances?

Markus