A listener receives incoming connection requests and directs them to a database service handler. Changing its state affects applications when they create connections or reconnect. A controlled change therefore includes an exact target, the correct owner, a recovery path, and a fresh connection test afterward.
Oracle DBA Lesson 39B — Control a Listener and Restore Access
These notes use an instructor-designated Oracle Database 19c lab on Linux. The commands and observations are teaching examples. No listener or database operation was executed to produce this lesson. Substitute the lab's approved names and actual paths, and record its release update and observed results.
Choose the target and preserve recovery
This exercise requires an isolated, disposable listener named LISTENER_COURSE, preconfigured by the instructor on an unused approved port such as 1522, with a separate configuration and no dependent business clients. Use its operating system owner and the Oracle home that supplies its listener binaries. Local listener administration uses OS authentication. Normally the account that started the listener administers it, with the super user as an exception. The owner need not be an account named oracle.
Use the framework's supported lifecycle tools for a Grid Infrastructure or Oracle Restart managed listener. The direct lsnrctl lifecycle sequence below applies to the non-Grid-managed exercise target. Oracle Restart can restart a listener it manages, so ownership determines how an intentional state change is performed. See Configuring and Administering Oracle Net Listener for listener configuration, registration, status and services, and Restart ownership.
Keep a local shell on the listener host, independent of the listener's database endpoint. START must run on that host. A SQL session reached through the target endpoint is useful evidence, but local host access is the path for restoring a stopped listener.
Before changing anything, capture:
- OS owner, listener home, listener name, configured endpoint, and exact parameter file.
- Original listener state, services, instance, and handlers, and the relevant listener log location.
- A saved copy of its original configuration and the approved restoration procedure.
- An inventory of dependent clients, connection pools, failover paths, and any shared-server routing. Confirm the exercise target has no business dependencies.
- A fresh baseline login and its actual service and container values.
Use the instructor-provided environment for the correct Oracle home and configuration directory. TNS_ADMIN, when configured, selects a network configuration directory. Another directory or home may resolve the same listener name differently. Confirm the returned target before proceeding.
lsnrctl status LISTENER_COURSE
lsnrctl services LISTENER_COURSESTATUS supplies the listener identity, configuration and log locations, and listening addresses. SERVICES provides detailed service, instance, and handler information. Compare the actual results with the intended exercise target and baseline. See the Listener Control Utility for command behavior, named targets, local START, and OS administration authentication.
Always include LISTENER_COURSE in this exercise. In an interactive utility an omitted name can use CURRENT_LISTENER. Otherwise the default name is LISTENER. A default listener can use port 1521. A short command with an omitted target can therefore select a different listener.
A second listener provides another network endpoint for existing database services. It creates no private database. A nondefault endpoint requires compatible service registration and network reachability. The instructor must arrange those prerequisites. Opening port 1522 alone does not register a service. Registration parameter design is a separate task.
Choose the state change
| Action | Required starting state | Meaning | Postcheck |
|---|---|---|---|
START | Target is stopped | Launch the named listener on its local host. | Correct endpoint, registered services and handlers, and a fresh client login. |
RELOAD | Target is running | Reread supported listener.ora configuration, such as static service changes, while the process continues. | Correct advertisement after renewed registration, then a fresh login. |
STOP | Target is running | End the named listener process. | Observe the planned client impact, then restore the original state. |
Ordinary RELOAD unregisters dynamically registered services, instances, handlers, and listening endpoints, then registers them again. Include its possible connection impact in a change plan. The documentation also describes an optional lightweight reload flag. Its applicability to an unknown lab release update has not been verified here, so the example uses ordinary RELOAD.
lsnrctl reload LISTENER_COURSE
lsnrctl services LISTENER_COURSEA command-success message records completion of that listener-control operation. After reload, allow registration to renew and check the expected service, instance, and ready handler. Then test from the client through the endpoint that was changed.
Understand existing and new connections
After a dedicated connection has been handed to a dedicated server process, client and server communicate directly. In the ordinary dedicated lab case, stopping the listener leaves that established connection running. This is an architectural consequence of the handoff. The actual exercise must confirm it in its environment. See Identifying and Accessing the Database for connection handoff and direct client/server communication.
A new connection through the stopped endpoint fails until a listener is accepting requests there again. A reconnecting pool or a failover attempt can therefore fail even while one existing session still works. Assess shared-server and other routing dependencies separately. Listener stopping is unsuitable as a production access-control mechanism. Existing sessions may continue, and clients may have other endpoints.
To make the existing-session observation specific, the instructor can provide a dedicated connection descriptor. This authored example connects to LABPDB through dbhost:1522. Use the actual approved values:
sqlplus -L 'COURSE_READER@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost)(PORT=1522))(CONNECT_DATA=(SERVICE_NAME=LABPDB)(SERVER=DEDICATED)))'SQL*Plus prompts for the account's password. The account needs CREATE SESSION in the intended container. Use read-only test work so the listener exercise adds no pending application transaction.
In that session:
SELECT SYS_CONTEXT('USERENV','SERVICE_NAME') AS current_service,
SYS_CONTEXT('USERENV','CON_NAME') AS current_container
FROM dual;
SELECT 1 AS connection_test FROM dual;The first query identifies this session's actual service and container. Compare it with the recorded baseline. The example's intended container is LABPDB. The simple second query provides a repeatable read-only observation of the established connection. See SYS_CONTEXT for current-session service and container attributes.
Only after confirming the isolated target and recovery path, the owner can perform the exercise:
lsnrctl stop LISTENER_COURSERepeat the simple query in the established dedicated session. In a separate client, attempt a new connection through the same single endpoint. Preserve the actual results as separate observations. A multi-address connect descriptor might find an alternative listener. Use the approved single-endpoint test for this exercise.
Restore and verify the baseline
If the configuration was edited, restore its saved original file using the approved lab procedure. From the local owner shell, start the exact target if it is stopped:
lsnrctl start LISTENER_COURSE
lsnrctl status LISTENER_COURSE
lsnrctl services LISTENER_COURSEFor a target already running after the configuration is restored, use reload LISTENER_COURSE instead of attempting another start. If startup fails, preserve the reported error and inspect the listener log named in the startup or status evidence. Check the intended configuration, owner and home, and endpoint conflict as indicated by that evidence. Keep investigation scoped to LISTENER_COURSE. Never stop the default LISTENER as a shortcut.
Registration can take time after startup. Once the expected route is advertised, open a fresh client connection through the restored endpoint. See Understanding Oracle Net Architecture for service handlers, registration after startup, and Oracle Restart control.
sqlplus -L COURSE_READER@//dbhost:1522/LABPDBRepeat the SYS_CONTEXT query above. Confirm the intended service and container and a successful read-only query. Compare the listener address, services and handlers, configuration, and client result with the initial baseline. End the exercise sessions with EXIT when their test work is complete. Leave the instructor's original listener state and configuration restored. Remove only temporary exercise files under the agreed cleanup procedure.
Practice and completion
Predict each action before executing it in the designated lab. Collect before and after evidence for ordinary reload, stop, and local start, including the existing dedicated session and a separate fresh connection. Record the exact version and release update, owner and home, target and configuration, timestamps, commands, actual output, and your interpretation.
Completion requires restoration of the saved configuration if it was changed, the original listener endpoint and state, expected service advertisement, and a fresh approved login to the intended service and container. An existing-session query alone does not satisfy that criterion. If the baseline cannot be restored, keep the exercise incomplete and follow the instructor's recovery procedure. Keeping an existing session alive alone is insufficient grounds for stopping a business listener. New connections and reconnecting clients are affected.
No comments:
Post a Comment