Examples of Using Server Pools

This section includes the following examples of using server pools:

 Minimum and Maximum Number of Servers

 IMPORTANCE Attribute of Server Pools
 Consolidation of Databases

Minimum and Maximum Number of Servers

Consider a four-node cluster configured into two server pools named online and backoffice. A database
named dbsales runs in the online server pool offering the browse, search, and salescart services. A
database named dberp runs in the backoffice server pool and offers
the inventory and shipping services, as shown in Figure 1-2. During normal business hours the enterprise
requires a minimum of two instances of the dbsales database and one instance of the dberp database to
meet normal demand.

Figure 1-2 Server Placement by Minimum and Maximum Limits

Description of "Figure 1-2 Server Placement by Minimum and Maximum Limits"

In this policy-managed deployment, the value of the MIN_SIZE server pool attribute for the online server
pool is 2, while the value of the MIN_SIZE server pool attribute for the backoffice server pool is 1.
Configured this way, Oracle Clusterware ensures that there are always two servers in the online server pool
and one server in the backoffice server pool. Because this is a four-node cluster, there is one server left not
assigned to either server pool. Where that last server gets deployed is determined by the MAX_SIZE server
pool parameter of each server pool. If the sum of the values of the MAX_SIZE server pool attribute for each
server pool is less than the total number of servers in the cluster, then the remaining servers stay in the Free
server pool awaiting a failure of a deployed node.

If the value of MAX_SIZE is greater than that of MIN_SIZE, then the remaining server will be deployed into
the server pool whose importance value is greatest, as shown in Figure 1-2, and fully discussed in the next
section. In this case, the server is a shareable resource that can be relocated online to join the server pool where
it is required. For example, during business hours the server could be given to the online server pool to add
an instance of the dbsales database but after hours could be relocated to the backoffice server pool,
adding a dberp database instance. All such movements are online and instances are shut down,
transactionally.

These two policy-managed databases are running only the instances that are required and they can be
dynamically increased or decreased to meet demand or business requirements.

IMPORTANCE Attribute of Server Pools

The IMPORTANCE server pool attribute is used at cluster startup and in response to a node failure or eviction.
In contrast to administrator-managed databases, you can configure server pools with different importance
levels to determine which databases are started first and which databases remain online in case there is a
multinode outage.

Consider a four-node cluster that hosts a database named dbapps in two server

pools, sales and backoffice. Two services, orderentry and billing, run in the sales server pool,
while two other services, erp and reports, run in the backoffice server pool, as shown in Figure 1-3. By
configuring the value of the IMPORTANCE server pool attribute of the sales server pool higher than that of
the backoffice server pool, the services in sales start first when the cluster starts and are always available,
even if there is only one server left running after a multinode failure. The IMPORTANCE server pool attribute
enables you to rank services and also eliminates the requirement to run a service on all nodes in a cluster to
ensure that it is always available.

Figure 1-3 Server Pool Importance

 Description of "Figure 1-3 Server Pool Importance"

Consolidation of Databases
You can use several different approaches, either discretely or combined, to consolidate Oracle databases.
Policy-managed deployments facilitate consolidation. In the case of schema consolidation, where multiple
applications are being hosted in a single database separated into discrete schemas or pluggable databases
(PDBs), you can use server pools to meet required capacity. Because of the dynamic scaling property of server
pools, you can increase or decrease the number of database instances to meet current demand or business
requirements. Since server pools also determine which services run together or separately, you can configure
and maintain required affinity or isolation.

When it is not possible to use schema consolidation because of, for example, version requirements, you can
host multiple databases on a single set of servers. Using policy-managed databases facilitates this database
consolidation because they can share the same server pool by making use of instance caging, which enables
you to dynamically increase or decrease databases, both horizontally (using server pool size) and vertically
(using the CPU_COUNT server configuration attribute) to meet demand or business policies and schedules.

See Also:
Oracle Clusterware Administration and Deployment Guide for more information about the CPU_COUNT server
configuration attribute

By contrast, with administrator-managed databases, you are required to reserve capacity on each server to
absorb workload failing over should a database instance or server fail. With policy-managed databases,
however, you can effectively rank server pools by the business necessity of the workloads that they are running
using the MIN_SIZE, MAX_SIZE, and IMPORTANCE server pool attributes.
When the failure of a server brings a server pool to below its configured minimum number of servers, another
server will move from a less important server pool to take its place and bring the number of servers back up to
the configured minimum. This eliminates the risk of cascade failures due to overloading the remaining servers
and enables you to significantly reduce or even eliminate the need to reserve capacity for handling failures.

Migrating or converting to policy-managed databases also enables cluster consolidation and creates larger
clusters that have greater availability and scalability because of the increased number of servers available to
host and scale databases. Because policy-managed databases do not require binding their instance names to a
particular server and binding services to particular instances, the complexity of configuring and managing
large clusters is greatly reduced.

An example deployment is shown in Figure 1-4 where the previous two cluster examples (shown in Figure 1-
2 and Figure 1-3) are consolidated into a single cluster, making use of both database consolidation (using
instance caging) and cluster consolidation (using server pools) configured so that workloads are properly sized
and prioritized.

Figure 1-4 Consolidating Databases

Description of "Figure 1-4 Consolidating Databases"