TCP/IP IN SQL*NET & SLIP / PPP

제품 : SQL*NET
작성날짜 : 1997-10-10
SLIP (Serial Line Internet Protocol)
SLIP 과 Ethernet 은 TCP/IP 을 구현하는 매체에 규정되어지는 두개의
PROTOCOL 입니다
SLIP은 serial/modem lines 에 사용되어지며, Ethernet은 Coaxial
cable 에 사용되어집니다
SQL*NET 에서는 이 두가지가 차이가 없으며, SQL*NET 은 이 두 가지를
단지 TCP/IP 로 볼 뿐입니다.
그림으로 보면 다음과 같읍니다
| SQL*Net |
| Tcp/ip |
-------------------+
| SLIP | Ether |
-------------------+
| Serial| Coax |
SLIP 대신에 PPP 를 사용하는 것은 serial TCP/IP 통신을 하는 새로운
방법입니다
이러한 방법은 SQL*NET 과는 직접적인 관련이 없으며, SQL*NET 은
Serial Line 을 통해 바로 접속이 됩니다.
따라서 Serial line (Modem)과 Ethernet (Lan card) 을 통한 접속은
TCP/IP 설정만 올바르게 되어있다면 SQL*NET 이상없이 접속할수
있으며 이상유무를 SQL*NET 에서 볼수는 없읍니다

When someone answers you, please forward the answer to my email. I am trying to connect to an Oracle db from Visual Basic, and need the component. I have downloaded software from this site, but it did not have the SQL Net.

Similar Messages

WINDOWS 용 SQL*NET 사용 시 TNS-12203

제품 : SQL*NET
작성날짜 : 2004-11-09
WINDOWS 용 SQL*NET 사용 시 TNS-12203
====================================
PURPOSE
TNS-12203 "TNS:unable to connect to destination"은 여러가지 원인 때문에
발생할 수 있습니다. 여기서는 가장 일반적인 몇 가지 원인을 설명합니다.
1. WINDOWS 용 TCP/IP 어댑터를 설치하지 않은 상태에서 연결하려 하면 TNS-
12203이 발생할 수 있습니다. SQL*NET TCP/IP V2는 SQL*NET V2와 V2 TCP/IP
어댑터 등 두가지 제품으로 구성됩니다. 이들은 별도의 두 키트로 되어 있는데,
반드시 두 키트를 모두 설치해야 합니다.
2. TNS-12203 에러는 WINDOWS 용 ORACLE SQL*NET소프트웨어가 ORACLE HOME
디렉토리를 찾을 수 없다는 의미일 수 있습니다. 이 문제를 해결하려면, 먼저
WIN.INI 화일의 ORACLE 부분에 다음 항목이 있는지 확인하십시오.
[ORACLE]
ORA_CONFIG=C:\WINDOWS\ORACLE.INI
WINDOWS디렉토리가 C:\WINDOWS가 아니면, 위 행의 C:\WINDOWS 부분을 그
이름으로 바꾸십시오. 그런 다음, ORACLE 소프트웨어를 다시 설치하십시오.
ORACLE.INI 화일이 있으면 그 ORACLE.INI 화일에 다음 행이 있는지
확인하십시오.
ORACLE_HOME=C:\ORAWIN
ORACLE 홈 디렉토리가 C:\ORAWIN이 아니면 위 행의 C:\ORAWIN 부분을 그
이름으로 바꾸십시오.
3. TNSNAMES.ORA가 ORACLE 홈 디렉토리 아래의 NETWORK\ADMIN에 있는지
확인하십시요. ORACLE 홈 디렉토리는 ORACLE.INI(또는 WIN.INI의
ORA_CONFIG 매개변수가 지시하는 파일)의 ORACLE_HOME 에 의해 정의됩니다.
4. 서버 쪽에서 실행 중인 SQL*NET V2 TCP/IP Listener가 없어도 TNS-12203이
발생할 수 있습니다. 서버 쪽에서 실행 중인 SQL*NET V2가 있는지 확인하십시오.
서버 쪽에서 Listener Control 유틸리티(LSNRCTL)를 사용하면 서버의 V2
Listener가 실행 중인지 확인할 수 있습니다. 서버에서 "LSNRCTL STATUS"
명령을 실행하십시오. Listener Control 유틸리티에 대해서는 SQL*NET
Administrator's Guide를 참조하십시오.
5. 연결할 SERVICES 이름에 대해 CONNECT DESCRIPTOR에 정확한 ADDRESS
매개 변수를 지정했는지 확인하십시오. 정확한 ADDRESS 매개변수를 사용 중인지
확인하는 방법은, WINDOWS 클라이언트에서 사용 할 것과 같은 ADDRESS 매개
변수를 가진 TNSNAMES.ORA를 사용하여 서버에서 루프백을 해 보는 것입니다.
루프백을 수행한다는 것은 데이타베이스와 같은 기계에서 SQL*DBA 등을
호출하고 연결 스트링을 지정함으로써 SQL*NET V2를 통해 연결한다는 뜻입니다.
6. JSB VSL 소켓이 초기화되지 않으면 TNS-12203이 발생할 수 있습니다. 이
문제를 해결하려면 다음 사항을 점검하여 JSB VSL 레이어가 정확하게
초기화되었는 지 확인하십시요.
1) ORACLE.INI 파일(또는 WIN.INI의 ORA_CONFIG 매개변수가 지시하는 파일)의
업체키 매개변수 TCP_VENDOR가 정확하게 설정되었는 지 확인하십시요
2) ORACLE_HOME\BIN 디렉토리에 MSOCKLIB.DLL이 있는지 확인하십시요.
3) ORACLE_HOME\BIN 디렉토리에 선택된 JSB 업체 특유의 DLL이 있는지, 또는
그 JSB 업체 특유의 TSR 파일이 실행되는 지 확인하십시요.
4) WINDOWS 홈 디렉토리에 VSL.INI 파일이 있는 지 확인하십시요.
7. TNS-12203에 이어 실제 문제가 무엇인지 더 자세하게 나타내 주는
또 다른 에러가 발생할 수 있습니다. 화면에서 다른 에러가 보이지 않으면
ORACLE_HOME\NETWORK\LOG 디렉토리의 SQLNET.LOG 파일을 점검하십시오.

change (Port = 1526) to 1521 and try to connect
add the entry to tnsnames.ora file on both client and server
ORCL =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST =192.168.25.16 )(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
    (CONNECT_DATA =
      (SID = PLSExtProc)
      (PRESENTATION = RO)
)Edited by: rajeysh on May 15, 2011 3:02 PM

처음 사용자를 위한 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

FUTURE TCP 와 SQL*NET V2 사용시 PERFORMANCE

제품 : SQL*NET
작성날짜 : 1995-05-04
Subject: Re: Know How..[ 2. Future/tcp 사용시]
두번째 항목의 경우 future/tcp 에서 Named Server를 잘못설정하면 Host의
Named Server를 다 찾고서, 없으면 Client의 host file을 뒤져서 자기 host
alias로 처리하는 경우가 있었습니다.(1-2초 걸리던 connection time이 12초
까지 걸렸음)
경남은행에도 SLIP으로 테스트를 하는데 SQL*Net을 통하면 엄청 늦다고 계속
불평 해서 가서 보니까 SQL*Net의 문제가 아니라 future/tcp의 Client host
file과 Named Server의 Host file의 불일치 때문으로 판명난 적이 있었습니다.
이런경우,
1. Client에서 future/tcp의 install program으로 Named Server를 없애든지
2. Host와 Client의 Host file을 일치 시키면 되었습니다.
sql*net v1 & v2 test 지원 중 발견된 사항입니다.
1.
아직도 많은 사용자가 sql*net v2 가 별 효과가 없다고 생각합니다. 이런
user는 주로 MTS 환경으로 setting은 하였으되 shared server와 dispatcher를
한개씩 뛰우고 사용하고 있었읍니다.
근본적으로 oracle의 mts는 FIFO 방식으로 SQL을 처리하기 때문에 server가
하나만 떠 가지고는 당연히 sql*net v1의 dedicated server 보다 느리게
처리됩니다.
따라서 mts 환경으로 setup 할 때에는 최소한 shared server와 dispatcher를
2개 이상씩 (3개이상 권유) 뛰워서 사용할 수 있도록 하기 바랍니다.
일부에서는 이런이유로 oracle mts 기능이 별볼일 없더라 라고 오해하며
옆사람에게도 전달하고 있습니다.
2.
future tcp/ip 사용시에 tnsnames.ora에 host name 을 사용하면 sql*net v2 가
v1보다 3배 정도 더 느리게 되는데 이때에는 ip address number를 직접사용하면
됩니다.
삼성전관 pdss test시 connection time : sql*net v1 --> 6-8초
sql*net v2 host name --> 25초
sql*net v2 ip number --> 2-3초

Yes, it seems to be a kernel bug. Previously, my wife used Windows for years and nothing like this happened. Now, she tells a lot about Linux systems :-)
An example of this very-ugly-workaround for somebody who'll find this topic struggling with the same problem:
$ cat /etc/pm/sleep.d/99_fix_time_shift
#!/bin/bash
# fixing https://bbs.archlinux.org/viewtopic.php?id=173487
case "$1" in
suspend)
date +%s > /tmp/suspend.log
resume)
was=`cat /tmp/suspend.log`
now=`date +%s`
# time shifts for 68 hours
if [ $now -gt `expr $was + 244800` ]; then
date -s "`date -R --date="-68 hours ago"`"
## sleep 30; ntpdate ntp.ubuntu.com
fi
esac
Last edited by shurup (2014-03-26 16:25:55)

SQL*NET for TCP/IP

Where can i download SQL*NET for tcp/ip?

When someone answers you, please forward the answer to my email. I am trying to connect to an Oracle db from Visual Basic, and need the component. I have downloaded software from this site, but it did not have the SQL Net.

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

TNS: connection closed error with SQL*net

Hi all,
I've got a new installation of Oracle 11.1.0.6.0 enterprise (Linux). It works fine with direct sqlplus connections but I'm having problems with SQL*net and JDBC thin client connections.
The database is built correctly and works fine:
user@cthulhu bash[61]: sqlplus user/pwd
SQL*Plus: Release 11.1.0.6.0 - Production on Mon Aug 4 12:59:53 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
SQL>
but if I try to connect using SQL*net I get errors. I have my TNS listener configured and it starts without errors, reporting the database as a service, and tnsping is fine:
user@cthulhu bash[62]: tnsping cthulhu_mar
TNS Ping Utility for Linux: Version 11.1.0.6.0 - Production on 04-AUG-2008 13:02:07
Copyright (c) 1997, 2007, Oracle. All rights reserved.
Used parameter files:
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.2.30)(PORT=1521)) (CONNECT_DATA=(SID=mar)))
OK (10 msec)
user@cthulhu bash[63]: sqlplus user/pwd@cthulhu_mar
SQL*Plus: Release 11.1.0.6.0 - Production on Mon Aug 4 13:02:41 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
ERROR:
ORA-12537: TNS:connection closed
Enter user-name:
In listener.log:
Mon Aug 04 13:02:41 2008
04-AUG-2008 13:02:41 * (CONNECT_DATA=(SID=mar)(CID=(PROGRAM=sqlplus)(HOST=cthulhu)(USER=marbur))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.2.30)(PORT=41754)) * establish * mar * 12518
TNS-12518: TNS:listener could not hand off client connection
TNS-12547: TNS:lost contact
TNS-12560: TNS:protocol adapter error
TNS-00517: Lost contact
Linux Error: 32: Broken pipe
This is a new instance of Oracle so there is no problem with listener.log being too large (as I've seen elsewhere). I've also tried increasing PROCESSES and SESSIONS in the initSID.ora file without any impact. The listener ports are open through the firewall (and disabling it temporarily makes no difference).
Any suggestions?!
Thanks, Matt

This means nothing to me, but it could to someone else......
from listener trace:
2008-08-04 16:19:05.135381 : nlpcaini:env[161] = OLDPWD=/u01/app/oracle/product/11.1.0/db_1
2008-08-04 16:19:05.135407 : nlpcaini:env[162] = ORA_NET2_DESC=12,15
2008-08-04 16:19:05.135432 : nlpcaini:env[163] = ORACLE_SPAWNED_PROCESS=1
2008-08-04 16:19:05.135465 : nlpcaini:exit
2008-08-04 16:19:05.135498 : nsc2addr:normal exit
2008-08-04 16:19:05.135536 : nsbeqaddr:entry
2008-08-04 16:19:05.135566 : nsbeqaddr:connecting...
2008-08-04 16:19:05.135603 : nsopen:entry
2008-08-04 16:19:05.135633 : nsmal:entry
2008-08-04 16:19:05.135667 : nsmal:1012 bytes at 0x81a8538
2008-08-04 16:19:05.135694 : nsmal:normal exit
2008-08-04 16:19:05.135722 : nsopenmplx:entry
2008-08-04 16:19:05.135749 : nsmal:entry
2008-08-04 16:19:05.135779 : nsmal:2020 bytes at 0x81a8930
2008-08-04 16:19:05.135804 : nsmal:normal exit
2008-08-04 16:19:05.135831 : nsiorini:entry
2008-08-04 16:19:05.135861 : nsbal:entry
2008-08-04 16:19:05.135889 : nsbgetfl:entry
2008-08-04 16:19:05.135918 : nsbgetfl:normal exit
2008-08-04 16:19:05.135966 : nsmal:entry
2008-08-04 16:19:05.135995 : nsmal:84 bytes at 0x81b3dd8
2008-08-04 16:19:05.136020 : nsmal:normal exit
2008-08-04 16:19:05.136057 : nsbal:normal exit
2008-08-04 16:19:05.136085 : nsiorini:exit (0)
2008-08-04 16:19:05.136112 : nscpxget:entry
2008-08-04 16:19:05.136139 : nscpxget:normal exit
2008-08-04 16:19:05.136168 : nsopenalloc_nsntx:nlhthput on mplx_ht_nsgbu:ctx=81a8538, nsntx=81a8930
2008-08-04 16:19:05.136196 : nsopenmplx:normal exit
2008-08-04 16:19:05.136225 : ntpcon:entry
2008-08-04 16:19:05.136253 : ntpcon:toc = 6
2008-08-04 16:19:05.136283 : ntpcon:exit
2008-08-04 16:19:05.136313 : nsopen:opening transport...
2008-08-04 16:19:05.136341 : ntpcon:entry
2008-08-04 16:19:05.136367 : ntpcon:toc = 1
2008-08-04 16:19:05.136404 : sntpcall:entry
2008-08-04 16:19:05.157048 : sntpcall:detaching from parent with additional fork
2008-08-04 16:19:05.157304 : sntpcall:hdl[IR]=17, hdl[IW]=16
2008-08-04 16:19:05.157350 : ntpcon:exit
2008-08-04 16:19:05.157390 : nserror:entry
2008-08-04 16:19:05.157428 : nsoptions:entry
2008-08-04 16:19:05.157459 : nsoptions:lcl[0]=0x0, lcl[1]=0x2006, gbl[0]=0x0, gbl[1]=0x0, cha=0x0
2008-08-04 16:19:05.157488 : nsoptions:Vectored IO not supported.
2008-08-04 16:19:05.157518 : nsoptions:lcl[0]=0xf4ffe9ff, lcl[1]=0x6016, gbl[0]=0xe881, gbl[1]=0x0
2008-08-04 16:19:05.157545 : nsoptions:normal exit
2008-08-04 16:19:05.157574 : nsnainit:entry
2008-08-04 16:19:05.157603 : nsnainit:normal exit
2008-08-04 16:19:05.157642 : nsopen:global context check-in (to slot 6) complete
2008-08-04 16:19:05.157675 : nsopen:lcl[0]=0xf4ffe9ff, lcl[1]=0x6016, gbl[0]=0xe881, gbl[1]=0x0, tdu=4096, sdu=8192
2008-08-04 16:19:05.157706 : nsfull_opn:entry
2008-08-04 16:19:05.157735 : nsfull_opn:cid=6, opcode=65, bl=0, what=0, uflgs=0x0, cflgs=0x0
2008-08-04 16:19:05.157761 : nsfull_opn:nsctx: state=7, flg=0x4001, mvd=0
2008-08-04 16:19:05.157790 : nsfull_opn:normal exit
2008-08-04 16:19:05.157816 : nsopen:normal exit
2008-08-04 16:19:05.157854 : nsevreg:entry
2008-08-04 16:19:05.157884 : nsevreg:begin registration process for 6
2008-08-04 16:19:05.157912 : nsevregPrePost:entry
2008-08-04 16:19:05.157940 : nsevregPrePost:normal exit
2008-08-04 16:19:05.157968 : nsevreg:sgt=0, evn=1, evt[2]=0x0
2008-08-04 16:19:05.157996 : nsevreg:begin notification process for 6
2008-08-04 16:19:05.158022 : nsevregAffectNotif:entry
2008-08-04 16:19:05.158050 : nsevregAffectNotif:exit (0)
2008-08-04 16:19:05.158078 : nsevreg:rdm=0, sgt=0, evt[0]=0x800, [1]=0x800, [2]=0x0, nrg=0
2008-08-04 16:19:05.158105 : nsevreg:registering for 0x800
2008-08-04 16:19:05.158135 : ntpctl:entry
2008-08-04 16:19:05.158162 : ntpctl:exit
2008-08-04 16:19:05.158203 : nsevreg:normal exit
2008-08-04 16:19:05.158260 : nsbeqaddr:error exit
2008-08-04 16:19:05.158289 : nsbequeath:error exit
2008-08-04 16:19:05.158342 : nsglhe:exit

WINDOWS 용 SQL*NET V1 사용 시 ORA-6136 조치 방법

제품 : SQL*NET
작성날짜 : 1995-11-07
WINDOWS 용 SQL*NET V1 사용 시 ORA-6136 조치 방법
===============================================
Client and Server 환경에서 간혹 SQL*NET으로 Server에 접속하려고 할 때,
ORA-6136 Error가 발생하면서 Unix Server에서 $tcpctl stop 으로 orasrv의
Process를 정지시키려고 해도 아무런 반응없이 Holding되는 경우가 발생하면서
다음과 같은 메서지가 나타납니다.
06136, 00000, "NETTCP: error during connection handshake"
// *Cause: Network I/O failure occurred while communicating with the
// host's SQL*Net TCP/IP server.
// See the SQL*Net TCP/IP server log file for more details.
// *Action: Contact your customer support representative.
상기의 에러가 나타날 경우에는 아래와 같은 방법으로 orasrv를 기동시키십시오.
1. TCPCTL Utility를 이용하여 다음의 Option을 부여하여 Start하는 방법.
$tcpctl start listen=30 timeout=30 forkon
listen=<queue size>이며, 청취자 열의 크기를 지정.
timeout=<seconds>이며, 지정된 시간에 orasrv와의 응답 확인 시간을 나타냄.
forkon SQL*net이 orasrv process에 접근하는 방법을 나타냄.
System에 따라서 forkon option이 적용 않되는 경우도 있음.
2. Client에서 접속을 하여 사용하다가 비정상 종료(Session이 맺어진 상태에서
Client의 Power Off)를 하여 Server에 Processor가 남아 있고, orasrv를 통해
접속할 수 있는 Session의 수가 점점 줄어들 경우가 있는 데 이러한 경우에는
orasrv를(tcpctl stop or UNIX kill command를 이용)강제로 종료하시고 다음과
같이 Start 시켜 주십시오.
#nohup tcpctl start ( Client의 비정상 종료가 Orasrv에는 영향을 미치지 않음)
또는
#orasrv (ORACLE_HOME\bin directory에서 직접 orasrv processor를 띄운다)

SQL*NET V1, V2의 STATUS를 확인하는 방법

제품 : SQL*NET
작성날짜 : 1995-11-06
* SQL*NET V 1의 적절한 사용 방법
ORASRV의 Permission, Owner 및 Group은 다음과 같이 설정이 되어 있어야 하며
파일의 Size는 Version에 따라 다를 수 있다.
-rwsr-xr-x 1 oracle dba 7544832 Jul 21 20:35 oracle
-rwsr-xr-x 1 root dba 303104 Jul 5 19:24 orasrv
만일 위와 같지 않다면 Unix 명령 프롬프트에서 다음을 수행하여 모드를 바꾸어
준다.
#chmod 4755 oracle
#chown root orasrv <= orasrv의 owner는 반드시 root로 되어야 합니다.
#chmod 4755 orasrv
1. SQL*NET V1을 사용하면서 가장 일반적으로 orasrv를 시작 및 정지 하는
경우이다.
#tcpctl start ( stop )
2. orasrv의 현상태를 확인하는 방법
#tcpctl status
tcputl: Status summary follows
Server is running :
Started : 4-OCT-95 15:58:48
Total connections : 0
Total rejections : 0
Active subprocesses : 0
ORACLE SIDs : RC,ORA722
Default SID : (null)
Logging mode is ENABLED.
DBA logins are DISABLED.
OPS$ logins are ENABLED.
OPS$ROOT logins are DISABLED.
Orasrv is detached from the terminal.
Break mode = OUT OF BAND.
Debug level = 1
Timeout (on orasrv handshaking) = 5 seconds.
Length of listen queue = 10
Orasrv logfile = /users2/oracle7/tcp/log/orasrv.log
Orasrv mapfile = /etc/oratab
* SQL*NET V2의 적절한 사용 방법
SQL*NET V2를 사용하는데 있어서 갖추야 할 파라미터 파일이 있다.
기본으로 listener.ora,tnsnames.ora,sqlnet.ora가 $ORACLE_HOME/network/admin
directory내에 있어야 합니다.(상기 파일에 대한 configuration은 SQL*NET
Administrator's Guide v 2.0을 참고하시기 바랍니다.)
1. SQL*NET V2을 사용하면서 가장 일반적으로 listener를 시작 및 정지 하는
경우이다.
#lsnrctl start (stop)
2. Oracle과 Listener의 Process를 확인하는 방법
$ ps -ef |grep ORA7
ora7 1343 1 7 Aug 22 ? 30:53 ora_dbwr_ORA7
ora7 1342 1 7 Aug 22 ? 0:32 ora_pmon_ORA7
ora7 1346 1 7 Aug 22 ? 0:00 ora_reco_ORA7
ora7 1347 1 7 Aug 22 ? 0:00 ora_s000_ORA7
ora7 1345 1 7 Aug 22 ? 12:25 ora_smon_ORA7
ora7 1344 1 7 Aug 22 ? 58:57 ora_lgwr_ORA7
ora7 1348 1 7 Aug 22 ? 0:00 ora_s001_ORA7
ora7 8036 1 7 Aug 22 ? 0:00 /ora/ora7/bin/tnslsnr LISTENER -
inherit
ora7 24279 1342 7 09:40:16 ? 0:05 ora_d001_ORA7
ora7 899 1342 7 14:54:36 ? 0:21 ora_d000_ORA7
3. Listener의 현상태를 확인하는 방법
$ lsnrctl service
LSNRCTL for 88open UNIX: Version 2.0.14.0.0 - Production on 24-AUG-94
09:19:37
Copyright (c) Oracle Corporation 1993. All rights reserved.
Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=ORA7))
Services Summary...
ORA7 has 3 service handlers
DEDICATED SERVER established:0 refused:0
DISPATCHER established:0 refused:0 current:0 max:60 state:ready
D000 (machine: AViiON, pid: 899)
(ADDRESS=(PROTOCOL=tcp)(DEV=6)(HOST=152.68.1.11)(PORT=2753))
DISPATCHER established:0 refused:0 current:0 max:60 state:ready
D002 (machine: AViiON, pid: 1357)
(ADDRESS=(PROTOCOL=ipc)(DEV=5)(KEY=#1357.1))
The command completed successfully
4. SQL*NET V2를 MTS와 DEDICATE방식으로 사용코자 할때.
MTS 방식 : ps -ef | grep s0 으로 시작하는 공유 process 를
띄어두고, tnsnames.ora 에 MTS 와 같은 alias 를
사용하여 접속한 session 들이 각각의 oracle process 를
띄우지 않고, 공유 process 를 사용하는 방법
dedicate 방식 :
tnsnames.ora 에 MTS_DED 와 같은 alias 를 사용하거나, alias 없이
server 에서 접속하는 유저들은 각각의 oracle process 를
기동시켜고 공유하지 않는다
$cd $ORACLE_HOME/network/admin/tnsnames.ora
MTS =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = Hostname)
(PORT = 1521)
(CONNECT_DATA =
(SID = ORA7)
MTS_DED =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = Hostname)
(PORT = 1521)
(CONNECT_DATA =
(SID = ORA7)
(SRVR = DEDICATED)
5. SQL*NET V2 Pipe Adapter를 사용중이라면 ps command를 통해서
oracleSID (LOACL=YES)라는 Shadow Process로써 확인 할 수 있다.

오랬만에 게시판에 들어오니 좀 썰렁하네요..
자주 들어와서 확인좀 하겠습니다.
SQL*NET V1 프로세스 수동 기동 중지는
기동
tcpctl start 중이
tcpctl stop

SQL*NET V1 사용 시 ORA-6107 조치 방법

제품 : SQL*NET
작성날짜 : 2005-11-06
* Windows용 SQL*NET TCP/IP Ver 1.X는 SQLTCP.DLL과 SQLTCP1.DLL 두 개의
DLL이 하나로 구성되어 있다. 이들 DLL은 ORACLE용 연결 스트링이 TCP/IP
프로토콜 스트링으로 확인되면 작업진행중에 OCI DLL에 의해 올려진다.
ORACLE Interface DLL은 SQLTCP.DLL을 먼저 올리려고 한다. 이것이 실패하면
DOS TSR 버전의 드라이버를 찾는다. 두 가지 모두 실패하면 ORA-3121
메세지가 나온다.
1. SQL*NET TCP/IP DLL이 올려지고 초기화가 되는 즉시 Logon 시도를 시작한다.
2. 이때 모든 것이 정상적이라면 logon시 제공된 연결 스트링내의 I.P
Address대신 Hostname을 사용하여 해결해 본다. 이러한 과정이 정상적이라면
클라이언트측의 통신관련 디렉토리에 있는 Services 화일에 Oracle Service's
Portnumber를 제대로 부여한 것이며 SQL*NET TCP/IP DLL이 ORACLE.INI ( 또는
WIN.INI의 [Oracle] session의 ORA_CONFIG=<path>\ORACLE.INI에 기술된 내용)
내에 기술된 TCP_SERVICES_FILE = <network protocol path> \services 을
사용한다는 것이다.
ORACLE Service를 받는 Part Number SERVICES files내에 "orasrv" 라고
기술된다. SERVICES File의 예를 보면 하단과 같다.
# This list has been derived from RFC1060
# TCP Ports
# Service Name Port/Protocol Aliases
echo 7/tcp
discard 9/tcp sink null
systat 11/tcp users
listener 1521/tcp oracle ？ SQL*NET V2 인 경우
orasrv 1525/tcp oracle ？ SQL*NET V1 인 경우
3. 만일 TCP_SERVICES_FILE에 SERVICES화일이 구성되어있지 않았다면
"orasrv"의 접속이 실패된다. 만일 SERVICES File Name이 제대로 구성되어
있다면 file내에 표현되어 있는 "orasrv" 항목을 점검한다. SERVICES File
내의 각 항목 끝에 <CARRIAGE RETURN> 이 없을 경우나 "orasrv" line 상에
<TAB>이 있을 경우에도 이러한 메세지를 수반한다.
* ORA-6107을 진단하는 방법
1. ORA-6107의 경우 ORACLE.INI내의 TCP_SERVICES_FILE이 무엇인지 (또는
WIN.INI내의 [ORACLE] Section에 ORA_CONFIG가 무엇인지)를 점검한다.
- ORACLE.INI의 경우
TCP_SERVICES_FILE=<path>\SERVICES
- WIN.INI의 경우
ORA_CONFIG=c:\windows\oracle.ini
- 만약 설정이 되어 있지 않았다면 Client상에서 사용하고 있는 특정 TCP/IP
Vendor에서 사용하고 있는 SERVICES 화일을 찾고 그 화일내에 Parameter를
설정한다.
2. 만일 TCP_SERVICES_FILE에 설정되어 있는 SERVICES 화일의 위치가 맞는다면
화일내에 "orasrv" 항목을 점검하여 본다. 화일내에 <TABS>를 확인해 본다.
화일내의 각 항목 끝에 <Carrige Return>이 있는지 확인한다.
3. 만일 이 모든 것이 정상적이라면 새로운 SERVICES 화일내에 "orasrv" 항목을
추가한다.
4. 만약 SERVICES 파일의 도움없이 개발 응용프로그램에서 직접 접속을 시도할
경우에는 명시적으로 다음과 같이 Connect String에서 Port Number을 사용하여
접속할 수 있다.
"t:<server name or ip address>/<port number>:<instance name>"
[주의] instance name = ORACLE SID
5. tcp_services_files=%drive1%\path%\services
[주의 1] ORACLE TCP/IP Listener의 기본 시작포트 번호는 십진수 1525 이다.
SERVICES 파일은 대부분의 장비에 /etc 디렉토리안에 있으며 또한, "tcpctl"
Utility를 사용하여 UNIX 장비상의 ORACLE orasrv 를 Start 시키고 Stop할
수 있다. Orasrv 를 정지하려면 "tcpctl stop"을 사용하고 다시 시작하려면
"tcpctl start"를 사용한다.
BUG 1 : 다음과 같은 경우에도 에러가 발생할 수가 있다.
orasrv 1525/tcp<CR>
위와 같이 기술되었을 경우 다음과 같이 하게되면 ora-6107 error 없이 접속이
가능하다. 즉, orasrv항목에서 <CR>전에 공란이 있을 경우에 에러없이
접속할수 있다.
orasrv 1525/tcp <CR>
* 이 버그는 v1.1.7.10.1 이후 버젼에서는 수정되었다.
BUG 2 : 동일한 응용 프로그램에서 동일한 Connect String으로 접속을
시도하였을 때 에러가 발생한다면 다음과 같이 Connect String에 Port
Number를 사용한다.
t:<host name>/<port number>:<oracle_SID>
* 이 버그는 v1.1.7.9 이후 버젼에서는 수정되었다.

SQL*NET SESSION의 DEAD CONNECTION 처리 방법

제품 : SQL*NET
작성날짜 : 1996-04-03
SQL*NET SESSION의 DEAD CONNECTION 처리 방법
==========================================
server에서 수행 중이던 프로그램이 비정상 종료한 경우에는 오라클의 smon이
자동으로 detection하여 수행 중이던 transaction을 rollback하여
정리하여 준다.
그러나, Client Server 환경에서 PC를 Client로 사용 시 비정상적인 방법으로
Server와 Disconnect 하면 Server 쪽에 있는 Dedicated Server가 남아 있다.
이는 Sql*net V1 & V2에서 발생하던 문제로 Sql*net V2.1 이후에는 아래와
같은 방법을 이용하면 Dead connection이 정상적으로 Disconnect 된다.
* 환경 : Server - Sql*net tcp/ip V2.1.3
Client - Sql*net V2.0
* Setup 방법 : Server와 Client에 있는
$ORACLE_HOME/network/admin/sqlnet.ora에
sqlnet.expire_time=n
으로 setting 한다.
여기서 n은 분 단위이며 실제 disconnect는 n분보다 더 걸린다.
일반적으로 sqlnet.expire_time=1로 설정하면 적당하다.

Hi,
Probe send - client and application still there - all fine
Network cable on the client is removedAt the above stage if the Sever sents a probe then if does not receive any message from Client it is treated as DCD. (It will receive any error code or negative response from client instead of any active status communication)
Application is shut down
(Optionally the computer is rebooted)
Network cable is reattached
Next probe send from server
At this point, the client is reachable, the Oracle NET component on the client is there, but the application on the client is gone without properly saying good bye to the DB server.
Would DCD detect the dead connection in this sceanrio?If my above comment is dismissed and your case or assumptions continues, then we need to check the SQL_EXPIRE time which you have connected. If the every thing happens with in the time setted for Expire time then, still it will treat as DCD, your session is getting terminated the system got rebooted.
You understanding with DCD is correct.
We see sessions in V$SESSIONS that don't have a process on the client any more. We have SQLNET.EXPIRE_TIME set to 2 minutes on the server, but still these sessions show up after days. Sessions show up as inactive and are waiting on "SQL*NET message from client" for hours and days.See basically INACTIVE and DCD are different. Slight difference exits. As you said you find inactive sessions. If you want to cleanup those inactive sessions, as per oracle documenation, you can create a custom profile as per your requrement and assign some IDLE_TIME and update the respective user profile. That might help you out.
- Pavan Kumar N

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 V2 에서 BUFFER SIZE 지정 방법

제품 : SQL*NET
작성날짜 : 1996-04-15
SQL*NET V2와 ODBC Driver를 사용하는 경우 Power Builder, Visual Basic,
SQL Windows, Object View, Excel, Access 등과 같은 프로그램을 사용하면서
대량의 데이타를 처리하는 경우 세션이 끊어지거나 하는 문제가 발생을 하면
SQL*NET V2의 Buffer Size를 줄여 줌으로써 문제를 해결할 수 있습니다.
PC의 tnsnames.ora화일에 SDU 를 적용하여 다음과 같이 수정하면 됩니다.
만약 SDU를 적용하여도 문제가 해결이 안된다면 DEDICATED 방식으로 접속
을 하여서 사용하기 바랍니다.
tnsnames.ora 화일의 위치
16BIT SQL*NET : c:\orawin\network\admin
32BIT SQL*NET : c:\orawin95\network\admin
=======================
SDU (Session Data Unit)
=======================
Syntax : SDU=n (Byte)
Range for 'n': 512 <= n <= 2048
Default value = 2048 Bytes.
=========
바꾸기 전
=========
TORA =
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(PORT=1521)
(HOST=krhp2)
(CONNECT_DATA=(SID=RC))
=======
바꾼 후
=======
TORA =
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(PORT=1521)
(HOST=krhp2)
(CONNECT_DATA=(SID=RC))
(SDU=1024)
단, 서버가 ORACLE V7.3 인 경우에는 SDU를 서버쪽에도 세팅할 수 있다.
서버의 listener.ora 화일에서
========
바꾸기 전
========
SID_LIST_LIST73 =
(SID_LIST =
(SID_DESC =
(SID_NAME = ORA73)
(ORACLE_HOME=/oracle2/ora73/app/oracle/product/7.3.2)
=======
바꾼 후
=======
SID_LIST_LIST73 =
(SID_LIST =
(SID_DESC =
(SDU=1024)(SID_NAME = ORA73)
(ORACLE_HOME=/oracle2/ora73/app/oracle/product/7.3.2)
와 같이 변경해 주면 된다. 서버와 클라이언트 양쪽에 SDI가 세팅된 경우에는
두 값중 작은 값을 사용하게 된다.

I have 4 redo log groups with one member each, size of each redo log file is 128 MB( By doing some research on internet I found the solution to increase the redo logs file size which I tried upto 400MB each still getting the same error. If there is any other way to check optimal size of REDO FILES, without changing the size of FAST_START_MTTR_TARGET please share with me). Use below doc to check redo log optimum size. And also as per note mentioned by Justin you can ignore the alert as its not going to harm your database.
274264.1 (10g New Feature - REDO LOGS SIZING ADVISORY)
Mark your Post as Answered or Helpful if Your question is answered.
Thanks & Regards,
SID
(StepIntoOracleDBA)
Email : [email protected]
http://stepintooracledba.blogspot.in/
http://www.stepintooracledba.com/

SQL*NET V2 SETUP (MTS)

제품 : SQL*NET
작성날짜 : 1997-06-23
SQL*NET V2 SETUP (MTS)
======================
UNIX에서 SQL*NET V2를 사용하려면 ORACLE 인스톨 후에 다음과 같이 SETUP을 한
다음 사용하면 된다. 여기서
ORACLE_HOME DIRECTORY는 /usr/oracle7
ORACLE_SID는 ORA7
이라고 가정한다.
1. (단, MTS로 setting하지 않고 dedicated로 접속할 때에는 이 과정은 생략하도록
한다.)
Multi-threaded server 프로세스들을 먼저 기동을 하여야 한다.
$ORACLE_HOME/dbs/initSID.ora 화일에 다음과 같은 내용을 추가하고
DB 를 다시 startup 을 한다
# Filename : /usr/oracle7/dbs/initSID.ora
# Protocol : tcp
mts_dispatchers="tcp, 3"
mts_max_dispatchers=10
mts_servers=5
mts_max_servers=10
mts_service=ORA7
mts_listener_address="(ADDRESS=(PROTOCOL=tcp)(port=1521)
(host=hostname))"
2. tnsnames.ora 및 listener.ora 를 작성한다. 이 화일들은
/usr/oracle7/network/admin 디렉토리에 만들어야 하며 유닉스 환경변수를
TNS_ADMIN=$ORACLE_HOME/network/admin
과 같이 지정하고 사용하는 것이 좋다.
<EXAMPLE>
# File name : /usr/oracle7/network/admin/listener.ora
# This configuration supports tcp
LISTENER =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)
(HOST = hostname)
(PORT = 1521)
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER = 0
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = ORA7)
(ORACLE_HOME=/usr/oracle7)
# Filename : /usr/oracle7/network/admin/tnsnames.ora
TORA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)
(HOST = hostname)
(PORT=1521)
(CONNECT_DATA =
(SID = ORA7)
3. Listener process를 start한다.
$lsnrctl start
4. SQL*NET v2 를 사용하여 MTS 에 접속한다.(LOOPBACK TEST)
$ sqlplus scott/tiger@TORA
5. CLIENT에서 접속하는 경우라면 위에서 만든 tnsnames.ora 화일을 CLIENT의
$ORACLE_HOME/network/admin 디렉토리에 COPY 하기만 하면 된다.
6. 예를 들어 CLIENT가 WIN95라면 C:\ORAWIN95\NETWORK\ADMIN 디렉토리에
tnsnames.ora 화일을 COPY하면 된다. 만약 ORA-12154 에러가 발생하면
C:\ORAWIN95\NETWORK\ADMIN 디렉토리에 sqlnet.ora가 있는지 확인하고
이것을 sqlnet.old 같이 다른 이름으로 rename 한 후에 접속테스트를 해
보도록 한다. sql*plus(plus33.exe or plus33w.exe)로 접속하는 경우
다음과 같이 접속하면 된다.
USERNAME scott
PASSWORD tiger
HOST STRING TORA
* SERVER가 WINDOWS NT인 경우에는 다른 부분은 UNIX와 동일하게 setup하면
되고 단지 Listener를 띄우는 방법만 다르다.
제어판 -> SERVICES 에서 ORACLE 관련 SERVICE들을 모두 START 시켜주면 된다.

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

SQL*NET V2 최적화하기

제품 : SQL*NET
작성날짜 : 2001-04-25
SQL*NET V2 최적화하기
====================
1) PING
TCP/IP 네트워크상에서 ping을 사용해서
client와 server간에 걸리는 시간을 check할 수 있다.
만일 이 시간이 오래 걸리면 SQL*Net 보다 이 문제를 먼저 해결해야 한다.
사용 방법 :
ping 호스트이름
(NT의 경우에는 dos command상태에서)
2) TNSPING
이 tool은 기본적으로 설치가 되어 있으며
이 tool을 가지고 user가 client에 setting한 TNS alias(tnsnames.ora
파일안에 설정)
가 정상적으로 동작하는지를 테스트해 볼 수 있습니다.
TNSPING은 접속하고자하는 database가 있는 machine의 listener에 접속을하고
걸리는 시간을 miliseconds로 표시해 줍니다.
(실제 db와 connection을 맺는 것은 아닙니다.)
사용 방법 :
tnsping TNSalias이름
(NT의 경우에는 dos command상태에서)
3) 모든 logging 과 tracing 막기
Tracing은 client와 server에 모두 가능하게 할 수 있습니다.
다음 parameter를 SQLNET.ORA파일과 LISTENER.ORA파일
( $ORACLE_HOME/network(또는 net80)/admin에 위치합니다 )
에 setting하고 listener를 restart
(lsnrctl stop, lsnrctl start)
하면 SQL*Net의 모든 tracing을 막을 수 있습니다.
SQLNET.ORA:
TRACE_LEVEL_CLIENT =OFF
TRACE_LEVEL_SERVER =OFF
TNSPING.TRACE_LEVEL=OFF
'OFF'대신에 '0'을 사용해도 됩니다.
LISTENER.ORA:
TRACE_LEVEL_LISTENER=OFF
LOGGING_LISTENER=OFF
4) Listener log 파일들 지우기
만일 listener의 logging이 설정되어 있는 상태라면 LISTENER.LOG 파일이
이 생깁니다. listener는 connection이 맺어질대 마다 이 파일에
lock을 걸고 write하기 때문에 size가 계속 증가하게 되어 문제가 생길 수
있습니다. 만일 LISTENER.LOG 파일의 size가 너무 크게 되면 rename을 하시기
바랍니다. 그리고 listener를 restart하면 새로운 log file이 만들어 집니다.
5) SQLNET.ORA에 AUTOMATIC_IPC를 OFF로 설정
AUTOMATIC_IPC = { ON | OFF }
위 parameter는 "SQLNET.ORA"파일에 설정할 수 있으며 ON으로 되어 있는경우
SQL*Net이 같은 alias정보를 가진 local database가 있는지 check하게
됩니다.
만일 local database가 있다면 connection은 network layer를 건너뛰고 local
'Inter Process Communication'(IPC) connection을 맺게 됩니다.
따라서 이 setting은 database server쪽에 사용할 수 있는 것이지
client machine SQL*Net에는 아무 쓸모 없습니다.
database server쪽에 사용하더라도 local database에 SQL*Net connection이
반드시 필요한 경우가 아니라면 사용하시 않는 것(OFF로 설정)이 좋습니다.
6) SQLNET.ORA에 NAMES.DIRECTORY_PATH 설정
NAMES.DIRECTORY_PATH = (ONAMES,TNSNAMES)
이 parameter는 TNS aliases를 찾는 경로를 지정할때 사용합니다.
Oracle*Names가 설정이 안되어 있는 경우 ONAMES을 지우시는 것이 좋습니다.
7) SDU와 TDU
SDU('Session Data Unit')는 네트워크를 통해 보내는 packet의 size입니다.
이 size는 MTU(Maximum Transmission Unit)를 넘어서는 안됩니다.
MTU는 네트워크상에 고정된 값입니다.
TDU('Transport Data Unit')는 SQL*Net이 data를 함께 묶는 기본 packet size
이며 SDU의 배수여야 합니다.
다음에서 예를 들어 보겠습니다.
* SDU=1024, TDU=1536:
SQL*Net은 buffer에 1536 byptes까지 저장했다가 네트워크로 보냅니다.
낮은 network layer에서 이것을 다시 두개의 physical packets(1024,512
bytes)로
나누어 보냅니다.
* SDU=1514, TDU=1000:
SQL*Net은 buffer에 1000 byptes까지 저장했다가 네트워크로 보냅니다.
SDU는 request당 514 bytes를 더 담을 수 있는데도 불구하고 보내지기 때문에
network resource의 낭비를 초래합니다.
표준 Ethernet network에서 MTU의 default size는 1514 bytes입니다.
표준 token ring network에서 MTU의 default size는 4202 bytes입니다.
SDU와 TDU를 설정하려면 TNSNAMES.ORA 과 LISTENER.ORA 를 다음과 같이
바꾸어야 합니다.
TNSNAMES.ORA:
ORCL.WORLD =
(DESCRIPTION =
(SDU=1514)
(TDU=1514)
(ADDRESS =
(PROTOCOL = TCP)
(HOST = fu.bar)
(PORT = 1521)
(CONNECT_DATA = (SID = ORCL))
LISTENER.ORA:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SDU = 1514)
(TDU = 1514)
(SID_NAME = ORCL)
(GLOBAL_DBNAME = ORCL.WORLD)
SDU와 TDU는 modem을 사용하는 환경에서는 줄여주는 것이 좋고
fiber나 T3 line을 사용하는 환경에서는 늘려주는 것이 좋습니다.
SDU와 TDU의 default값은 2048이고 maximum값은 32768입니다.
8) PROTOCOL.ORA의 tcp.no_delay 설정
기본적으로 SQL*Net은 SDU buffer가 찰때가지 request를 전송하지 않고
기다립니다. 다시 말해 request가 도착지점으로 바로 전송되지 않는 다는것을
의미 합니다. 그런데 'no_delay'를 설정함으로써 data buffering을 하지 않게
할 수 있습니다. 따라서 'no_delay'를 설정하게 되면 작은 size의 patckets의
전송이 늘게되어 network traffic이 증가하게 됩니다.
따라서 이 parameter는 TCP timeout이 발생했을 경우에만 사용하셔야 합니다.
9) LISTENER.ORA의 QUEUESIZE 설정
QUEUESIZE는 listener가 저장할 수 있는 request의 수를 의미 합니다.
만일 들어오는 reqeusts의 수가 buffer의 size를 넘게 되면,
접속을 시도한 client는 접속을 실패하게 됩니다.
이 buffer의 size는 예상되는 동시 접속 수를 설정해 주는 것이 좋습니다.
LISTENER =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = fu.bar)
(PORT = 1521)
(QUEUESIZE = 32)
이 parameter는 TCP/IP나 DECNET protocol이 사용될때만 사용됩니다.
10) SQLNET.ORA의 BREAK_POLL_SKIP 설정
이 parameter는 user break을 check하는 사이의 packet수를 지정합니다.
다시 말해 만일 이 parameter의 값이 높으면 CTRL-C checking은 덜 자주
일어나게되며 CPU overhead는 줄게 됩니다.
만일 이 parameter의 값이 낮으면 CTRL-C checking이 자주 발생되어
CPU overhead가 늘게 됩니다.
기본값은 4이며 client SQL*NET에만 사용됩니다.
11) SQLNET.ORA의 DISABLE_OOB 설정
Out of band break check를 enable시키거나 disable시킬때 사용하는
parameter입니다.
기본값은 off입니다.
여기서 잠간만 !
Out of Band Breaks란 무엇인가 ?
네트워크 통신상에서 받아들여지는 interrupt signals은 일반적으로
다른 data(예를 들어 select 문장)과 같이 도착하게 됩니다.
이것을 In-band Breaks라고 합니다.
그런데 이 interrupt signals을 connection과는 다른 channel을 통해
전달할 수 있습니다 이것을 Out of Band Breaks라고 하며 이 방식은
interrupt signal을 훨씬 빠르게 그리고 효과적으로 전달 할 수 있습니다.
(예를 들어 deadlock을 break하기위해 control-C를 사용하는 것)
12) PROCESS.DAT와 REGID.DAT
7.3.2 버전에서 Oracle Server Tracing은 기본적으로 enabled되어 있습니다.
따라서 모든 connection과 request가 PROCESS.DAT와 REGID.DAT에
기록이됩니다.
database의 사용기간이 길어지면 이 파일들은 접속속도를 현저히 떨어뜨리게
됩니다.
이러한 trace 파일들을 사용하지 않기위해 listener.ora파일에
'EPC_DISBLED=TRUE'를 설정해야 합니다.

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

TCP/IP IN SQL*NET & SLIP / PPP

Similar Messages

Maybe you are looking for