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

Similar Messages

  • SQL*NET에서 CLIENT IP를 이용하여 CONNECT를 제한하는 방법(protocol.ora)

    제품 : SQL*NET
    작성날짜 : 2005-07-05
    SQL*Net을 통해 listener에 접속할 수 있는 Client Node를 제한하는 방법
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    SQL*Net을 사용하면서 특정한 Client Node의 접근을 제한할 수 있으며,
    이 기능은 Oracle V7.1이상에서 적용을 할 수가 있습니다.
    Configuration은
    ~ 8i:
    $ORACLE_HOME/network/admin/protocol.ora에 설정합니다.
    9i: $ORACLE_HOME/network/admin/sqlnet.ora file에 설정합니다.
    변수 지정의 예;
    1. tcp.validnode_checking = yes
    tcp.invited_nodes=( 152.68.18.73 )
    이 경우는 오직 152.68.18.73 Node의 사용자만 접속을 할수 있으며,
    그외의 Node에서는 접속이 거절됩니다. (ora-12537 발생) 여기서 조심할
    사항은 반드시 자기 자신의 IP를 invited_nodes에 등록해줘야 합니다.
    2. tcp.validnode_checking = yes
    tcp.excluded_nodes=( 152.68.18.73 )
         이 경우는 152.68.18.73 만 접속이 거절되며, 그외의 다른 machine
    에서는 접속이 정상적입니다.
    3. tcp.validnode_checking = yes
    tcp.invited_nodes = (152.68.19.210, 152.68.18.74)
    tcp.excluded_nodes = (152.68.18.73)
         152.68.19.210, 152.68.18.74 Node의 사용자는 Listener에 접속을
    할 수 있고, 152.68.18.73 Node의 사용자는 접속을 못합니다.
    단, 하나 이상의 ip address 를 나열할 때는 single line 에 기록해야
    합니다.
    이렇게 설정 후에는 listener를 재기동합니다.

  • WINDOWS 용 SQL*NET 를 사용 시 ORA-3121

    제품 : SQL*NET
    작성날짜 : 1995-11-06
    다음은 ORA-3121을 해결하기 위해 단계별 조치방법을 설명하겠습니다.
    ==========================
    SQL*NET V2 에서의 ORA-3121
    ==========================
    1) SQL*NET V2를 통해 연결하려 할 때 Connect String에 'tns:' prefix를 사용
    하지 않으면 ORA-3121이 나오는 경우가 있습니다.
    예를 들어서 tnsnames.ora 에 등록된 service name이 TORA라고 가정한다면
    Connect String을
         tns:TORA
    와 같이 지정하면 됩니다.
    Powerbuilder의 경우에는
         @TORA 또는 @tns:TORA
    로 주게 됩니다.
    2) PC에 SQL*NET V2가 install이 안 되어 있는 경우에 Connect String을 TORA와
    같이 SQL*NET V2 형식으로 주게되면 ORA-3121이 발생합니다.
    ORACLE Installer를 실행하여 현재 인스톨 되어 있는 목록을 확인하여 SQL*NET
    V2와 TCP/IP ADAPTER가 인스톨이 되어 있는지 확인합니다.
    3) 만약 NETTEST나 TNSPING, SQLPLUS에서는 접속이 되는데 POWER BUILDER와 같은
    3rd Party Tool에서 접속이 되지 않고 ORA-3121이 발생하면 이 때에는
         C:\ORAWIN\BIN 또는 C:\ORAWIN95\BIN
    디렉토리가 PATH에 설정이 되어 있지 않은 경우입니다.
    PATH를 확인하시기 바랍니다.
    4) 3rd PARTY TOOL로 개발된 16BIT APPLICATION 이라면 AUTOEXEC.BAT 화일에
    다음을 추가하고 PC를 REBOOTING 합니다.
    SET CONFIG=C:\WINDOWS\ORACLE.INI
    =========================
    SQL*NET V1에서의 ORA-3121
    =========================
    1. Windows에서 나와서 DOS 프롬프트로 가십시요.
    2. DOS 프롬프트에서 PATH를 입력하고 <RETURN>을 누르십시요.
    현재 경로에 있는 모든 드라이브를 적어 두십시요. (C:, D:)
    3. 2에서 적은 DOS 경로의 모든 드라이브에서 ORA6WIN.DLL 이라는 화일을 찾으시
    기 바랍니다.
    (Norton에서 FILEFIND 유틸리티를 사용하거나 DOS 5.0 이상의 경우 Root 디렉토
    리에서 간단하게 DIR ORA6WIN.DLL/S를 실행하는 것이 좋은 방법입니다.
    Windows 파일 관리자의 파일 찾기 유틸리티를 사용할 수도 있습니다.)
    ORA6WIN.DLL이 여러 개이면 한 가지만 제외하고 모든 복사본의 이름을 바꾸십
    시요.
    (ORA6WIN.DLL같은 것으로). 한 가지 예외는 4/13/92(285573 byte)
    또는 10/15/92(380639 bytes)라고 적힌 ORA6WIN.DLL은 복사본입니다.
    이들 두 버전의 ORA6WIUN.DLL은 Oracle Corporation이 적접 배포한 것입니다.
    10/15/92이후 날짜로 되어있고 380639 바이트보다 큰 파일을 가지고 있다면 그
    것을 사용해도 좋습니다.
    ( 이들 날짜의 ORA6WIN.DLL 복사본이 없으면 제3자 응용 프로그램 업체에 연락해
    서 이 파일의 복사본을 구하십시요. 디스크 레이블이 "Windows Required
    Support Files Version 6.0xx.x.x"인 Oracle 제품이라면, 틀림없이
    ORA6WIN.DLL의 최신 복사본이 있을 것입니다.)
    4. ORA6WIN.DLL이 있는 디렉토리를 적어 두십시요.
    5. 현재 경로에 앞서 말한 디렉토리가 있는지 확인하십시요.
    DOS Prompt에서 PATH를 입력하고 <RETURN>을 누르면 됩니다.
    6. 현재 경로에 ORAWIN\BIN 디렉토리가 있는지 확인하십시요. (또는 Windows용
    SQL*NET이 설치된 곳, 잘 모르겠으면 ORACLE_HOME\BIN 디렉토리를 보십시요.
    ORACLE.INI 파일에 ORACLE_HOME이 정의되어 있습니다.)
    또한 ORACLE_HOME\BIN 디렉토리에 SQL*NET DLL이 있는지 확인하십시요.
    (예를 들어, Windows용 SQL*NET SPX의 경우는 SQLSPX.DLL과 SQLSPX1.DLL,
    WINDOWS용 SQL*NET TCP/IP의 경우는 SQLTCP.DLL과 SQLTCP1.DLL).
    ORACLE_HOME\BIN디렉토리에 ORA7WIN.DLL이 있는 지도 확인해야 합니다.
    7. WINDOWS 디렉토리의 win.ini 파일을 편집하십시요.
    다음과 같은 ORACLE이라는 그룹을 반드시 넣어야 합니다.
    [Oracle]
    ORA_CONFIG=C:\WINDOWS\ORACLE.INI
    8. A) DOS 프롬프트에서 SET을 다시 입력하고 <RETURN>을 누르십시요.
    CONFIG라는 DOS환경 변수가 CONFIG.ORA 라는 파일에 인쇄하도록 설정되어 있는지
    점검하십시요.
    CONFIG 환경 변수는 다음과 같아야 합니다.
    <server : DOS, unix, tool : DOS>
    CONFIG=C:\ORACLE6\CONFIG.ORA
    B) 환경 변수에 CONFIG 변수가 설정되어 있지 않으면 AUTOEXEC.BAT 파일에
    다음 명령문을 추가하고 나서 다시 부팅하십시요.
    <server : unix, tool : windows>
    SET CONFIG=C:\WINDOWS\ORACLE.INI
    (Windows 디렉토리에 해당 경로에 넣으십시요)
    CONFIG가 설정되지 않아서 8B) 단계를 수행했으면 9단계는 무시하십시요.
    9. CONFIG.ORA와 ORACLE.INI FILE의 다음 매개변수를 일치 시키십시요.
    (이들 파일의 위치에 대해서는 8단계를 참조하십시요.)
    이들 매개변수 중에는 두 파일에 없는 것도 있습니다. 이들 매개 변수가 CONFIG.ORA나 ORACLE.INI에 있으면 정확히 일치하게 하십시요. 이들 매개변수 중
    에 두 파일 중 어디에도 없는 것이 있다면, 그것을 추가하지 마십시요.
    또한 이들 매개변수 중에 불필요한 것이 있을 수도 있지만, 그것을 CONFIG.
    ORA와 ORACLE.INI에 모두 추가해도 전혀 문제는 없습니다.
    매개변수 목록 :
    WIN_LOCAL_SESSIONS
    WIN_REMOTE_SESSIONS
    LOCAL
    REMOTE
    INTERRUPT
    XMMITR
    TCP_HOSTS_FILE
    TCP_SERVICES_FILE
    SQLNET DBNAME
    10. 지금 WINDOWS를 시작한 다음, 프로그램 관리자의 도움말(HELP)을 클릭하고
    ABOUT PROGRAM MANAGER를 클릭하여 WINDOWS가 enhanced mode인지 확인해 보시
    기 바랍니다.
    WINDOWS용 SQL*NET은 표준 모드로 작동하지 않습니다.
    11. 로그인 화면에 Connect String을 명시적으로 제공한 경우에는 Connect
    String 앞에 '@'를 지정하지 마십시요.
    다음 예와 같이 그냥 Connect String만을 입력하십시요.
    t:orasrv:orasid 혹은 x:orasrv
    12. ORACLE.INI와 CONFIG.ORA에 LOCAL 매개 변수가 있으면, 로그인 화면에서
    Connect String을 지정하지 않고 Connect String field를 비워둘 수 있습니다.
    LOCAL=t:orasrv:orasid
    (Note): Oracle Corporation은 사용자의 \ORAWIN\BIN 디렉토리에 설치되는
    NETTEST.EXE라는 WINDOWS 시험 프로그램을 배포합니다. 이 프로그램을 사용하면
    Remote ORACLE 서버에 대한 연결을 시험할 수 있습니다. 이 프로그램은 연결되지
    만 제3자 툴이 연결되지 않으면 해당 툴 업체에 문의하십시요.

    The last 16-bit ODBC driver was an Oracle7 driver. I don't believe it's certified for use with an 8i database.
    Justin

  • 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

  • How to connect to DB in repository assistant using SQL*net

    Hi all,
    We are in RAC enviroment. When I try to connecting to oracle DB in repository assistant (the page that asks for SYS account), I check the SQL*net, and enter the net service name (absolutly also enter the SYS and SYS psw field), but the 'next' button is grey out.
    according to installation guide, in a RAC environment, do not type the host name, port number and oracle service name. But in my case, I have to enter all these fields to enable the 'next' button.
    any idea of how to fix it?
    thanks

    I forget to say that I can connect to the repository browser using SQL*net. So I suppose that net service name is correct.
    thanks for any suggestion.

  • Can't connect to sql*net, ORA-12638: Credential retrieval failed

    after installed oracle9i, I can use sqlplus, but when I try to use sql navigator, I can't connect to sql*net.
    I found out the following error message in logfile:
    Fatal NI connect error 12638, connecting to:
    (DESCRIPTION=
    (ADDRESS=
    (PROTOCOL=BEQ)
    (PROGRAM=oracle)
    (ARGV0=oracleoms)
    (ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))
    (CONNECT_DATA=(SID=oms)(CID=(PROGRAM=c:\oracle\ora92\bin\ORACLE.EXE)(HOST=JZQGG31)(USER=OraUser))))
    VERSION INFORMATION:
         TNS for 32-bit Windows: Version 9.2.0.1.0 - Production
         Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version 9.2.0.1.0 - Production
    Time: 11-MAR-2004 17:04:17
    Tracing not turned on.
    Tns error struct:
    nr err code: 0
    ns main err code: 12638
    TNS-12638: Credential retrieval failed
    ns secondary err code: 0
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
    =============================================
    Hope somebody can help me! Thanks!

    change in sqlnet.ora file
    find under oracle home\network\admin\sqlnet
    and
    SQLNET.AUTHENTICATION_SERVICES = (NTS)
    CHANGE TO
    SQLNET.AUTHENTICATION_SERVICES = (NONE)
    hope it will solve u r problem
    kuljeet pal singh

  • How can I connect oracle without installing its SQL*Net client?

    How can I connect oracle without installing its SQL*Net client?

    Pls suggest, any possible solution, i cross checked from below link, and tried to install the instant clients, but
    http://www.oracle.com/technology/software/tech/oci/instantclient/htdocs/winsoft.html
    its showing me error of "This application has failed to start because OCI.dll was not found. Re-installing the application may fix this problem."
    Let me know if you have any thing on this.

  • Connecting oracle database with sql*net via VIP on Ace

    Is there any way to get oracle Database traffic working only via the ACE Blade instead of using a firewall to do packet inspection.
    The case is we have application servers in a DMZ wich should connect via a VIP to a Oracle database on port 1521.
    Normally oracle negotiates the tcp ports wich it will use and a normal firewall will do an inspect and opens up the dynamic channel.
    However on the Ace there is still no Inspect for Sql*net.
    Everthing on routing and connection level works fine tnspings telnet to 1521 works fine. Only when using the application stack the dynamic ports needs to be used.
    In our design a firewall in between this node's is at this moment impossible.
    Any Ideas or examples how to solve this...

    ORA-27140: attach to post/wait facility failedThis is to do with filesystem permissions on $ORALCE_HOME/bin
    Login as the 'oracle' account (or the account with which oracle binaries are installed.
    goto $ORACLE_HOME/bin
    chmod 6751 account_used_to_install

  • SQL net connection

    hi,
    Currently Timesten needs a change in the application's connection string to point to a
    ODBC or JDBC datasource. Instead of using this, to use the existing SQL net to point to
    timesten instace is in the developent queue? or will never be developed?
    Thanks

    An OCI/SQL*Net API for TimesTen is in the roadmap for delivery in a future release.
    Chris

  • 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

  • How to drill down the cause of "SQL*Net message from/to client"

    Pretty frustrated with my tune up using suggestions from many papers for Oracle 10g R2 on AIX 5.3 L system. My users told me that the system (including Baan 5c) still responds slowly in some processes, some even worsen.
    Using both queries such as
    SELECT sid, schemaname, status FROM gv$session ORDER BY 2;
    SELECT inst_id, seq#, event, p1, p2, p3, wait_time FROM v$session_wait_history WHERE sid=<sid from above>
    INST_ID SEQ# EVENT P1 P2 P3 WAIT_TIME
    1 1 SQL*Net message from client 1413697536 1 0 6419
    1 2 SQL*Net message to client 1413697536 1 0 0
    and others similar, I found very large numbers (almost 97%) of the sessions have events as “SQL*Net message to client” and “SQL*Net message from client” on their wait_time even the sids are in inactive status. After checking the meaning of those messages in Oracle Performance and Tuning document, the document states that mainly they are probably network problems. So How can I drill down to what status of network from my client (the users) to server by Oracle or AIX? In Baan, it has its own parameter sets in its db_resource file controlling the connectivity. In average, there are 4000 “opened cursor current”, but most of them inactives.
    So my colleague asked me rollback all th changes I did on OS level such as minperm%=5
    maxperm%=90
    maxclient%=90,
    lgpg_regions lgpg_size,
    sys0 maxuproc=512,
    aio0 maxservers='260'
    and many ioo parameters to system defaults.
    I even removed the mulitplex copy of the redo log.
    I tried to proof them that there maybe the problem of the Baan/Oracle connectivity, ie due to message above,

    http://docs.oracle.com ... read them for configuration information.
    http://tahiti.oracle.com ... read them for recommendations.
    http://otn.oracle.com ... find the best practices docs.
    http://metalink.oracle.com ... look for similar issues to yours.
    People that change things, on production boxes, without first determining that metrics indicate they are a good idea, and then determining their impact on a test box, should be sold to zoos as leopard food.
    PS: Slowly likely has absolutely nothing to do with anything you touched. First you tune the application. Then you tune the database. Then you tune the operating system. Get out of the way and make the DBAs do their job.

  • SQL*Net more data to dblink event for hours or days

    Hello Everyone,
    in our production database when we commit a transaction we call a remote procedure over dblink.
    usually the call succeeds ,but every now and then a couple of sessions hang up,
    when I use the session browser of Toad I notice that these sessions are waiting with the event SQL*Net more data to dblink
    below are some queries and their results:
    select sid,event,wait_class,wait_time,seconds_in_wait,state from gv$session_wait where sid=225
    rslt:
    225 SQL*Net more data to dblink Network -1 18279 WAITED SHORT TIME
    select * from gv$session_wait_history where sid=225
    rslt:
    INST_ID     SID     SEQ#     EVENT#     EVENT     P1TEXT     P1     P2TEXT     P2     P3TEXT     P3     WAIT_TIME     WAIT_TIME_MICRO     TIME_SINCE_LAST_WAIT_MICRO
    2     225     1     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8144          0     0     8     41
    2     225     2     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8143          0     0     13     39
    2     225     3     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8149          0     0     7     37
    2     225     4     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8145          0     0     8     40
    2     225     5     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8145          0     1     11394     37
    2     225     6     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8143          0     0     7     37
    2     225     7     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8145          0     0     7     36
    2     225     8     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8138          0     0     8     37
    2     225     9     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8149          0     0     8     38
    2     225     10     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8149          0     1     11476     37I'm not sure but from the above results ,is it safe to conclude that I get stuck because I am caught in infinite loop trying to write to dblink?
    additional notes:
    <li>some times when I look at the current statement I find that the statement is a query or insert into a local table.
    <li>there were some network outages.
    <li>when viewing the database log files I found:Error 3135 trapped in 2PC on transaction 7.6.306086. Cleaning up.
    Error stack returned to user:
    ORA-03135: connection lost contact
    ORA-02063: preceding line from MPF//where MPF is the name of dblinkeven though we use the DBLink to execute the procedure only without any changes on the remote DB, and we don't use 2PC.
    <li> the local DB is a RAC
    select * from dba_blockers
    rslt:
    no rows
    select * from dba_waiters
    rslt:
    no rows
    select * from gv$lock where sid=225
    rslt:
    INST_ID     ADDR     KADDR     SID     TYPE     ID1     ID2     LMODE     REQUEST     CTIME     BLOCK
    2     0000000199D54F60     0000000199D54FB8     225     AE     100     0     4     0     20152     2
    2     000000018EA18108     000000018EA18180     225     TX     1114138     251539     6     0     19654     2
    select * from gv$session where sid=225
    rslt:
    INST_ID     SADDR     SID     SERIAL#     AUDSID     PADDR     USER#     USERNAME     COMMAND     OWNERID     TADDR     LOCKWAIT     STATUS     SERVER     SCHEMA#     SCHEMANAME     OSUSER     PROCESS     MACHINE     PORT     TERMINAL     PROGRAM     TYPE     SQL_ADDRESS     SQL_HASH_VALUE     SQL_ID     SQL_CHILD_NUMBER     SQL_EXEC_START     SQL_EXEC_ID     PREV_SQL_ADDR     PREV_HASH_VALUE     PREV_SQL_ID     PREV_CHILD_NUMBER     PREV_EXEC_START     PREV_EXEC_ID     PLSQL_ENTRY_OBJECT_ID     PLSQL_ENTRY_SUBPROGRAM_ID     PLSQL_OBJECT_ID     PLSQL_SUBPROGRAM_ID     MODULE     MODULE_HASH     ACTION     ACTION_HASH     CLIENT_INFO     FIXED_TABLE_SEQUENCE     ROW_WAIT_OBJ#     ROW_WAIT_FILE#     ROW_WAIT_BLOCK#     ROW_WAIT_ROW#     TOP_LEVEL_CALL#     LOGON_TIME     LAST_CALL_ET     PDML_ENABLED     FAILOVER_TYPE     FAILOVER_METHOD     FAILED_OVER     RESOURCE_CONSUMER_GROUP     PDML_STATUS     PDDL_STATUS     PQ_STATUS     CURRENT_QUEUE_DURATION     CLIENT_IDENTIFIER     BLOCKING_SESSION_STATUS     BLOCKING_INSTANCE     BLOCKING_SESSION     FINAL_BLOCKING_SESSION_STATUS     FINAL_BLOCKING_INSTANCE     FINAL_BLOCKING_SESSION     SEQ#     EVENT#     EVENT     P1TEXT     P1     P1RAW     P2TEXT     P2     P2RAW     P3TEXT     P3     P3RAW     WAIT_CLASS_ID     WAIT_CLASS#     WAIT_CLASS     WAIT_TIME     SECONDS_IN_WAIT     STATE     WAIT_TIME_MICRO     TIME_REMAINING_MICRO     TIME_SINCE_LAST_WAIT_MICRO     SERVICE_NAME     SQL_TRACE     SQL_TRACE_WAITS     SQL_TRACE_BINDS     SQL_TRACE_PLAN_STATS     SESSION_EDITION_ID     CREATOR_ADDR     CREATOR_SERIAL#     ECID
    2     00000001993E4F58     225     445     1353611     0000000198E2FA10     198     <schema>     47     2147483644     000000018EA18108          ACTIVE     DEDICATED     198     <schema>     oracle     1234     <cluster name>     49993     unknown     JDBC Thin Client     USER     00000001968A1250     3198676106     72y8ztfzagv4a     2     02/04/2013 11:18:22 ص     33554852     00000001968A18E0     3992616824     03mm4u3qznzvs     0     02/04/2013 11:18:22 ص     33554730     158207     1     158207     1     JDBC Thin Client     2546894660          0          12206     122409     8     49354     0     94     02/04/2013 10:53:20 ص     19559     NO     NONE     NONE     NO          DISABLED     ENABLED     ENABLED     0          NOT IN WAIT               NOT IN WAIT               42844     344     SQL*Net more data to dblink     driver id     1413697536     0000000054435000     #bytes     8144     0000000000001FD0          0     00     2000153315     7     Network     -1     19553     WAITED SHORT TIME     8          19553325216     SYS$USERS     DISABLED     FALSE     FALSE     FIRST EXEC     100     0000000198E2FA10     2     004qLk^iPyp0bqw5wFDCiW0002fR000B^f

    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.

  • 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 이후 버젼에서는 수정되었다.

Maybe you are looking for

  • I have bogus charges on my bank account. How can I get help from Itunes customer service? Been in an insane loop here.

    There are two charges on my bank account that I did not make. When I look at my ITunes account there are no purchases showing. So why is I tunes charging my account for a total of $17.00. You would think if someone was using my account, there would b

  • Printing Problem with Xerox 6120

    I've connected a Xerox 6120 color laser printer to my home LAN (cable modem to Netgear wireless router). When the printer is turned on the Mini can't get an IP.I've tried using fixed IP for both the Mac and the Xerox to no avail. (FYI, my G3 Pismo La

  • Using long text in Mobile 7.1

    Hello, We are using Mobile 7.1. We want to display a long text of the notification object in the Mobile Client. We defined this field as STRING data type in the DOE and set TEXT MEMO flag for it. Unfortunately we have a problem with its definition in

  • Facebook force closing safari?

    Safari force closes every time I open Facebook. Every other website will load and stay open with no problem. I emptied history, cookies, cache and repaired disk permissions to no avai (and yes, I've restarted multiple times)l. Help!

  • Contract Output

    Dears, We have created (by copying output type 'NEU') a new message type 'ZNEU' for outline agreements.  However it is not showing in ME32K.  Any idea why it is not coming? Thanks,