Oracle RAC Administration - Part 14: Services Architecture in Workload Management
February 1, 2007
There is a lot of hype on Virtualization. It is a $20 Billion market and although heavy transaction intensive applications and Oracle RAC may not find its place in your Virtual Infrastructure today, someday they surely will. Disk Virtualization, Network Virtualization, not only address the increasingly crucial issues of cost but also taking a harder look at manageability. Oracle RAC and Oracle installations have always been big deals. If you do a search on Oracles site, youll find installation documents all over the place.
Performance is where the meat is. Even in the virtualization arena, there are some developments. There is a committee (A Non Profit Organization) called SPEC that is working on a model for benchmarks. VMware will be introducing its VMmark soon. Someday we will have a globally deployable Oracle RAC on a Virtual Infrastructure, like the screenshot on my blogpost!
In this article, we will focus on the workload management. We will start our discussion and I hope to have my 4-node RAC ready on the Enterprise Linux provided by Oracle on VMwares ESX 3.0.1 server (latest version) with enough memory and 4 vCPUs!
Introduction to Workload Management
Workload management helps us manage and distribute our workload to provide us with peak performance and high availability. So what all do we have in the Workload management?
Let's take a look at the above mentioned components.
Although the Services is the core of the Service Architecture of RAC, and can be an extended topic, lets just briefly see what it is about and we will see what we can do in the upcoming example articles on more practical aspects of services.
Now when a user connects to a database, it is preferable to connect to the service layer by mentioning the service in the connection string. As I mentioned above, we can create more services to address and logically differentiate the needs of the clients and applications without mingling into the nodes. Let's see various service level deployments.
1. Using Oracle Services
2. Default Service Connections
3. Connection Load Balancing
Oracle Services: This is a perfect way to manage applications or a subset of applications. Simply, OLTP users, DWH/Batch Operations can have their own services assigned to themselves. Service level requirements should be the same for users /applications assigned to a service. When defining a service, you have the opportunity to define which nodes will support that service. They become preferred instances while the ones that will provide failover support are known as available instances.
When you specify
Also, note that Resource profiles are automatically created when you define a service. A resource profile takes care of the manageability of the service and defines service dependencies for the instance and database. Stopping a service would mean stopping the database and the instances associated with the service, so use caution when you attempt to bring down the services.
Services are integrated with Resource Manager thus enabling us to restrict the resources that are being used by a service. Consumer groups are mapped to the services so users connecting are members of the specific consumer group. AWR (Automatic Workload Repository) helps us monitor the performance per service.
ONS (Oracle Net Services) provides connection load
balancing. This can be simply done by setting the CLB goal in the listener,
In future articles we will continue what we've started here and try to stay on course, describing the services deployment scenarios.