Dynamic and Static listeners

When the status of the lsnrctl command is used for dynamic and static listeners, the following return values are often displayed: [plain] Service "elvis" has 2 instance (s ). instance "elvis", statusUNKNOWN, has 1 handler (s) for this service... instance "elvis", statusREADY, has 1 handler (s) for this service... service "elvisXDB" has 1 instance (s ). instance "elvis", statusREADY, has 1 handler (s) for this service... the command completed successfully here, The State UNKOWN indicates static registration (manually enter The parameter); The State is READY records, indicating Dynamic Registration (listener. the ora parameter is automatically obtained by the PMON process from the parameter file). You may be surprised. Maybe I am a little different from yours. There are two instances in elvis, the reason is that elvis is my Instance name and the system comes with one, and the service name is the same as the database name by default (if there is no domain name), it may be for the Instance name, domain name, the service name is a bit messy. You can view my other post on this concept: http://www.bkjia.com/database/201305/215220.html The unknown is the listener I created manually (static listener), and The created listener also uses elvis, which is the same as the system, so it is merged together, if you manually create an individual name, such as a (the Global Database Name specified when the listener is created, this can be started at will, and the SID must be consistent !!!), [Plain] Service "a" has 2 instance (s ). instance "elvis", statusUNKNOWN, has 1 handler (s) for this service... instance "elvis", statusREADY, has 1 handler (s) for this service... service "elvisXDB" has 1 instance (s ). instance "elvis", statusREADY, has 1 handler (s) for this service... the command completed successfully 1: register The database as a service and register it with The listener. The client does not need to know the Database Name and Instance name. It only needs to know the service name provided by the database to external users and can apply to connect to the database. The service name may be the same or different from the instance name. When the database server is started, the database server registers the corresponding service with the listener (whenever a database is started, two messages are registered to the listener by default: the instance and service corresponding to the database server .) As a result, there is a Listener (Listener) between the database server and the client. In the Listener, the service name corresponding to the database is recorded (one database may have multiple service names). When the client needs to connect to the database, only the service name is required, you can establish a connection between the client and the server. 2. In the static listening configuration, the global database name in the Database Service can write any content, which is irrelevant to the database. The database can be connected as long as the SID is correct. Due to static registration, the parameter is manually added statically, which is irrelevant to the database. The database cannot confirm whether the listener is correctly configured. Therefore, the status in lsnrctl is displayed as unkown. That is, the database cannot be connected. Note: For static registration listening, the client is configuring tnsnames. when the ora service is named, the content in "(Oracle 8i or later) service name" must be consistent with the global database name when the server registers the listener statically. Otherwise, the connection fails. [Plain] Service "a" has 1 instance (s ). instance "elvis", status UNKNOWN, has 1 handler (s) for this service... elvis refers to the value (the value of GLOBAL_DBNAME in the configuration file) read from the "Global Database Name" in the Database Service during the monitoring configuration process. "elvis" refers to the value from the monitoring configuration, value read by SID in Database Service (value of SID_NAME) [plain] SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = elvis) (ORACLE_HOME =/u01/oracle/product/11.2.0/dbhome_1) (SID_NAME = elvis) when the client configures tnsname, the service name (SERVICE_NAME) Is test. Otherwise, the database cannot be connected. [Plain] ABC = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.201.128) (PORT = 1521 ))) (CONNECT_DATA = (SERVICE_NAME = elvis) ABC here, name the service. Can be any value. When the client connects to the server, enter the host string, that is, the service name ABC. 3. Dynamic Registration 3.1 default Dynamic Registration pmon dynamically reads the service_names value from the parameter file when the database is started to mount or open. Service_names can be multi-value (there can be 64, including two systems ). Service_names is the global database name when the database is created by default. Set the service_names parameter to 'B, c, D'. The command is as follows: alter system set service_names = B, c, d; lsnrctl status is as follows: [plain] Service "B" has 1 instance (s ). instance "elvis", status READY, has1 handler (s) for this service... service "C" has1 instance (s ). instance "elvis", status READY, has1 handler (s) for this service... service "D" has1 instance (s ). instance "elvis", status READY, has1 handler (s) for this service... service "a" has 1 instance (s ). instance "elvis", status UNKNOWN, has 1 handler (s) for this service... service "elvis" has 1 instance (s ). instance "elvis", status READY, has1 handler (s) for this service... service "elvisXDB" has 1 instance (s ). instance "elvis", status READY, has1 handler (s) for this service... the command completedsuccessfully and above service names B, c, d, elvis are all READY and are dynamically registered. Note: No matter what the value of the service_names parameter is, pmon automatically registers a listener with the global database name (elvis here) as the service name. By default, if Dynamic Registration listening is enabled, the port number must be 1521. If Dynamic Registration of other ports is enabled, the relevant configuration must be required. 3.2 Dynamic Registration listening for custom ports if you want to enable dynamic registration for non-default port 1521, Oracle will not dynamically register by default. To enable Dynamic Registration, you must set the local_listener parameter. Configure tnsnames. ora on the server to specify the listener parameters, or modify local_listener to specify the listener parameters. The procedure is as follows: 1) configure the listener on the netmgr server. The listening port is 1525 (non-default port). 2) Specify the listening parameter (1) Method 1: modify the local_listener parameter to specify [SQL] SQL> alter system set LOCAL_LISTENER = '(ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.201.128) (PORT = 1525 ))'; SQL> alter system register (2) Method 2: Create $ ORACLE_HOME/network/admin/tnsnames on the Oracle server. ora. Parse the file and fill in the following content [plain] mytest = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.201.128) (PORT = 1522 ))) here, mytest can also be changed to another string as needed. For example, a or B. Set parameters to specify the listening parameter [SQL] SQL> alter system setlocal_listener = mytest; SQL> alter system register through the information in tnsnames. ora;