cancel
Showing results for 
Search instead for 
Did you mean: 

Installing Oracle for SAP on existing non-SAP RDBMS

Former Member
0 Kudos

The title says it all -

I haven't been able to find any real docs supporting or not supporting the practice of using an existing Oracle 10.2 RDBMS to add an SAP DB. I know it's technically possible, but since the SAP Oracle installer is configured to build a new RDBMS for each SAP instance/DB installation, I'm wondering if it can be altered and piggy back on an existing one.

The reason is I have a customer who would like to do this so they can continue to use an existing DEV Oracle server without adding the stress of an indepedent set of oracle binaries running, and consuming resources.

Accepted Solutions (0)

Answers (1)

Answers (1)

fidel_vales
Employee
Employee
0 Kudos

3 questions

1) is any other application(s) running on that Database

2) I assume you got the licence for that "non-SAP RDBMS" directly from Oracle. What are the licencing conditions?

3) Is it an Enterprise version or any other?

I think that the best person to answer your question is your SAP Sales representative, but perhaps we can drop some ideas.

Former Member
0 Kudos

Hi -

This isn't really a question about licensing or the permissibility. I'm talking purely from a technical and supportability perspective.

So, to answer your questions-

1) is any other application(s) running on that Database

Other DB SIDs (non SAP) are using the same RDBMS that they would want to put the new SAP SIDs on.

2) I assume you got the licence for that "non-SAP RDBMS" directly from Oracle. What are the licencing conditions?

They do have an agreement with Oracle for their own DBs, but the decision has not been made whether or not to purchase the SAP Oracle licenses from them directly or bundled with SAP software.

3) Is it an Enterprise version or any other?

It is 10.2.0.4

markus_doehr2
Active Contributor
0 Kudos

So you mean you want to use one software installation for different databases? Technically possible but from a maintenance point of view critical.

SAP requires a bunch of patches for the database, your other application may also require others, you may get conflicts.

Markus

Former Member
0 Kudos

It's not me that wants to do this, but it's my customer. I have never encountered this kind of request before, so I am reaching out to the community.

But basically, yes, they want to install the SAP DB(s) to a pre-existing RDBMS installation in /opt/oracle/.... with multiple other non-SAP DBs. I'm talking about a non-prod environment, by the way.

You raise a good point about the patches because if they need to apply any to the RDBMS for the pre-existing <non-SAP> DBs, then there is the potential they could cause issues if they are not supported from an SAP perspective.

But aside from that - let's assume the release and patch levels from their own DBs are equal to the requirements from SAP. What other considerations/issues/supportabilty problems might be encountered?

markus_doehr2
Active Contributor
0 Kudos

> But aside from that - let's assume the release and patch levels from their own DBs are equal to the requirements from SAP. What other considerations/issues/supportabilty problems might be encountered?

If it's not a production system you could certainly go for it.

I think though, that it's MUCH LESS maintenance work using a second ORACLE_HOME than to try to fiddle with the huge amount of single/interim patches SAP requires. If you just check

Note 871096 - Oracle 10.2.0: Patches/patch collections for Oracle 10.2.0.2 (59 interim patches)

Note 1137346 - Oracle 10.2.0: Patches/patch collections for Oracle 10.2.0.4 (39 interim patches)

I can imagine you having a pretty hard time aligning that with the other non-SAP databases. On top may come incompatibilities with OPatch (SAP uses a "special OPatch") where you may need to switch between the official one and the "SAP-one" depending on which patch you install.

The only additional resources the new ORACLE_HOME uses is harddisk space (some GB) - which shouldn't be more expensive than the work you'll need to invest to keep the system and working for both.

Technically it can be done - certainly.

Markus

fidel_vales
Employee
Employee
0 Kudos

> This isn't really a question about licensing or the permissibility. I'm talking purely from a technical and supportability perspective.

As mentioned by Markus

=> Technically is possible

You do not want to talk about licences, but it is possible that the Oracle licence purchased does not allow it.

You didn't answered if it is an enterprise version of Oracle, you only answered the patchset level.

SAP only supports Enterprise Version.

SAP does not recommend for SAP instances to share the Oracle HOME with other SAP instances, therefore SAP will not recommend to do the same with other NON SAP instances.

You also have the mentioned problems with patches.

I see a lot os issues that will be raised as soon as you open a ticket in SAP.

Of course, those are not "technical"

Former Member
0 Kudos

Thanks for all the comments. Very helpful. Here's one more monkey wrench - the customer is running a version of LINUX (from Oracle) that is not in our PAM. They would want to use this for the Oracle DB tier. The app tier would run on Win server that is supported on our PAM.

Former Member
0 Kudos

If it's not in the PAM, it is not supported by SAP.

For more info SAP note 997990 may be helpful.

Former Member
0 Kudos

Thanks. But that note specifies that you must run SAP software on a supported version of LINUX. In the case of a distributed installation where the DB tier will be separate from the App tier, what are the support issues if the customer chooses to run Oracle DB on Oracle Enterprise LINUX?

markus_doehr2
Active Contributor
0 Kudos

> Thanks. But that note specifies that you must run SAP software on a supported version of LINUX. In the case of a distributed installation where the DB tier will be separate from the App tier, what are the support issues if the customer chooses to run Oracle DB on Oracle Enterprise LINUX?

Note 997990 - Oracle Enterprise Linux / Oracle Unbreakable Linux

<...>

As Oracle is going to provide their own patches for Oracle Unbreakable Linux, future compatibility to Red Hat Enterprise Linux is not assured.

Supporting Oracle Unbreakable Linux, Oracle Enterprise Linux or Oracle VM would then require a complete new certification by SAP, as hard- and software certifications prior conducted on Red Hat Enterprise Linux cannot be transfered to Oracle Unbreakable Linux by default.

Therefore SAP recommends using one of the already certified Linux distributions and their support offering (see note 171356 for more details), as there are currently no plans to support Oracle Unbreakable Linux for running SAP software on Linux.

<...>

Markus

Former Member
0 Kudos

Hello David,

so they will rely on getting support for the database server from Oracle, and getting support for the application server from SAP.

I think this might well work for a long time, but I would be afraid of support issues because SAP support and database support can't be separated clearly.

I am not sure how realistic the following scenario is, but it might be worth a thought:

Let's assume SAP will say: In order to run our application flawlessly on Oracle database, you have to set Oracle parameter whatever to the value of false.

Whereas Oracle will say: In order to run our database on Oracle Enterprise Linux, it is mandatory to set whatever to true.

Whom will you follow?

regards

fidel_vales
Employee
Employee
0 Kudos

Hi Joe,

That is the everyday with performance issues.

The transaction xxx is slow

The time is "lost" in the database => message forwarded to SAP/Oracle

Parameters and Patches are checked and do not match SAP recommendations ==> problems

SAP works in close contact with Oracle, but those are oracle people that know SAP.

It is not the first time a customer contact directly Oracle and they go crazy then they see the ammount of underscore parameters used in SAP systems.

Moreover. The "optimizer merge fix" are specifically build for SAP, a pure Oracle supported would have problems finding them and even knowing wich one the latest one is.

In general, the cases I have seen with a similar setup

1) use the SAP supported OS/patches

2a) when they get a recommendation from Oracle Support that "does not fit" SAP recommendations (Patch/parameter) a message is opened also in SAP to check.

2b) a message is opened both in SAP and Oracle for the issue.