Oracle RAC load balancing sessions

[Former Member]

Hi Gurus,

I have just implemented SAP on a 2 node RAC. We had RAC1 shutdown for maintenance, and all sessions were failed over to RAC2. Upon bringing RAC1 up, all the sessions remains connected to RAC2. New sessions are load balance between the 2 nodes. Hence, RAC2 is much busier than RAC1.

How can I distribute the sessions/load in oracle upon bringing back a RAC node?

Thanks,

Tzyy Ming

[Former Member · Accepted solution]

Hi Steve,

This is what I was expecting. Do you have a note? I was hoping to find some way or utility to re-balance the sessions. Since the sessions can fail from 1 node to another, my thought is failing back should not be a problem.

Hi Orkun,

I am using 11g scan. I have switched all the scan services to RAC1. RAC2 has over 300 sessions. After the entire afternoon, RAC1 only manage to build up less than 100 sessions, while RAC2 still has 300 sessions. Most users are connected to SAP throughout the day. It will be nice if we can average out to 200 sessions on each node.

Relocating the service manually requires human intervention and creates human error. How can we configure RAC so that it knows 1 node is busier than the others and automatically redirect the connection to the lighter node?

Thanks all,

Tzyy Ming

[Former Member · Accepted solution]

Hi,

>> I am using 11g scan. I have switched all the scan services to RAC1. RAC2 has over 300 sessions. After the entire afternoon, RAC1 only manage to build up less than 100 sessions, while RAC2 still has 300 sessions. Most users are connected to SAP throughout the day. It will be nice if we can average out to 200 sessions on each node.

You shoudn't expect that a SAP workprocess kills itself and connect to another resource during the runtime, in order to RAC1. So, newly created processes may be connected to the newly startup RAC node. Because of this RAC2 has 300 and RAC1 has 100 sessions on it.

>> Relocating the service manually requires human intervention and creates human error. How can we configure RAC so that it knows 1 node is busier than the others and automatically redirect the connection to the lighter node?

As far as I know that this is manual operation, not automatic

I hope that it is clear

Best regards,

Orkun Gedik

[Former Member]

I got my answer, some work processes error out and restarts itself. Thanks both.

[Former Member]

Hi Orkun,

If I understand you correctly, Oracle sessions are linked to SAP work processes. And SAP work processes have persistent connection to Oracle.

So if the connection is persistent, I am wondering why the number of Oracle sessions count for our system varies over time? Our dialog instances work processes remains untouch, operating mode is not used, but the sessions count increases and decreases.

Further, what is the relationship between Oracle sessions and SAP work processes? 1-1? How does work process knows when to establish sessions?

Thanks so much. It puzzled me.

Cheers,

Tzyy Ming

[Former Member]

I was expecting much more advance technology from Oracle RAC. Thanks Orkun.

[Former Member]

Hi,

It is not related by Oracle RAC but SAP workprocess architecture itself In the theorical perspective, there must be a virtualization layer between SAP WPs and Oracle WPs. Otherwise, how can a SAP workprocess will handle a physical database WP?

Or SAP WPs needs to be attached for each request which will increase response time.

Best regards,

Orkun Gedik

[Former Member]

Hi,

It is relocation of failed services concept. So, assume that RAC1 is failed, the services will be migrated to RAC2. At this stage, when the RAC1 started-up respectfully, all migrated service will not come back to the RAC1.

So the services needs to be relocated manually;

srvctl relocate service -d <DB_UNIQUE_NAME> -s <Service name> -i RAC2 -t RAC1

Best regards,

Orkun Gedik

[former_member182307]

Hello,

It's not possible, as far as I know.

The SAP workprocesses connect to the database at startup.

Once the connection is done, it won't be set ton another RAC n,ode unless it's stopped.

HTH,

Steve.