Network Topology   «Prev 

Database Location Independence

End users do not necessarily know or care about the physical location of the databases that comprise the system. Data is retrieved without any specific reference to the physical sites. Oracle Net8 accomplishes this through the use of transparent service names that hide the IP address, protocol, and remote database name.
In its most basic form, SQL*Net is a software tool that enables a network of Oracle clients and servers to communicate transparently on top of any underlying network topology or protocol via SQL.
Although SQL*Net is a very robust and sophisticated tool, you must appreciate the inherent complexity that accompanies its flexibility. This article provides a no-nonsense overview of the SQL*Net architecture. All of the examples are based on Unix.
SQL*Net is not easy to install.
You need the following files on the server side in order to operate SQL*Net 2.0 on a Unix system:
  1. /etc/TNSNAMES.ORA : Used for outgoing database requests, this file contains all of the database names (or service identifiers, SIDs) running on the processor, as well as domain name, protocol, host, and port information. When a new database is added to a box, you must update this file (changes to TNSNAMES.ORA become effective instantly). Note: SQL*Net version 1.0 equivalent is /etc/ORATAB.
  2. /etc/LISTENER.ORA : This file contains a list of destinations for outgoing database connections. When you add a new destination database to a Unix host, you must also add it to this file.
  3. /etc/HOSTS : This file lists all of your network addresses.
  4. /etc/SERVICES : This file lists all of the services available on a server, including SQL*Net services. It is no longer necessary with version 2.0.
  5. The only file required on the client side is /etc/TNSNAMES.ORA. (On a PC client, this file is determined by the path in the c:\windows\oracle.ini file.)
  6. (Although the Oracle Network Manager now sets up these file automatically, sometimes you must access or set them up manually.)

Location Transparency

Location transparency, or location independence, means that neither applications nor users need to know the actual location of the
  1. tables,
  2. views, or
  3. stored procedures
they are accessing. Oracle provides support for location transparency by means of database links and synonyms. Suppose that the fictitious Bigwheel Bicycle company wants to make its PRODUCTS table visible to its sales site, while the actual table resides at the headquarters site. We can configure the sales sites so that a reference to PRODUCTS maps to the table in the headquarters site by creating a database link from PSLS.BIGWHEEL.COM to PHQS.BIGWHEEL.COM and creating a synonym for the remote object: 

CREATE DATABASE LINK PHQS.BIGWHEEL.COM
USING 'prodhq';
CREATE SYNONYM products
FOR [email protected];

Location Transparency

Each database is represented by one or more services and a service is identified by a service name, for example, sales.us.example.com. A client uses a service name to identify the database it must access. The information about the database service and its location in the network is transparent to the client because the information needed for a connection is stored in a repository. The repository is represented by one or more naming methods. A naming method is a resolution method used by a client application to resolve a connect identifier to a connect descriptor when attempting to connect to a database service. Oracle Net Services offers several types of naming methods that support localized configuration on each client, or centralized configuration that can be accessed by all clients in the network. GUIs enable you to manage data stored in the naming methods.

Ad Distributed Databases