1262-1263

Previous Table of Contents Next

Page 1262

Figure 55.13.
SQL*Net 1 imple-
mented as a DLL.

I could discuss many issues regarding SQL*Net 1; however, because you might not even use this version of the software and it usually is transparent to developers and end users, I want to cover only one more topic: controlling and using SQL*Net 1. If you are using SQL*Net under Microsoft Windows 3.1 and everything is set up correctly on your computer, you load the SQL*Net software automatically when needed. On computers where SQL*Net is a background process, you have to ensure that the background process is running before you use SQL*Net.

The good news is that Oracle provides relatively simple-to-use utilities to determine the status of this background process, to start it, and to stop it. The bad news is that you have to know the name of the process and the way to access it. Process is a term that works under UNIX. Under Windows NT, the more proper term is service. Novell refers to Novell loadable modules (NLMs). For the name of the process (or service), you need to see what name your database administrator set up when installing the software. It also is important to know which utility controls the background process. Under Windows NT, you access the Services utility from the Control Panel to start up the service. Under UNIX, you use the tcpctl utility (with the start, stop, or status option) to work with the SQL*Net TCP/IP background process. Because such a wide variety of configurations is available, it is a good idea to check with your database administrator, systems administrator, or whoever installed your SQL*Net software.

The topic most interesting to the average user is using SQL*Net 1 to access remote databases. This process is relatively simple; all you have to do is specify the database address in the manner appropriate to your application. The SQL*Net 1 address is composed of three parts . The first part tells SQL*Net which protocol you are using (T = TCP/IP, P = named pipes, and so on). The second part of the address shows on which computer the desired database resides. In TCP/IP, for example, you can use an alias defined in the hosts table (such as marketing) or the Internet address of the server (such as 10.15.20.25). For the third part, you need to specify the SID (Oracle's system ID) for the database you want. The SID is set up by the DBA when creating the new database, so that person has to tell you the name of the SID.

SQL*Net 1 enables you to create aliases for your remote databases. It also enables you to define default local and remote databases that are accessed when the user does not specify the desired database. The following is a sample call to the SQL*Plus utility that accesses the jdoe account in the MKT Oracle instance on the marketing server using the TCP/IP protocol:

 $ sqlplus jdoe@t:marketing:MKT 

If you are using an upper middleware product such as ODBC, you define the SQL*Net 1 address to the ODBC administrator and then use the ODBC alias when you reference the data source

Page 1263

in your applications. Basically, your job is talking to ODBC. ODBC then is responsible for routing your request to the appropriate database.

SQL*Net 2

If you understand the basic concepts of SQL*Net 1, you are well on your way to understanding SQL*Net 2. SQL*Net 2 is not really a revolution in the concept of how Oracle networks its products. It still interfaces directly with SQL*Plus and all the other Oracle tools (you do not even have to change any configuration files on those development products). It still interfaces to ODBC and OLE. The main differences between version 1 and version 2 follow:

• In SQL*Net 2, the DBA has to prepare a series of files that contain all the connection information for the various data sources available. These data files associate a simple alias (such as main_sales) with all the information, such as the SID, host computer, protocol to use for communication, and so on. All the users have to worry about, after they get copies of these files from the administrator on their computers, is what the aliases are and what information is stored in each of these databases.
• SQL*Net 2 can interface with a feature of the Oracle7 Server known as the multithreaded server. In SQL*Net 1, you allocate a dedicated process for each user who connects to Oracle via SQL*Net. This process stays open until the user disconnects, which could be the end of the day for some users. This can become a problem when you have a large number of users accessing a system where they might be connected to their application all day even though they are not actively working with the database. The multithreaded server concept enables the SQL*Net users to share a series of server processes, with each user accessing the server process only when he has an active query or transaction.
• The later versions of SQL*Net 2 (2.2 and later) are much better at detecting when users are disconnected from Oracle without issuing a proper command to disconnect (for example, if they get bored and press Ctrl+Alt+Delete in the middle of a long query). Under SQL*Net 1, this can cause a shadow process to hang around, which eats up large amounts of processor time (these processes run away and can take up the entire CPU). SQL*Net 2 has some time-out parameters that enable you to eliminate this problem.
• The names of the controlling processes are different for each of the two versions of SQL*Net, so you easily can tell which version is running.
• You really should use the Oracle network management tools to create the configuration files. You can edit the aliases in the old SQL*Net 1 files if you are ambitious (the default remote connection, and so on). Unless you are really sure of what you are doing, though, use the Oracle utilities to make your network configuration files. These files are somewhat complex in syntax, and the names of the fields are not always obvious.

Previous Table of Contents Next