Oracle - SAP in MC Service Guard

[Emanuele_4]

Hi everybody...a simple question (I hope so! ;.))

I've a production environment with a 2 node cluster. On the first node I have a package with SAP Central Instance and on the second node I have a package with oracle DB.

Obviously, Sap needs Oracle to run properly.

Whene the oracle package fails...it switches on the standby node (so, it switches on the sap CI node)...

I thought that Sap should run properly...I supposed that, after a few minutes of inactivity (the time need to switch the oracle package) sap could be able to work again with the switched DB.

The sap consultant told me that SAP had a problem with semaphores and I need to clean all the sap semaphores and restart sap!

I think it's abnormal to re-start sap after that the Oracle DB has switched...because...what kind ok high availability is it if I should restart sap every time I switch Oracle??

Ok, I should have done the One package configuratione (CI and DB toghether) but the client has always the reason! ;-)

Thanks in advance to everybody...

Emanuele

[Chan 007]

Hi Emanuele,

I am not sure how the SAP to DB integration is implemented in your place.

The debate you put here is about the integration part between DB & SAP.

So hardware it is nothing, that what i can say bening a SA. But check your DB & SAP BASIS team to have a meeting what exactly they need when the DB is restarted? This should solve your question.

I have checked few things, there is a parameter called dbreconnect in the SAP-CI, if this times out you need to restart your SAP-CI. Check with your SAP-CI (BASIS team) and solve this problem, by increasing the timeout.

Chan

[Brian Crabtree]

Emanuele,

I would verify that SAP and Oracle can run on the same server at the same time. It almost sounds like there might be an issue with the kernel parameters not being set high enough.

For us, we run the DB and CI on the same server, which has been recommended by SAP, and use the standby server as an app server that we stop when we have to fail over. It does make things simpler in most cases.

Brian

[Emanuele_4]

Thaks again...

I know that the DB and the CI can work fine on the same node...I also know that the two packages can work fine even on separete nodes but the thing I don't know is how can SAP work if the DB packages switch from the second node to the first one.

Example:

Before:
1st node --- 2nd node
CI --- DB

After failover or planned switch:
1st node --- 2nd node
CI - DB --- no packages

At this point...How should I expect SAP is working?

Does sap wait until the DB is up and running?
Or SAP will never work properly until I restart sap (this is the actual situaztion...I should restart sap to clean semaphores...)

That's all...

Thanks again!

Emanuele

[Philippe Cussigh]

Hello,

- Oracle and SAP can work on the same node of clusters.
- The switch can be done without stopping SAP
- First condition is to set the dbreconnect parameters (on Ap.Server. also if you have)
- Second condition is to have enough kernel resources

This is normally working perfectly. Maybe if you have possibility you can test the dbreconnect by stopping/restarting Oracle on same node without switch. You will be then able to isolate the issue.

Best regards

Philippe

[Chan 007]

Hi,

I have a same systems, but if my server DB fails to come back in say 10 Mins, SAP needs to be restarted. That is what I told you to check you dbreconnect parameter and increase the timeout. This should solve your problem.

But restarting CI is better, that is what your BASIS team insists.

All SAP can tell you is that SAP is working, e.g get a GUI, but when you try to establish a connection it will fail or sometimes you will timeout when login.

Hope this helps you

Chan

[Sunil Kumar MK]

Hi Emanuele,

Just in case: make sure you have your Oracle database setup correctly on the Cluster. Check if the remote listeners are configured and started on different nodes and that you can connect to the database after failover using sqlplus or any Oracle client with the same logical Ip Address.

Regards
Sunil

[Volker Borowski]

Well,

SAP is a DB Application !
You can forget it, to work with it when the DB is down for whatever reason.

If SAP is loosing the DB, it is trying to reconnect to the DB. If it succeeds -> fine. If not, it will continue trying. There are some parameters availabe which you can squeeze, but a new release has reasonable settings to survive an offline backup started form transaction DB13 in a running system.
This is where this reconnect mechanism was originally intended for. To keep SAP up and keep the filled buffers in memory at their quality-level. Now if you do not want the defaults (as said, the default are set to survive an offline backup), you might need to have the workprocesses some quicker spinning in HA-environment. See the parameters needed to adjust here:
http://help.sap.com/saphelp_erp2005/helpdata/en/08/57446a4ae611d1894f0000e829fbbd/frameset.htm

Now when the DB is down you will not be able to do anything sensible with the SAP. Shortdumps all over will occur for any action that needs the DB (which is roughly 99.2% of all possible action). Nearly all of your active jobs will die for database faults and may be in need to be restarted.

So strictly spoken the architechture in a switchover environment is not "high availability", but "very quick re-availability".

Now if the CI is configured to utilize a lot of the physical resources of node1, it might be usefull to restart the CI in case the DB is switching to the same node1, as less resources are available now on this node. You might want to reduce memory consumption on the CI to feed something to the DB in this case.
Of cource taking down the CI has some additional impacts to consider too (enqueue is going down and might loose ernties that are allocated on other app-instances, so their de-queue will fail later on, if no replicated enqueue configured), but you might find out, that it is not all that bad at all to take CI down in addition.
I have a customer who has DB+CI on node1 and a big APP-instance on node2 and if node1 dies, he takes down the APP-Instance completely and entire CI+DB are restarted on node2. This results in a complete shutdown of the system for a short time, but lets him at least run the CI in the very same configuration.

Hope this helps
Volker