tip-of-the Week -- Why should I use services (cont.)

Topics about Databases, Backups, Tuning, Architecture, Systems Management, etc etc.

Post Reply
bgrenn
Posts: 91
Joined: Mon Mar 16, 2009 11:47 am
Location: Rochester, NY
Contact:

tip-of-the Week -- Why should I use services (cont.)

Post by bgrenn »

Last week I talked about all the wonderful reasons to use services.  

This week I will cover why Services are especially important in RAC.  

First lets cover the 2 ways to create services.

For my example, I will create 2 services for my 2 instances.. The instances are db1 and db2.  the 2 services are payroll and batch..

Paroll runs only on db1
Batch runs on both db1 and db2.

1) Create services within the spfile.

Alter services set service_names='batch,payroll' scope=both sid='db1';
Alter services set service_names='batch' scope=both sid='db2';

PROS –

A) Services are automatically started with the database.

CONS –

A) No automatic failover
B) Services automatically starting with database may be undesirable.

2) Create services within CRS

Srvctl add service –d db –s batch –r db1,db2
Srvctl add service –d db –s payroll –r db1 –a db2
Srvctl start service d db


PROS –

A) services can be failed over automatically in the even of node loss.
B) Services Don’t automatically come up with database giving more control in a maintenance/emergency situation

CONS –

A) starting the services isn’t automated when a node bounces (most likely a protection mechanism giving the DBA the ability to access the nodes health before allowing connections).

SUMMARY- In my opinion using services within CRS allows much more flexability, and can be used to “drain” connections from a specific node to do maintenance (i.e. shutdown the batch service on db1 2 hours before maintenance to stop new connections).

Remember, in RAC it is very important for the application to be able to handle disconnects properly to use the full power of RAC.

GOTCHAS – Services will fail over automatically when a database processes cannot be initiated. This could include max processes on the instance, or archiver hung. Both situations will cause RAC to failover the service, and possible kill all current connects to facility this switch.
Post Reply