MCOD - yay or nay

[Former Member]

We're planning our new SAP landscape. Medium-Large customer (4000 users), with the lot (ECC6, XI, EP, BI). We're using Solaris 10 and Oracle 10.

Time has come to decide on DB deployment. MCOD is an option I'm considering since it can significantly reduce the number of instances to manage / upgrade / maintain (depending on how you do it, it could go from 17 down to 5 or 8, quite a considerable reduction).

However, I'm reluctant to go this way for a number of reasons:

- Lack of installed base. I don't know anyone in a mid-larg customer using MCOD on Oracle for production (and SAP was not helpful in getting reference sites)

- Unkown operations. I just don't know if this makes life simpler or a living hell.

- I'm reluctant to do this in production, and I've set a rule that testing environments should resemble production as closely as possible, so with PRD and TST out, the reduction in number of instances is not huge, so it does not make sense.

I'm looking for real-life experiences of people using MCOD in testing or production environments, supporting different products (at least ECC, BI, XI) and on rather large customers (1000+ users).

Any comments on why / why not to do it , or operational experiences would be much appreciatted.

Thanks

[Former Member · Accepted solution]

MCOD is only necessary if you need to have the possibility of a point in time recovery of databases which store data of depending systems.

regards

Peter

[Former Member]

MCOD does significantly reduce the overall size of the database compared to a sperated landscape. The ease-of-use is mainly in the single backup strategy it takes. MCOD was originally designed to support SAP All-in-One and not for the mySAP Business Suite. The only situation I would recommend MCOD is in the case where an extra small appliaction resides to SAP, like Vertex or BugsEye.

[Former Member]

Thanks for all the answers folks.

[Former Member]

Hello:

Our first phase is completed and we have just gone live with R3,XI,AP,BW and SM. We also have a medium-large customer base (3500 users), number of instances 14. We did not use MCOD mainly because our production environment is a clustered environment. Second, we were strongly advised to stay away from MCOD because to manage / upgrade and maintain can become a total nightmare. So as Eric has stated over and over again......... AVOID...............

Regards

[Former Member]

Thanks folks. Staying away from MCOD was also my gut feel, but I wanted some hard evidence on where the hiccups were, given that -at first sight- there seems to be substantial cost savings by using it.

Seems like ease of maintenance -or rather its lack of- is the main driver to stay away from it. Any other potential issues you see?

Thanks

regards

[former_member204746]

About MCOD:

Avoid

run away from this.

refreshing this type of environement is full of trouble.

oracle upgrade is messy

you put all your eggs in the same bag

in case of maintenance, both instances will not be available

avoid! avoid! avoid!

[Former Member]

Hi

I would only use MCOD in your non-production environment. A couple of reasons are:

1) When you upgrade the database and need to change Kernel's, service packs, etc, in ALL the instances at the same time, it can become a bit a hair raising experience.

2) Refreshing your Test systems from production is alot harder.

I have only used MCOD in our Test/Development environment but I have reverted to having a database per instance having just going through the NW04s upgrades. If your systems have enough memory, I recommend not going MCOD.

Regards

Doug