cancel
Showing results for 
Search instead for 
Did you mean: 

One database for 2 system?

Former Member
0 Kudos

We have an expert who says the best is to have one database for two main system using RAC.

Is it possible?. (I believe this is MCOD). What are the plus and minuses?

How to perform such an instalation?

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Thank you all for your contributes.

Let me explain. We are in the beginning of redesign of infrastracture having 2 productive systems with Oracle as OS.

They comunicates with each other(I have no details so far but i think it is java connector, RFC or XI communication(I will learn about that tomorrow).

Our infrastracture expert does not have SAP experience. (and I do not havve MCOD experience)

The infrastructure expert opignion is to have "one database only which is more logical and easier to maintain).

So far I am in line with him.

However his idea that two ECC 6.0 system should communicate directly Oracle to Oracle seems completely unlogical (if possible at all).

He is sure that this would lead to improvement of performance(and this is the right way)

I thing even if possible this would be a "dirty" solution

Former Member
0 Kudos

Wow, MCOD is not easier to mantain because if you need for example to install patches to Oracle both systems will go down and so much other maintenance jobs for SAP already mentioned.

Let me ask you something, how many concurrent users does the company have? When you say that they have two production systems comunicating with each other you mean that it both are the Production system and they did this because performance? or they are two different companies or branch offices, etc, and each one have its own PROD system?

lbreddemann
Active Contributor
0 Kudos

> Let me explain. We are in the beginning of redesign of infrastracture having 2 productive systems with Oracle as OS.

Although Oracle began to sell "Unbreakable Linux" as a OS, I believe you mean that you will use Oracle as your DB platform, here...

> They comunicates with each other(I have no details so far but i think it is java connector, RFC or XI communication(I will learn about that tomorrow).

Most SAP products communicate with each other. That's the whole point of a integrated solution.

And usually all available communication models are used ...

> Our infrastracture expert does not have SAP experience. (and I do not havve MCOD experience)

Well, in that case your expert is the wrong person to teach you the best way to implement your SAP systems landscape.

MCOD does not change the way SAP systems communicate. It's just about storing data in the same database instance.

To be able to do that, SAP stopped using SAPR3 as the only possible database schema name, and introduced the SAP<SID> /SAP<SID>DB users. That way you can put more than one schema of a SAP product in any database.

Let's say you want to run ECC and CRM on one machine, then you may use the db users SAPECC/SAPECCDB and SAPCRM/SAPCRMDB in the very same database.

But although it would technically possible to allow the SAPCRM user access to the SAPECC data, this is not done. Instead the systems will still use the same communication models like RFC, BAPIs, XI - you name it. But never ever direct database access.

This is not even done between the SAP<SID>/SAP<SID>DB schemas. Instead data is send via JCOnnector.

> The infrastructure expert opignion is to have "one database only which is more logical and easier to maintain).

Nice thought and heavily Oracle-biased (everything into a single database!).

But this is not what you do with SAP products.

> So far I am in line with him.

> However his idea that two ECC 6.0 system should communicate directly Oracle to Oracle seems completely unlogical (if possible at all).

> He is sure that this would lead to improvement of performance(and this is the right way)

> I thing even if possible this would be a "dirty" solution

He is far from having the faintest idea about SAP NetWeaver - he really shouldn't be your advisor for that product. "Dirty" solutions will be solutions that won't be supported and that will get you in trouble.

Sorry, but I just can recommend to get a consultant who actually knows what he's talking about.

regards,

Lars

Answers (2)

Answers (2)

Former Member
0 Kudos

RAC gives you High Avalability. Regardless of separate databases or MCOD, RAC with 2+ nodes give High Availability. If one nodes goes down, your system continues to operate. But as Lars said, RAC is expensive and has additional administrational challenges.

-Regards

lbreddemann
Active Contributor
0 Kudos

We have an expert who says the best is to have one database for two main system using RAC.

Hi Joe,

define 'the best' please.

Do you mean: cheapest, fastet, most reliable .... ?

MCOD (Multiple Component in One Database) ís an option to have two or more SAP products use the same database instance.

E.g. you can put a ECC and a CRM into the same DB instance.

OneDB (SCM + liveCache) is another example for that.

Basically all double-stack installations (ABAP+J2EE) are like that.

Anyhow, you create an additional dependency between the systems that share the db instance.

You cannot backup/restore just one product, but you'll always have to do it for all installed products.

You don't have a downtime for one system anymore - but always for all systems that share the db.

Using RAC does not change this.

Besides the fact that RAC is quite expensive and needs intensive administration, it does not change anything about the MCOD approach.

So perhaps you ask your expert, about what his proposal is 'best for' and I'm sure he will then be able to explain you how to implement this.

regards,

Lars