Oracle Default Listener

042 第23题 关于动态注册监听器

23.Your database is started with SPFILE. You want the database instance to be dynamically
registered with a listener L2 with the following details:
Protocol: TCP
Host: indl151e
Port: 1525
Which is the correct order of the steps that you would follow to achieve this?
1. Set the LOCAL_LISTENER parameter to L2 dynamically.
2. Make an entry for L2 in tnsnames.ora on the database server.
3. Restart L2.
4. Modify the listener.ora file to add the instance name in SID_LIST of L2.
A: 1, 2, 4, 3
B: 1, 2, 3; 4 is not required.
C: 2, 1; 3 and 4 are not required.
D: 1, 2; 3 and 4 are not required.

Oracle Default Listener

Submitted by Nidhi Jain on Sat, 2003-02-01 08:52.

• RDBMS Server

by Nidhi Jain

Prior to Oracle 8i, a listener was statically configured (listener.ora) to service a given set of SIDs. From 8i, PMON dynamically registers a database service with the listener.Further, if the listener is running on the default TCP port of 1521, then there is no need to configure a listener.ora at all.

USING A DEFAULT LISTENER

A listener.ora file is not required in order to use the default listener.
The listener is started in the conventional manner:

$lsnrctl start

This listener will listen on two addresses:

   (ADDRESS=(PROTOCOL=ipc)(KEY=PNPKEY))
   (ADDRESS=(PROTOCOL=tcp)(PORT=1521))

 

In order to change parameters to non default values (such as enabling listener tracing), a listener.ora should be created with the relevant parameters specified. The listener then needs to be restarted.

By default, PMON will register the database service with the listener on port 1521.

USING A NON DEFAULT LISTENER

When a non-default listener is used, then a listener.ora must be configured with the relevant listener address. For example,

 

LISTENER =
 (ADDRESS_LIST =
   (ADDRESS = (PROTOCOL=TCP) (HOST=uksn115) (PORT=2500))
 )

 

This would start a listener on port 2500.

In order for PMON to be able to register the database service(s) with this listener, the init.ora parameter LOCAL_LISTENER must be set.

eg, LOCAL_LISTENER=listener_A

PMON will attempt to resolve LOCAL_LISTENER using some naming method. For example, this may be resolved in tnsnames.ora, as follows:

 

listener_A =
  (DESCRIPTION =
    (ADDRESS=(PROTOCOL=TCP)(HOST=uksn155)(PORT=2500))
  )

 

PMON will search for tnsnames.ora in the following order:

• $HOME/.tnsnames.ora
• $TNS_ADMIN/tnsnames.ora
• /var/opt/oracle/tnsnames.ora or /etc/tnsnames.ora (depending on platform)
• $ORACLE_HOME/network/admin/tnsnames.ora

 

If a tnsnames.ora cannot be found or if LOCAL_LISTENER cannot be resolved, the alert.log will show:

 

PMON started with pid=2
Syntax error in listener string

 

If LOCAL_LISTENER can be resolved, but there is a syntax error in the tnsnames.ora specification, the alert log will show:

 

PMON started with pid=2
Syntax error in listener string (DESCRIPTION =)

 

The instance will start regardless of PMON errors during registration, unless MTS is enabled. If MTS enabled, then both of the above error scenarios will give:

 

ORA-00101: invalid specification for system parameter
MTS_DISPATCHERS

 

in addition to the relevant alert log message. The instance will not start.

Note that if 'NAMES.DEFAULT_DOMAIN' is set in sqlnet.ora, then the tnsnames.ora entry should be of the form NAME.DOMAIN. The domain will be appended to LOCAL_LISTENER if not already specified.

eg,

init.ora:           LOCAL_LISTENER=listener_A (or listener_A.uk.oracle.com)
sqlnet.ora:         NAMES.DEFAULT_DOMAIN=uk.oracle.com
tnsnames.ora:       listener_A.uk.oracle.com=(...)

 

The search order for the 'system' sqlnet.ora is:

• $TNS_ADMIN/sqlnet.ora
• $ORACLE_HOME/network/admin/sqlnet.ora

Additionally, the 'local' sqlnet.ora is always read from:

• $HOME/.sqlnet.ora

If this file exists, then any parameters defined here will override the ones in the 'system' sqlnet.ora.

Note, /etc or /var/opt/oracle is not searched for the 'system' sqlnet.ora unless TNS_ADMIN happens to be set to this directory.

WHAT INFO IS REGISTERED?

The easiest way to check the information registered by PMON is to enable level 16 (SUPPORT) listener tracing.

Oracle 8.1.5 Registration

In 8.1.5, the listener trace shows that the 'register' command is actually a CONNECT packet. This is of the form:

 

  (CONNECT_DATA=
   (COMMAND=service_register)
   ...
   (SERVICE=)
   ...
   (INFO=LOCAL SERVER)
   (DISPLAY=DEDICATED SERVER)
   (GLOBAL_NAME=.)
   ...
   (ENVS='')
   ....
 )

 

Oracle 8.1.6 Registration

In 8.1.6, this process has changed slightly. PMON initiates registration by sending the following CONNECT packet

 

  (CONNECT_DATA=
   (COMMAND=service_register_NSGR)
  )

 

The listener responds with an ACKnowledgement. PMON and the listener then exchange DATA packets to complete the registration.

Compatibility

The listener is backwards compatible. Therefore, an 8.1.5 instance can register with a 8.1.6 listener.

However, it is not possible to register an 8.1.6 instance with an 8.1.5 listener. This is due to the 8.1.5 listener not recognising the 'service_register_NSGR' command.

This can be seen from a listener trace:

 

 ...
 (CONNECT_DATA=
   (COMMAND=service_register_NSGR)
 )                                <-- extracted from packet dump
 nscon: got NSPTCN packet         <-- a CONNECT packet is rxed
 ...
 nsglfc: The command was not recognized
 ...
 nscon: sending NSPTRF packet     <-- a REFUSE packet is sent

 

SPECIFYING MULTIPLE LOCAL_LISTENERS

Multiple LOCAL_LISTENERs can be specified in one of two ways in the init.ora:

• local_listener=listener_A, listener_B
• local_listener=listener_A
  local_listener=listener_B
  

In both cases, v$parameter will show: local_listener=listener_A, listener_B

PMON will register ONLY with the listener that appears first in the v$parameter value for local_listener (ie, listener_A in the above).

The correct method is to specify one local_listener in the init.ora, and to specify multiple listener ADDRESSes in the connect descriptor.

For example,

 

init.ora:
   local_listener=all_listeners

tnsnames.ora:
   all_listeners.uk.oracle.com=
    (DESCRIPTION =
      (ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=2500))
      (ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=2600))
    )

 

In non-MTS mode, all listeners must be on the same host as the instance (unless pre-spawned servers are used on the remote host). However, even in dedicated mode and no pre-spawned servers, PMON still registers with listeners on another node. But this does not make any sense, as the remote listener will not be able to fork/exec oracle.

Registration in an MTS Environment

Service registration is more flexible if the instance is running in MTS mode. For example,

• PMON can register services with listeners on more than one node
• the dispatchers can register with a different listener than dedicated services
• different dispatchers can register with different listeners

 

This is illustrated by way of the following examples.

Example 1

init.ora on host1:

  local_listener=all_listeners
   mts_dispatchers="(protocol=tcp)"

 

tnsnames.ora on host1:

    all_listeners.uk.oracle.com=
    (DESCRIPTION =
      (ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=2500))
      (ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=2600))
    )

 

output of 'lsnrctl services':

 

  host1, listener on port 2500:
  -----------------------------
     Services Summary...
       V816         has 2 service handler(s)
         DEDICATED SERVER established:0 refused:0
           LOCAL SERVER
         DISPATCHER established:0 refused:0 current:0 max:1022 state:ready
         D000 
         (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=59155))

 

host1, listener on port 2600:

   Services Summary...
     V816         has 2 service handler(s)
       DEDICATED SERVER established:0 refused:0
         LOCAL SERVER
       DISPATCHER established:0 refused:0 current:0 max:1022 state:ready

         D000 
         (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=59155))

 

In this case, the dispatcher has registered with the listeners specified by the local_listener parameter.

Example 2

init.ora on host1:

 

  mts_dispatchers="(protocol=tcp)(listener=listener_host2.uk.oracle.com)"
   local_listener=listener_host1.uk.oracle.com

 

tnsnames.ora on host1:

   listener_host2.uk.oracle.com=
    (DESCRIPTION =
      (ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=2500))
    )
   listener_host1.uk.oracle.com=
    (DESCRIPTION =
      (ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=2500))
    )

 

output of 'lsnrctl services':

host1:

    Services Summary...
       Nov10         has 1 service handler(s)
         DEDICATED SERVER established:0 refused:0
           LOCAL SERVER

 

host2:

     Services Summary...
       V816         has 1 service handler(s)
         DISPATCHER established:0 refused:0 current:0 max:1022
state:ready
           D000 
           (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=59165))

 

In this case, the dispatcher explicitly registers with a different listener than the one for the dedicated service.

Example 3

init.ora on host1:

   mts_dispatchers="(protocol=tcp)(listener=listenerA.uk.oracle.com)"
   local_listener=all_listeners

 

tnsnames.ora on host1:

   all_listeners.uk.oracle.com=
    (DESCRIPTION =
      (ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=2500))
      (ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=2600))
    )
   listenerA.uk.oracle.com=
    (DESCRIPTION =
      (ADDRESS=(PROTOCOL=TCP)(HOST=host1)(PORT=2600))
    )

 

output of 'lsnrctl services':

host1, listener on port 2500:

     Services Summary...
       V816         has 1 service handler(s)
         DEDICATED SERVER established:0 refused:0
           LOCAL SERVER

 

host1, listener on port 2600:

     Services Summary...
       V816         has 2 service handler(s)
         DEDICATED SERVER established:0 refused:0
           LOCAL SERVER
         DISPATCHER established:0 refused:0 current:0 max:1022 state:ready
           D000 
           (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=59160))

 

This illustrates that the 'listener=' part of mts_dispatchers overrides local_listener when registering dispatchers.

Static Info Overwrite

If a listener.ora is used, and a SID_DESC entry exists for an instance, the data within the SID_DESC section is referred to as 'static information' for that instance.

In 8.1.6, all static information in the listener.ora is overwritten when the instance is dynamically registered with the listener.

Therefore, any environment variables set within the listener.ora will not be visible unless the variable is set in the environment used to start the instance (and thus inherited by PMON).

This behaviour is different from 8.1.5. In 8.1.5, the existance of a SID_DESC section results in the listener NOT registering PMON's (and therefore the instances' environment (note that the instance is still registered).

Therefore, in 8.1.5, any environment variables set in the listener.ora would be retained even after dynamic registration.

If there is no SID_DESC section, then the listener WILL register PMON's environment (ie, behaves as 8.1.6).

---

About the author:

Nidhi Jain is a Senior DBA at Totality.com. He is a certified Oracle and DB2 database administrator.