Data Guard Listener Networking

I am currently reviewing an environment to create a third standby database. One of the primary challenges I’ve encountered is the lack of a consistent naming convention across the existing setup.

Establishing a standard for db_name, db_unique_name, and listener aliases is critical for long-term manageability, especially when scaling out to multiple standby sites.

1. Naming Conventions: Best Practices

Consistency starts with how you name your instances. Here are a few rules of thumb I follow:

Avoid Numbers in db_unique_name

Firstly, do not name your db_unique_name using numbers (e.g., hawk1, hawk2). In Real Application Cluster (RAC) environments, instances are already suffixed with numbers. Adding them to the unique name creates unnecessary confusion during troubleshooting and maintenance.

Standardizing the local_listener

When configuring the local_listener parameter, a common pattern is to use LISTENER_$(db_unique_name).

Does the listener name have to match this exactly?

• If you are not using a TNS alias: Yes, it must match.
• If you are using a TNS alias: No, the name can be anything defined in your tnsnames.ora.

However, why name the listener at the OS level at all? It is often easier to use a standard alias and run lsnrctl status rather than lsnrctl status LISTENER_$(db_unique_name). The latter varies by host, creating a dependency that complicates automation scripts.

2. Analyzing the Primary Database Configuration

Let's look at the current primary environment to see how these parameters are currently set up.

OL7-121-DG1:(SYS@hawk):PRIMARY> show parameter db_name NAME           TYPE     VALUE -------------- -------- ------- db_name        string   hawk  OL7-121-DG1:(SYS@hawk):PRIMARY> show parameter db_unique_name NAME           TYPE     VALUE -------------- -------- ------- db_unique_name string   hawka  OL7-121-DG1:(SYS@hawk):PRIMARY> show parameter local_listener NAME           TYPE     VALUE -------------- -------- ------- local_listener string   LISTENER_HAWKA 

Primary Listener Status

The status of the listener shows the various services being registered. Note the "READY" status, indicating dynamic registration via the database instance.

[oracle@ol7-121-dg1 ~]$ lsnrctl status ... Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ol7-121-dg1.localdomain)(PORT=1521))) STATUS of the LISTENER ------------------------ Alias                     LISTENER Version                   TNSLSNR for Linux: Version 12.1.0.2.0 - Production ... Services Summary... Service "hawka" has 2 instance(s).   Instance "hawk", status UNKNOWN, has 1 handler(s) for this service...   Instance "hawk", status READY, has 1 handler(s) for this service... Service "hawka_DGB" has 1 instance(s).   Instance "hawk", status READY, has 1 handler(s) for this service... 

3. Network Configuration and TNS Resolution

The network configuration files must be synchronized across all standby hosts to ensure seamless role transitions (switchover/failover).

SQLNET.ORA and Default Domains

In this environment, we are using the world domain:

[oracle@ol7-121-dg1 ~]$ grep -i DOMAIN $ORACLE_HOME/network/admin/sqlnet.ora NAMES.DEFAULT_DOMAIN=world 

TNSNAMES.ORA Strategies

When defining listeners in tnsnames.ora, you have a few options. I've tested a specific entry, LISTENER_HAWKA2, which omits the hostname.

• The Benefit: It defaults to localhost, making it easy to set as a local_listener without changing the string across different servers.
• The Drawback: You still have to manage the tnsnames.ora file on every host.

Typically, you can choose between having all static entries for all hosts, or a mix of static entries for remote standbys and one dynamic/local entry.

[oracle@ol7-121-dg1 ~]$ grep LISTEN $ORACLE_HOME/network/admin/tnsnames.ora LISTENER_HAWKA2.world = (ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521)) LISTENER_HAWKA.world = (ADDRESS = (PROTOCOL = TCP)(HOST = ol7-121-dg1.localdomain)(PORT = 1521)) LISTENER_HAWKB.world = (ADDRESS = (PROTOCOL = TCP)(HOST = ol7-121-dg2.localdomain)(PORT = 1521)) LISTENER_HAWKC.world = (ADDRESS = (PROTOCOL = TCP)(HOST = ol7-121-dg3.localdomain)(PORT = 1521)) 

Verification with TNSPING

Testing the reachability of these listeners ensures that our naming strategy is valid across the proposed 3-standby topology:

[oracle@ol7-121-dg1 ~]$ tnsping LISTENER_HAWKA2 Attempting to contact (ADDRESS = (PROTOCOL = TCP)(HOST =)(PORT = 1521)) OK (0 msec)  [oracle@ol7-121-dg1 ~]$ tnsping LISTENER_HAWKB Attempting to contact (ADDRESS = (PROTOCOL = TCP)(HOST = ol7-121-dg2.localdomain)(PORT = 1521)) OK (0 msec) 

By standardizing these names early, the addition of the third standby becomes a much smoother process. Hopefully, this post helps you plan and implement a consistent, easy-to-manage Data Guard environment.

Oracle Database Consulting Services

Ready to optimize your Oracle Database for the future?