RAC One Node changes in 11.2.0.2

I have covered Oracle RAC One Node in one of my previous post. RAC One Node is a single instance of an Oracle RAC database running on node in a cluster. There have been significant changes in the way a RAC One database is administered in version 11.2.0.2 compared to earlier versions. I have briefly summarized the changes herein –

• OUI has a new option to select RAC One Installation (look at the screenshot below)

• You can now create and configure RAC One database using DBCA
• Configure and administer RAC One database using SRVCTL instead of using  "Omotion", "raconestatus", "raconeinit", "racone2rac" etc.
• So move/relocate and convert your database using  SRVCTL
• Dataguard Broker is RAC One aware

I thought to quickly cover the changes since I had previously posted about RAC One. You can also refer to Metalink note 1232802.1 for details.

Instance Caging

Many of you would already be aware of this one while I discover it now but still putting down my thoughts on this 11g new feature.

Most of the times, we end up running multiple instances on a single box for developmental effort. Or even on Production by buying a reasonably big box to save on licensing cost and also in the name of consolidation exercise :). But doing so, throws up the challenge for a DBA in terms of allocating resources to each instance. Some low priority activity on an instance eating up CPU resources and thus depriving the much needed resource to those requiring it. CPU allocation decisions such as this are made solely by the operating system; the user generally has no control over them.

Instance caging in 11gR2 is a method to cage or bound the instance to use a certain no of CPU’s instead hogging all the available CPU’s. All we have to do is set an initialization parameter to control the CPU resources an instance can use. It basically limits the no of CPU’s an instance can use e.g. I can set this parameter to “1” on a 4 CPU machine. It’s very simple (silly :)) to set it –

ALTER SYSTEM SET CPU_COUNT = 4; 

However, it works with resource manager feature so you will need to enable RM and create a resource plan first before running the above command.

Instance caging can be useful on larger box with multiple instances running – some development and a few production allowing CPU and resource allocation be done effectively. Apart from this, it can also be said that it’s Oracle’s way (alternate option) of giving CPU resource allocation control to a DBA rather than leveraging a logical/physical partitioning of a large box resorting to usage of tools/technologies such as VMware, AIX LPAR or Sun containers etc. In a nut shell, it’s the simple way to control the CPU consumption of each database instance.

Maybe sometime later, I will try to post an example. Thanks for reading and appreciate your comments / thoughts.

Edition based redefinition

Oracle 11g brought in a new feature called Edition based redefinition (EBS) basically aimed at reducing the planned downtime during application releases/upgrades etc. In this changing and dynamic world, application also undergoes numerous enhancements; it’s in these situations that one cannot afford to take a downtime and looks for options to minimize or eliminate them. While the application code and the software provide some options, the Oracle database engine had no such option.  

Till recently, Oracle database had only few options – such as online index rebuild and table redefinition to address planned downtime [Also has Workspace manager; Thanks for pointing out Gary Myers]. However, we all know Oracle’s capability to address unplanned downtimes with features such as – Real Applications Cluster (RAC), Physical / logical standby database, Streams etc.

With 11gR2, Oracle claims to have addressed the gap with edition based redefinition.  Oracle now supports multiple versions (editions) of a given object. So now, the objects are called as “editioned object” or “non-editioned objects” based on whether an object can have multiple versions or not. While one version of the object is used by the live application, the other version can be used to carry out changes and tested before making it permanent. However, the editionable feature is available for the following database objects ->

• Synonym
• View
• Procedure
• Function
• Package and Package Body pe
• Trigger
• Type and Type Body
• Library

The all-important and most used object – table and indexes are missing from the above list. So if you look at the list, you will feel that the versioning of code is now extended to database engine. Only view (though that’s also a piece of SQL code) and synonyms have been added. However, one can work around table by creating views and making them editionable but again only simple views without the use of functions etc. can be editioned. As a change, the developer needs to make his/her code work against editionable objects.

The other important thing is data within the table can’t be versioned; a lot of changes happen to be DML in nature so this is another important thing missing though there are workaround.

So, in my opinion this feature is useful in the following scenario =>

• If you make changes to procedures, function etc.
• Changes are done to physical structure of tables rather than data

Otherwise I feel this is not as useful yet. Also it’s a relatively a new feature and yet to mature. I'm sure future releases of Oracle will bring in some enhancements.