admin
2010-08-20
Issues Affecting Automatic Service Registration
Contents:
1.0 Service registration
1.1 Configuring service registration
1.2 Registering information with the default local listener
1.3 Registering information with a non-default listener
1.4 Registering information with a remote listener
2.0 Known issues with instance registration
2.1 ORA-12514 errors connecting to registered instances
2.2 Listeners intermittently crashing
2.3 Instance fails to register with instance if ANO in use
2.4 SDU and TDU are overwritten by dynamically registered instances
2.5 Dynamically registered instances don't work with prespawned servers
2.6 Environment picked up from registered instance, not the listener
2.7 ORA-00119 Error starting a 9.x instance with LOCAL_LISTENER defined
3.0 How to disable automatic instance registration
1.0 Service registration
------------------------
Prior to Oracle8i (8.1.x), information about database instances had to be
manually configured in the LISTENER.ORA file. From Oracle8i onward, database
instances can register themselves with the Oracle Net Listener upon instance
startup.
Automatic Service Registration reduces the administrative overhead for
multiple databases or instances. Information about the services, to which the
Listener forwards client requests, is registered with the Listener.
Service registration is performed by the PMON process, a background process
of each instance, to register instance-specific information with the local
Listener. PMON sends the current state and load of the instance and Shared
Servers/Dispatchers. The registered information enables the Listener to
forward client connection requests to the appropriate service handler. Service
registration does not require any configuration in the LISTENER.ORA file.
The initialisation parameter SERVICE_NAMES identifies which database service(s)
an instance belongs to. Upon startup, each instance registers with the
Listeners of other instances belonging to the same service. During database
operations, instances of each service pass information about CPU usage and
current connection counts to all of the Listeners of the same services. This
enables dynamic load balancing and connection failover.
For Oracle8i/9i databases, the Listener uses the dynamic service information
about the database/instance it receives through Automatic Service Registration
before using statically configured information in the LISTENER.ORA file.
Dynamic service registration is configured in the database initialization file.
It does not require any configuration in the LISTENER.ORA file. However,
Listener configuration must be synchronized with the information in the
database initialization file.
1.1 Configuring Service Registration
------------------------------------
To ensure that Service Registration works properly, the initialization
parameter file should contain the following parameters:
SERVICE_NAMES for the database service name
INSTANCE_NAME for the instance name
For example:
SERVICE_NAMES=sales.us.acme.com
INSTANCE_NAME=sales
The value of SERVICE_NAMES parameter defaults to the global database name,
a name comprising the DB_NAME and DB_DOMAIN parameters in the initialization
parameter file, entered during installation or database creation. The value
of INSTANCE_NAME parameter defaults to the SID, entered during installation
or database creation.
1.2 Registering information with the default local listener
-----------------------------------------------------------
By default, the PMON process registers service information with its local
Listener on the default local address of TCP/IP port 1521. As long as the
Listener configuration is synchronized with the database configuration, PMON
can register service information with a non-default local Listener or a remote
Listener on another node. Synchronization is simply a matter of specifying the
protocol address of the Listener in the LISTENER.ORA file and the location of
the Listener in the initialization parameter file.
1.3 Registering information with a non-default listener
-------------------------------------------------------
If you want PMON to register with a local listener that does not use TCP/IP
port 1521, configure the LOCAL_LISTENER parameter in the initialization
parameter file to locate the local listener.
For a Shared Server (aka MTS) environment, you can alternatively use the
LISTENER attribute of the DISPATCHERS or MTS_DISPATCHERS parameter in the
initialization parameter file to register Dispatchers with a non-default local
Listener.
Because both the LOCAL_LISTENER parameter and the LISTENER attribute enable
PMON to register Dispatcher information with the Listener, it is not necessary
to specify both the parameter and the attribute if the Listener values are the
same.
Set the LOCAL_LISTENER parameter as follows:
LOCAL_LISTENER=<listener_alias>
Set the LISTENER attribute in Oracle8i as follows:
MTS_DISPATCHERS="(PROTOCOL=tcp)(LISTENER=<listener_alias>)"
Set the LISTENER attribute in Oracle9i as follows:
DISPATCHERS="(PROTOCOL=tcp)(LISTENER=<listener_alias>)"
The <listener_alias> is resolved to the listening end-point through a naming
method, such as a TNSNAMES.ORA file on the database server.
For example, if the Listener is configured to listen on port 1421 rather than
1521, define the LOCAL_LISTENER parameter in the initialization parameter file
as follows:
LOCAL_LISTENER=listener1
Using the same Listener example, define the LISTENER attribute as follows:
DISPATCHERS="(PROTOCOL=tcp)(LISTENER=listener1)"
Listener1 must be resolvable on the server so it would need to be defined in
the TNSNAMES.ORA file as follows:
listener1=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1421))
)
You can also dynamically update the LOCAL_LISTENER parameter using the SQL
statement ALTER SYSTEM SET:
SQL> ALTER SYSTEM SET LOCAL_LISTENER='<listener_alias>' SID='<db_sid>';
If you set the parameter to null, the default local address of TCP/IP port
1521 is assumed.
SQL> ALTER SYSTEM SET LOCAL_LISTENER='';
The LISTENER attribute overrides the LOCAL_LISTENER parameter. As a result,
the SQL statement 'ALTER SYSTEM SET LOCAL_LISTENER ...' does not affect the
setting of the LISTENER attribute.
1.4 Registering information with a remote listener
--------------------------------------------------
Registration to remote listeners, such as in the case of Oracle9i Real
Application Clusters (RAC), can be configured for Shared Server or Dedicated
Server environments.
If you want PMON to register with a remote Listener, configure the
REMOTE_LISTENER parameter in the initialization parameter file to locate the
remote listener.
For a Shared Server environment, you can alternatively use the LISTENER
attribute of the DISPATCHERS parameter in the initialization parameter file to
register the Dispatchers with any Listener. If running MTS under Oracle8i,
the LISTENER attribute is set in the MTS_DISPATCHERS parameter.
Because both the REMOTE_LISTENER parameter and the LISTENER attribute enable
PMON to register Dispatcher information with the Listener, it is not necessary
to specify both the parameter and the attribute if the Listener values are the
same.
Set the REMOTE_LISTENER parameter as follows:
REMOTE_LISTENER=<listener_alias>
Set the LISTENER attribute in Oracle8i as follows:
MTS_DISPATCHERS="(PROTOCOL=tcp)(LISTENER=<listener_alias>)"
Set the LISTENER attribute in Oracle9i as follows:
DISPATCHERS="(PROTOCOL=tcp)(LISTENER=<listener_alias>)"
The <listener_alias> is then resolved to the listening end-point through a
naming method, such as TNSNAMES.ORA file on the database server.
For example, if separate Listeners are configured to listen on port 1521 on
servers sales1-server and sales2-server, you can set the REMOTE_LISTENER
parameter in the initialization file for the instance on host sales1-server as
follows:
REMOTE_LISTENER=listener_sales2
You can set the REMOTE_LISTENER parameter in the initialization file for the
instance on host sales2-server as follows:
REMOTE_LISTENER=listener_sales1
You can then resolve listener_sales2 in the local TNSNAMES.ORA on sales1-server
as follows:
listener_sales2=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))
)
Similarly, you can resolve listener_sales1 in the local TNSNAMES.ORA file on
sales2-server as follows:
listener_sales1=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521))
)
If Shared Server is configured, you can set the DISPATCHERS parameter in the
initialization parameter file as follows:
DISPATCHERS="(PROTOCOL=tcp)(LISTENER=listeners_sales)"
You can then resolve listener_sales in the local TNSNAMES.ORA as follows:
listeners_sales=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))
)
You can also dynamically update the REMOTE_LISTENER parameter using the SQL
statement ALTER SYSTEM SET:
SQL> ALTER SYSTEM SET REMOTE_LISTENER='listener_alias';
If you set the parameter to null, then PMON de-registers information with the
remote listener with which it had previously registered information.
SQL> ALTER SYSTEM SET REMOTE_LISTENER='';
The LISTENER attribute overrides the REMOTE_LISTENER parameter. As a result,
the SQL statement ALTER SYSTEM SET REMOTE_LISTENER does not affect the setting
of this attribute.
2.0 Known issues with instance registration
-------------------------------------------
There are several known issues with instance registration. Most known
issues are resolved in the 9.2.0.2 patchset.
2.1 ORA-12514 errors connecting to registered instances
-------------------------------------------------------
When attempting to connect to Oracle8i using a connect descriptor containing a
SERVICE_NAME entry, you may receive the following error:
ORA-12514: TNS:listener could not resolve SERVICE_NAME given in connect
descriptor
The error means that the client has connected to the Listener but is
requesting a connection to SERVICE_NAME that the Listener does not have a
service handler for. This is usually not a problem with Service Registration,
but since the SERVICE_NAME entry that the client is attempting to connect to
is almost always a dynamically registered service, it needs to be addressed
here.
There are several reasons that error ORA-12514 might occur:
1) The instance that the client is attempting to connect to is not registered
with the Listener because the instance cannot locate the correct Listener
address in order to register itself.
If the LOCAL_LISTENER parameter is present in the INIT.ORA file, it will
attempt to resolve to an address. The instance will attempt to connect to
a Listener on that address to register itself.
If the LOCAL_LISTENER parameter is not present in the INIT.ORA file, the
instance will attempt to connect to the Default Listener using the default
address of TCP/IP port 1521 or IPC key PNPKEY.
2) The instance has registered with the listener, but the SERVICE_NAME that
the client is attempting to connect to does not match the SERVICE that
PMON has registered with the Listener.
The following steps show which SERVICE_NAME is registering with the
Listener:
- Run the listener control utility (lsnrctl).
- At the LSNRCTL prompt, type "set displaymode verbose" and press Enter.
- At the LSNRCTL prompt, type "services" and press Enter.
Ensure that the TNSNAMES.ORA entry for the SERVICE_NAME parameter exactly
matches a service that is registered with the Listener.
3) The instance is down.
One of the benefits of using service registration is that the Listener is
aware of the state of the instance.
When the instance is up, it registers itself with the Listener, allowing
the Listener to service incoming requests for it.
When the instance is down, it will not be registered with the Listener. If
the instance is not registered with the Listener, the Listener will refuse
incoming requests for it, and clients receive error ORA-12514.
4) The instance and Listener are both up, but the instance has not yet
registered with the Listener.
When the instance is started, it attempts to connect to register with the
local Listener. It continues to check for the Listener about once every
60 seconds.
If the Listener is up when the instance is started, service registration
should take place as the instance starts. If the Listener comes up after
the instance, it will take up to a minute or so for the instance to
register itself with the Listener. This is usually not an issue, but if
the Listener is stopped then started, users may fail to connect until the
the instance successfully re-registers with the Listener.
You can check to see whether the instance has registered itself using the
lsnrctl commands described in 2).
To resolve the ORA-12514 errors, you need to either resolve the registration
problems, resolve the problems with the SERVICE_NAME not matching what the name
that is actually registering with the listener, or define a static service
handler in the LISTENER.ORA file and modify the TNSNAMES.ORA file to connect
to the newly defined SID instead of the SERVICE_NAME.
2.2 Listeners intermittently crashing
-------------------------------------
Instance registration can cause listeners to intermittently crash.
In a hybrid setup with a 64-bit Listener and a 32-bit instance, the Listener
can intermittently hang or crash during Service Registration or updates. This
may occurs after the Listener has been running for some time.
In the event of a Listener intermittently crashing, one of the first things
to check is whether the Listener has service handlers for multiple instances.
The easiest way to do this is to run the ‘lsnrctl services’ command and check
whether other instances are registered with the Listener. If there are other
instances registering with the Listener, the service updates will also appear
in the LISTENER.LOG file.
There are several workarounds for this:
- Disable Service Registration and use only static service handlers. Please
see below for more information about disabling Automatic Service Registration.
- Force the 32-bit instance to register exclusively with a 32-bit Listener,
preferably of the same version as the instance.
This was patched in 8.1.7.4 and 9.0.1.3 on Solaris and is fixed in 9.2.0.2.
Refer Bug:2187760.
2.3 Instance fails to register with instance if ASO in use
----------------------------------------------------------
Installing Oracle Security Option (ASO), formerly known as Oracle Networking
Option - ANO, may be problematic.
If the following entries are present in the SQLNET.ORA file on the database
server, Automatic Instance Registration will not occur:
SQLNET.ENCRYPTION_CLIENT=REQUIRED
SQLNET.ENCRYPTION_SERVER=REQUIRED
If you either disable encryption or change these values to ACCEPTED or
REQUESTED, instance registration will work correctly:
SQLNET.ENCRYPTION_CLIENT=REQUESTED
SQLNET.ENCRYPTION_SERVER=REQUESTED
The other workaround is to use static service handlers instead of Service
Registration.
As of Oracle9i, this issue still exists.
Refer Bug:887753.
2.4 SDU and TDU are overwritten by dynamically registered instances
-------------------------------------------------------------------
Dedicated service handlers registered dynamically with a TNS listener will
always use the default maximum SDU size (usually 2048 bytes).
The SDU parameters are configured in the LISTENER.ORA file in the sid_desc
section. When the Listener is started, the service handler that is started
based on the SID_DESC section will reflect the specified SDU size.
The problem is that with Service Registration, there is no place to set the
SDU size for dedicated service handlers, so the default value (2048) is
always used.
There are a couple of workarounds for this issue:
1) Disable Service Registration and connect using the static service handlers.
2) Use Shared Server/MTS. You can set SDU in the DISPATCHERS or
MTS_DISPATCHERS parameter.
DISPATCHERS="(description=(SDU=8192)(address=(protocol=tcp)\
(host=<hostname>)))(dispatchers=1)"
When the Dispatchers are started, they will reflect the specified SDU size.
Refer Bug:1113588
IMPORTANT NOTE: Beginning with version 9.2.0.4, it is possible to workaround
the SDU issue mentioned above by setting the following sqlnet.ora file parameter:
DEFAULT_SDU_SIZE
Example:
DEFAULT_SDU_SIZE=32767
Please refer to Note:1113588.8 New SQLNET.ORA parameter DEFAULT_SDU_SIZE
2.5 Dynamically registered instances do not work with prespawned servers
------------------------------------------------------------------------
Dedicated service handlers registered dynamically with a TNS listener will not
use prespawned servers.
The PRESPAWN parameters are configured in the LISTENER.ORA file in the
SID_DESC section. Prespawned Dedicated Server processes are pre-started by
the Listener before any incoming connection requests.
The problem is that with Service Registration, there is no place to configure
prespawn.
The solution is to ensure that the dynamic registration uses a different
service name than the static registration. Clients can then select the static
prespawned service if desired to attach to the prespawned dedicated servers.
Starting from Oracle9i, pre-started dedicated server processes are no longer
supported. Instead, configure Shared Server to improve scalability and system
resource usage.
2.6 Environment picked up from the registered instance, not the Listener
------------------------------------------------------------------------
A server process that has been spawned by the Listener will inherit TNS_ADMIN
from the Listener. If this server process itself needs to create a new
connection, such as when opening a database link, the value of TNS_ADMIN is
checked in order to locate Net configuration files. If the Net
configuration files are not found, or incorrect files read, a TNS-12154 error
could result.
At instance startup, PMON picks up the TNS_ADMIN environment variable. When
PMON subsequently registers the instance with the Listener, the value of
TNS_ADMIN is passed to the Listener causing PMON's TNS_ADMIN value to
overwrite the value that the Listener had. If TNS_ADMIN is not set when PMON
starts, after registration the Listener's TNS_ADMIN value is cleared.
This is only a problem if the user that starts the database and Listener do
not have the same value of TNS_ADMIN set in their environment.
The way to resolve this is to either disable Instance Registration or ensure
that the users that start the database and Listener have the same value for
TNS_ADMIN.
2.7 ORA-00119 Error starting a 9.x instance with LOCAL_LISTENER defined
-----------------------------------------------------------------------
A common method if disabling instance registration is to set the
LOCAL_LISTENER parameter to a dummy alias or address. Having the parameter
set keep the listener from contacting the listener and therefore disable the
default registration from occurring.
In version 8.x, LOCAL_LISTENER could be set to a dummy alias and the instance
would whether the alias was resolvable or not.
In version 9.x, the LOCAL_LISTENER must be resolvable or the instance will fail
to start, returning the following errors:
ORA-00119: invalid specification for system parameter local_listener
ORA-00132: syntax error or unresolved network name 'DUMMY'
ORA-01078: failure in processing system parameters
To resolve these errors, either use an actual address in the LOCAL_LISTENER
parameter or set up an alias in the tnsnames.ora file on the server to resolve
the alias to an address.
To enable instance registration to a non-default listener, this address should
match the listener's address.
To disable default instance registration, this address should not match the
listener's address.
3.0 How to disable automatic instance registration
--------------------------------------------------
There are circumstances, for example to work around known issues, when it
may be desirable to disable Automatic Service registration of an instance to
prevent the Instance from registering with the Listener.
By default, PMON registers with the local Listener at the default local
address of TCP/IP port 1521. This behavior can only be disabled for Oracle8i
versions 8.1.5 and 8.1.7.
There are several ways to avoid this behavior:
1) For versions 8.1.5 and 8.1.7 only, set the following INIT.ORA event to
disable Automatic Service Registration:
EVENT="10258 TRACE NAME CONTEXT FOREVER, LEVEL 4"
Note: Due to Bug:1278836, the event does not apply for 8.1.6.
2) Do not run any Listeners on port 1521. PMON will not be able to locate the
Listener if it is not either specified in the LOCAL_LISTENER parameter or
located on this default port. If PMON cannot find the Listener, it cannot
register with it.
3) Use the INIT.ORA LOCAL_LISTENER parameter to define a dummy address.
Automatic Service Registration will not occur if the LOCAL_LISTENER
parameter is present. PMON will reject the invalid address and will not
attempt to register with port 1521. In version 8.x, LOCAL_LISTENER can be
set to either a dummy alias or an address other than the address that the
listener is running on. In 9.x, LOCAL_LISTENER can still be set to an
address, but if it is set to a dummy alias, the alias must be resolvable
to an address other than the address that the listener is running on.
For version 8.x, add the following parameter to the init.ora file:
LOCAL_LISTENER=dummy
-or-
LOCAL_LISTENER="(address=(protocol=tcp)(host=<hostname>)(port=<port#>))"
For version 9.x, run the following:
SQL> ALTER SYSTEM SET LOCAL_LISTENER=dummy SCOPE=SPFILE;
-or-
SQL> ALTER SYSTEM SET LOCAL_LISTENER="(address=(protocol=tcp)
(host=<hostname>)(port=<port#>))" SCOPE=SPF