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.
Make sure that you’ve installed the latest required patches.
This should be common sense by now: one of the most important security practices is to make sure that the latest patches are applied to your system. Especially if you’re doing a new installation, there’s no excuse for not making sure that the system is up-to-date. There are three steps to getting the right patches: (1) install the latest patchset available for your platform, for example at the moment on Linux this is 10.2.0.3; (2) install the latest CPU (Critical Patch Update) listed at http://www.oracle.com/technology/deploy/security/alerts.htm; and (3) install any additional required one-off patches; for 10.2 you can check metalink note 316900.1 for the latest information and they usually do a good job of keeping this list down to the bare essentials.
Configure the listener from the ASM home if and only if there is more than one DB home on the machine.
If you are using ASM with Oracle 10g then it is a best practice to install two copies of the Oracle DB software; one for ASM and one for the database itself. Although it is not recommended, it’s possible to have multiple versions of Oracle running on the server. If there is more than one database home (not including ASM) then you should run the listener from ASM since the listener is treated as a node-level (not database-level) resource by the clusterware. For example, if you have a 10.1 database and a 10.2 database on the same server then your ASM home must be 10.1 and the listener should run from there. If there will only be one database home then it makes sense to go ahead and run the listener from there since you probably want listener-related patches to go into the database home rather than the ASM home.
Explicitly configure the listener before creating any ASM instances or databases.
Whether you manually create the LISTENER.ORA file or use NETCA, you should explicitly configure the listener rather than relying on DBCA to do it for you. DBCA will choose default settings from whatever home it happens to run from. For example, one good security recommendation is to run the listener on a non-default port – and DBCA will not configure this.
Configure the listener to only listen on the VIP address.
By default the listener will listen on all public IP addresses. However in a RAC system only VIP addresses should be used to access databases. The public non-VIP address can be used for system administration, but never by oracle clients. You should configure the listener to only attach to the VIP addresses since clients should only connect to that IP. If you used NETCA to configure the listener, then you will need to manually edit the LISTENER.ORA file to make this change. Comment out the line with the public IP address.
[oracle@iss-365-rac01 ~]$ cd $ORACLE_HOME/network/admin [oracle@iss-365-rac01 admin]$ head listener.ora # listener.ora.iss-365-rac01 Network Configuration File: /u01/app/oracle/product/10.2.0/db/network/admin/listener.ora.iss-365-rac01 # Generated by Oracle configuration tools. LISTENER_ISS-365-RAC01 = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1)) (ADDRESS = (PROTOCOL = TCP)(HOST = iss-365-rac01-vip)(PORT = 1521)(IP = FIRST)) # (ADDRESS = (PROTOCOL = TCP)(HOST = iss-365-rac01)(PORT = 1521)(IP = FIRST)) )
By the way, the clusterware in 10.2 contains a default dependancy between the VIP and the listener; it will always make sure that the VIP is available before starting the listener.
[root@iss-365-rac01 ~]# crs_stat -p ora.iss-365-rac01.LISTENER_ISS-365-RAC01.lsnr|grep REQ REQUIRED_RESOURCES=ora.iss-365-rac01.vip
Secure the listener.
At a minimum you should (1) set a listener password, (2) set ADMIN_RESTRICTIONS, and (3) secure the TNS_ADMIN directory. Integrigy has released an excellent whitepaper on Listener security and all of their recommendations are still valid on version 10.2 of Oracle.
Following these basic guidelines can save you a headache or two down the road. They will keep the right people connecting properly and keep the wrong people from connecting at all.
Superb Article. But it does not elaborate on why RAC often fails every two months
Good tips …
Can you please inform me about the significance of this crs_stat -p command…
I’ve found, thru an SR with support, that a default listener “listener_” is hardcoded into crs. I discovered this b/c I created that listener with netca, and then removed it and created a different one. Then kept getting errors in srvctl whenever start/stop/status the nodapps, complaining about listener resource.
Support is still working it.
Seems crs/srvctl/netca are not flexible enough to detail with non-default, multiple listeners per node.
Good tips. But it does not mention about usage of different listeners for different applications on different ports other than default port(1521)
“For example, if you have a 10.1 database and a 10.2 database on the same server then your ASM home must be 10.1 and the listener should run from there.”
<– I think this is not valid, your ASM & CRS home must be higher than your RDBMS homes.. so the ASM home must be 10.2 and I think you’ll also have issues on Enterprise Manager if you run the LISTENER on ASM home..
Yikes, you’re right Karl. ASM is forward and backwards compatible with databases and probably ought to be the newer version to support the latest features. This blog post is outdated (and just plain wrong in a few places)… it really needs an overhaul.