The Oracle databases db_unique_name parameter is used by Oracle for numerous different reasons and is various places in the Oracle software stack. It is described by Oracle in their own documentation as the following:
DB_UNIQUE_NAME specifies a globally unique name for the database.
What does this description actually mean?
Oracle is indicating through this description that the database must be uniquely identifiable through this name within a specific operational environment. This could be the entire company or a portion of the network infrastructure within that organisation. The premise behind it is to ensure each Oracle database can be uniquely identified through this parameter in combination with the db_domain parameter and there should not be multiple databases utilising the same db_unique_name.db_domain name combination where there is a potential for network based connections to be routed incorrectly or maintenance of databases be performed that inadvertently impacts the wrong database.
Why would a database need to be uniquely named and identified?
Each and every Oracle database will have a default database service registered in an Oracle listener that the database has been told to register its services and connection endpoints against through parameters like local_listener and remote_listener. Having multiple db_unique_name.db_domain values that are the same for multiple databases in a specific environment can lead to scenarios where a specific listener (or set of listeners in the case of a SCAN listener) may have the same service presented for what are ultimately very different databases. Oracle listeners do allow for sqlnet connections to be redirected to remote instances as is the case for Oracle RAC. This can lead to database connections being advertently being directed to the wrong place resulting in connection failures and other problems. Ensuring db_unique_name.db_domain is unique across your IT infrastructure avoids these problems.
- Oracle forces db_unique_name values to differ in Data Guard Physical Standby environments where Data Guard is correctly configured with Data Guard broker. No two databases participating in the physical standby environment can have the same db_unique_name value. This is enforced by the Data Guard broker mechanisms and configuration to ensure all databases who have the same db_name can be uniquely identified within this potential network of database copies that are being maintained through redo shipping across the network. As Oracle has the capability to ship redo to up to 31 different destinations so there is the potential for their to be 30 remote standby destinations. If you than take into account cascaded standby sites the potential number of copies of the original database grows again. Uniquely naming each of these database begins to make more sense the more copies of the same database exist within a specific organisational environment.
- Oracle uses the db_unique_name value to provide default locations for numerous file paths including database files held in ASM or using Oracle Managed Files and Data Guard Broker configuration files to name a few.
- Oracles Clusterware relies on the db_unique_name value when registering resources within a RAC cluster and this value is used in naming and identifying a specific database within the Oracle Cluster Registry. In later releases of RAC once a database has a resource registered in the clusterware stack Oracle will prevent it from being altered inside the database and break the relationship between the RAC database and the clusterware resource.
- Oracle also uses db_unique_name within RMAN backup and recovery catalog maintenance, its backup appliances and Oracle Cloud for identifying databases. The backups of a database, for example, have db_unique_name associated with the backup file names in the recovery catalog.
How does Delphix use db_unique_name?
Given this list of uses within Oracle itself where db_unique_name is attempting to enforce a unique identifier for a specific database within an organisation and its computing infrastructure, Delphix is also using db_unique_name to enforce uniqueness within Delphix Engines. This makes sense given this is also how Oracle themselves are intending the parameter to be used. Allowing multiple Oracle databases with the same db_unique_name to be held within the same Delphix engine has the potential to lead to all sorts of confusion in identifying both dSources and virtual databases. Forcing this uniqueness reduces to some degree the possibility of mistakes and errors resulting from allowing duplicate db_unique_names to exist.
Some examples of where db_unique_name comes into play within Oracles technology stack.
Delphix uses srvctl to discover databases in clustered environments. srvctl config database returns a list of db_unique_names for any database resources registered in the Oracle Clusterware (Grid Infrastructure).
[oracle@oelc5n1 ~]$ srvctl config database d19c1
Database resources are registered within the Oracle clusterware through the issuing of srvctl add commands. Database administrators may do this or oracle provided utilities for managing databases like the database configuration assistant (dbca) and Enterprise Manager can be used to configure these resources.
[oracle@oelc5n1 ~]$ srvctl config database -d d19c1 Database unique name: d19c1 Database name: Oracle home: /u01/app/oracle/19.3 Oracle user: oracle Spfile: +DATA/D19C1/PARAMETERFILE/spfile.272.1083600001 Password file: +DATA/D19C1/PASSWORD/pwdd19c1.256.1083599111 Domain: plb.internal Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: Disk Groups: DATA,FRA Mount point paths: Services: Type: RAC Start concurrency: Stop concurrency: OSDBA group: dba OSOPER group: dba Database instances: d19c11,d19c12 Configured nodes: oelc5n1,oelc5n2 CSS critical: no CPU count: 0 Memory target: 0 Maximum memory: 0 Default network number for database services: Database is administrator managed
Applicable Delphix Versions
- Click here to view the versions of the Delphix engine to which this article applies
Major Release All Sub Releases 6.0 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52
184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52
184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11
18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168
22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52
The following articles may provide more information or related information to this article: