Database Reference
In-Depth Information
Guidelines for Services
The following guidelines are useful while creating services to improve cluster management.
•
Create a separate service for each major application component. Service is an excellent
method to implement application affinity. For example, if PO application accesses numerous
PO-related tables and if one instance is sufficient to service the PO application, then keep PO
service contained in one instance. You can keep the PO service connecting to an instance by
creating the service with just a preferred instance. Application affinity improves performance
by reducing global cache latency.
•
Design the service in such a way that both preferred and available instances are configured.
While designing services, consider the scenario of each node shutting down and construct the
service placement based upon those scenarios.
•
Use policy-managed databases instead of administrator-managed databases if there are
numerous nodes (12+) in your cluster.
•
Use of SCAN listeners and services reduces administration overhead. Especially for sites
upgrading from versions 11.1 and earlier, it is important to alter the connection string to
use SCAN listeners and SCAN IP addresses. It is very hard to change the connection string
post-upgrade.
•
Specify optimal clbgoal and rlbgoal parameters matching the application workload. Service
metrics are calculated as an average for all the workloads connecting to that service. So, if
your application has different workloads and if it is possible to segregate the application
components depending upon the workload characteristics, then use disjointed, unique
services for those application components. This segregation of application workload to
different services improves the accuracy of service metrics and improves the accuracy of
load balancing decisions. This segregation also improves the ability to identify application
components consuming resources quickly.
There are only a few minor pitfalls in creating a new service. Production clusters with 100+ services operate
without any major side effects. While we are not recommending that you create hundreds of unnecessary services,
you should create as many services as you need to split the applications into manageable, disjointed workloads.
In version 11.2, if there are numerous services (100+) and numerous listeners, then there is a possibility that the
PMON process might spend more time on service registration to listeners due to the sheer number of services and
listeners. But, in version 12c, this possibility is eliminated as the LREG parameter performs service registration and
PMON is freed from listener registration.
SCAN and SCAN Listeners
Introduced in version 11.2, SCAN (Single Client Access Name) is an effective tool to enhance workload management
in RAC, to eliminate complexity in connection string management, and to provide faster connect time/runtime
failover. Further, the SCAN feature simplifies connection management by providing a logical abstraction layer of the
cluster topology. Cluster topology changes do not trigger changes to connect strings.
Consider an environment with numerous applications and users who are connecting to a RAC database with
three nodes in the cluster, using the following connect string:
PO =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=YES)
(FAILOVER=YES)
