While this variable does not directly store a value that you can identify your database with, it does dictate how you might connect to a database. This variable is either TRUE or FALSE and if it is set to TRUE it enforces database links to have the same name as the remote database to which they are linking. In Listing 5, you can see a sequence of events where I first set GLOBAL_NAMES to TRUE and then created a database link. The interesting thing is that Oracle lets you create a database link that goes against the GLOBAL_NAMES parameter setting. It 'is not until you actually try to use it that you get an ORA-02085 error. After setting GLOBAL_NAMES to FALSE, I am able to use the database link.
Use of GLOBAL_NAMES parameter
The INSTANCE_NAME is the name given to the set of processes that are running on the database server. This parameter is set in the INIT.ORA and can be seen by querying the V$INSTANCE table. The SQL is given in Listing 6.
SQL for extracting the INSTANCE_NAME
This parameter will default to the GLOBAL_NAME. Remember the GLOBAL_NAME is a combination of DB_NAME and DB_DOMAIN. This parameter can take on multiple names that are comma separated. This allows you to give different service names to the same instance or a single service name for multiple instances that access the same database, as in Oracle's real application cluster environment. The point here is that the service name will not give you a unique name for the instance to which you are connected.
While DBID is not a "name" of a database, it does have the quality of uniquely identifying a database be a unique number. The DBID number is generated at database creation. Don't ask me how this number is generated, I wish I knew. All I can say is that it is supposed to be unique across databases. Well we all know that nothing in this world can be trusted to be absolutely unique across all databases. I know of one instance where if you were to clone a database, the DBID will be the same for the cloned database as the original. At least Oracle has given us a work-around in the form of a utility to change the DBID. Listing 7 will give you the SQL to extract the DBID. There are two tables you can get this information from, the V$DATABASE and the GV$DATABASE. If you are not aware of the 'GV' tables, they are GLOBAL across clustered instances.
SQL for getting DBID
You should have noticed in Listing 6 and Listing 7 that when selecting from the V$ table there was no INST_ID. That is because the V$ tables act on the current instance connected to and the GV$ tables acts on all instances for the database as in a cluster environment. The other GV$ table to get some information from is the GV$INSTANCE table. By executing the SQL in Listing 8, you can get the INST_ID, INSTANCE_NUMBER, INSTANCE_NAME and HOST_NAME for determining what machine you are on.
SQL for extracting the HOST_NAME
When we as DBA(s) start working in a distributed environment where there are replicated environments, Real Application Clusters, standby databases, cloned databases and a variety of other configurations, it is imperative that we are able to distinguish the database instance that we are connected to and the database it is connected to. Go forth and name properly so that you won't get lost in the sea of confusion.