Brief Intro
Since my last article, quite a few developments have taken
place. Oracle has not only continued its onslaught on Red Hat but also opened up
its own version of Enterprise Linux for download. Larry Ellison did mention in
one of his older interviews that buying Red Hat would not add much value to
their stack, but at the same time, he missed that essential part of his “Oracle
Stack”, the OS! So here you go, you have your own Enterprise Linux! I have also
started building my own Oracle
Linux RAC.
Actually, in a way, it might just be a bit better. I just have to look at one supplier, since the
service/application stack (like RAC and other Oracle services) are crucial to
me, and other OS related issues can also be taken care of by the same supplier (i.e.
Oracle). It certainly means that the Oracle
support staff would need to be more effective. Sure, the OS is very important
but very soon an OS will be just a layer; it might even be irrelevant if you
listened to Diane Greene in VMworld 2006!
You as the RAC DBA
In previous articles, we have gone through some advanced material
in RAC administration (which we will certainly continue) because I want to keep
you people glued to the exciting world of RAC. However, from time to time we
must step back and review some of the RAC basics. In this article, we will do Just
that.
What is an spfile?
Pretty simple, it is the file that your instance reads from
when starting up. To check the parameters check the following:
SQL> show parameter spfile
Viewing of the SPFILE can be done with several commands,
such as CAT/MORE (in Linux) or your good old notepad in Windows. Since it is a
binary file, (you must have found out when you tried to open it), you have to
submit an ALTER SYSTEM SET command. This is for safety and can be irritating,
as you cannot edit it like your plain old pfile. In your RAC environment, all
instances must share the same spfile (as seen in the step where we choose the OCFS’ed
mount point).
Modifying the parameters:
In your RAC, the SID option is the important part of
changing the parameters. There, you must do something like this:
ALTER SYSTEM SET db_cache_size = 1024m scope=spfile sid=’nick01’;
This would show up in your “show parameter” command as:
nick01.db_cache_size=1024
nick02.db_cache_size=500
*.job_queue_processes=4
As you observe, the *. applies to all nodes in the RAC
cluster, so those parameters prevail universally across the RAC environment.
More RAC specific parameters:
Let’s check out a few more parameters that are present in
our RAC environment (there are, however, a lot more which we will get in touch
with in future articles):
CLUSTER_INTERCONNECTS
Many things happen in the RAC environment. You might want to
install an NIC card to your environment and replace the current IPC settings to
use this card. A typical example is: replacing a 1G IPC traffic related card
with a 10G card. Whatever the reason, things happen in your RAC environment and
you will need to address the cluster interconnection aspects should these
changes have a direct impact on your RAC settings. Then you might want to do
this on each node:
ALTER SYSTEM SET CLUSTER_INTERCONNECTS = ‘10.0.0.25’ scope=spfile sid=’nick01′;
ALTER SYSTEM SET CLUSTER_INTERCONNECTS = ‘10.0.0.26’ scope=spfile sid=’nick02′;
Alternatively, you can be sitting on a third node like on
our ‘brian01’, which is our third node, and carry these operations out like
this:
ALTER SYSTEM SET CLUSTER_INTERCONNECTS = ‘10.0.0.25:172.22.202.25′ scope=spfile sid=’nick01’;
ALTER SYSTEM SET CLUSTER_INTERCONNECTS = ‘10.0.0.26:172.22.202.26′ scope=spfile sid=’nick02’;
Obviously, if I were you (or if you were a diligent DBA), I
would quickly check the alert log to see if the changes were effective. You should
also have an option to generate a trace file using the ORADEBUG utility (we
will also talk about it sometime later):
SQL> oradebug setmypid
And then:
SQL> oradebug ipc
Now this trace file is written in the udump directory (I
would arrange the files in the list with the last modified file on top). Open
the file with gedit, vi or notepad to see the socket information, ip and udp
etc.
Note: You can also edit the NIC information with the oifcfg
command. We will check that out in our next article.
CLUSTER_DATABASE
This option needs to be set to ‘TRUE’ for obvious reasons in
RAC operation, BUT there are exceptions when you have to patch. Say you have to
shutdown all the nodes except one, then you set the parameter for this node to
‘FALSE’ and carry on with the operations of patching/upgrading the instance.
ACTIVE_INSTANCE_COUNT
This is used in a 2-node RAC. It enables you to assign one instance in a
two-instance RAC cluster as the primary instance and the other instance
as the secondary instance. So obviously, it has no use in a RAC that
consists of more than two nodes.
It is pretty simple. You do:
ALTER SYSTEM SET ACTIVE_INSTANCE_COUNT= 1
The first starting node becomes the primary node and the
other one is the secondary node. This means that the primary node goes ahead
and accepts client connections and should that fail then the secondary node
takes over the failed connections from the first node, thus making the
secondary node the primary node. Should the failed primary node come back
online then it starts operating as the secondary node and will not accept client
connections unless the (current) primary node has failed.
Conclusion
In the next article,
we will continue our RAC DBA essentials, covering more of these processes and
the oifcfg utility as well. We will also talk a bit about the test/development
and staging environment and how you can use the (now currently in beta), VMware’s
converter utility to simple ‘push click’ your production environment into a
fully functional virtualized RAC environment. This is an easy and even smart
thing to offer to your boss. It saves money and your DBAs stay abreast of all
the wicked stuff that happens on the net and allows them to contain it on a virtualization stack before it hits production.
