Oracle Listener Knowledge Summary

One, dynamic registration

Dynamic registration of listening is when the instance is started the Pmon process dynamically registers the listener according to the Instance_name,service_names two parameters in the initialization parameter file.

Note that if you configure in RAC, you must set the instance_name parameter of each instance in the cluster to a unique value.

When taking the dynamic registration method, the contents of the Listener.ora:

Sid_list_listener =

(Sid_list =

(Sid_desc =

(Sid_name = Clrextproc)

(Oracle_home = f:appadministratorproduct11.2.0dbhome_1)

(program = Extproc)

(Envs = "Extproc_dlls=only:f:appadministratorproduct11.2.0dbhome_1binoraclr11.dll")

)

)

Optionally, you can specify multiple service values in the Service_names parameter, with commas between the values, which is useful for shared server configuration.

Such as:

alter system set SERVICE_NAMES=ORCL1,ORCL2;

Dynamic registration By default only registers to the default listener (name is listener, port is 1521, protocol is TCP), because Pmon only dynamically registers the port equals 1521 listens, otherwise Pmon cannot dynamically register listener, if needs to not the default listens for registration, You need to configure the Local_listener parameter!

Adds the listening information to the Tnsnames.ora file because Pmon reads the relevant information from the Tnsnames.ora when it is dynamically registering for listening.

LISTENER =

(DESCRIPTION =

(address = (PROTOCOL = TCP) (HOST = localhost) (PORT = 1522))

)

Then modify the Local_listener parameter

Sql> alter system set Local_listener=listener;

Sql> alter system register;

Or:

Sql> alter system set local_listener= ' (address = (PROTOCOL = TCP) (HOST = localhost) (PORT = 1522)) ';

Sql> alter system register;

You can see that the ALTER system register is used above, and this command registers the service value with the listener at any time when the database is open. This command is useful for replacing a service value that is lost because of a listener reboot, and its registered value is exactly the same as the value set by dynamic registration when the database is started.

If the values for Service_names and instance_name are not explicitly set, dynamic registration occurs only if the database is started after the listener is run, in which case the dynamic registration information will be lost if the listener subsequently restarts. Obviously, it is best to start the listener before all databases are started, so that you avoid the loss of dynamic registration information that is caused by restarting the listener without explicitly setting the values for Service_names and instance_name.

It is a good practice to set explicit values for initialization parameters Service_names and instance_name, although if you do not set them, Oracle generates default values (based on db_name and Db_main) for dynamic registration. The reason for this is that if the listener restarts after the database is started, there will be some subtle differences in their dynamic registration behavior.

If the listener restarts after the database is run, you only have the Service_names and instance_name values explicitly set in the Init.ora file, and the Pmon process for each database will automatically register the database after a short period of time.

If you need to perform a connection with failover or load balancing, or if you want to configure a transparent distribution of connections between instances in the RAC, then using the Service_names parameter will be necessary. To enable these features, you only need to set the Service_names in the database parameter file for each instance to the same value and reference the value in the Service_Name setting of the client connection request.

Second, static registration

Static registration is the configuration that reads the Listener.ora file when the instance is started, registering the instance and service to the listener. Whenever you start a database, two messages are registered to the listener by default: the instance and service corresponding to the database server.

More Wonderful content: http://www.bianceng.cn/database/Oracle/

When statically registered, the Global_dbname in Listener.ora provides the service name, and the Sid_name in Listener.ora provides the registered instance name.

When a static registration method is adopted, the contents of the Listener.ora are as follows:

Sid_list_listener =

(Sid_list =

(Sid_desc =

(Sid_name = Clrextproc)

(Oracle_home = f:appadministratorproduct11.2.0dbhome_1)

(program = Extproc)

(Envs = "Extproc_dlls=only:f:appadministratorproduct11.2.0dbhome_1binoraclr11.dll")

)

(Sid_desc =

(Global_dbname = ORCL)

(Oracle_home = f:appadministratorproduct11.2.0dbhome_1)

(Sid_name = ORCL)

)

)

LISTENER =

(Description_list =

(DESCRIPTION =

(address = (PROTOCOL = IPC) (KEY = EXTPROC1521))

)

(DESCRIPTION =

(address = (PROTOCOL = TCP) (HOST = localhost) (PORT = 1521))

)

)

Where Global_dbname corresponds to Oracle's external service name, which is service_names in initialization parameters.

And sid_name corresponds to the name of the Oralce instance, that is, the instance_name in the initialization parameter

Static registration applies To scenarios:

1. Start the instance first, and then start the listener

2. When the listener reboots

3.oracle instance when there is no open

Third, how to determine whether the static registration or dynamic registration

Use the command Lsnrctl status to see whether static or dynamic registration is in the end.

The instance state is a unknown value indicating that the service is statically registered. Because the listener uses it to not know any information about the instance, it checks that the instance exists only if the client issues a connection request.

Dynamically registered databases are indicated by state ready or state blocked (for an alternate database) in state information. Whenever the database is closed, dynamically registered databases are dynamically logged off from the listener, and the information associated with them disappears from the status list. This way, the listener always knows its state, regardless of whether the database is running or closed. This information will be used for the fallback (fallback) and load balancing of the connection request.

This article is from "Richard's notes-accumulate micro Cheng" blog, please be sure to keep this source http://zxf261.blog.51cto.com/701797/886027