Page 470
NOTE |
Step 6a does not actually create a database. It only defines it within the SQL*Net environment.n |
After generation has completed, the configuration files for the Oracle network will be in the directory you specified in the last step above. A directory exists with the name you gave the network file. Within this directory will be subdirectories for each Node in the network, as well as for each community. The community directory will contain the files necessary for clients, and the server directories will contain the server configuration files. Transfer these files to the appropriate directories on the server or clients, and test your network configuration. Assuming all parameters were entered correctly, your networking configuration is complete.
When a change is made to the network configuration, it will be necessary to regenerate and distribute all of the configuration files for each server. While time-consuming, the benefits you realize from maintaining the entire network configuration in one central location are great.
NOTE |
Network Manager and Net8 Assistant store the options found in the sqlnet.ora file in the Profile object. Edit the Profile for the Community to modify the sqlnet.ora parameters.n |
Creating a network configuration using Net8 Assistant is very similar to doing so with the Network Manager. The biggest difference is the look and feel of the utility itself. Terminology and configuration is for the most part identical, with the addition of configuration for Net8 resources and options. The new configuration options available in Net8 are detailed in the following section, "Exploring the New Net8 Parameters."
One of the most noticeable differences between Net8 and SQL*Net V2 are the new configuration parameters available. The following is a list of the new parameters you should be aware of (most of these parameters can be configured in the Profile editor in the Net8 Assistant, or by hand by editing the sqlnet.ora file):
Page 471
DISABLE_OOBDisable out-of-bound breaks if transport protocol doesn't support a feature. Out-of-bound breaks are what allows you to cancel a long-running query or job by pressing Ctrl+C (or the Cancel button), by sending a control command that does not wait for completion of the current command, but executes immediately (in other words, an out-of-bound command).
SQLNET.EXPIRE_TIMEOUTIn earlier versions of SQL*Net, this defaulted to an extremely high number of seconds. When calculated, it measures in years. It is recommended that this value be reduced to a more manageable number, such as 10. This does not mean that if the connection is idle for 10 seconds, it will be disconnected, but rather when the connection dies it spins off on its own. This is the number of seconds the process will stay active prior to being killed. DBAs that have had to deal with locks left over from these "ghost" processes will appreciate the effects of this setting.
LOG_FILE_CLIENTThe log file will be written on the client to this filename. The file will be placed in the directory specified in TRACE_DIRECTORY_CLIENT. Logging is automatic in Oracle and cannot be turned off. It tracks the errors that occur on the client. This is a good place to go when evaluating errors. When not specified, the default filename is SQLNET.LOG. This file should be periodically purged; however, this should be done while the client is quiet so that the logging facility will find the file if an error occurs.
LOG_DIRECTORY_CLIENTThis is the directory location for logging files on the client.
TRACE_LEVEL_CLIENTIn version 7.3 and below, in order to get a full trace, the trace level would have to be set to the undocumented level 16. In version 8, Oracle has renamed this level to "support." Keep in mind that this is a very robust trace level and should not be used unless requested by support, or extremely well versed in network trace files. Normally, the trace levels of "user" or "admin" are sufficient. Naturally, a performance hit will be taken when tracing is enabled.
TRACE_FILE_CLIENTThe trace file will be written on the client to this filename. The file will be placed in the directory specified in the TRACE_DIRECTORY_CLIENT.
TRACE_DIRECTORY_CLIENTThis is the directory location for logging files on the client.
TNSPING.TRACE_LEVELThis is the level for the tnsping. It can be the following values: OFF, USER, ADMIN.
TNSPING.TRACE_DIRECTORYThis is the directory location for the tnsping trace.
One of the most important components of your Oracle Network configuration is the Oracle Listener. The Listener is the program that services the requests by programs to connect to remote databases. It "listens" at a specific port on the database server, and connects incoming connections with server sessions on the database. Ensuring that your Listener runs properly is key to managing your Oracle Network environment.
Page 472
The most common way to control the Listener is by using the Listener Command Utility, LSNRCTL. This is a command line utility that allows you to perform administrative tasks against the listener. You can run LSNRCTL commands in interactive or batch mode. To run LSNRCTL interactive, issue the command with no arguments. To run LSNRCTL in batch mode, issue the LSNRCTL command with the Listener commands as arguments to the program.
All of the commands you can issue can be displayed by typing help at the LSNRCTL prompt. To start the listener, you issue the start command. For example:
$lsnrctl start [listener name]
By default, all commands will be issued against the default Listener named Listener. If you have multiple Listeners running on one Node, you will have to specify the names of the Listeners in the command. For example:
Lsnrctl start listener01
If you have defined a password for the Listener, you will not be able to change the Listener status without first issuing the password. To do this, start the LSNRCTL control program and issue the set password command. For example:
% lsnrctl LSNRCTL> set password oraclerules Command completed successfully. LSNRCTL> [perform administrative tasks] LSNRCTL> quit
To stop the listener, you use the stop command. In batch mode, this command will be issued as follows:
Lsnrctl stop [listener_name]
Again, the default Listener will be stopped, unless a Listener name is explicitly given. You can also display the status of the listener with the status command. This will display the resources this Listener is servicing, as well as the trace level, Listener start time, and so on.
There are many configuration files involved in making a successful SQL*Net connection. Unfortunately, a slight error in any of these files, on the client or server side, can result in hours of frustration resolving the issue. And pity the administrator who wastes hours of time troubleshooting network connection problems, only to find a misplaced `)' in their tnsnames.ora file. For this reason, we offer the following checklist of common problem solutions: