Stefan Roesch

Subscribe to Stefan Roesch feed
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: 8 hours 25 min ago

All good things come to an end

Fri, 2006-09-22 22:33
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

Sat, 2005-12-17 16:10
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

Tue, 2005-12-13 23:04
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

Fri, 2005-11-18 01:12
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

Fri, 2005-11-18 00:51
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

Thu, 2005-11-17 23:39
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

Fri, 2004-12-24 18:36
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

Fri, 2004-12-24 18:24
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

Wed, 2004-12-22 11:36
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

Tue, 2004-12-21 20:59
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

Fri, 2004-12-17 21:56
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

Fri, 2004-12-17 17:23
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

Thu, 2004-12-16 21:35
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

Sun, 2004-12-05 16:27
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