Oracle RAC is designed to cater for Oracle specific applications and also non-oracle applications. These applications, both Oracle and non-Oracle, when deployed on RAC, are termed as resources and Oracle RAC can manage both kinds of resources on the clusterware stack. Examples of both oracle and non-oracle resources are: database instance, database services, xclock, Apache etc.
The traditional way to manage these resources was manually. The DBA was supposed to decide on which instance (or instances) these resources would run and would set them up accordingly. An example of this can be taken when you are configuring a service which has to be present on some nodes as Preferred and on another node(s) as Available. Although this kind of management works well, it’s not something that can scale for a cluster which has got a large number of nodes in it. Think about sitting and managing the instances over a 200 nodes cluster, it wouldn’t be very exciting would it?
Enter Server Pools
Grid computing is a concept within Oracle database which has been there since 10g. The basic meaning of grid computing is to divide the hard coupling of the availability of a resource over the machines thus letting the resources be available on a ‘wherever and whenever’ kind of basis. This means that there shouldn’t be a restriction on a said resource which must be present on a specific machine itself or can only be accessed from a specific machine. The very same concept is enhanced in 11.2 RAC with the introduction of Server Pools.
Server Pools allow the same functionality of logically dividing the cluster into small segments that can be used for varying workloads. But unlike the traditional mechanism available up to 11.1, which only allows this task by choosing the instances to run on nodes as Preferred & Available and running services using the same architecture, server pools offer a much larger list of attributes which help in the management of resources in a rather simple and transparent way. In server pools, the underlying hosts of the cluster are added (and removed) from the pools much more on-the-fly, and take the burden off the DBA’s shoulders for this task. With just a few parameters to take care of, the whole stack becomes much easier to govern and administer, while still being completely transparent yet powerful to manage all the types of different resources in the RAC clusterware environment, especially when the number of the nodes go beyond two digits.
The built-in pools, Free and Generic
In 11.2, with the installation of the cluster, two pools get created by default-Free & Generic.
Generic Pool
When you upgrade your existing version of the clusterware to 11.2, all the nodes get mapped to the in-built Generic pool. This is an internally managed server pool and the modification of the attributes of this pool is not allowed. Besides the addition of the nodes of the previous cluster, in 11.2, when you create a database which is Admin-managed, that also becomes a part of the Generic Pool as a child pool of it.
Free Pool
This is another pool which gets created by default with the installation of the 11.2 clusterware. If it’s going to be a fresh installation of the clusterware environment, all the nodes would be attached to this pool first of all. From this pool only, the nodes would move to the manually created server pools. As like the Generic pool, this is also an internally managed pool but still some attributes are available to be modified by the dba like IMPORTANCE.
Child Pools
Server pools can have the child pools under them as well. The child pools are going to have their own properties. The order in which the host allocated to them is going to be based on the IMPORTANCE parameter assigned to them. To understand the child pools, we can imagine a parent pool named as OLTP which represents the working of OLTP database. This parent pool now can have two further child pools, HR (human resource) and AP (account payable) . Now, we can have different attributes set up for the child pools depending on the importance that we want to give to each domain of the work. The hosts assigned are mutually exclusive within the parent pools. For the child pools, whether the same is possible for the child pools or not, would be based on the fact that what’s the value of the attribute EXCLUSIVE_POOL for them. If there is a string value assigned to this parameter and this is shared by two child pools, host assigned to one child pool can’t be shared by its other sibling.
How the hosts are added to the server pools
The allocation of the hosts is going to be happening in the following order:
Generic Pool
Explicitly created pool
Free Pool
Oracle would keep on adding the hosts to the server pools as long as they have not been equal to the values of the MIN_SIZE and MAX_SIZE on the basis of the IMPORTANCE that’s assigned to the server pools. The hosts are going to be added exclusively to the pools i.e. the hosts added to one server pool won’t be shared with the other pools. The hosts can be shared by the child pools provided that there is no value set for the parameter EXCLUSIVE_POOLS which would restrict the host sharing within the child pools as well.
Database management changes in 11.2 -to use server pools
To incorporate the usage of server pools, there is a change introduced in the database itself. From 11.2 onwards, there would be two types of databases available, Admin Managed and Policy Managed. Choosing either one would make you use the server pools though it would vary whether those server pools would be explicitly created by you or would be the default one available already.
Admin managed database
This is sort of the same as the traditional database type i.e. where a DBA is responsible to manage the allocation of the resources and instances explicitly on the available instances, and also the instances on the respective nodes. This database type would assign the instances to a child pool of the default pool available Generic pool. Having the Generic pool as the parent, no modification of the child pools of the Admin managed database’s instances would be allowed for the DBA to be done by their self. Depending on the number of nodes being chosen initially for the database, the instances would be started on each one of them. By default, with a fresh installation of 11.2 RAC, all the nodes would get added to the Generic pool and in the upgrade, all the nodes of the previous version would also be added to the Generic pool. Although this type seems to be much simpler and like the older versions and techniques of managing the instances, this can’t be used when the number of nodes pass a number which is difficult to manage by a DBA, for example 100. In that case, the next type of the 11.2 database would be helpful-Policy Managed database.
Policy Managed Database
This type of database administration is meant to make DBAs’ life simpler by not letting them worry about managing each of their instances on each node individually, but to use a server pool to manage the instances. By using server pools, the administrative tasks to manage the database becomes much simpler.
-----------------------------------------------------------------------------------------------------------
Related links:
11G R2 RAC PROBLEMS AND SOLUTIONS
CLONE DATABASE HOME IN 11GR2 RAC
NIC BONDING IN 11G R2 RAC
PREREQUISITE TO CONFIGURE GNS AND GPNP IN 11G R2 RAC
SERVICES CONFUSIONS CLEARED
SETUP 10G RAC ON YOUR LAPTOP
SETUP AND PLAY WITH 11G R2 RAC AT YOUR HOME PC
11g R2 RAC - ADD INSTANCE MANUALLY
The traditional way to manage these resources was manually. The DBA was supposed to decide on which instance (or instances) these resources would run and would set them up accordingly. An example of this can be taken when you are configuring a service which has to be present on some nodes as Preferred and on another node(s) as Available. Although this kind of management works well, it’s not something that can scale for a cluster which has got a large number of nodes in it. Think about sitting and managing the instances over a 200 nodes cluster, it wouldn’t be very exciting would it?
Enter Server Pools
Grid computing is a concept within Oracle database which has been there since 10g. The basic meaning of grid computing is to divide the hard coupling of the availability of a resource over the machines thus letting the resources be available on a ‘wherever and whenever’ kind of basis. This means that there shouldn’t be a restriction on a said resource which must be present on a specific machine itself or can only be accessed from a specific machine. The very same concept is enhanced in 11.2 RAC with the introduction of Server Pools.
Server Pools allow the same functionality of logically dividing the cluster into small segments that can be used for varying workloads. But unlike the traditional mechanism available up to 11.1, which only allows this task by choosing the instances to run on nodes as Preferred & Available and running services using the same architecture, server pools offer a much larger list of attributes which help in the management of resources in a rather simple and transparent way. In server pools, the underlying hosts of the cluster are added (and removed) from the pools much more on-the-fly, and take the burden off the DBA’s shoulders for this task. With just a few parameters to take care of, the whole stack becomes much easier to govern and administer, while still being completely transparent yet powerful to manage all the types of different resources in the RAC clusterware environment, especially when the number of the nodes go beyond two digits.
The built-in pools, Free and Generic
In 11.2, with the installation of the cluster, two pools get created by default-Free & Generic.
Generic Pool
When you upgrade your existing version of the clusterware to 11.2, all the nodes get mapped to the in-built Generic pool. This is an internally managed server pool and the modification of the attributes of this pool is not allowed. Besides the addition of the nodes of the previous cluster, in 11.2, when you create a database which is Admin-managed, that also becomes a part of the Generic Pool as a child pool of it.
Free Pool
This is another pool which gets created by default with the installation of the 11.2 clusterware. If it’s going to be a fresh installation of the clusterware environment, all the nodes would be attached to this pool first of all. From this pool only, the nodes would move to the manually created server pools. As like the Generic pool, this is also an internally managed pool but still some attributes are available to be modified by the dba like IMPORTANCE.
Child Pools
Server pools can have the child pools under them as well. The child pools are going to have their own properties. The order in which the host allocated to them is going to be based on the IMPORTANCE parameter assigned to them. To understand the child pools, we can imagine a parent pool named as OLTP which represents the working of OLTP database. This parent pool now can have two further child pools, HR (human resource) and AP (account payable) . Now, we can have different attributes set up for the child pools depending on the importance that we want to give to each domain of the work. The hosts assigned are mutually exclusive within the parent pools. For the child pools, whether the same is possible for the child pools or not, would be based on the fact that what’s the value of the attribute EXCLUSIVE_POOL for them. If there is a string value assigned to this parameter and this is shared by two child pools, host assigned to one child pool can’t be shared by its other sibling.
How the hosts are added to the server pools
The allocation of the hosts is going to be happening in the following order:
Generic Pool
Explicitly created pool
Free Pool
Oracle would keep on adding the hosts to the server pools as long as they have not been equal to the values of the MIN_SIZE and MAX_SIZE on the basis of the IMPORTANCE that’s assigned to the server pools. The hosts are going to be added exclusively to the pools i.e. the hosts added to one server pool won’t be shared with the other pools. The hosts can be shared by the child pools provided that there is no value set for the parameter EXCLUSIVE_POOLS which would restrict the host sharing within the child pools as well.
Database management changes in 11.2 -to use server pools
To incorporate the usage of server pools, there is a change introduced in the database itself. From 11.2 onwards, there would be two types of databases available, Admin Managed and Policy Managed. Choosing either one would make you use the server pools though it would vary whether those server pools would be explicitly created by you or would be the default one available already.
Admin managed database
This is sort of the same as the traditional database type i.e. where a DBA is responsible to manage the allocation of the resources and instances explicitly on the available instances, and also the instances on the respective nodes. This database type would assign the instances to a child pool of the default pool available Generic pool. Having the Generic pool as the parent, no modification of the child pools of the Admin managed database’s instances would be allowed for the DBA to be done by their self. Depending on the number of nodes being chosen initially for the database, the instances would be started on each one of them. By default, with a fresh installation of 11.2 RAC, all the nodes would get added to the Generic pool and in the upgrade, all the nodes of the previous version would also be added to the Generic pool. Although this type seems to be much simpler and like the older versions and techniques of managing the instances, this can’t be used when the number of nodes pass a number which is difficult to manage by a DBA, for example 100. In that case, the next type of the 11.2 database would be helpful-Policy Managed database.
Policy Managed Database
This type of database administration is meant to make DBAs’ life simpler by not letting them worry about managing each of their instances on each node individually, but to use a server pool to manage the instances. By using server pools, the administrative tasks to manage the database becomes much simpler.
-----------------------------------------------------------------------------------------------------------
Related links:
11G R2 RAC PROBLEMS AND SOLUTIONS
CLONE DATABASE HOME IN 11GR2 RAC
NIC BONDING IN 11G R2 RAC
PREREQUISITE TO CONFIGURE GNS AND GPNP IN 11G R2 RAC
SERVICES CONFUSIONS CLEARED
SETUP 10G RAC ON YOUR LAPTOP
SETUP AND PLAY WITH 11G R2 RAC AT YOUR HOME PC
11g R2 RAC - ADD INSTANCE MANUALLY
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%20-%20ADD%
11g R2 RAC - LOCAL ARCHIVE WITH NFS
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%20-%20LOCAL%20ARCHIVE%20WITH%20NFS
11g R2 RAC : CACHE FUSION DEMONSTRATED
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%20%3A%20CACHE%20FUSION%20DEMONSTRATED
11gR2 RAC : USE RCONFIG TO CONVERT NON RAC DATABASE TO RAC DATABASE
http://koenigocm.blogspot.in/search/label/11gR2%20RAC%20%3A%20USE%20RCONFIG%20TO%20CONVERT%20NON%20RAC%20DATABASE%20TO%20%20RAC%20DATABASE
11g R2 RAC : RECOVER VOTING DISK - A SCENARIO
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%20%3A%20RECOVER%20VOTING%20DISK%20-%20A%20SCENARIO
11g R2 RAC : TRACING SERVICES IN A RAC DATABASE
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%20%3A%20TRACING%20SERVICES%20%20IN%20A%20RAC%20DATABASE
11g R2 RAC - LOCAL ARCHIVE WITH NFS
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%20-%20LOCAL%20ARCHIVE%20WITH%20NFS
11g R2 RAC : CACHE FUSION DEMONSTRATED
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%20%3A%20CACHE%20FUSION%20DEMONSTRATED
11G R2 RAC : DYNAMIC REMASTERING DEMONSTRATED
11gR2 RAC : USE RCONFIG TO CONVERT NON RAC DATABASE TO RAC DATABASE
http://koenigocm.blogspot.in/search/label/11gR2%20RAC%20%3A%20USE%20RCONFIG%20TO%20CONVERT%20NON%20RAC%20DATABASE%20TO%20%20RAC%20DATABASE
11g R2 RAC : RECOVER VOTING DISK - A SCENARIO
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%20%3A%20RECOVER%20VOTING%20DISK%20-%20A%20SCENARIO
11g R2 RAC : TRACING SERVICES IN A RAC DATABASE
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%20%3A%20TRACING%20SERVICES%20%20IN%20A%20RAC%20DATABASE
11G R2 RAC: INSTANCE RECOVERY
http://koenigocm.blogspot.in/search/label/11G%20R2%20RAC%3A%20INSTANCE%20RECOVERY
11g R2 RAC: MANAGING THIRD PARTY APPLICATIONS USING APPLICATION VIP
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%3A%20MANAGING%20THIRD%20PARTY%20APPLICATIONS%20USING%20APPLICATION%20VIP
http://koenigocm.blogspot.in/search/label/11G%20R2%20RAC%3A%20INSTANCE%20RECOVERY
11g R2 RAC: MANAGING THIRD PARTY APPLICATIONS USING APPLICATION VIP
http://koenigocm.blogspot.in/search/label/11g%20R2%20RAC%3A%20MANAGING%20THIRD%20PARTY%20APPLICATIONS%20USING%20APPLICATION%20VIP
