Stefan Roesch
![Subscribe to Stefan Roesch feed](http://www.orafaq.com/misc/feed.png)
Oracle RAC is the clustering solution for
databases from Oracle. This site describes
my travel to the center of the cluster and
the mysteries discovered and solved.stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.comBlogger14125
Updated: 9 hours 36 min ago
All good things come to an end
After a more than seven great years at Oracle Corporation I have decided to resign and pursue new opportunities. In July I started to work for Microsoft Corporation.stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com0
Disabling CPUs on Linux- Part Two
If the server is supporting Hyperthreading, Linux implements the following mechanism: First all the physical CPU's are enabled and then then the logical CPU's are enabledThis means that all the possible combinations can be enabled by specifying the maxcpu parameter in the boot command mentioned in the earlier post. For instance if the server has more than one physical CPU it is not possible to stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com2
Granularity of CPU statistics in V$SERVICE_STATS
After making several tests it turns out that the "DB CPU" statistics in the view V$SERVICE_STATS only has a granularity of centiseconds despite what the documentation says.stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com1
Disabling CPUs on Linux - Part One
For running performance tests and to determine the potential benefit of additional CPUs it can be very helpful to be able to disable CPUs. CPU's can be disabled by adding the following clause to the kernel configuration line in the grub.conf configuration line:maxcpus=The placeholder NUM_CPUS has to be replaced with the number of CPUs that will be enabled. After re-booting with the stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com1
Disabling Hyper-Threading
The use of Hyper-Threading for server applications is questionable, especially if the number of I/O requests is high. To determine the cost or the potential performance improvements it makes sense to disable the Hyper-threading (from known on abbreviated with HT) support. The are two ways to disable HT:Disable Hyper-Threading in the kernelDisable Hyper-threading by the BIOSIntel recommends to stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com0
Upgrade to RedHat AS 4.0
Upgrading to RedHat 4.0 introduces some new challenges. With the switch to the 2.6 linux kernel the udev device filesystem was introduced. By default the udev device tree does not support raw devices anymore. Luckily it is still supported with the Redhat distribution. It can be configured in the old way with the rawdevices service configuration.To check if it is currently enabled run the stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com0
Determining the IP address of the cluster interconnect in 9i
In Oracle database version 9i there is no way to determine the IP address through a database view. The only way to determine this IP address is with the oradebug command (Please keep in mind oradebug is not a supported product from Oracle, so if there are problems/crashes you are on your own). The oradebug ipc command creates a trace file. The example shows the process: SQL> oradebug setmypid
stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com0
How to determine SQL statements that cause hard parses
From a tuning point of view hard parses can be quite limiting to the scalability of database and an application. If the number of hard parses is high this is a serious problem. To tackle the problem the first step is to determine which SQL statements are causing hard parses. With the column FIRST_LOAD_TIME of the view V$SQL this can be determined. The following example shows how this knowledge stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com0
Deleting the wrong cluster interconnect information from the OCR
The current configuration of the cluster interconnect information can be checked with the oifcfg command. The following example shows this:$ oifcfg getif eth0 142.2.166.0 global public ib0 192.169.1.0 global cluster_interconnectLet's assume that the address for the cluster interconnect was specified incorrectly. This will prevent cluster communication. The situation can be resolved by stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com2
Determining what IP address was configured in the OCR
In 10gR1 the IP address for the cluster interconnect is determined by default from the OCR (Oracle Cluster Repository). The configured address can be determined with the following command:
# oifcfg getif
eth1 140.87.81.0 global cluster_interconnectIf the database parameter cluster_interconnects is specified, the value that is obtained from OCR is not used.stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com0
Determining what IP address was picked for the cluster interconnect
In the past it was difficult for a user or DBA to determine which cluster interconnect was picked. It was possible to obtain that information with an oradebug comnmand. With Oracle Version 10gR1 this information is available with the X$ table X$KSXPIA.
The following SQL shows which information is returned by querying that view.
SQL> SELECT * FROM x$ksxpia;
ADDR INDX INST_ID P stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com0
OOW on Thursday
Thursday was my second day at OOW 2004. Yesterday, we presented our first session, everyhting went fine. Today we are presenting to more sessions: "Project MegaGrid: Performance Management in Large Clusters" and "MegaGrid: Capacity Planning for Large Commodity Clusters". Both of the presentations were a success. If you plan on migrating from a single instance to a grid/cluster environment stefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com0
OOW 2004 on Wednesday
Monday and Tuesday I haven't attended the OOW, so Wednesday was my first day. Altogether we were presenting 3 sessions. On Wednesday afternoon it was out first session "Project MegaGrid: Deploying large clusters".
Abstract:
The successful deployment of an enterprise grid computing environment requires careful and thorough planning in order to build a flexible, easily scalable architecture. Thisstefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com0
OOW 2004
Oracle OpenWorld 2004 ıs just around the corner. I had the
pleasure to go to SF on Sunday afternoon to setup the MegaGrid
demo. I arrived together with a collegue and received my speakers
pass. But as we learned with the the Speaker pass we are not
allowed to enter the demo ground. We went back to registration and
obtained additionally the demogrounds pass.
We were lucky everyhting went fine andstefan roeschhttp://www.blogger.com/profile/15182787826739074738noreply@blogger.com0