About wait SQL*Net

Hi;
I have huge wait for SQL*Net more data from dblink,Anyone has idea why this parameters rise? And how i can decrease it?
Thanks alot

hi,
ckeck these links it might be useful for you...
[http://download.oracle.com/docs/cd/B10501_01/server.920/a96536/apa5.htm]
[http://74.125.153.132/search?q=cache:y-wXM02DSCoJ:nocoug.org/download/2006-08/unit7_sqlnet.ppt+huge+wait+for+SQL*Net+more+data+from+dblink+in+oracle&cd=1&hl=en&ct=clnk&gl=in]
regards,
Deepak

Similar Messages

Process wait SQL*Net message from dblink /SQL*Net message from client

Hi There,
We have an ETL process that we kindly need your help with. The process been running since Sun, where it transfers the data from one server (via remote query). The process was running ok till last night where it appeared
to have stopped working and/or the session is just idling doing nothing.
Here are some tests that we did to figure out what's going on:
1. when looking at the session IO, we noticed that it's not changing:
etl_user@datap> select sess_io.sid,
2         sess_io.block_gets,
3         sess_io.consistent_gets,
4         sess_io.physical_reads,
5         sess_io.block_changes,
6         sess_io.consistent_changes
7    from v$sess_io sess_io, v$session sesion
8   where sesion.sid = sess_io.sid
9     and sesion.username is not null
10     and sess_io.sid=301
11 order by 1;
                    logical   physical
SID BLOCK_GETS      reads      reads BLOCK_CHANGES CONSISTENT_CHANGES
301 388131317   97721268   26687579     223052804             161334
Elapsed: 00:00:00.012. Check there is nothing blocking the session
etl_user@datap> select * from v$lock where sid=301;
ADDR     KADDR           SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
684703F0 6847041C        301 DX         35          0          1          0      45237          0
684714C4 684714F0        301 AE     199675          0          4          0     260148          0
619651EC 6196521C        301 TM      52733          0          3          0      45241          0
67F86ACC 67F86B0C        301 TX     458763      52730          6          0      45241          03. Check if the session is still valid:
etl_user@datap> select status from v$session where sid=301;
STATUS
ACTIVE4. Check if there is anything in long ops that has not completed:
etl_user@datap> SELECT SID, SERIAL#, opname, SOFAR, TOTALWORK,
2      ROUND(SOFAR/TOTALWORK*100,2) COMPLETE, TIME_REMAINING/60
3      FROM   V$SESSION_LONGOPS
4      WHERE
5      TOTALWORK != 0
6      AND    SOFAR != TOTALWORK
7     order by 1;
no rows selected
Elapsed: 00:00:00.005. Check if there is anything in long ops for the session:
etl_user@datap> r
1* select SID,SOFAR,TOTALWORK,START_TIME,LAST_UPDATE_TIME,TIME_REMAINING,MESSAGE from V$SESSION_LONGOPS where sid=301
SID      SOFAR TOTALWORK START_TIM LAST_UPDA TIME_REMAINING MESSAGE
301          0          0 22-JUL-12 22-JUL-12                Gather Table's Index Statistics: Table address_etl : 0 out of 0 Indexes done
Elapsed: 00:00:00.00This is a bit odd!! This particular step have actually completed successfully on the 22nd of July, and we don't know why it's still showing in long opps!? any ideas?
6. Looking at the sql and what's it actually doing:
etl_user@datap> select a.sid, a.value session_cpu, c.physical_reads,
2 c.consistent_gets,d.event,
3 d.seconds_in_wait
4 from v$sesstat a,v$statname b, v$sess_io c, v$session_wait d
5 where a.sid= &p_sid_number
6 and b.name = 'CPU used by this session'
7 and a.statistic# = b.statistic#
8 and a.sid=c.sid
9 and a.sid=d.sid;
Enter value for p_sid_number: 301
old   5: where a.sid= &p_sid_number
new   5: where a.sid= 301
             CPU   physical    logical                                   seconds
SID       used      reads      reads EVENT                             waiting
301    1966595   26687579   97721268 SQL*Net message from dblink         45792
Elapsed: 00:00:00.037. We looked at the remote DB where the data resides on, and we noticed that the remote session was also waiting on the db link:
SYS@destp> select a.sid, a.value session_cpu, c.physical_reads,
2 c.consistent_gets,d.event,
3 d.seconds_in_wait
4 from v$sesstat a,v$statname b, v$sess_io c, v$session_wait d
5 where a.sid= &p_sid_number
6 and b.name = 'CPU used by this session'
7 and a.statistic# = b.statistic#
8 and a.sid=c.sid
9 and a.sid=d.sid;
Enter value for p_sid_number: 388
old   5: where a.sid= &p_sid_number
new   5: where a.sid= 390
       SID SESSION_CPU PHYSICAL_READS CONSISTENT_GETS EVENT                                                    SECONDS_IN_WAIT
       390         136              0            7605 SQL*Net message from client                                        46101
SYS@destp>We have had an issue in the past where the connection was being dropped by the network when the process runs for few days, hence we have added the following to the sqlnet.ora and listener.ora files:
sqlnet.ora:
SQLNET.EXPIRE_TIME = 1
SQLNET.INBOUND_CONNECT_TIMEOUT = 6000
listener.ora:
INBOUND_CONNECT_TIMEOUT_LISTENER = 6000What else can we do and/or further investigate to work out the root cause of the problem, and may be help resolve this. We don't want to just stop and start the process again as it took few days already. We have
had a chat to the infrastructure team and they've assured us that there have been no network outages.
Also, the alert logs for both instances (local and remote) shows no errors what so ever!
Your input is highly appreciated.
Thanks
Edited by: rsar001 on Jul 25, 2012 10:22 AM

Ran the query on both local/remote db, and no rows returned:
etl_user@datap> SELECT DECODE(request,0,'Holder: ','Waiter: ')||vl.sid sess, status,
2 id1, id2, lmode, request, vl.type
3 FROM V$LOCK vl, v$session vs
4 WHERE (id1, id2, vl.type) IN
5 (SELECT id1, id2, type FROM V$LOCK WHERE request>0)
6 and vl.sid = vs.sid
7 ORDER BY id1, request
8 /
no rows selected
Elapsed: 00:00:00.21

SQL*Net message from client - huge wait in trace file

Dear All,
I am facing a performance issue in a particular operation ( which was completed in 21 Minutes earlier). Now the same operation takes more than 35 Minutes. I took a trace for those session ( 10046 level 12 trace ) and found Lot of waits in SQL*Net message from client.
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQLNet message from client 611927 10.00 1121.35*
I copied only the highest wait in the tkprof output.
And I found from the tkprof and even in raw trace file this event waits more time after excuting
SELECT sysdate AS SERVERDATE from dual;
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 115 0.00 0.00
SQLNet message from client 115 10.00 724.52*
Please help me to find out why this wait taking long time, especially on the above query..
Regards,
Vinodh

Vinodh Kumar wrote:
Hi,
This is what available in the trace file
PARSING IN CURSOR #2 len=38 dep=0 uid=60 oct=3 lid=60 tim=7052598842 hv=3788189359 ad='7d844fa0'
*"SELECT sysdate AS SERVERDATE FROM dual"*
END OF STMT
PARSE #2:c=0,e=12,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=7052598839
BINDS #2:
EXEC #2:c=0,e=42,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=7052599002
WAIT #2: nam='SQL*Net message to client' ela= 1 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=7052599058
FETCH #2:c=0,e=15,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=7052599110
*** 2012-01-02 17:07:30.364
WAIT #2: nam='SQL*Net message from client' *" ela= 10007957"* driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=7062607120Please find the last line WAIT -- in the complete trace after executing this query
In awr report , this query taken less than a sec for more than 2000 executions.
Regards,
VinodhGood idea to check the raw trace file. It is important to notice that this particular wait event appears after the fetch of the result from the database. The client receives the SYSDATE from the database server, and then the client performs some sort of action for about 10 seconds before submitting its next request to the database. The SQL statement that immediately follows and immediately preceeds this section of the trace file might provide clues regarding what caused the delay, and where that delay resides in the client side code. Maybe a creative developer added a "sleep for 10 seconds" routine when intending to sleep for 10ms? Maybe the client CPU is close to 100% utilization?
Charles Hooper
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

SQL*NET waits in trace file

Hi All,
There is a long running query, i generated trace file for this request. In trace file i found that there are huge waits on SQL*Net message from client
The below is the trace file output:
Elapsed times include waiting on following events:
Event waited on Times Waited Max. Wait Total Waited
SQL*Net message to client 16 0.00 0.00
SQL*Net more data to client 17 0.00 0.00
db file sequential read 1450 0.02 4.26
SQL*Net message from client 16 1414.20 2702.84
How to resolve this waits from SQL*NET message from client? I checked the network connection, there is no delays in network.
Any inputs on this issue will be appreciated.

As Satish indicated, the "SQL*Net message from client" wait is an event which indicates that the database server was waiting for the next request from the client computer, and not an indication that the query needs to be tuned. Manually review the trace file. At one point in the trace file, you will see this wait event with an ela= value which begins with 14142 - please post to this thread that line from the trace file along with the 20 lines before that line and the 20 lines after that line. You may just have a long wait on this event at the beginning, and another long wait on this event at the end of the query.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

High SQL*Net message values in trace file.

Hi all,
This is my first post here. I will try to more less describe the problem i am facing.
Any help is more than welcome!
I am facing some performance issues with application. Slow GUI. I run some tests, i tracked the session. what i found in trace file is:
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse     1734     1.61   1.61             0            0            0              0
Execute   1734   32.52 32.56           0           26          15             4
Fetch     1737     14.46 14.51           2        41867        84          2847
total     5205     48.59   48.69            2        41893        99          2851
Misses in library cache during parse: 7
Misses in library cache during execute: 5
Elapsed times include waiting on following events:
Event waited on                             Times       Max. Wait     Total Waited
----------------------------------------           Waited       ----------            ------------
SQL*Net message to client            5207           0.00               0.02
SQL*Net message from client        5206          106.18             339.72
log file sync                                    3               0.00               0.00
SQL*Net more data to client            51              0.00               0.00
SQL*Net more data from client        10              0.00               0.00
Disk file operations I/O                    1               0.00               0.00
db file sequential read                     2               0.00               0.01
library cache: mutex X                    1               0.05               0.05
Look at Max. Wait and Total Waited columns. Is it possible to safely tune it by changing SDU in sql*net ? and if so, is it needed to change the SDU value on client and server sides ?

66ff73bb-87bd-4c84-bada-0141fb25344b wrote:
Hi all,
This is my first post here. I will try to more less describe the problem i am facing.
Any help is more than welcome!
I am facing some performance issues with application. Slow GUI. I run some tests, i tracked the session. what i found in trace file is:
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse     1734     1.61   1.61             0            0            0              0
Execute   1734   32.52 32.56           0           26          15             4
Fetch     1737     14.46 14.51           2        41867        84          2847
total     5205     48.59   48.69            2        41893        99          2851
Misses in library cache during parse: 7
Misses in library cache during execute: 5
Elapsed times include waiting on following events:
Event waited on                             Times       Max. Wait     Total Waited
----------------------------------------           Waited       ----------            ------------
SQL*Net message to client            5207           0.00               0.02
SQL*Net message from client        5206          106.18             339.72
log file sync                                    3               0.00               0.00
SQL*Net more data to client            51              0.00               0.00
SQL*Net more data from client        10              0.00               0.00
Disk file operations I/O                    1               0.00               0.00
db file sequential read                     2               0.00               0.01
library cache: mutex X                    1               0.05               0.05
Look at Max. Wait and Total Waited columns. Is it possible to safely tune it by changing SDU in sql*net ? and if so, is it needed to change the SDU value on client and server sides ?
When you start with the wrong question, no matter how good an answer you get, it won't matter very much.
you do NOT have any problem; just a useless observation.

VMS : SQL*NET V2.0 ARCHITECTURE

제품 : SQL*NET
작성날짜 : 2001-05-28
VMS : SQL*NET V2.0 ARCHITECTURE
===============================
1. SQL*Net V2.0 Architecture
* Master File 위치 : Logical name TNS_ADMIN
= ORA_ROOT:[NETWORK.ADMIN]
* Main File 종류 : SQLNET.ORA
LISTENER.ORA
TNSNAMES.ORA
2. SQLNET.ORA
* SQL*Net에 대한 몇가지 parameter setting을 가지고 있다.
* Comments는 # 후에 기록한다.
* Client와 Server 측면에서의 trace와 log level을 setting할 수 있다.
* TRACE_FILE_xxxxx parameter는 trace file의 이름을 지정한다.
.TRC file name의 끝부분을 자동으로 생성한다.
* IPC(Inter-Process Communication)를 제어하는 parameter를 설정할 수
있는데 default는 ON이다. 이것은 자동으로 OpenVMS Mailboxe와
Unix pipes 중에서 platform에 맞게 고르는 것이다.
# FILENAME: sqlnet.ora
# NETWORK.: UK_VAX_NET
# SERVICE.: NA
TRACE_LEVEL_CLIENT = OFF
TRACE_DIRECTORY_CLIENT = ORACLE$DISK:[ORACLE7.PROD.NETWORK.TRACE]
TRACE_FILE_CLIENT = CLIENT
LOG_DIRECTORY_CLIENT = ORACLE$DISK:[ORACLE7.PROD.NETWORK.LOG]
LOG_FILE_CLIENT = CLIENT
TRACE_LEVEL_SERVER = OFF
TRACE_DIRECTORY_SERVER = ORACLE$DISK:[ORACLE7.PROD.NETWORK.TRACE]
TRACE_FILE_SERVER = SERVER
LOG_DIRECTORY_SERVER = ORACLE$DISK:[ORACLE7.PROD.NETWORK.LOG]
LOG_FILE_SERVER = SERVER
AUTOMATIC_IPC = ON
SQLNET.EXPIRE_TIME = 10
3. LISTENER.ORA
* LISTENER의 default name은 LISTENER이다.
* LISTENER의 name과 capability를 setting한다.
<lsnr-name> = (ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = IPC)
(KEY = sid)
(ADDRESS =
(PROTOCOL = DECNET)
(NODE = node-name)
(OBJECT = object-name)
(ADDRESS =
(PROTOCOL = TCP)
(HOST = node-name)
(PORT = 1521)
* ORACLE8 이후로는 DECnet protocol은 지원하지 않는다.
* LISTENER START & STOP COMMAND : LISTENER 이름이 LISTENER일 경우
$ LSNRCTL START
$ LSNRCTL STOP
$ LSNRCTL STATUS
4. TNSNAMES.ORA
* Client level에서 필요한 file로 service를 define한다.
* Service Define
For DECnet...
<service-name> =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = DECNET)
(NODE = <node-name>)
(OBJECT = <lsnr-object>)
(CONNECT_DATA =
(SID = <sid>)
For TCP/IP...
<service-name> =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = <node-name>)
(PORT = 1521)
(CONNECT_DATA =
(SID = <sid>)
5. Logging and Tracing
* Listener logging은 default로 자동으로 하게 되어있다.
LOG_DIRECTORY : Log File이 생성될 Directory setting
LOG_FILE_<lis> : Log File name
* Tracing Level
TRACE_LEVEL_<listener-name> = OFF|USER|ADMIN
OFF tracing을 disable시킨다.
USER 제한적으로 tracing 한다.
ADMIN 상세하게 tracing 한다.
* server process에 대한 tracing은 default로 disable되어 있다.
6. Tips
* 실제로 동작하기 위해서 server process를 기동시켜주는 command
procedure인 ORASRV_NETV2.COM 이 있어야 하는데 TNS_ADMIN 에
sample이 있으므로 수정해서 사용하도록 한다.
이때 반드시 ORA_DB directory가 정의되어 있어야 한다.
* SYLOGIN.COM이나 LOGIN.COM에 다음의 조건문을 넣어서 Network
Access를 처리할 수 있다.
$ IF F$MODE() .EQS. "NETWORK" .OR. F$MODE() .EQS. "OTHER" -
THEN EXIT
* 만약 listener나 server process가 아무런 tracing information을
남기지 않고 계속 죽는다면 VMS Accounting Utility를 이용하여
process termination status를 점검해본다.
$ ACCOUNTING/FULL/IDENT=<pid>

Depending on how large is your database you can use either exp/imp utility to migrate the data after installing the Oracle8i on your O/S or Inplace db upgrade. Otherwise backup your current Oracle7.x release and install the Oracle8i Software only without the database. Open old database using the Oracle8i svrlmgrl utility. Upgrade using the upgrade scripts available in $ORACLE_HOME/rdbms directory. Also read the documentation for any additional information on issues on the upgrades.
I am not sure about the SQL Net versions, but SQL Net Version 2 should work against net8 listener. You could try v1 too.
Hope this helps
null

처음 사용자를 위한 SQL*NET V1/V2

제품 : SQL*NET
작성날짜 : 1997-10-10
처음 사용자를 위한 SQL*NET V1/V2
===============================
오라클에서는 기존의 통신프로토콜(TCP/IP 등)에 기반한 오라클 고유의 middleware
인 SQL*NET을 이용하여 client/server 간의 통신을 하게 됩니다.
sql*net은 v1,v2 의 두가지 버젼이 있는데 이것은 upgrade 차원의 개념이 아니고
독립적인 방식을 취하고 있기 때문에 서로간의 호환성이 없습니다.
따라서 client 에서 v1를 사용한다면 server에서도 v1을 지원해야만 접속이
가능합니다.
일반적으로는 서버와 클라이언트 양쪽에 sql*net v1,v2를 모두 다 인스톨
해놓고 사용합니다.
오라클 db 에 접속하려면 우선 db 를 startup 시켜야 하며 클라이언트
접속을 처리하기 위해서는 sql*net 프로세스도 함께 구동시켜야 합니다.
NT에서는 이들이 모두 제어판의 SERVICES에서 관리되므로 SERVICES에서 Oracle
이라는 문장이 들어 있는 모든 서비스들을 Started 상태로 기동시켜 주시면 됩니다.
단, v1 은 인스톨 후에 특별한 셋업과정이 필요없지만 v2의 경우는 간단한
셋업 과정이 필요합니다. (뒷부분 참조)
이렇게 해 둔 상태에서 client 에서 접속할 수 있습니다.
다음은 SQL*NET V1,V2를 사용하여 접속하는 방법입니다.
여기서 서버의 hostname은 krunix, <ORACLE SID>는 ORA7 이라고 가정합니다.
NT의 경우에는 DEFAULT로 <ORACLE SID>가 ORCL 입니다.
참고로 UNIX의 경우 <ORACLE SID>는 서버에 오라클 유저로 들어간 다음
echo $ORACLE_SID
라고 치면 확인할 수 있습니다.
그리고, 사용하는 유저는 오라클 인스톨시에 기본적으로 생성되는 scott 유저
(패스워드는 tiger)를 사용하도록 합니다.
그리고 hostname(krunix)가 들어가는 곳에 직접 ip address를 써 주어도 상관
없습니다 (접속 속도는 조금 빨라집니다)
========================
SQL*NET V1 으로 접속하기
========================
우선 서버에서 SQL*NET V1 프로세스를 구동하여야 합니다.
서버에 오라클 유저로 들어간 다음
tcpctl start
하면 됩니다.
NT의 경우에는 제어판의 서비스에서 OracleTCPListener가 기동된
상태이어야 합니다.
다음에 클라이언트에서는 다음과 같이 하여 접속을 할 수 있습니다.
역시 오라클 유저로 유닉스에 들어간 다음
sqlplus scott/tiger@t:krunix:ORA7
하면 접속이 됩니다.
PC에서 접속하는 경우에도 유사한 방법으로 하면 됩니다.
======================
SQL*NET V2 로 접속하기
======================
SQL*NET V2는 SQL*NET V1처럼 바로 사용할 수 없고 다음과 같이 간단한 셋업 과정을
거쳐야 합니다.
서버상에 오라클 유저로 접속한 다음,
1) Multi-threaded server 프로세스들을 먼저 기동을 하여야 한다.
기동하는 방법은 ORACLE_HOME/dbs/init<SID>.ora 화일에 다음과 같은 내용을
추가하고 DB 를 다시 startup 을 한다. <SID>를 ORA7이라고 가정하면 실제의
화일이름은 initORA7.ora 가 됩니다.
# Filename : $ORACLE_HOHE/dbs/init<SID>.ora
# Protocol : tcp
mts_dispatchers="tcp,3"
mts_max_dispatchers=10
mts_servers=2
mts_max_servers=10
mts_service=ORA7
mts_listener_address="(ADDRESS=(PROTOCOL=tcp)(port=1521)(host=krunix)"
mts_service 에는 <ORACLE SID>를 입력하는 것입니다.
2) /etc/services file 에 다음내용을 추가한다. services 화일은 Machine에
따라 디렉토리가 다를 수 있다. 이 작업은 root 유저로 합니다.
listener 1521/tcp
3) tnsnames.ora 및 listener.ora 를 작성한다. 이 화일들은 유닉스 환경변수를
TNS_ADMIN=$ORACLE_HOME/network/admin 와 같이 지정한 다음
$ORACLE_HOME/network/admin 디렉토리에 만들어 주면 된다.
예)
# File name : $ORACLE_HOME/network/admin/listener.ora
LISTENER =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)
(HOST = krunix)
(PORT=1521)
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER = 0
TRACE_LEVEL_LISTENER = off
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = ORA7)
(ORACLE_HOME=/usr/oracle7)
여기서 <ORACLE SID>는 ORA7, ORACLE HOME DIRECTORY를 /usr/oracle7
이라고 가정하였습니다.
# Filename : $ORACLE_HOME/network/admin/tnsnames.ora
TORA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)
(HOST = krunix)
(PORT=1521)
(CONNECT_DATA =
(SID = ORA7)
4)listener 프로세스를 start 한다(오라클 유저로 START한다.)
$lsnrctl start
여기서 에러가 발생하면 listener.ora 가 잘못 만들어진 것입니다.
정상적으로 start가 되면 tnslsnr이라는 프로세스가 뜹니다.
5)클라이언트에 앞에서 만든 tnsnames.ora 화일을
$ORACLE_HOME/network/admin 디렉토리에 copy 한 다음
다음과 같이 접속한다.
sqlplus scott/tiger@TORA
=======================================================================
<PC의 SQLPLUS에서 접속>
SQL*Plus 등에서 username, password, connect string 주는 부분을 다음과 같이
주면 됩니다.
username scott
password tiger
connect string t:hostname:SID
여기서 hostname 대신에 server의 ip address 를 써도 되고 SID 부분은
WORKGROUP SERVER 라면 DEFAULT가 ORCL 입니다. 확인하려면 Unix 에 oracle
유저로 들어가서 env 를 쳐보시면 환경변수가 출력되는데 거기서 ORACLE_SID로
지정된 부분입니다.
v2 의 경우는 tnsnames.ora 라는 화일에 alias 와 관련정보를 기록한 다음
connect string에 alias 를 바로 주면 연결이 됩니다.
SQL*NET V2는 서버와 PC 양쪽에 간단하게 셋업을 해주셔야 합니다.
PC쪽은 서버쪽의 $ORACLE_HOME/network/admin 디렉토리에 있는 화일들을
모두 PC 의 C:\orawin\network\admin 디렉토리로 COPY 하기만 하면 됩니다.
그리고 connect 시에 connect string 으로 tnsnames.ora 에 등록한
service name(자료에는 TORA 로 되어 있음)을 주면 접속이 됩니다. 위와 같이
셋업을 하였을 경우라면 예를 들면 다음과 같습니다.
username scott
password tiger
connect string TORA
그리고 PC의 c:\orawin\network\admin 디렉토리의 sqlnet.ora 화일은 삭제하고
접속하시기 바랍니다.
<WINDOWS NT의 경우>
간단히 말씀드리면 V2의 경우에는 c:\orant\network\admin 디렉토리에 listener.ora
를 만들어 주어야 하고 PC의 c:\orawin\network\admin 디렉토리에는 tnsnames.ora
를 만들어 주어야 합니다.
NT는 인스톨 하게 되면 기본적으로 SQL*NET V1,V2 프로세스가 자동으로 서비스에
등록되어서 실행이 되기 때문에 서버쪽에서 특별히 셋업하실 것은 없고 클라이언
쪽만 셋업을 하시면 됩니다(V2만 셋업하면 됩니다.)

Depending on how large is your database you can use either exp/imp utility to migrate the data after installing the Oracle8i on your O/S or Inplace db upgrade. Otherwise backup your current Oracle7.x release and install the Oracle8i Software only without the database. Open old database using the Oracle8i svrlmgrl utility. Upgrade using the upgrade scripts available in $ORACLE_HOME/rdbms directory. Also read the documentation for any additional information on issues on the upgrades.
I am not sure about the SQL Net versions, but SQL Net Version 2 should work against net8 listener. You could try v1 too.
Hope this helps
null

JDBC, SQL*Net wait interface, performance degradation on 10g vs. 9i

Hi All,
I came across performance issue that I think results from mis-configuration of something between Oracle and JDBC. The logic of my system executes 12 threads in java. Each thread performs simple 'select a,b,c...f from table_xyz' on different tables. (so I have 12 different tables with cardinality from 3 to 48 millions and one working thread per table).
In each thread I'm creating result set that is explicitly marked as forward_only, transaction is set read only, fetch size is set to 100000 records. Java logic processes records in standard while(rs.next()) {...} loop.
I'm experiencing performance degradation between execution on Oracle 9i and Oracle 10g of the same java code, on the same machine, on the same data. The difference is enormous, 9i execution takes 26 hours while 10g execution takes 39 hours.
I have collected statspack for 9i and awr report for 10g. Below I've enclosed top wait events for 9i and 10g
===== 9i ===================
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
db file sequential read 22,939,988 0 6,240 0 0.7
control file parallel write 6,152 0 296 48 0.0
SQL*Net more data to client 2,877,154 0 280 0 0.1
db file scattered read 26,842 0 91 3 0.0
log file parallel write 3,528 0 83 23 0.0
latch free 94,845 0 50 1 0.0
process startup 93 0 5 50 0.0
log file sync 34 0 2 46 0.0
log file switch completion 2 0 0 215 0.0
db file single write 9 0 0 33 0.0
control file sequential read 4,912 0 0 0 0.0
wait list latch free 15 0 0 12 0.0
LGWR wait for redo copy 84 0 0 1 0.0
log file single write 2 0 0 18 0.0
async disk IO 263 0 0 0 0.0
direct path read 2,058 0 0 0 0.0
slave TJ process wait 1 1 0 12 0.0
===== 10g ==================
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
db file scattered read 268,314 .0 2,776 10 0.0
SQL*Net message to client 278,082,276 .0 813 0 7.1
io done 20,715 .0 457 22 0.0
control file parallel write 10,971 .0 336 31 0.0
db file parallel write 15,904 .0 294 18 0.0
db file sequential read 66,266 .0 257 4 0.0
log file parallel write 3,510 .0 145 41 0.0
SQL*Net more data to client 2,221,521 .0 102 0 0.1
SGA: allocation forcing comp 2,489 99.9 27 11 0.0
log file sync 564 .0 23 41 0.0
os thread startup 176 4.0 19 106 0.0
latch: shared pool 372 .0 11 29 0.0
latch: library cache 537 .0 5 10 0.0
rdbms ipc reply 57 .0 3 49 0.0
log file switch completion 5 40.0 3 552 0.0
latch free 4,141 .0 2 0 0.0
I put full blame for the slowdown on SQL*Net message to client wait event. All I could find about this event is that it is a network related problem. I assume it would be true if database and client were on different machines.. However in my case they are on them very same machine.
I'd be very very grateful if someone could point me in the right direction, i.e. give a hint what statistics should I analyze further? what might cause this event to appear? why probable cause (that is said be outside db) affects only 10g instance?
Thanks in advance,
Rafi.

Hi Steven,
Thanks for the input. It's a fact that I did not gather statistics on my tables. My understanding is that statistics are useful for queries more complex than simple select * from table_xxx. In my case tables don't have indexes. There's no filtering condition as well. Full table scan is what I actually want as all software logic is inside the java code.
Explain plans are as follows:
======= 10g ================================
PLAN_TABLE_OUTPUT
Plan hash value: 1141003974
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 259 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| xxx | 1 | 259 | 2 (0)| 00:00:01 |
In sqlplus I get:
SQL> set autotrace traceonly explain statistics;
SQL> select * from xxx;
36184384 rows selected.
Elapsed: 00:38:44.35
Execution Plan
Plan hash value: 1141003974
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 259 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| xxx | 1 | 259 | 2 (0)| 00:00:01 |
Statistics
1 recursive calls
0 db block gets
3339240 consistent gets
981517 physical reads
116 redo size
26535700 bytes received via SQL*Net from client
2412294 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
36184384 rows processed
======= 9i =================================
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | | | |
| 1 | TABLE ACCESS FULL | xxx | | | |
Note: rule based optimization
In sqlplus I get:
SQL> set autotrace traceonly explain statistics;
SQL> select * from xxx;
36184384 rows selected.
Elapsed: 00:17:43.06
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (FULL) OF 'xxx'
Statistics
0 recursive calls
1 db block gets
3306118 consistent gets
957515 physical reads
100 redo size
23659424 bytes sent via SQL*Net to client
26535867 bytes received via SQL*Net from client
2412294 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
36184384 rows processed
Thanks for pointing me difference in table scans. I infer that 9i is doing single-block full table scan (db file sequential read) while 10g is using multi-block full table scan (db file scattered read).
I now have theory that 9i is faster because sequential reads use continuous buffer space while scattered reads use discontinuous buffer space. Since I'm accessing data 'row by row' in jdbc 10g might have an overhead in providing data from discontinuous buffer space. This overhead shows itself as SQL*Net message to client wait. Is that making any sense?
Is there any way I could force 10g (i.e. with hint) to use sequential reads instead of scattered reads for full table scan?
I'll experiment with FTS tuning in 10g by enabling automatic multi-block reads tuning (i.e. db_file_multiblock_read_count=0 instead of 32 as it is now). I'll also check if response time improves after statistics are gathered.
Please advice if you have any other ideas.
Thanks & regards,
Rafi.

SQL*Net break/reset to client wait event

Hi,
Can you please explain me about "SQL*Net break/reset to client" wait event. One of my session was waiting for this event and when I looked which is causing the problem there are many duplicates in the input which were geting rejecting due ot the primary key. I didn't exactly get how the duplicate reject causing this wait event.
I appreciate your help !!
Thanks
Anand
Edited by: user509266 on Sep 4, 2009 10:58 AM

Better place to ask is over in the Database forums.

Getting SQL*Net more data from client waits when running a query through web based interface

Hi, you all,
We are having this weird behavior when running query through web based interface, we get a lot of "SQL*Net more data from client" waits, the OEM indicates that the current wait event is SQL*Net more data from client
It's just a very simple query wich invokes a db link.
When I execute the same query on any PL/SQL tool like toad or sql developer it works fine, but that query inside an application executed through a web based interface, it hangs for ever.
Where can I start looking for the problem.
We are working on a 3 Node RAC 11gr2, both databases are on the same RAC.
Thanks.

Hi ,
we managed to reproduce the case in test environment, below are the steps:
1)have 2 databases on different machines, will call the first one local, the other one remote.
2)in the local database create:
a - DBLink to remote database.
b - read data from remote database(we simply used select count(*) from dummy_table )
c - insert data into a table on the local database
d - terminate the connection between the 2 databases (disconnect either machine from the network)
e - commit on local database.
what we noticed was the following:
1)when the local database is disconnected from the network(the machine is not connected to any network at the moment): almost immediately throws an error, and issuing the following:
select * from dba_2pc_pending;we found some data .
2) when the remote database was disconnected(the local database is still connected to the network):
after 7-8 seconds an error is thrown, and issuing the following:
select * from dba_2pc_pending;did not return any data.
since this is pretty similar to our case ,we concluded that it's a network issue.
is this the correct behavior ?
as a temporary solution till the network issue is fixed ,we did the following:
1) changed the call of the remote procedure to calling a local procedure that calls the remote procedure.
2) added pragma autonomous_transaction to the local procedure.
3) at the end of the local procedure rollback the autonomous transaction.
it seems that since the global transaction does not use the DBLink database does not issue a 2PC commit.
this works in my cases since the DBLink is only issed to read data.

A question about waits

Hi,
We are on Oracle 10.2.0.4 on Solaris 10.
In my awr report I have the following among top five top wait event:
Wait event
SQL*Net more data to client 14,022,144 3,758 0 17.7 Network
Edited by: orausern on Apr 15, 2010 5:07 AM

Your average wait on "more data to client" is very small.
The number of calls is large - but you don't have any real measure of its significance and meaning.
You need to look at Instances statistics:
SQL*Net roundtrips to/from clien         17,407,740        9,876.1          32.6
bytes sent via SQL*Net to client      4,429,719,421    2,513,152.0       8,303.4A round-trip consists of one 'sql net data to client' plus ALL the ' more data to client' that took place at the same time, so:
Compare your count of 'more data to client' with roundtrips - if it is a large multiple you can infer that on average each round trip is a large chunk of data that has to be sent as several packets, and you probably need to make your SDU larger. If you look at 'bytes sent via SQL net to client' compared to roundtrips, you get an idea of the size of the the "average" packet - hence an indication of the necessary size of the SDU.
There are also a couple of tcp network configuration parameters that may need setting. I never remember the exact names, but it's something like 'tcp_transmit_buf' and 'tcp_recv_buf'. This is the volume of data that the tcp layer can send before it needs an ACK from the far end. So, for example, if your SDU is 32K and your tcp buffer size was only 4KB, then Oracle would send one packet of 32KB, tcp would handle as 8 chunks of 4KB - with 8 tcp ACKs from the far end, and the (because tcp works in line packets of about 1400 bytes - each 4KB would go as 3 packets with an ACK expected on the third). So you need the tcp buffer sizes to be slightly larger than the SDU for best effect.
(If your procsses parameter is large, though, the total tcp buffer memory needed is processes * tcp buffer size).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

SQL*NET V1 FOR APPC/LU6.2 TEST

제품 : SQL*NET
작성날짜 : 1995-06-05
Olivetti system에서 SQL*Net V1 for APPC/LU6.2 test 결과입니다.
customer : 한국컴퓨터
Test System : Olivetti UNIX System 2대
O / S version : SVR4 2.4
1. Server Install
1.1 Shared Memory Parameter
SHMMAX8388608
SHMSEG6
SHMMIN1
SHMMNI100
1.2 Kernel Parameter
SVMMLIM0x7FFFFFFF
HVMMLIM0x7FFFFFFF
SFSZLIM0x7FFFFFFF
HFSZLIM0x7FFFFFFF
파라메터가 이보다 적으면 oracle kernel을 만들면서 에러가 발생함.
1.3 Oracle Server Install 시 relink option 에서 Yes 선택.
LU6.2를 사용하기 위해서 반드시 해주어야 함.
1.4 Version이 2.3이하인 경우 kernel 생성시 에러 발생.
2. SQL*Net Install
2.1 Transaction Program 을 Generate.
$ $ORACLE_HOME/bin/gentpn ORACLE_SID Max_RU_size Min_RU_size
RU_size는 256 에서 1024 범위내에서 set 해야함.
ex) $ gentpn ORA7 512 512
generate 후 TPORA7 이라는 Transaction Program 이 generate
되었다는 message가 떨어짐
TP name은 ORACLE_SID 앞에 TP가 붙어서 생성.
generate후 $ORACLE_HOME/lu62/server directory 에 TPORA7
이라는 binary file이 생성.
2.2 TPORA7을 APPC Services에 등록.
sysadm tool을 이용하여 등록.
TP_Name : TPORA7
TP_Filespec : /home/oracle7/lu62/server/TPORA7
3. Connection.
3.1 Connect String
- @L:remote_LU_name::local_LU_name:mode_name:TP_name
remote_LU_name, local_LU_name, mode_name 의 value는 APPC
service에 등록이 되어있슴.
ex) $ sqlplus scott/tiger@L:BBBBBBBB::AAAAAAAA:CCCCCCCC:TPORA7
4. 특이사항.
-. gentpn시 Max_RU_size와 Min_RU_size 256으로 set:
sqlplus에서 접속시 SQL> prompt가 떨어지지 않고 waiting 상태.
반면 상대방 remote system에 session 은 연결됨.
-. gentpn시 Max_RU_size와 Min_RU_size 512으로 set:
sqlplus에서 접속은 됨.
그러나 512를 넘어서는 데이타일경우에는 ORA-6412 에러가 떨어지면서
disconnect 가 되어버림. (ORA-6412:bad read length)
remote에서 select 된 데이타는 local system 까지는 가져옴.
data size 는 548.
sqlplus 에서 array size를 '1'로 하면 정상적으로 작동.
ex) 1). select empno, ename from emp; ----> 정상
2). select * from emp; ----> disconnect
3). select empno, ename, hiredate, sal,
mgr, comm, deptno
from emp; ----> disconnect
4). set array 1
select * from emp; ----> 정상
-. gentpn시 Max_RU_size와 Min_RU_size 1024으로 set:
데이타 사이즈가 1024를 넘어설경우 동일한 현상발생.

great to hear some one talking of sql*net for dos
hi
you can't connect from v1 to net8
you can conn from v1 to v2
don't start net8
on the server
start sql*net 2.?? at the server
hope this helps
I need drivers for sql*net on dos
where can i down load these from
thnkx
Adrian Maier (guest) wrote:
: Here is my problem:
: I have some DOS applications written for Oracle 6 for DOS.
: I want that these connect to an Oracle Server using SQL*Net.
: For the start, I want to connect to the server with sqlplus,
: from DOS. For testing I have a small TCP/IP network with two
: computers:
: 1. the SERVER, running Linux(Debian 2.1) and Oracle 8.0.5
: 2. the CLIENT, running MSDOS, PSNFS as networking software
: and SQL*Net Client v1 for DOS.
: Question: Is this version of SQl*Net client compatible with
: Net8 which comes with Oracle8?
: From win95 I've bben able to connect to the server, so I
: believe the serevr is correctly configured. When I'm trying
: to connect from DOS with sqlplus, the ethernet card's leds
: blink two or three times, which means that some data is
: transmitted through network. After that, sqlplus waits for
: an indefinite period of time.
: If I stop the listener, sqlplus generates the error ORA-06136
: and asks for a new username. If I don't stop the listener,
: sqlplus remains blocked.
: In SQLNet documentation I've found:
: "ORA-06136: Error during connection handshake.
: Cause: The destination server was unable to obtain enough
: information to complete the connection.
: Action: Check that the configuration of the server is correct,
: blah, blah .... "
: I think that the server might not understand this version
: of client, but Net8 should be "backward compatible"!
: SQL*Net client v1 was the only DOS version I could find.
: Are there any other newer DOS SQl*Net clients available?
: If you have any idea about what could I do, please let me know.
: Best regards,
: Adrian Maier
: [email protected]
null

Oracle - Informatica transfer speed fetch size and SQL*Net message from c

Hi,
I'm testing how fast informatica can take data from our 10.2.0.3 and using large (140GB 1 200 000 000 rows) table as source and doing simple
select * from large_table .
Here goes quite interesting wait time analyze :) .
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch   186994    131.84     198.25     127545     314167          0    25431184
total   186994    131.84     198.25     127545     314167          0    25431184
Misses in library cache during parse: 0
Parsing user id: 400
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file scattered read                       9122        0.33         64.71
SQL*Net more data to client                529327        0.00          8.34
SQL*Net message from client                186994        0.21        478.74
SQL*Net message to client                  186994        0.00          0.30
db file sequential read                       145        0.01          0.49
gc cr multi block request                    6998        0.01          6.30
gc current grant 2-way                          9        0.00          0.00
gc cr grant 2-way                              67        0.00          0.03The interesting part is ' SQL*Net message from client 186994 0.21 478.74'
so looks like from Informaticka point of view (client side) is lagging 478 sec , so its lagging .
Doing some math 25431184/186994 = 136 .
Could You share with me Your experience in that matter ?
Looks like to speed up I need to :
1. increase fetch size (not sure how to do that).
2. increase SDU client and probably server side .
Network is 100Mbit ethernet so about 10MBytes per second .
Regards
GregG

Have you solve your problem ?
If yes I'm strongly interest by the solution.
If you have a question of issue create your own thread and provide the particulars of your use case. This thread is year old.
OP likely did NOT have any problem. As OP stated the max throughput for a 100 Mbit network is about 10 MB per second. So do the math for moving 140 GB and you will see that the network itself will be the limiting factor.

TRACING IN SQL*NET V2

제품 : SQL*NET
작성날짜 : 1997-10-10
Introduction
~~~~~~~~~~~~
For most problems you need to identify the relevant parts of a
connection to trace. To do this consider which scenario you are
having problems with and where tracing needs to be enabled.
Note that tracing produces a lot of output , especially at higher
trace levels.
There are 3 main areas of SQL*Net that can produce trace output:
1 = the SQL*Net 'client'
2 = the 'listener' process
3 = the SQL*Net 'server'.
a) Establishing a connection:
Client ----> Listener ----> Server
1 2 3
b) An established connection:
Client --------> Server
1 3
c) Opening a database link:
Client ----> Server ----> Listener -----> Server2
1 3 1 2 3
Note here that the Oracle server process is also a SQL*Net
client when it makes an outgoing call to a listener to
open a database link. Database links are OPENED when first
used. They should then remain open until closed.
d) An established database link:
Client ----> Server -----> Server2
1 3 1 3
In each case here there are several potential sampling points. You
should be able to identify quickly which of these scenarios matches
your setup. As these scenarios are likely to involve connections
between different machines you should remember that tracing for any
process is controlled by the configuration details that the process
reads WHEN IT IS STARTED. This is especially important when looking
at MTS connections as the SQL*Net server is the 'dispatcher' process.
Some dispatchers are started when the database instance is started
and others may start at a later time (on demand). Each dispatcher will
read their SQL*Net configuration WHEN THEY START.
7.2 Client Tracing
~~~~~~~~~~~~~~
For client TOOLS edit or create the file $HOME/.sqlnet.ora and add
the lines:
trace_level_client=16
trace_file_client=cli
trace_directory_client=/tmp # Or a known directory
trace_unique_client=true # Add '_pid' to trace filename
This will turn on FULL tracing for your user account only producing
output in a file called /tmp/cli_<PID>.trc .
(For some SQL*Net versions the file will be just /tmp/cli.trc)
For client 'ORACLE' process (as in the case of database links) put this
same information into $TNS_ADMIN/sqlnet.ora file.
On versions up to and including Oracle 7.0.16 client trace may not
add a process ID to the name of the trace file. This means two
processes may end up writing to the same trace file unless you
take care to control which processes write trace output to each file.
7.3 Listener Tracing
~~~~~~~~~~~~~~~~
Listener tracing can ONLY be configured in the listener.ora file.
Add the lines below to the listener.ora file:
trace_level_listener=16
trace_file_listener=listener
trace_directory_listener=/tmp # Or a known directory
This will define FULL listener tracing to the file /tmp/listener.trc.
You can enable this tracing by either:
lsnrctl reload
OR
lsnrctl stop;
lsnrctl start;
TCP/IP
~~~~~~
It is often useful to confirm that a listener is listening on a
specified address. Most Unix machines include a command called
'netstat' (Often in /etc or in /usr/etc). The command netstat -a
should list all TCP/IP end points on which a listener is listening.
Eg:
For a listener listening on HOST=... PORT=1580 there should be a
netstat entry of the form:
RecvQ SendQ Local Address Foreign Address TCP state
0 0 *.1580 *.* LISTEN
Note: Some versions of netstat will only list established connections
and not listen end points. See the man page on your machine.
7.4 Server Tracing
~~~~~~~~~~~~~~
Server side trace is not required as often as the other two traces
mainly because most problems are related to establishing a connection.
Once a connection has been established the client and server processes
are communicating. It is sometimes useful to see exactly what SQL
commands have been received by the server, and what data it has sent
back out.
The file $TNS_ADMIN/sqlnet.ora controls the server side tracing. Add
the lines below to this file:
trace_level_server=16
trace_file_server=server
trace_directory_server=/tmp # Or a known directory
Output should be sent to the file /tmp/server_<PID>.trc
Note: Server side tracing acts on the SQL*Net server side.
For dedicated connections this is the Oracle process on the
server machine.
For MTS connections this is the DISPATCHER and NOT the shared
server. Data is passed between the dispatcher and the shared
servers via the SGA and this does NOT involve SQL*Net.
It is also important to note that as a dispatcher handles
several client processes the dispatcher trace output can be a
mix of trace from many client processes making it VERY difficult
to follow. The general advice for such problems is:
a) See if the problem reproduces WITHOUT using MTS - if
so the trace is much cleaner
b) If a problem ONLY reproduces under MTS ensure the machine
is in a controlled environment so you can be sure that only
YOUR process is using the dispatcher.
7.5 Trace Summary
~~~~~~~~~~~~~
1) Identify where you need to trace.
2) Identify which files on which machines control tracing at these
points. Tracing is controlled in the following files:
Client Server Listener
~~~~~~ ~~~~~~ ~~~~~~~~
Files: $HOME/.sqlnet.ora sqlnet.ora listener.ora
sqlnet.ora
3) Add in the relevant trace parameters (See Below)
4) Restart any processes that need to read the new trace values.
Reload the listener as required.
5) Reproduce your problem
6) Save all your trace output immediately
7) Disable the tracing
7.6 Main Trace Parameters
~~~~~~~~~~~~~~~~~~~~~
trace_level_listener = off
trace_file_listener = Filename *1
trace_directory_listener = Directory *2
*1 Unquoted (") filenames will be translated into lower case.
*2 You CANNOT use environment variables in the Filename or Directory
name.
7.7 Diagnosing Trace output
~~~~~~~~~~~~~~~~~~~~~~~
Trace output can be very difficult to follow. Before looking at a
trace file make sure:
a) You are familiar with the sequence of events in setting up
a connection. SQL*Net connections follow a sequence of
events - you will need to determin where in the sequence
the problem occurs.
b) Do not be misled by error reports in the trace files. You
must follow the context of the errors - an error may be
quite valid at that point in a sequence. Eg: For client
connections a list of addresses to call is built - if the
first address yeilds no response the next address is tried.
This next address may yeild a response and the 'true' error
occurs at this point in the sequence.
c) Do not be misled by unusual 'Bequeath' connections in the
trace. If an error is received over SQL*Net the client
may use a "Bequeath" operation to spawn an oracle process
which it then uses to get the TEXT of the error. A very short
exchange of packets occurs and the bequethed process exits.
The 'TRUE' problem is likely to be before this bequeath
operation.
Useful trace 'tags':
The following are useful items to follow in trace files - these
are not guaranteed to be valid across all SQL*Net releases and
are for guidance only. Entries are assumed to be taken at trace
level 16 to allow data packets to be seen. This will produce a
LOT of trace output.
-<ERROR>-
Error information follows. Remember the error may be acceptable
osntns: Calling address
Shows address list constructed for a call OUT to a listener
nricall: Making call with following address information: ...
Shows the ACTUAL address being called from the above list
nsopen: entry
We are about to try and open a connection.
nsopen: transport is open
nsopen: error exit
A connection to the called address has been made / failed.
nsclose: ...
An established connection is being closed - check nearby
for errors.
nscall: redirected
The client has been redirected to a differenct address.
The next step should be to call the new address. The address
should appear in an earlier data packet.
nspsend / nsprecv
Outgoung / Incoming data

This forum is for Oracle Migration Workbench issues, i.e. migration using the workbench from a non Oracle database to an Oracle database.
Here are some pointers that may be useful, but you may need to get more information elsewhere, for example Oracle Customer Support.
a Oracle 7.1 client (including your example) will connect to an Oracle 8.1.5 server.
Is the server correctly configured (can a client connect from another machine)?
Tracing can be turned on in the client, server and/or listener to get further information.
Turloch

CLIENT SIDE TRACING IN SQL*NET V2

제품 : SQL*NET
작성날짜 : 1997-10-10
Client Tracing
~~~~~~~~~~~~~~
1) Set the environment variable TNS_ADMIN to the directory where the
tnsnames.ora and listener.ora files exist.
The default location is $ORACLE_HOME/network/admin. Set $TNS_ADMIN
to this if it is not set. This ENSURES you know which files you are
using.
2) Start the listener: lsnrctl
> set password <password>
> start
Note any errors. If you do not have a password set then ignore the
set password command.
3) If the listener started, start the database.
4) Create a file in $HOME called .sqlnet.ora and add the lines:
trace_level_client= 16
trace_file_client=client
trace_directory_client= /tmp (or similar)
trace_unique_client=true
5) Try to connect from SQL*Plus thus:
sqlplus username/password@alias
or
sqlplus username/password
substituting a suitable alias.
6) If you get an error we may need to see the client trace file
/tmp/client_<PID>.trc where <PID> is the process ID of the
client process (*1).
This will be quite large so it is best to FAX or EMAIL it.
*1 Note: On earlier versions of SQL*Net the filename may NOT have
the process ID appended to it.
Listener Tracing:
~~~~~~~~~~~~~~~~~
1) Edit your $TNS_ADMIN/listener.ora file and add the lines:
TRACE_LEVEL_LISTENER = 16
TRACE_DIRECTORY_LISTENER = /tmp
TRACE_FILE_LISTENER = "listener"
2) Stop and restart the listener:
lsnrctl stop
lsnrctl start
Output should go to /tmp/listener.trc

By default in 11g traces will go to the ADR which is a new feature.
To disable that feature add the following line to your sqlnet.ora
diag_adr_enabled =OFF
[oops] saw that this is over a month old this post - sorry about that!
hope that helps
John
Edited by: Johnsung on Sep 27, 2012 3:59 PM

About wait SQL*Net

Similar Messages

Maybe you are looking for