The listener is a small part of an Oracle RAC configuration – and maybe that’s why it is so often overlooked and setup with only the defaults. More often than not, the listener gets setup automatically by DBCA during the ASM or database configuration. However this is not a good practice at all; at best it leaves security holes and at worst it configures your listener totally wrong.

Getting listener configuration right is actually very simple. Following these five best practices will ensure that you have a secure and optimal listener configuration on your RAC database.
› Read more

I’ve recently installed Oracle RAC on both RedHat 4 and Suse Enterprise 9. The most recent installation reminded me of an issue which has come up more than once: persistance of raw device permissions. If you remember installing Oracle on SLES8, RHEL2 and RHEL3, then you remember that you would just chmod the /dev files and that was it. But with RHEL4 and SLES9 (and all newer releases) everything breaks when you reboot! It doesn’t take long to figure out that the /dev file permissions were reset to their defaults.

The root cause is a change that was introduced several years ago in the 2.6 Linux kernel called udev. Unlike the 2.4 Linux system, where the device nodes in the /dev directory were a static set of files, udev in 2.6 dynamically creates files for the devices that are actually present on a system. It was also designed from the ground up to support persistent device naming. Naturally udev is nothing new to Linux admins; but if you’re not familiar with it and are interested in a good overview then check out Greg Kroah-Hartman’s talk and paper from the 2003 Linux Symposium.

What does this mean to DBAs installing Oracle RAC on Linux? What is the best and most secure way to get the permissions right for Oracle on your system?
› Read more

In Oracle 10g there are two very different ways to configure TAF: with TNSNAMES (since 8.0, automatic generation new in 10g) and with DBMS_SERVICES (entirely new in 10g). They are very different approaches and it appears that the new DBMS_SERVICES method will be preferred moving forward since it has been given precedence and overrides whatever is in the client’s TNSNAMES.

The fundamental difference between these approaches is that the latter (preferred) method is truly centralized and much more manageable in an environment with many clients. The TAF settings are stored in only one place – on the server. There are a few disadvantages to this approach but overall the advantages seem to outweigh them. However before getting to that, 10g has also simplified management for the original TNSNAMES approach.

When TAF was introduced in Oracle 8.0 it was setup through the client’s TNSNAMES file. The syntax changed in 8i but it still went into the same file; and it has not changed much since then. But 10g did add a useful new TAF-related feature to two of its utilities: the ability to auto-generate a TAF TNSNAMES entry. This can not only save you a little time but can also help you avoid simple syntax mistakes.
› Read more