Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: lsnrctl can start listener, crs_start cannot

Re: lsnrctl can start listener, crs_start cannot

From: <>
Date: Thu, 07 Jun 2007 13:59:49 -0000
Message-ID: <>

On Jun 7, 6:59 am, herta <> wrote:
> I'm in the process of setting up a two-node Oracle RAC
> cluster on SLES 10. I ran a clusterware installation and two database
> software installations (db_1 to be used for the databases, and db_2 to
> be used for asm). The database software installations were run with
> the "install database software only" option.
> Prior to setting up asm, I ran netca to define the listeners, but
> netca gives me pop-up warnings:
> Problem in configuration: ol01: LISTENER_OL01
> Listener start failed. Listener may already be running.
> CRS-0215: Could not start resource 'ora.ol01.LISTENER_OL01.lsnr'.
> Problem in configuration: ol02: LISTENER_OL02
> Listener start failed. Listener may already be running.
> CRS-0215: Could not start resource 'ora.ol02.LISTENER_OL02.lsnr'.
> I verified that the listeners are not running on either node.
> 'oerr CRS 215' returns
> 215, 0, "Could not start resource '%s'."
> // *Cause: There was an internal error while starting the resource.
> // *Action: Check the CRS daemon log file.
> but the daemon log is not exactly helpful:
> 2007-06-07 12:01:24.134: [ CRSRES][1411561792]0Attempting to start
> `ora.ol01.LI
> STENER_OL01.lsnr` on member `ol01`
> 2007-06-07 12:01:24.623: [ CRSAPP][1411561792]0StartResource error
> for ora.ol01
> .LISTENER_OL01.lsnr error code = 1
> 2007-06-07 12:01:24.928: [ CRSRES][1411561792]0Start of
> `ora.ol01.LISTENER_OL01
> .lsnr` on member `ol01` failed.
> I tried to start the listeners using 'crs_start
> ora.ol01.LISTENER_OL01.lsnr -c ol01'
> but that again fails with
> Attempting to start `ora.ol01.LISTENER_OL01.lsnr` on member `ol01`
> Start of `ora.ol01.LISTENER_OL01.lsnr` on member `ol01` failed.
> CRS-0215: Could not start resource 'ora.ol01.LISTENER_OL01.lsnr'.
> Starting them with lsnrctl works fine, but crs_stat still sees them as
> offline:
> NAME=ora.ol01.LISTENER_OL01.lsnr
> TYPE=application
> I removed the listeners (crs_unregister), and tried defining them
> during the asm setup using dbca. Same result.
> I found thread
> which discusses a similar error (similar in that the STATE there is
> UNKNOWN), and but none of the suggestions seem to work.
> I ran cluvfy, which only fails on 'Checking system requirements', with
> a ' No checks registered for this product', but that is 'normal' for
> SLES10.
> crs_stat only shows the listeners to be OFFLINE. Everything else is
> I re-installed the cluster software dropping the domain names from the
> hostnames, but thta didn't help either.
> Initially, the vip-addresses were only defined in /etc/hosts, so I had
> them added to dns (and verified both the lookup and reverse lookup).
> Still no luck.
> Does anyone have any idea what else I could check?
> I'll probably open an SR with Oracle later today, but given that they
> only just started working on a severity 2 call I opened on May 22nd, I
> was hoping to get this resolved a bit quicker with your help.
> Kind regards,
> Herta

The SQL*Net process controls RAC instance access. Access to any Oracle instance can be through either a dedicated server connection or through a shared server connection. If access is through a shared server connection, then the instance is set up for multi-threaded server (MTS). If the connection is a dedicated server, then either the user process required a dedicated connection or the instance is not using MTS.

The configuration of SQL*Net for RAC can be quite simple. Essentially only two files need to be configured for basic access, the SQL*Net listener control file, listener.ora, and the instance names file, tnsnames.ora. In a basic configuration, each server has a listener.ora and a tnsnames.ora file, and each client has a tnsnames.ora file. A third file, sqlnet.ora, is also present on both server and client, but usually no configuration changes are needed to the basic file. Received on Thu Jun 07 2007 - 08:59:49 CDT

Original text of this message