| If you've ever administered an Oracle database, you're probably very familiar with local naming. This is the traditional method involving tnsnames.ora and sqlnet.ora files that must be distributed to each client machine on your network that accesses an Oracle database. The tnsnames.ora file is a text file containing definitions for net service names . The sqlnet.ora file is a text file with parameter settings that control Net8's operation. The entire local naming setup is illustrated in Figure 2.1. Figure 2.1. Local naming uses tnsnames.ora and sqlnet.ora to interpret net service names  As you can see from Figure 2.1, when you connect to a database using local naming, Oracle reads the sqlnet.ora file to determine the default domain, and then reads the tnsnames.ora file to resolve your net service name to a specific database, or database instance, on a specific server. The entries in the tnsnames.ora file look like this: prod.hr = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = hr_server)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = prod.hr) ) ) The primary advantage of local naming is that it is straightforward and simple to use. You don't have to configure Oracle Names, and you don't have to link Net8 to an external directory service. The primary disadvantage (and this can be a big one) is that local naming depends on getting the right files out to each client. If you have a large network of, say, 1000 or so PCs, each with its own tnsnames.ora file, and you need to move a database to a new server, you'll find yourself faced with the task of distributing a new tnsnames.ora file to each of those PCs.  | Some sites work around the problem of distributing tnsnames.ora files by maintaining one copy on a file server and pointing all client machines to that one copy. The TNS_ADMIN environment variable provides one mechanism you can use for that purpose. See Appendix E for details. | |  | 
