The right way to run SGEN in MSCS cluster system?

[Former Member]

We have a NW7.0 system installed on MSCS cluster with two nodes. We executed SGEN when central instance and database is running on node2 and everything works fine. And we can see when SGEN was running, it was using work processes in both nodes. However, after a while we failover the central instance and database to node1, we experienced some program compiling and some indexes are missing. So the performance in node1 is slow than node2. My question is: Do we need run SGEN again in node1? With the new architecture of NW cluster, there are local instances on both nodes, what is the right way to run SGEN in this architecture?

Any comments and experiecen sharing are appreciated.

Yujun Ran

[Former Member]

Hi all,

I am Yujun's colleague working on the installation of this cluster...

The reason we have to regenerate SAP_ALL in the first place, was because we(with SAP_ALL assigned) were not able to run SM59 and the SU53 report suggested auth object S_RFC_ADM. Regenerated SAP_ALL on node 2 fixed the problem. However after failed-over to node 1 we found we can't use SM59 again with the same SU53. This is one more thing that rose for our concerns.

For your information, the DB and ASCS are installed on shared disks. And 2 dialog instances and 2 enqueue replication instances are installed separately on 2 nodes.

For the kernel I am sure ASCS and both CI instances are the same as they all copy kernel files from
sapmnt\sap\<SID>\SYS\exe\uc\NTAMD64. Also profiles for all instances are stored on
sapmnt\sap\<SID>\SYS\profile. And kernel/profiles are all on shared disks.

If you can see anything in this configuration is incorrect, we would appreciate a lot if you can help point it out.

Regards,

Eric

[Former Member]

Dear Eric

SGEN has got nothing to do with the nodes or the hardware.

Please try to compare both the nodes with their connectivity.

Most probably this may the network issues through which data packets flow.

Regards

Khalid

[Former Member]

Bhavik,

Thanks for your quick reply. We did not apply any kernel, SP, or any changes on both node since we ran SGEN last time, which was just three weeks ago. Because our system was running on node2 (which was the place we ran SGEN) and everything run fine so we did not notice any issues. But last week, when we were testing something else and we failover to node1 and immediate noticed something performance impact. For example, it is doing sequencial read to table BALHDR and slow down everything. After we failover back to node2, then read table BALLHDR is fast and everything back to normal. We don't know how to fix this issue except to failover to node1 and try to run SGEN again in node1?

Thanks,

Yujun Ran

[Former Member]

Hi Yujun,

What you mention is not so extrange, remember that when you switch to Node 1 you are sharing the same RAM and CPU for Database and Central Instance and of course performance will suffer. When runing CI in Node 2 and DB in Node1 then everyone has its own HW for itself, DB won't have to share Memory and CPU so performance will be better.

ABAP programs are precompiled at DB level so it does not have anything to do if you are running in Node 1 or 2.

[Former Member]

AC,

Thanks for your reply. I am not talking about general performance issue regarding memory or CPU. We are running CI and DB on one node, either node1 or node2, they are equal regarding hardware. The problem we don't know how to fix is when CI and DB on node2, BALHDR table is read by index, very fast. But when CI and DB on node1, BALHDR table is read sequencially, very slow. And we are running the same applications and we don't know how to fix the problem. That's why I am thinking to regenerate index by running SGEN again when system is running on node1.

Thanks,

Yujun Ran

[former_member524429]

Hi,

The CI and/or DB are installed on shared disks ?

The problem may be with the NIC settings or any other communication link to that Shared Disk Storage. Compare them with the other node where you are not getting any performance issue.

Have you analyzed the availability of memory after fail-over to node 1 ?

Regards,

Bhavik G. Shroff

[Former Member]

OK, I see what you meant, basically if you run SGEN in either node you should have the same result even if you switch nodes so if you are sure an index is missing when switching disks to node 1 then ST04 should help about misssing indexes but I don´t see how a database is missing an index if database is in the shared disks. Running SGEN again should not have any impact but you could give it a try and see what happens.

[Former Member]

Hi Bhavik and AC,

Thanks both of you. Yes, our database is on shared disk and so as message server and enque process are also installed on shared disk. But as you may be aware, the new NW 7.0 cluster has different architecture from WAS 6.40, for example, we have two dialog instance (with dispatch and enquen replication process) run the same time on EACH node. So when we failover, only DB and CI(message server) move to next node, but two local dialog instances not change. I am wondering what we have generated by SGEN in database have to somehow recoup with the node have not been running SGEN. We are concerning if our cluster system was installed properly.

We found another example is that, we have to regenerate SAP_ALL profile when system failover to node1. Looks in similar situation. The problem for us is most of the transaction/programs run OK on both nodes, just a few spot like we talked here had problem.

Thanks,

Yujun Ran

[Former Member]

we have to regenerate SAP_ALL profile when system failover to node1

Now I'm in shock.....

This should be a Cluster problem, have you checked if DB and SAP Kernels are in shared disks also? what about the profiles? looks to me that something is not being moved when you switch between nodes.

But SAP_ALL profile is in the DB not a outside or in any file at disk level, the only thing I can think about is Kernel that is probably not moving and for some reason there are differences between SAP Kernel in the Two nodes and for some reason out of my mind this behavior is happening.

Please keep posting your findings because this is very interesting.

[former_member524429]

Hi

However, after a while we failover the central instance and database to node1, 
we experienced some program compiling and some indexes are missing. 
So the performance in node1 is slow than node2. My question is: Do we need run SGEN again in node1?

SGEN is used to pre-compile all ABAP loads of a number of programs, function groups, classes, BSPs. And the compiled Result is stored into the Database. So, upon program execution the Response Time will be less.

It is not having relation with "Index missing" situation. that is other thing that After successful of SGEN, you will have to update Statistics of whole DB Objects.

For all Programs, it is showing compiling...or only for some Programs... ?

Have you applied new SAP Kernel......Have you applied Any Support Patches after ur last successful SGEN ? These may lead to the invalidation of existing ABAP loads. In that case you will have to re-run SGEN on low workload.

You can[ schedule RSGENINVLAS|http://help.sap.com/saphelp_sm32/helpdata/en/b1/52583c65399965e10000000a114084/frameset.htm] report in night to regenerate all invalidated ABAP loads automatically(SAP Note 438038).

Regards,

Bhavik G. Shroff