Configuring listener.ora and Adding a Database Service in Oracle AI Database 26ai

Oracle Net Listener settings live in a text file named listener.ora^[1]. On Linux and UNIX, it's typically found under $ORACLE_HOME/network/admin; on Windows, the exact path varies by install but usually ends with \network\admin.

In older Oracle versions — and in a lot of legacy tutorials still circulating — "adding a database" to the listener meant editing this file directly, adding a static entry under a SID_LIST_<listener_name> heading. In Oracle AI Database 26ai, that's rarely what you actually want to do. The normal approach is dynamic service registration: you keep listener.ora focused on the listener's own network address (host and port), and the database instance itself takes care of registering its services with that listener automatically. "Adding a database" today usually means confirming registration is happening correctly, not editing a config file by hand.

This lesson covers three things:

1. Historical context — how a legacy SID_LIST_LISTENER block is structured, and why you'll still encounter it in older documentation and scripts.
2. Current best practice — how to confirm and, if needed, correct dynamic registration for a database in Oracle AI Database 26ai.
3. When static entries are still genuinely required — a short, specific list of real scenarios, not a vague catch-all.

A few things worth understanding about this structure, since you'll still see it in real environments even though it's no longer the default approach:

1. Oracle can run multiple listeners. The name — often simply LISTENER — identifies which listener a given block of configuration applies to.
2. A listener can have a "SID list" (service list). Each entry begins with SID_DESC.
3. PLSExtProc commonly represents the external procedure handler (extproc), used to let Oracle call out to external libraries — a genuinely current use case, covered below.
4. A database entry is recognizable because it references a SID_NAME for an actual instance, rather than only a PROGRAM (which marks an agent like extproc instead).
5. GLOBAL_DBNAME lets clients reference a service name that includes both the database name and a domain — for example, sales.us.example.com.
6. SID_NAME identifies the instance name used to route the connection to the correct server process.
7. ORACLE_HOME tells the listener where the Oracle home for that entry is located.

In Oracle AI Database 26ai, you usually don't add a new database by copying SID_DESC blocks into listener.ora. Instead, you confirm the database and its services register themselves with the listener automatically. Conceptually, you're "adding" the database by ensuring the listener can see the service — not by hand-editing a config file to describe it.

The process behind this has a name worth knowing: a background process called LREG (the Listener Registration process) is what actually performs dynamic service registration on the database's behalf. LREG periodically registers the instance's service information with whichever listener it's configured to reach — the local listener by default, or a nondefault local listener or remote listener if you've told it to look elsewhere. This is also exactly why forcing an immediate registration works the way it does later in this lesson: ALTER SYSTEM REGISTER is telling LREG to register right now, rather than waiting for its normal registration interval to come around.

Make sure your listener is configured to listen on the correct host and port. A minimal example:

LISTENER=
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=TCP)(HOST=sale-server)(PORT=1521))
  )

If you're using external procedures, keep the IPC address alongside it — this is the same extproc mechanism the historical example above illustrates:

LISTENER=
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=TCP)(HOST=sale-server)(PORT=1521))
    (ADDRESS=(PROTOCOL=IPC)(KEY=extproc))
  )

From SQL*Plus or SQLcl, connected as SYSDBA, check the current configuration. In a multitenant environment, remember you're typically connecting clients to a service name — often a PDB's service — not a bare SID, consistent with how this course has handled connections throughout.

-- Quick checks (names vary by environment)
SHOW PARAMETER service_names
SHOW PARAMETER local_listener

If the listener isn't on the default host and port — or you're using a custom listener name — set LOCAL_LISTENER explicitly and force LREG to re-register immediately rather than waiting:

ALTER SYSTEM SET local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=sale-server)(PORT=1521))' SCOPE=BOTH;
ALTER SYSTEM REGISTER;

On the database host, confirm registration succeeded from the OS side:

lsnrctl status
lsnrctl services

You should see your database's service(s) listed under the Services Summary. If you don't, the usual suspects are: wrong host or port in LOCAL_LISTENER, a DNS or hosts-file mismatch, a firewall blocking the listener's port, the listener having been started under a different Oracle Home than the one the database instance expects, or a missing or incorrect LOCAL_LISTENER value entirely. Working through these in order — network reachability first, then configuration mismatches — tends to be faster than guessing.

Static service registration isn't obsolete — it's just no longer the default, and Oracle checks dynamic registration information first before falling back to whatever's statically configured in listener.ora. The real, current list of scenarios where static configuration is actually required is shorter and more specific than "certain management setups":

• External procedure calls — the extproc case already covered above, and the most common reason you'll actually touch SID_LIST_LISTENER today.
• Oracle Heterogeneous Services — connecting to non-Oracle databases through Oracle's gateway architecture.
• Oracle Data Guard — standby database configurations often need static entries so the listener can respond correctly even when the instance itself isn't in a normal open state.
• Remote database startup from a tool other than Oracle Enterprise Manager Cloud Control — if you're starting a database remotely without EM Cloud Control managing that process, dynamic registration alone isn't sufficient, since the instance can't register a service it hasn't started yet.

Of these, Data Guard and the remote-startup case are worth remembering even though they come up less often in day-to-day work than the extproc scenario — they're the ones most likely to catch you off guard precisely because dynamic registration works so reliably everywhere else. For deeper coverage of exactly how LSNRCTL and listener.ora interact once you're troubleshooting a mixed static/dynamic configuration, see the LSNRCTL/listener.ora interaction lesson — the short version for this course: prefer dynamic service registration by default, and reach for a static SID_LIST entry only when one of the scenarios above genuinely applies.

Example of a static database entry — use only when you have a clear requirement from the list above, not as a default habit:

SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC=
      (GLOBAL_DBNAME = sales.us.example.com)
      (ORACLE_HOME   = /oracle26ai)
      (SID_NAME      = sales)
    )
  )

Editing tip: the most common failure with hand-edited static entries is broken parenthesis nesting. If you're copying and pasting, recheck indentation and matching parentheses carefully before restarting the listener — a single unmatched parenthesis will keep the listener from starting at all, and the resulting error doesn't always point clearly at which line is the actual problem.

Click the exercise link below to add an entry for the COIN database to your listener.ora file.
Configuring Listener - Exercise

[1] listener.ora: A configuration file that defines Oracle Net Listener properties — addresses and ports, optional static services, and control parameters.