10
Troubleshooting Net8

Net8 provides methods for understanding and resolving network problems through the use of log and trace files. These files keep track of the interaction between network components as errors occur. Evaluating this information will help you to diagnose and troubleshoot even the most complex network problems.

This chapter describes common network errors and outlines procedures for resolving them. It also describes methods for logging and tracing error information to diagnose and troubleshoot more complex network problems. This chapter contains the following sections:

• Section 10.1, "Troubleshooting Common Network Errors"
• Section 10.2, "Troubleshooting Network Problems Using Log and Trace Files"
• Section 10.3, "Logging Error Information"
• Section 10.4, "Tracing Error Information"
• Section 10.5, "Contacting Oracle Customer Support"

10.1 Troubleshooting Common Network Errors

Due to the complexity of network communications, network errors may originate from a variety of sources, for a variety of reasons. If an error occurs, applications such as SQL*Plus and SQL*Forms, which depend on network services from Net8, will normally generate an error message.

A list of the most common network error messages follows:

• ORA-12154 ``TNS:could not resolve service name"
• ORA-12198 ``TNS:could not find path to destination"
• ORA-12203 ``TNS:unable to connect to destination"
• ORA-12224 ``TNS:no listener"
• ORA-12500 ``TNS:listener failed to start a dedicated server process"
• ORA-12533 ``TNS:illegal ADDRESS parameters"
• ORA-12545 ``TNS:name lookup failure"
• ORA-12560 ``TNS:protocol adapter error"
• ORA- 3113 ``TNS:End-of-file on communication channel"

Table 10-1 Common Network Errors and Troubleshooting Procedures

10.2 Troubleshooting Network Problems Using Log and Trace Files

Oracle Network Products provide detailed information about the source and context of problems as they arise. This information is generated and stored in log and trace files. The process of logging and tracing error information will help you to diagnose and resolve network problems.

10.3 Logging Error Information

Logging refers to the process by which network components note and append error-specific information to a log file. Each Net8 component produces its own log file to describe the state of the software at various communication layers as an error occurs. To ensure that all errors are recorded, logging cannot be disabled on clients or Names Servers. Furthermore, only an administrator may replace or erase log files. The log file for the listener also includes Audit Trail information about every client connection request, as well as most listener control commands.

10.3.1 Error Stacks

Log files provide information contained in an error stack. An error stack refers to the information that is produced by each layer in an Oracle communications stack as the result of a network error.

Figure 10-1 depicts the relationship among Oracle network products as they might appear in an error stack:

Figure 10-1 Network Products and Error Stack Component

The layers in Figure 8-1 are as follows:

Your network may or may not include all of these components.

Error Example

As an example, suppose that a user of a client application tries to establish a connection with a database server using Net8 and TCP/IP, and the user enters:

sqlplus scott/tiger@hrserver.world 

The SQL*Plus banner is displayed on the screen, and the following error is displayed:

ORA-12203: TNS:Unable to connect to destination

This message indicates that the connection to the server failed because the database could not be contacted. Although the application displays only a one-line error message, an error stack that is much more informative is recorded in the log file by the network layer. On the client-side, a log file called SQLNET.LOG, contains an error stack corresponding to the ORA-12203 error as follows:

Example 10-1 Typical Error Stack

***********************************************************

Fatal OSN connect error 12203, connecting to:
 (DESCRIPTION=(CONNECT_DATA=(SID=trace)(CID=(PROGRAM=)
   (HOST=lala)(USER=sviavant)))(ADDRESS_LIST=(ADDRESS=
   (PROTOCOL=ipc)(KEY=trace))(ADDRESS=(PROTOCOL=tcp)
   (HOST=lala)(PORT=1521))))

VERSION INFORMATION:
TNS for SunOS:
Oracle Bequeath NT Protocol Adapter for SunOS:
Unix Domain Socket IPC NT Protocol Adaptor for SunOS: 
TCP/IP NT Protocol Adapter for SunOS:
  Tracing to file: /home/sviavant/trace_admin.trc
  Tns error struct:
    nr err code: 12203
    TNS-12203: TNS:unable to connect to destination
    ns main err code: 12541
    TNS-12541: TNS:no listener
    ns secondary err code: 12560
    nt main err code: 511
    TNS-00511: No listener
    nt secondary err code: 61
    nt OS err code: 0

10.3.2 Log Filenames

Each Net8 component produces its own log file. Table 10-2 provides the default filenames and a description of the information they contain:

Table 10-2 Log File Component Information

10.3.3 Setting Log Parameters

Parameters that control logging, including the type and amount of information logged, as well as the location where the files are stored, are set in the configuration file of each network component as follows:

Table 10-3 Setting Log Parameters

Although there are operating system specific default names and locations for the log files, you can specify alternative names and locations if you wish. Each component may have log parameters that determine the following:

• the log file name (optional)
• the log file directory (optional)

10.3.3.1 Changing Log File Names

To change log file names, edit the following parameter in the appropriate component configuration file:

LOG_FILE_component = string 

For example, the following parameter in your listener configuration file would send listener log output to a file called TEST.LOG on the server machine.

LOG_FILE_LISTENER = TEST






Note::



On most operating systems, the .log suffix is automatically appended to the log filename. For a full description of configuration parameters, refer to Appendix  B, "Configuration Parameters". Some platforms have restrictions on the properties of a filename. See your Oracle operating system-specific documentation for platform-specific restrictions.

  

10.3.3.2 Changing Log File Directories

To change the location of where the log file for each component is stored, edit the following parameter in the appropriate component configuration file:

LOG_DIRECTORY_component = valid directory

Examples are specific to different operating systems. An example on UNIX might be:

LOG_DIRECTORY_LISTENER = /tmp/log 

Some platforms have restrictions on the properties of a directory. For more information about platform-specific restrictions, refer to your Oracle operating system-specific documentation.

10.3.4 Using Log Files

To use a log file to diagnose a network error:

1. Review the log file for the most recent error number you received from the application. Note that this is almost always the last entry in the log file.
2. Starting from the bottom of the file, locate the first non-zero entry in the error report. This is usually the actual cause.
3. If that error does not provide the desired information, review the next error in the stack until you locate the correct error information.
4. If the cause of the error is still not clear, turn on tracing and re-execute the statement that produced the error message.

10.3.5 Listener's Log Audit Trail

The listener log file contains Audit Trail information that allows you to gather and analyze network usage statistics, as well as information indicating the following:

• a client connection request
• a start, stop, status, reload or service command issued by the Listener Control Utility

Note that you cannot turn this feature off.

10.3.5.1 Format of the Listener's Log Audit Trail

The Audit Trail formats text into the following fields: Timestamp, Connect Data, [Protocol Info], event, [sid], return Code. Properties of the Audit Trail are as follows:

• Each field is delimited by an asterisk (*)
• PROTOCOL INFO and SID appear only when a connection is attempted
• A successful connection or command returns a code of 0
• A failure produces a code that maps to an error message

Typical output to the log file upon a reload request is as follows:

Example 10-2 Typical Audit Trail Information for Successful Reload Request

10-MAY-96 14:16:21 *(CONNECT_DATA=(CID=(PROGRAM=)(HOST=roach)(USER=reltest)
(COMMAND=reload)(ARGUMENTS=64)(SERVICE=LISTENER)
(VERSION=36704256))*reload*0

Typical output to the log file upon a connection request is as follows:

Example 10-3 Typical Audit Trail Information for Successful Connection Request

10-MAY-96 14:16:21*(CONNECT_DATA=(SID=reltest)(CID=
(PROGRAM=C:\ORAWIN\BIN\PLUS31.EXE)
(HOST=WINDOWSPC)(USER=CCLOW))*(ADDRESS=(PROTOCOL=tcp)
(HOST=144.25.23.246)(PORT=3366))
*establish*reltest*0

Notice that the user ID is recorded as well as the platform, protocol, and software used to make the connection.

10.3.5.2 Using Audit Trail Information

You can use Audit Trail information to view trends and user activity by first storing it in a table and then collating it into a report format. To import the data into a table, use an import utility such as SQL*Loader.

10.4 Tracing Error Information

The trace facility produces a detailed sequence of statements that describe network events as they are executed. "Tracing" an operation allows you to obtain more information on the internal operations of the components of Net8 than is provided in a log file. This information is output to files that can be evaluated to identify the events that led to an error.

Components that can be traced using the trace facility are:

• Network listener
• Net8 components on the client and server
• Oracle Connection Manager components
• Oracle Names Server
• Oracle Names Control Utility
• TNSPING utility

10.4.1 Setting Tracing Parameters

To enable tracing as well as to set specific trace parameters, you may use either:

• component configuration files
• component control utilities
• Oracle Trace

10.4.1.1 Setting Trace Parameters Using Component Configuration Files

To set tracing parameters using component configuration files:

1. Specify the following parameters in the component configuration file:

   TRACE_LEVEL_component name=(OFF/USER/ADMIN/SUPPORT)
   TRACE_DIRECTORY_component name=directory name
   
   

2. If you modified the configuration files while the component was running, start or restart the component to enable the changed parameters.

10.4.1.2 Setting Trace Parameters Using Component Control Utilities

To set trace parameters using component control utilities:

• For the listener, use the TRACE command from the Listener Control Utility, to set the trace level while the listener is running;
• For Oracle Names, use the SET TRACE_LEVEL command from the Names Server Control Utility, to set the trace level while the Names Server is running.

  Note:: For Oracle Connection Manager, the trace level can only be set from the Connection Manager configuration file.

10.4.1.3 Setting Trace Parameters Using Oracle Trace

Oracle Trace is a new tool that can be used with Oracle Enterprise Manager or stand alone enabling you to format and correlate data from two different trace files. Use Oracle Trace in situations where you will need to compare and/or correlate the trace information produced individually by Net8 and the server, or by Net8 as it interacts between the client and server. For more information on enabling Oracle Trace, refer to the Net8 Release Notes.

10.4.2 Evaluating Net8 Traces

Evaluating trace files either manually, or by using the Trace Assistant tool will help you to diagnose and troubleshoot network problems by giving you a better understanding of the following:

• the flow of packets between network nodes
• which component of Net8 is failing
• pertinent error codes

10.4.2.1 Understanding the Flow of Data Packets Between Network Nodes

Net8 performs its functions by sending and receiving data packets.By specifying a trace level of SUPPORT, you can view the actual contents of the Net8 packet in your trace file. The order of the packet types sent and received will help you to determine how your connection was established.

10.4.2.1.1 Understanding Data Packet Formats

Each line in the trace file begins with a procedure followed by a message. Following each procedure is a line of hexadecimal data representing actual data. The actual data that flows inside the packet is sometimes viewable to the right of the hexadecimal data.

Table 10-4 provides a list of the Net8 packet keywords and describes the types of packets they represent:

Table 10-4 Keyword and Packet Types

For example, the following line describes a procedure called "nscon" sending a NSPTCN packet over the network:

nscon: sending NSPTCN packet

Each packet has a keyword that denotes the packet type. All packet types begin with the prefix "NSP". It is helpful to remember this when reviewing trace files for specific packet information

Example 10-4 provides typical packet information:

Example 10-4 Packet Information

nscon: entry
nscon: doing connect handshake...
nscon: sending NSPTCN packet
nspsend: entry
nspsend: plen=187, type=1
nspsend: 187 bytes to transport
nspsend:packet dump
nspsend:00 BB 00 00 01 00 00 00  |........|
nspsend:01 33 01 2C 0C 01 08 00  |.3.,....|
nspsend:7F FF 7F 08 00 00 00 01  |........|
nspsend:00 99 00 22 00 00 08 00  |..."....|
nspsend:01 01 28 44 45 53 43 52  |..(DESCR|
nspsend:49 50 54 49 4F 4E 3D 28  |IPTION=(|
nspsend:43 4F 4E 4E 45 43 54 5F  |CONNECT_|
nspsend:44 41 54 41 3D 28 53 49  |DATA=(SI|
nspsend:44 3D 61 70 33 34 37 64  |D=ap347d|
nspsend:62 31 29 28 43 49 44 3D  |b1)(CID=|
nspsend:28 50 52 4F 47 52 41 4D  |(PROGRAM|
nspsend:3D 29 28 48 4F 53 54 3D  |=)(HOST=|
nspsend:61 70 32 30 37 73 75 6E  |ap207sun|
nspsend:29 28 55 53 45 52 3D 6D  |)(USER=m|
nspsend:77 61 72 72 65 6E 29 29  |warren))|
nspsend:29 28 41 44 44 52 45 53  |)(ADDRES|
nspsend:53 5F 4C 49 53 54 3D 28  |S_LIST=(|
nspsend:41 44 44 52 45 53 53 3D  |ADDRESS=|
nspsend:28 50 52 4F 54 4F 43 4F  |(PROTOCO|
nspsend:4C 3D 74 63 70 29 28 48  |L=tcp)(H|
nspsend:4F 53 54 3D 61 70 33 34  |OST=ap34|
nspsend:37 73 75 6E 29 28 50 4F  |7sun)(PO|
nspsend:52 54 3D 31 35 32 31 29  |RT=1521)|
nspsend:29 29 29 00 00 00 00 00  |))).....|
nspsend: normal exit
nscon: exit (0)

10.4.2.2 Understanding Pertinent Error Output

Every time a problem occurs with the connection in Net8, the error code is logged in the trace file with the prefix of <ERROR> or <FATAL>. Example 10-5 depicts typical trace file error output.

Example 10-5 Trace File Error Output

nspsend: entry
nspsend: plen=244, type=6
ntpwr: entry
ntpwr: exit
-<ERROR>- nspsend: transport write error
nspsend: error exit
nserror: entry
-<ERROR>- nserror: nsres: id=0, op=65, ns=12541, ns2=12560; nt[0]=511, 
nt[1]=61,nt[2]=0
-<ERROR>- nsopen: unable to open transport
nricdt: Call failed...
nricdt: exit
-<ERROR>- osnqper:  error from nricall
-<ERROR>- osnqper:  nr err code: 12203
-<ERROR>- osnqper:  ns main err code: 12541
-<ERROR>- osnqper:  ns (2)  err code: 12560
-<ERROR>- osnqper:  nt main err code: 511
-<ERROR>- osnqper:  nt (2)  err code: 61
-<ERROR>- osnqper:  nt OS   err code: 0
osnqme: entry
osnqme:  reporting nr (1) error: (12203) as rdbms err (12203)
osnqme: exit
-<ERROR>- onstns: Couldn't connect, returning 12203
nricall: Exiting NRICALL with following termination result -1
nricall: exit
osnqme: entry
osnqme:  reporting nr (1) error: (12203) as rdbms err (12203)
osnqme: exit
-<ERROR>- onstns: Couldn't connect, returning 12203
-<ERROR>- osnqper:  error from nricall

The most efficient way to evaluate error codes is to find the most recent NS error code logged. This is because the session layer controls the connection. The most important error messages are the ones at the bottom of the file. They are the most recent errors and the source of the problem with your connection.

For information about the specific return codes, use the Oracle UNIX error tool "oerr". Use the "oerr" tool to discover more information about Net8 return codes, by entering the following at any command line prompt:

oerr tns error_number

10.4.3 Using the Trace Assistant to Examine Your Trace Files

Net8 provides a tool called the Trace Assistant to help you understand the information provided in your trace files by converting existing lines of trace file text into a more readable paragraph. Note that the Trace Assistant runs against only a level 16 (SUPPORT) SQL*Net or Net8 trace file.

To run the Trace Assistant, type the following at any command line prompt:

trcasst [options] filename

Table 10-5 describes the options that are available.

Table 10-5 Trace Assistant Text Formatting Options

Example 10-6 depicts how Trace Assistant converts trace file information into a more readable format.

Example 10-6 Typical Trace Assistant Conversion

nsc2addr: normal exit
nsopen: entry
nsmal: 404 bytes at 
0x10d5a48
nsopen: opening 
transport...
-<ERROR>- ntus2err: 
sd=13, op=1, 
resnt[0]=511, resnt[1]=2, 
resnt[2]=0
-<ERROR>- nserror: nsres: 
id=0, op=65, ns=12541, 
ns2=12560; nt[0]=511, 
nt[1]=2, nt[2]=0
-<ERROR>- nsopen: unable 
to open transport

However, other errors may also exist within the trace file that were not logged from the nserror function.

10.4.3.1 Understanding Information Traversing the Network in Net8 Packets

Trace Assistant also allows you to view data packets from both the Net8 and Two Task Common communication layers. Trace Assistant offers you two options to view these packets:

• summary connectivity (using option -oc)
• detailed connectivity (using option -od) Net8 Packet Examples
  

The following examples depict how Trace Assistant presents various packets as they are sent to and from the Net8 layer in a variety of transactions:

• bequeathed connection
• redirected connection
• data packet

Note that the packets being sent or received have a prefix of "---> Send nnn bytes" or "<--- Received nnn bytes" showing that this node is sending or receiving a packet of a certain type and with nnn number of bytes. This prefix enables you to determine if the node is the client or the server. The connection request is always sent by the client, but received by the server (or listener).

Example 10-7 Summary Data Packets Sent in a Bequeathed Connection

--->  Send     192 bytes - Connect packet
        Connect data length: 142
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=dlsun)(Port=1521))(CONNECT_DATA=(SID=db1)(CID=(PROGRAM=)(HO
ST=dlsun)(USER=use1))))
<---  Received 24 bytes - Accept packet
        Accept data length: 0

Example 10-8 Detailed Data Packets Sent in a Bequeathed Connection

--->  Send     50 bytes - Connect packet
Current NS version number is: 309.
Lowest NS version number can accommodate is: 300.
Global options for the connection:
        can receive attention
        no attention processing
        Don't care
        Maximum SDU size: 2048
        Maximum TDU size: 5120
        NT protocol characteristics:
                Test for more data
                Spawner is running
                Hang on to Listener connection
                Full duplex I/O
                Urgent data support
                Generate SIGURG signal
                Handoff connection to another
        Line turnaround value: 0
        Connect data length: 234
        Connect data offset: 50
        Connect data maximum size: 2048
                Native Services wanted
                Native Services wanted
Cross facility item 1: 0
        Cross facility item 2: 0
        Connection id: Ox0000000000000000
        Packet data is in the following data packet
--->  Send     244 bytes - Data packet
(DESCRIPTION=(ADDRESS=(PROTOCOL=beq)(PROGRAM=/private/oracle/bin/
oracle)(ARGV0=oracle)(ARGS='(DESCRIPTION=(LOCAL=YES) 
(ADDRESS=(PROTOCOL=beq))))(DETACH=NO))(CONNECT_DATA=(CID=(PROGRAM=)(HOST=dlsun)(USER=use1))))
<---  Received 24 bytes - Accept packet
        Accepted NS version number is: 307.
Global options for the connection:
        no attention processing
        Don't care
        Accepted maximum SDU size: 2048
        Accepted maximum TDU size: 4096
        Connect data length: 0
                Native Services wanted
                Native Services wanted

Example 10-9 Summary Data Packets Sent in a Redirected Connection

--->  Send     187 bytes - Connect packet
        Connect data length: 153
(DESCRIPTION=(CONNECT_DATA=(SID=ap347db1)(CID=(PROGRAM=)(HOST=apsun)(USER=use2)))(ADDRESS_LIST=(ADDRE
SS=(PROTOCOL=tcp)(HOST=apsun)(PORT=1521))))
<---  Received 8 bytes - Resend packet
--->  Send     187 bytes - Connect packet
        Connect data length: 153
(DESCRIPTION=(CONNECT_DATA=(SID=apdb1)(CID=(PROGRAM=)(HOST=apsun)(USER=use2)))(ADDRESS_LIST=(ADDRESS=
(PROTOCOL=tcp)(HOST=apsun)(PORT=1521))))
<---  Received 24 bytes - Accept packet
        Accept data length: 0

Example 10-10 Data Packet

--->  Send     30 bytes - Data packet
<---  Received 201 bytes - Data packet
--->  Send     439 bytes - Data packet
<---  Received 400 bytes - Data packet

Two Task Common Packet Examples

Two-Task Common handles requests such as open cursor, select rows, and update rows that are directed to the database. All requests are answered by the server. If you request to logon, a response is returned from the database that the request was completed. Example 10-11 and Example 10-12 show the type of information you can expect.

Summary information for Two-Task Common is different from other displays in that it shows two packets on each line, rather than one. This is done to mirror the request/response pairings process by which Two-Task Common operates.

Example 10-11 Two Task Common Summary Information

(O3LOGA)

1st half of challenge-response logon

80

78

(O3LOGON) 

2nd half of challenge-response logon

97

59 

(OOPEN)

# 1 

21

16

(OPARSEX)

# 1 

245

 59

(OCLOSE) 

# 1 

17

11

(OVERSION)

29

16

(OOPEN) 

# 2

 21

16

(OALL7) 

# 2 Parse Can Defn=2 Exec Fetch "SELECT A.V

268

100

(OOPEN) 

# 3 

21

16

(OALL7) 

# 3 Parse Exec=1 "SELECT USER FROM SYS.DUAL

152

70

(OALL7) 

# 3 Defn=1 Fetc

117

88

(OCLOSE)

# 3

17

11

Example 10-12 Two Task Common Summary Information

start of user function (TTIFUN)
        1st half of challenge-response logon (O3LOGA)
          Username: applsys
          Terminal: ttyp5
          Machine: ap207sun
          System User: mwarren
          Process: 24459
          Program: aiap45@ap207sun (TNS interface)
return opi parameter (TTIRPA)
        OPI parameter: 3309B1A977A62A3C
start of user function (TTIFUN)
        2nd half of challenge-response logon (O3LOGON)
          Username: applsys
          Terminal: ttyp5
          Machine: ap207sun
          System User: mwarren
          Process: 24459
          Program: aiap45@ap207sun (TNS interface)
ORACLE function complete (TTIOER)
start of user function (TTIFUN)
        Open a cursor
return opi parameter (TTIRPA)
        Cursor #: 1
start of user function (TTIFUN)
        Parse and Execute (OPARSEX) Cursor # 1 
alter session set nls_language= `AMERICAN' nls_territory= `AMERICA' nls_currency= `$' 
nls_iso_currency= `AMERICA' nls_numeric_characters= `.,' nls_date_format= `DD-MON-YY' 
nls_date_language= `AMERICAN' nls_sort= `BINARY'
ORACLE function complete (TTIOER)
start of user function (TTIFUN)
        Close cursor (OCLOSE) Cursor # 1 
V6 Oracle func complete (TTISTA)
        Succeeded

Example 10-13 Detailed SQL information on top of summary Two-Task

(O3LOGA)

1st half of challenge-response logon

180

78

(O3LOGON) 

2nd half of challenge-response logon

197

59 

(OOPEN)

# 1 

21

16

(OPARSEX)

# 1 alter session set nls_language= `AMERICAN' 
nls_territory= `AMERICA' nls_currency= `$' 
nls_iso_currency= `AMERICA' nls_numeric_characters= 
`.,' nls_date_format= `DD-MON-YY' nls_date_language= 
`AMERICAN' nls_sort= `BINARY'

245

 59

(OCLOSE) 

# 1 

17

11

(O71SESOPN)

(get session ID) 

47

18    

(OOPEN)

# 1

21 

16   

(OVERSION)

Oracle7 Server Release 7.1.4.1.0 - Production 
Release with the distributed and parallel query 
optionsPL/SQL Release 2.1.4.0.0 - Production

29

157

(O71SESOPN)

(get session ID) 

47

18

10.4.3.2 Analyze the Data Collected into Appropriate Statistics

The type of statistics gathered is on the order of how many calls (TTC), packets and bytes were sent and received between the network partners. The following example depicts typical trace file statistics:

Example 10-14 Typical Trace File Statistics

======================================================================
     Trace File Statistics: 
    ----------------------------------------------------------------------
     SQL*Net:
          Total Calls:       466 sent,       491 received,       423 upi
          Total Bytes:    119214 sent,     86614 received
        Average Bytes:       255 sent,       176 received
        Maximum Bytes:      2048 sent,      2048 received 
     GRAND TOTAL PACKETS  sent:    466     received:    491

10.4.3.3 Example of a Trace File

The following example shows a full trace file decoded. This example was created using the Oracle client tool SVRMGRL with the request:

connect scott/tiger@june

The message ORA-12154: TNS:could not resolve service name was displayed on the screen.

Example 10-15 Trace File Example

-- TRACE CONFIGURATION INFORMATION FOLLOWS ---
New trace stream is "C:\ORAWIN\network\trace\sqlnet7.trc"
New trace level is 16
--- TRACE CONFIGURATION INFORMATION ENDS ---

nnfotran: tnsname.ora entry for name "june.world" not found
nnftqnm: Error querying june.world of attribute A.SMD 
errcode 406
nnfgrwsp: Query unsuccessful, skipping to next adapter

nnfgrwsp: Switching to ONAMES adapter
nnfgrwsp: Original name: june
nnfgrwsp: Qualified name: june.world
nngsget_get_stream: looking for 
"(DESCRIPTION=(CONNECT_DATA=(RPC=ON))(ADDRESS=(PROTOCOL=tcp)(
HOST=oranamesrvr0)(PORT=1575)))"
nngsget_get_stream: cache miss, opening new stream
nngsnad_new_stream_addr: "(DESCRIP 
TION=(CONNECT_DATA=(RPC=ON))(ADDRESS=(PROTOCOL
=tcp)(HOST=oranamesrvr0)(PORT=1575)))"
nngsget_get_stream: no caller address will be sent to callee

nricall: entry
nric2a: entry
nric2a: Getting local community information
nriglp: entry
nriglp: Looking for local addresses setup by nrigla
nriglp: No addresses in the preferred address list
nriglp: exit
nric2a: TNSNAV.ORA is not present. No local communities 
entry.
nrigla: entry
nrigla: Getting local address information
nrigla: Simple address...
nrigla: No community component so just use straight address
nrigla: exit
nridst: entry
nridst: Resolving address to use to call destination or next 
hop
nridst: Found destination address
nridst: Local address
nridst: Local destination community found
nridst: exit
nric2a: This is a local community access
nric2a: exit
nricall: Got routable address information

nricall: Making call with following address information: 
(DESCRIPTION=(CONNECT_DATA=(RPC=ON))(ADDRESS=(PROTOCOL=tcp)(H
OST=oranamesrvr0)(PORT=1575)))
nricdt: entry
nricdt: Calling with outgoing connect data 
(DESCRIPTION=(CONNECT_DATA=(RPC=ON))(ADDRESS=(PROTOCOL=tcp)(H
OST=oranamesrvr0)(PORT=1575)))

nscall: entry
nscall: connecting...
nsc2addr: entry
nsc2addr: 
(DESCRIPTION=(CONNECT_DATA=(RPC=ON))(ADDRESS=(PROTOCOL=tcp)(H
OST=oranamesrvr0)(PORT=1575)))

nttbnd2addr: entry
nttbnd2addr: port resolved to 1575
nttbnd2addr: looking up IP addr for host: oranamesrvr0
nttbnd2addr: exitnsopen: entry
nsmal: entry
nsmal: 330 bytes at 0x30d76e74
nsmal: normal exit
nsopen: opening transport...
nttcon: entry
nttcon: toc = 1
nttcnp: entry
nttcnp: creating a socket.
nttcnp: exit
nttcni: entry
nttcni: trying to connect to socket 1.
ntt2err: entry

-<ERROR>- ntt2err: soc 1 error - operation=1, 
ntresnt[0]=511, ntresnt[1]=61 ntresnt[2]=0
ntt2err: exit
nttcni: exit
nttcon: exit
nserror: entry

  -<ERROR>- nserror: nsres: id=0, op=65, ns=12541, ns2=12560; 
nt[0]=511, nt[1]=61,nt[2]=0
-<ERROR>- nsopen: unable to open transport

nsmfr: entry
nsmfr: 330 bytes at 0x30d76e74
nsmfr: normal exit
nsopen: error exit
nscall: error exit
nricdt: Call failed...
nricfg: entry
nricfg: exit
nricdt: Call made to destination
nricdt: exit

nricall: Failed to copy originating community name value 
binding
nricall: Exiting NRICALL with following termination result -1
nricall: exit
nngsfad_free_stream_addr: 
"(DESCRIPTION=(CONNECT_DATA=(RPC=ON))(ADDRESS=(PROTOCOL=tcp)(
HOST=oranamesrvr0)(PORT=1575)))"
-<ERROR>- nngsget_get_stream: open failure, error stack 
follows

TNS-12224: TNS:no listener
TNS-12541: TNS:no listener
TNS-12560: TNS:protocol adapter error
TNS-00511: No listener
nnfgrwsp: Query unsuccessful, skipping to next adapter

nnfun2a: address for name "june" not found
nngsfad_free_stream_addr: "(DESCRIPTION = (CONNECT_DATA= 
(RPC=ON)) (ADDRESS=(PROTOCL=tcp) (HOST=oranamesrvr0) 
(PORT=1575)))"
nngtdei_deinit_msg: free message pool block
nngtfms_free_msg: message ID -10429
nngtfms_free_msg: message was a request
nngtfms_free_msg: message free, type 100
nngtfoa_free_objarr: free message object array
nngtfmt_free_msg_type: type-specific message free, type 100
nngtfoa_free_objarr: free message object array
nngtfms_free_msg: message ID 0
nngtfms_free_msg: message was a response
nngtfms_free_msg: message free, type 0
nngsdei_deinit_streams: deinit
nngscls_close_stream: UID 11 not established, ignored
nngscls_close_stream: UID 0 not established, ignored
osnqrn: Return code from nnfsn2a is 409

-<ERROR>- onstns: Couldn't connect, returning 12154
onstns: exit
osnqtg: Count in the OSN global area is now 0
rigbd: entry
nrigbd: exit
osnqtg: Count in the NL global area is now 0

Trace File Example Summary

This trace file provides a summary of what occurs with Net8 when you encounter the error "Could not resolve service name". In this example, a client is unsuccessful in making a connection to service name "june". This is because a "names.default_domain = world" parameter exists in the profile. This parameter adds the ".world" extension to all service names requested, including the service name "june". Unfortunately, this service name is defined in neither the client's local naming configuration file, nor a Names Server. To troubleshoot this problem, the user should:

• edit the profile to remove the NAMES.DEFAULT_DOMAIN configuration parameter; or
• request a connection to "june.world" instead of "june"

10.5 Contacting Oracle Customer Support

If you are still unable to resolve your problems or if you are requested to contact Oracle Customer Support to report the error, please have the following information at hand:

• The hardware, operating system, and release number of the operating system on which your application(s) is running.

  Example: "My client application runs on a Sun workstation running SUN OS4.1.3 and the server application runs on a VAX machine running VMS version 5.4. The protocol is TCP/IP."

• The release numbers of all the Oracle networking products involved in the current problem.
• If you encountered one or more error codes or messages, the exact code numbers and message texts in the order they appeared.
• The problem severity according to the following codes:

  1 = Program not usable. Critical impact on operations.

  2 = Program usable. Operations severely restricted.

  3 = Program usable with limited functions. Not critical to overall operations.

  4 = Problem circumvented by customer. Minimal effect, if any, on operations.

• A description of the problem, including any unusual conditions.
• You will also be expected to provide your:
  • name
  • company's name
  • company's Oracle customer support ID (CSI) number
  • phone number