| All of the various Net8 facilities generate log files, or have the ability to generate log files, while they are running. These log files can provide you with all sorts of useful information. At a minimum, you can tell when a facility such as a listener has been started and stopped . By default, all Net8 log files are written to the $ORACLE_HOME /network /log directory. However, you can change that location on a facility-by-facility basis. You can also change the log filenames to something other than their defaults, if that's what you prefer. Table 10.2 lists the default log filenames that are used, and provides a brief description of each log file's contents. Table 10.2. Net8 Log Files | Facility | Default Log Filename | Description | | Net8 client and server | sqlnet.log | Records Net8 errors on clients and servers. Parameters in the sqlnet.ora file control this log file. | | Listener | listener_name.log | Records errors, connections, and other significant events while a listener is running. The listener name usually ends up being used for the log filename. Parameters in the listener.ora file control this log file. | | Oracle Names | names.log | Records significant events related to the operation of an Oracle Names server. Parameters in the names.ora file control this log file. | | Connection Manager | cmadm_pid.log cman_pid.log | Records each connection made through Connection Manager. Also records other significant events. Parameters in the cman.ora file control these log files. | Log files are always written sequentially, which means that the most recent error or event is recorded at the bottom of the file. The next few sections provide a brief example of the information that you can expect to see in each of the different log files.  | Log files should be periodically deleted so that they don't grow to consume the entire disk. | | 10.2.1 Client and Server Log Files Client and server log files record any serious Net8 errors that might occur. For example, the following entry records an internal native service error: Fatal NI connect error 12699, connecting to: (LOCAL=NO) VERSION INFORMATION: TNS for 32-bit Windows: Version 8.1.5.0.0 - Production Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version 8.1.5.0.0 - Production Windows NT TCP/IP NT Protocol Adapter for 32-bit Windows: Version 8.1.5.0.0 - Production Time: 29-MAR-00 06:55:09 Tracing not turned on. Tns error struct: nr err code: 0 ns main err code: 12699 TNS-12699: Native service internal error ns secondary err code: 0 nt main err code: 0 nt secondary err code: 0 nt OS err code: 0 Most connectivity errors do not result in log entries being written to sqlnet.ora , and our experience has been that this file is not too useful for diagnosing connectivity problems. 10.2.2 Listener Log Files Listener log files record the operation of a listener. Each listener will have its own log file, and the log filename will match the listener name. The listener is one facility where you can disable logging by placing LOGGING_ listener_name = OFF in your listener.ora file. The advantage to doing that is you'll never have to remember to delete your log file, but that comes with the disadvantage of losing all that helpful diagnostic information. We recommend that you do not disable logging unless you have a good reason to do so. 10.2.2.1 Start and stop events When you start a listener, that event will be recorded in the log. For example: TNSLSNR for Linux: Version 8.1.6.0.0 - Production on 22-AUG-2000 19:47:50 (c) Copyright 1998, 1999, Oracle Corporation. All rights reserved. System parameter file is /s01/app/oracle/product/8.1.6/network/admin/listener.ora Log messages written to /s01/app/oracle/product/8.1.6/network/log/prodlistener.log Trace information written to /s01/app/oracle/product/8.1.6/network/trace/prodlistener.trc Trace level is currently 0 Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=donna.gennick.org) (PORT=1523))) TIMESTAMP * CONNECT DATA [* PROTOCOL INFO] * EVENT [* SID] * RETURN CODE 22-AUG-2000 19:47:50 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=donna.gennick.org) (USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=prodlistener) (VERSION=135290880)) * status * 0 Quite a bit of information is given here. One important item to notice is the listener address, which is preceded by the text "Listening on:". This can sometimes be useful in diagnosing connectivity problems. Other items worth noticing are the names and locations of the listener's parameter and log and trace files. If you ever have doubts about which directory Net8 is looking in to find configuration files, check your listener log file and see where Net8 is finding listener.ora . Likewise, when you stop a listener, that event is also recorded in the log. Here's an example of the log entries written as a result of a Listener Control STOP command: 23-AUG-2000 17:04:03 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=donna.gennick.org) (USER=oracle))(COMMAND=stop)(ARGUMENTS=64)(SERVICE=prodlistener) (VERSION=135290880)) * stop * 0 No longer listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=donna.gennick. org)(PORT=1523))) 10.2.2.2 Client connections Some other entries that you'll see frequently in your listener log files are those that record client connections to a database service. Here is an example of a client connection being established: 23-AUG-2000 17:21:16 * (CONNECT_DATA=(SERVICE_NAME=donna.gennick.org)(SRVR=) (CID=(PROGRAM=)(HOST=donna.gennick.org)(USER=oracle))) * (ADDRESS=(PROTOCOL=tcp) (HOST=10.11.12.16)(PORT=2374)) * establish * donna.gennick.org * 0 Even more useful are the log entries that result when a connection attempt fails for some reason. Here is an example: 23-AUG-2000 13:43:42 * (CONNECT_DATA=(SERVICE_NAME=herman2.gennick. org)(CID=(PROGRAM=)(HOST=donna.gennick.org)(USER=oracle))) * (ADDRESS=(PROTOCOL=spx)(NET=00000000)(NODE=005004ad2db6)(SOCKET=6211)) * establish * herman2.gennick.org * 12514 TNS-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor In this case the connection failed because the service name wasn't recognized. Notice that the log entry consists of six elements delimited by asterisks (*). These are actually all on one long line, though that's not visible in the book. The last value in the log entry is 12514, which represents the error code returned by the listener to the client. Following the log entry is the contents of the error stack, which in this case consists of just one error. Table 10.3 describes each of the six fields in the log entry. Table 10.3. Listener Log Entry Fields for Connection Attempts | Field Name | Contents | Example | | Timestamp | The date and time at which the event being logged occurred. | 23-AUG-2000 13:43:42 | | Connect Data | The connect data used by the client in order to make the connection. | (CONNECT_DATA=(SERVICE_NAME=herman2. gennick.org)(CID=(PROGRAM=)(HOST=donna. gennick.org)(USER=oracle))) | | Protocol Address | The protocol address of the client making the connection. | (ADDRESS=(PROTOCOL=spx)(NET=00000000) (NODE=005004ad2db6)(SOCKET=6211)) | | Event | The name of the event that is occurring. | establish | | Service | The name of the database service, or SID, to which the client is connecting. | herman2.gennick.org | | Return Code | The status code that the listener returns to the client. A status of indicates a successful operation. Any other value represents an Oracle error code. | 12514 | This same general format described in Table 10.3 is used for other types of listener log entries. When fields are not relevant, they are omitted. 10.2.2.3 Service registration and other events Also in the listener log file, you'll see entries showing services being registered and deregistered as database instances are started and stopped. You may also see messages showing the use of tnsping to test connectivity from remote clients. Here are some examples: 23-AUG-2000 17:19:44 * service_register * donna * 0 23-AUG-2000 17:19:48 * service_update * donna * 0 ... 23-AUG-2000 17:21:17 * service_update * donna * 0 ... 23-AUG-2000 17:21:32 * service_update * donna * 0 ... 23-AUG-2000 17:50:39 * ping * 0 ... 23-AUG-2000 17:55:18 * service_died * donna * 12537 Service registration occurs when you start a new instance and it registers its services with the listener. Service updates occur periodically so that the listener knows that a service is still available. You get the "service_died" message when you stop an instance. 10.2.3 Names Server Log Files Names server log files record significant errors and events such as the starting and stopping of a Names server. If you have set a NAMES.LOG_STATS_INTERVAL of other than zero, then your Names server will periodically write statistics information to the log file. For example: 23-AUG-2000 18:04:41: NNO-00326: server statistic counter dump follows Query requests received: 0 Messages received: 6 ... Requests received: 6 Requests forwarded: 0 Foreign data items cached: 0 23-AUG-2000 18:04:41: NNO-00327: server statistic counter dump ends As with any other log file, you should periodically delete your Names server log file so that it doesn't consume too much disk. This is especially true if you are logging statistics frequently. Because you can't delete the log file that is currently being used, you may find it helpful to set NAMES.LOG_UNIQUE = TRUE in your names.ora file. That way, each time you start your Names server, you will get a different log filename, and you can periodically purge the old files. 10.2.4 Connection Manager Log Files Connection Manager actually generates two log files, one for the administrator process and one for the gateway process. The administrator log files are named cmadm_ pid.log , where pid represents the process ID. The administrator log files are relatively small and generally don't contain much helpful information. Where Connection Manager is concerned , the really useful information is in the gateway process log files. These are named cman_ pid.log , and again the pid represents a process ID number. Here you'll find a complete record of all Net8 connections made via Connection Manager. The following two log entries show a session being connected and then disconnected: (TIMESTAMP=24-AUG-2000 12:14:25) (EVENT=26)(RLYNO=0)(SRC=(ADDRESS=(PROTOCOL=tcp)(HOST=10.11.12.16) (PORT=1205)))(DST=(ADDRESS=(PROTOCOL=spx)(NET=00000000)(NODE=005004ad2db6) (SOCKET=604f)))(TNS_INFO=(SDU=2048)(GBL=0x801)(FLGO=0x49)(FLG1=0x9) (TIM0=1007)(TIM1=1157)) (TIMESTAMP=24-AUG-2000 12:14:29)(EVENT=28)(RLYNO=0)(SINCE=24-AUG-2000 12:14:25) Notice that the first entry, the one recording the connection, includes the protocol address pointing back to the client that is the source of the connection. It also includes the destination address. Table 10.4 lists the event codes that you will see in Connection Manager log files. Table 10.5 lists reason codes. Reason codes are included in the log only when a connection can't be made, and their purpose is to record the reason why the connection failed. Reason codes need to be interpreted in conjunction with a corresponding event code. Table 10.4. Connection Manager Event Codes | Event Code | Event Description | | 10 | The Connection Manager gateway is starting. | | 11 | An address list was bad. | | 12 | The Connection Manager gateway is stopping. | | 13 | A parameter list was bad. | | 14 | Connection Manager is monitoring a protocol address. | | 15 | A rule list was bad. | | 18 | An answer failed. | | 20 | An incoming connection was refused . | | 23 | A bad Connection Manager Control record was encountered . | | 25 | A command-line argument was too long. | | 26 | A connection (referred to as a relay) has been opened. | | 27 | A memory allocation failure occurred. | | 28 | A connection (referred to as a relay) has been closed. | | 29 | A TNS error occurred. | | 30 | A statistics report has been written to the log file. | | 31 | A TNS error occurred while a Connection Manager Control utility command was being processed . | | 32 | The Connection Manager parameter list has been written to the log file. | | 34 | The Connection Manager address list has been written to the log file. | | 36 | The Connection Manager rule list has been written to the log file. | | 38 | An execution of a Connection Manager Control utility command was logged. | | 40 | A Connection Manager command could not be executed because the gateway process was busy. | | 42 | A dead connection has been detected . | | 44 | A relay has timed out. | Table 10.5. Connection Manager Reason Codes | Event Code | Reason Code | Reason Description | | 18 | 1 | The operation timed out. | | | 2 | The connect data buffer was too small. | | | 3 | TNS refused an answer message. | | | 4 | A TNS packet checksum error occurred. | | 20 | 1 | The gateway was shutting down. | | | 2 | The gateway was offline. | | | 3 | No connect data was present for an incoming connection. | | | 4 | An incoming connection presented bad connection data. | | | 5 | All relays were in use. | | | 6 | No relay buffers could be obtained. | | | 7 | A fatal TNS error occurred. | | | 8 | There was no Advanced Security Option (ASO) service available. | | | 9 | A Connection Manager access control rule prevented a connection from being made. | | | 10 | An outgoing call failed. | | | 11 | A connection was refused by Net8 at the destination. | | | 12 | The destination listener was not running. | | | 13 | The destination listener was not reachable . | | | 14 | A hostname could not be resolved to an address. | | | 15 | The correct protocol adapter was not available. | | | 16 | The SOURCE_ROUTE parameter was not set in the incoming address data. | | | 17 | A connection was rejected because of a bad connect string or because of a rule violation. | Many Connection Manager Control utility commands are recorded in the Connection Manager log file. These are described in Table 10.6. However, not all commands are logged. The HELP command, for example, does not result in a log entry. As a general rule, if a command affects the actual operation of Connection Manager, it will be logged. Otherwise, it won't be. Sometimes one Connection Manager command results in more than one log entry. The following two log entries resulted from a SET command: (TIMESTAMP=25-AUG-2000 11:39:28)(EVENT=32)(PARAMETER_LIST=(MAXIMUM_ RELAYS=128)(RELAY_STATISTICS=no)(AUTHENTICATION_LEVEL=0)(LOG_LEVEL=1) (SHOW_TNS_INFO=yes)(ANSWER_TIMEOUT=0)(MAXIMUM_CONNECT_DATA=1024)(USE_ASYNC_ CALL=yes)(TRACING=no)(TRACE_DIRECTORY=default)(MAX_FREELIST_BUFFERS=0) (REMOTE_ADMIN=no)) (TIMESTAMP=25-AUG-2000 11:39:28)(EVENT=38)(COMMAND=6) The first entry, which is rather long and wraps around to five lines, shows the new parameter settings as a result of issuing the SET Command. The second log entry shows that COMMAND=6 was executed. COMMAND=6 corresponds to SET. There is not always a one-to-one correspondence between a Connection Manager command and the command codes that appear in the log file. The commands SHOW RELAY and CLOSE_RELAY both cause Connection Manager to retrieve relay information, and both consequently generate log entries for COMMAND=12. Closing a relay with the CLOSE_RELAY command actually results in two log entries with two different command codes: a COMMAND=12 (relay lookup) and a COMMAND=14 (relay close). Table 10.6. Connection Manager Command Codes | Command Code | Command | | 1 | SHUTDOWN | | 2 | STATUS (you'll always see this following a startup too, because Connection Manager Control always displays the status immediately following a START) | | 3 | STATS | | 4 | SHOW ADDRESS | | 5 | SHOW PROFILE | | 6 | SET | | 7 | SHOW RULES | | 9 | STOP or STOPNOW | | 10 | ACCEPT_CONNECTIONS OFF | | 11 | ACCEPT_CONNECTIONS ON | | 12 | SHOW_RELAY (the CLOSE_RELAY will also generate a log entry with this code) | | 14 | CLOSE_RELAY | | 
