A static entry supplies a listener with an explicitly configured service-to-instance mapping. It is useful when a management tool needs a route to an instance before ordinary dynamic service information is available. By the end of this part, you should be able to identify the mapping values, interpret UNKNOWN, and choose the additional evidence needed for a management connection.
Oracle DBA Lesson 40B — Reading a Static Listener Mapping
Ordinary supported application services use dynamic registration. Choose a static entry for the selected tool's documented requirement. See 19c static service registration. It lists particular uses, including Data Guard and remote startup from certain tools. The actual management tool and deployment determine the configuration.
A documented management use
For Data Guard broker restart operations, a static service is required when the database is managed without Oracle Clusterware or Oracle Restart. The broker's instance-specific StaticConnectIdentifier supplies the startup connection route. Its requested service must agree with the static service registered at the intended listener. The default broker name follows <DB_UNIQUE_NAME>_DGMGRL.<DB_DOMAIN>. A custom static name requires a matching property value. See the 19c broker prerequisites and the StaticConnectIdentifier property.
This is a narrow example of a management requirement. This lesson reviews a configuration. Setting up Data Guard and performing role changes are outside its practice. A database's NOMOUNT state alone is not a general rule requiring static registration.
Read the three values
Here is an authored listener.ora fragment for a listener named LISTENER_COURSE:
SID_LIST_LISTENER_COURSE =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = course_mgmt.example)
(SID_NAME = LABDB)
(ORACLE_HOME = /lab/oracle/product/19c/dbhome_1)
)
)| Configuration value | Role in this example | Resolve before use |
|---|---|---|
GLOBAL_DBNAME | course_mgmt.example matches the service requested in the client's SERVICE_NAME | The selected management tool's service name and connection route |
SID_NAME | LABDB identifies the database instance SID | The instructor-confirmed instance inventory |
ORACLE_HOME | The Oracle software home supplies that instance's binaries | The actual instance software home on the database host |
The listener-name suffix connects this list to LISTENER_COURSE. GLOBAL_DBNAME and SID_NAME have separate roles: the client requests a service, and the entry maps it to an instance. Oracle's 19c OCI connection example shows the same service name in GLOBAL_DBNAME and client SERVICE_NAME. The 19c Net Services Reference documents listener-name configuration suffixes and configuration-file location rules. Use the actual listener's reported configuration file. The listener and database software homes may differ.
The generic service above is a teaching example, not the broker's default service name or an executable setup for the current host. Resolve all values, and any tool-specific descriptor or environment requirements, against the lab inventory and matching release documentation. Static configuration supplies routing information. Authentication, the requested administrative privilege, and database or PDB state are separate operating requirements. Creating this entry does not grant SYSDBA or open an application PDB.
Interpret the listener report
The OS listener owner can inspect registered services with:
lsnrctl services LISTENER_COURSESERVICES reports services, their associated instances, and handlers. Consider these shortened, authored excerpts:
Service "course_mgmt.example" has 1 instance(s).
Instance "LABDB", status UNKNOWN, has 1 handler(s) for this service...
Service "LABPDB" has 1 instance(s).
Instance "LABDB", status READY, has 1 handler(s) for this service...UNKNOWN identifies a static registration: the listener lacks dynamically reported instance state for that entry. The configured mapping can be advertised while the instance is unavailable. READY means the reported instance can accept connections. BLOCKED is a separate state indicating that the instance cannot accept connections. Read the reported field in the 19c listener status and service documentation.
For the required learning check, No: UNKNOWN alone cannot establish that the instance is stopped. It also supplies no proof of failure, blocking, or overall health. Establish the current instance state and obtain evidence for the intended management connection separately. A successful listener command reports the listener's information. Record the actual connection validation result as its own evidence.
Use the management tool's validation
In an instructor-designated existing Data Guard broker lab, the documented command is:
VALIDATE STATIC CONNECT IDENTIFIER FOR <database>;Replace <database> with the actual broker database member name before entering the command at a DGMGRL> prompt. DGMGRL requires an appropriately authorized SYSDG or SYSDBA identity and the lab's configured authentication. The command validates the static connect identifier by making a new connection using the static service. The broker adds STATIC_SERVICE=TRUE so that this connection uses the static service without falling back to a dynamically registered service. In the applicable non-Clusterware case, inspect the named database, connection route, and actual success or error result. It checks the route without restarting the database. Do not mark a restart or a complete recovery test as passed from this check. Clusterware-managed results have different behavior. See the 19c DGMGRL command reference and static identifier validation guidance.
There is no requirement to provision or connect to Data Guard for the primary review exercise below. For another management tool, use its documented validation and authentication requirements.
Independent review practice
Ask the instructor for two saved SERVICES reports, the relevant static configuration, and a resolved inventory. The inventory must identify the intended listener or endpoint, instance SID, instance Oracle software home, requested management service, management tool, and deployment management method. Compare the reports with these records:
- Identify the static entry and explain its
GLOBAL_DBNAME,SID_NAME, andORACLE_HOMEvalues. - Explain what the entry's
UNKNOWNstatus records. Distinguish it from a dynamicREADYreport and fromBLOCKED. - Name the additional instance-state and connection evidence needed. If actual validation evidence is supplied, tie its result to the requested management route and instance. Keep missing evidence pending.
Pass when you explain UNKNOWN without diagnosing the instance as failed or stopped, match all three values to inventory, and identify a documented connection check. This exercise reads saved evidence and requires no cleanup.
Optional isolated configuration exercise
Only use an instructor-designated disposable 19c Linux instance and an isolated LISTENER_COURSE maintained by its OS owner. Record the release and RU, software ownership, the exact listener endpoint, the active configuration path, the instance SID and software home, existing services, and a tested baseline connection. Agree a lab change window and retain local host access. The instructor must verify that the service name is unused, resolve the complete tool-specific settings, and confirm that the listener configuration can be restored. Do not substitute the current host's paths or a shared listener.
Back up the exact active listener.ora before editing. Add only the reviewed entry using the resolved lab values. The listener owner can then run:
lsnrctl reload LISTENER_COURSE
lsnrctl services LISTENER_COURSERELOAD rereads configuration while the listener remains running. The 19c Listener Control reference documents this behavior. Ordinary reload unregisters and then re-registers dynamic services and handlers. Allow registration to settle, and verify the expected services and a fresh baseline login. This exercise never uses a database shutdown to demonstrate UNKNOWN and requires no firewall or registration-security changes.
Record the actual output and explain the static entry. If an authorized management validation is available, record its actual result separately. Remove only the entry added for this exercise, or restore the verified backup when it remains the correct baseline and no other lab edits have occurred. Reload the same listener. Confirm the original services and a fresh connection again. Finish only after the baseline is restored. Keep a failed restoration for instructor resolution.
All configuration values and displayed reports in these notes are authored examples checked against documentation. No database or listener command was executed while preparing them. Use actual designated-lab records for practical evidence. Unresolved inventory or unavailable privileges leave execution pending.
No comments:
Post a Comment