TNS/SQL*Net problem

Sorry if this is a dim question but I have gone through the wise words in other threads and haven't managed to apply them to my situation - either I'm trying the wrong things, being stupid or there's something odd going on.
OS: Windows XP (Media Centre)
DB: Oracle 10.2.0
Proprietary application accesses this using a straightforward x/y@db_name connect string.
This was working quite happily until a registry cleaner decided to target some registry entries and now
a) the listener service doesn't start, even though it is set to 'Automatic'
b) even though the OracleServicedb_name service starts, I cannot connect to it
I don't have the registry entries that were cleaned as I was trying to press 'Cancel', and somehow the wrong button was pressed (yeah I know, I know....)
I am getting sonnection errors as follows:
When I try to connect using sql*plus, I get 12154: The listener does not currently know of the service in the connect descriptor (typed from memory as I'm at home with different network connections etc and I can't reproduce it at the moment).
Listener.ora:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = ETSCF)
(ORACLE_HOME = D:\oracle\product\10.2.0\db_1)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.35)(PORT = 1521))
(excerpt from) tnsnames.ora:
ETSCF =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.35)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = ETSCF)
sqlnet.ora:
# This file is actually generated by netca. But if customers choose to
# install "Software Only", this file wont exist and without the native
# authentication, they will not be able to connect to the database on NT.
SQLNET.AUTHENTICATION_SERVICES= ()
I would really appreciate any help....
Thanks,
Bruce

Thanks - I have stopped and removed the listener, and set the authentication_services to NONE.
I can run a tnsping which can 'see' the instance using the sqlnet.ora file and the TNSNAMES adapter, but the database will not start up.
Having read other threads, it seems likely that the service name in the spfileETSCF.ora cannot be read. If I connect as sysdba, I can get to the SQL prompt "Connected to an idle instance" but when I start the database I get errors complaining about the default block size.
I have resolved this now but am most grateful for people taking the time to read and reply.
I have removed the reference to the parameter file and inserted the minimal parameters into the initETSCF.ora, and was then able to connect as sysdba and mount and open the db.
Thanks again!

Similar Messages

  • SQL Net Problem

    I am trying to connect from an Oracle client 9i-V1 to an Oracle server 8i-V3 over the internet and through MS ISA Firwall , tnsping is working correctly and returing latency as between 250 and 330 M/Second.
    When trying to connect using SQL+ I get ORA-12535 despite that I have adjusted the CONNECT_TIMEOUT on the listener and reloaded it , I have adjusted the parameter to 0 but still getting the error.
    We are running Oracle Apps 11i from the same location using the same internet line and its working at a remarkable speed , also all the required ports are opened and secured on the firewall.
    Could you advise something.

    These two waits in your statspack report:
    SQL*Net more data from dblink
    SQL*Net message from dblink
    refer to a database link. (A connection between this database and another database.)
    http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref4564
    It looks like a lot if the time during that snapshot was consumed waiting for data over the database link.
    It looks like that would be the place to look for improvements.
    The SQL*Net more data to client wait was only a tiny percentage.

  • 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

  • TROUBLE SHOOTING PROBLEM ON SQL*NET, NET8.X, AND NET SERVICES

    제품 : SQL*NET
    작성날짜 : 2002-11-24
    TROUBLE SHOOTING PROBLEM ON SQL*NET, NET8.X, AND NET SERVICES
    (GENERATING TRACE FILE OF SQL*NET, NET8.X, AND NET SERVICES)
    ==========================================================
    PURPOSE
    이 글은 고객들이 Oracle Server의 Oracle Networking 제품들을 사용하다가
    Networking과 관련된 문제를 만났으나 스스로 해결할 수 없는 경우, 예를
    들어 http://metalink.oracle.com 에서 같은 case를 발견할 수 없는 경우,
    원인을 찾기 위하여 Networking 제품의 trace를 떠 보는 방법을 설명합니다.
    Explanation
    Oracle Networking 제품을 사용 중에 어떠한 문제를 겪는 경우 무엇보다도
    OS의 Networking Protocol Stack 쪽을 살펴보는 것이 선행되어야 합니다.
    일부 고객분들은 Oracle Networking 제품들이 OS의 Protocol Stack이 동작
    하는데 어떤 중대한 영향을 주는 것이 아닌가 하고 문의를 합니다만
    그러한 의문은 Oracle Networking 제품도 OS의 Protocol Stack을 사용하는
    하나의 network client라는 것을 이해함으로써 해소가 됩니다.
    Oracle Networking 제품도 OS의 Protocol Stack을 이용하는 하나의 network
    client이기 때문에 Oracle Networking 제품이 OS Protocol Stack의 동작에
    어떠한 식으로든 영향을 준다던가 하는 것은 있을 수 없기 때문입니다.
    고객의 관점에서 OS의 Protocol Stack은 정상적으로 설정이 되었다고 믿고
    있으며 기타 networking 환경을 정확히 판단할 수 없는, 예를 들어
    host설정은 잘 되어 있다고 믿고 있으나 firewall을 통해야만 하는 등의
    다소 접근하기 어려운 networking 환경에서 networking이 잘 되지 않는,
    예를 들어, Oracle Server에 연결이 잘 안되거나 연결 중 networking
    error가 발생하는 경우에는 http://metalink.oracle.com에서 같은 case를
    찾는 것이 가장 빠른 해결 방법입니다.
    그러나 드물게 http://metalink.oracle.com에서 같은 case가 나오지 않는
    경우 Oracle Networking 제품의 trace file을 떠서 원인을 찾게 됩니다.
    Oracle Networking 제품은 Oracle 7.x에서 SQL*Net, Oracle 8.x에서 Net 8.x,
    Oracle 9.x에서 Oracle Net Services라는 이름이 가지고 있으나 여기에서는
    편의상 모두 Oracle Networking 제품으로 부르도록 하겠습니다.
    아울러 여기서 언급하는 Trace File은 Oracle Server의 Trace File과
    다른 것입니다. Oracle Server의 Trace File은 database instance의 대한
    내용만을 기록하며 Oracle Networking 제품의 Trace File은 networking에
    대한 내용만을 기록합니다.
    Trace File의 작성 방법은 Oracle 7.x부터 9.x까지 같습니다.
    Solution Description
    1. Client가 되는 host에서 어떠한 문제를 경험한 경우, 간혹 문제의 발생
    빈도가 낮거나 network나 server 쪽에 이상을 느끼시면서도 문제를 확인하기
    여러운 경우가 있습니다. 이런 경우엔는 문제가 다시 발생될 때 까지
    Client에서 Client Trace File를 작성하여 보아야 합니다.
    a. prompt$ echo $TNS_ADMIN
    b. $TNS_ADMIN이 설정되어 있으면, prompt$ cd $TNS_ADMIN
    아니면, prompt$ cd $ORACLE_HOME/network/admin
    c. vi sqlnet.ora
    # 다음 line들을 추가
    TRACE_LEVEL_client=16
    TRACE_FILE_client=<filename>
    TRACE_DIRECTORY_client=<directory>
    TRACE_UNIQUE_client=TRUE
    :wq
    prompt$
    예를 들어, client가 Windows OS인 경우 다음과 같이 합니다.
    prompt> notepad sqlnet.ora
    TRACE_LEVEL_client=16
    TRACE_FILE_client=client
    TRACE_DIRECTORY_client=D:\temp
    TRACE_UNIQUE_client=TRUE
    prompt>
    d. SQL*Plus와 같은, 또는 사용하던 Client software를 계속 이용
    e. 다시 문제가 발생
    f. 작성된 trace file들의 날자를 보아 문제가 발생한 시간과
    거의 같은 시간에 작성된 file들이 있는지 확인
    prompt> dir D:\temp
    client_<PID1>.trc ...
    client_<PID2>.trc ...
    prompt>
    g. trace를 중단합니다.
    prompt$ vi sqlnet.ora
    TRACE_LEVEL_client=0
    :wq
    prompt$
    h. Trace Assistant를 이용하여 Oracle Networking 제품의 error code
    (이하 TNS error code)를 trace file에서 찾아냅니다.
    prompt$ cd <directory of TRACE_DIRECTORY_client>
    prompt$ trcasst <filename of TRACE_FILE_client>_<PID>.trc > trcasst.out
    prompt$ vi -R trcasst.out
    Trace Assistant (trcasst command)는 Oracle 8.x부터 제공되며,
    Oracle 9.x의 Trace Assistant를 사용할 것을 권합니다.
    i. oerr command로 tns error에 대한 error message를 봅니다.
    예를 들어, 흔한 경우 중에 listener가 실행 중이지 않거나 잘못된
    tnsnames.ora 설정으로 client가 listener가 service 중이지 않은
    network address로 연결을 시도하다가 TNS-12541 TNS-12560 TNS-511
    error가 차례대로 나왔다면 다음과 같이 하여 각 TNS error code에
    대한 message와 설명 및 해결방법을 볼 수 있습니다.
    prompt$ oerr tns 12541
    prompt$ oerr tns 12560
    prompt$ oerr tns 511
    j. Trace Assistant가 알려준 TNS error code를 http://metalink.oracle.com
    에서 검색하여 같은 case가 있는지 확인합니다.
    Web browser에서:
    1) Go to http://metalink.oracle.com, then login
    오른쪽 위 HTML frame에서 :
    2) "Advanced" Button을 누릅니다.
    오른쪽 아래 HTML frame에서:
    3) "Enter Keyword" text box에 tns error code를 모두 입력합니다.
    예를 들어, tns-12541 tns-12560 tns-511
    4) "Search" button을 누릅니다.
    k. http://metalink.oracle.com에서 검색이 거의 되지 않거나
    문제가 매우 이상한 경우 이 글 아래를 보시기 바랍니다.
    2. Client에서 SQL*Plus나 Oracle Client를 사용하는 다른 3rd party
    appliction은 잘 동작하나 유독 tnsping command에서 error가 나는 경우가
    드물게 있습니다. 이 때에는 tnsping command의 trace file을 작성해봅니다.
    prompt$ vi sqlnet.ora
    TNSPING_TRACE_LEVEL=16
    TNSPING_TRACE_DIRECTORY=<directory>
    :wq
    prompt$ tnsping <tns alias>
    3. Server, 즉 listener에 문제가 있다고 생각되는 경우 우선 listener의
    log file을 봅니다. listener의 log에 대해서는 bulletin.18364를
    이용합니다.
    4. listener의 trace file은 다음과 같이 설정합니다.
    listener의 trace 설정은 parameter 이름에 trace file을 작성하고자 하는
    listener의 이름이 오는 점, 설정 후 listener process를 restart해야 하는
    점 두 가지를 제외하면 나머지 절차가 앞서 설명드린 client와 같습니다.
    prompt$ vi listener.ora
    TRACE_LEVEL_<listener name>=16
    TRACE_FILE_<listener name>=<filename>
    TRACE_DIRECTORY_<listener name>=<directory>
    :wq
    prompt$ lsnrctl stop <listener name>
    prompt$ lsnrctl start <listener name>
    5. 만일 위와 같이 http://metalink.oracle.com을 검색하여도
    같은 case가 전혀 없거나 찾아낸 error message들이 원인과 관련이 없어
    보일정도로 매우 이상한 경우 다음과 같이 해봅니다.
    a. Oracle Software의 version과 OS의 version이 certification matrix에
    있는 지 확인합니다.
    Web browser에서:
    1) Go to http://metalink.oracle.com, then login
    왼쪽 menu에서 :
    2) "Certify & Availabilty" menu item을 click합니다.
    오른쪽 아래 HTML frame에서:
    3) 현재 사용중인 Product와 그 version 및 OS와 그 version을 선택하
    여 검색합니다.
    Certification Matrix는 매우 정확하게 정보를 보여주고 있습니다.
    Matrix에 없는 Oracle Product와 OS version은 certify되어 있지 않으며
    모든 Oracle 제품을 Certify되지 않은 OS version에서 사용하는 것은
    그 어떠한 이유로든 보증과 지원이 되지 않습니다.
    만일 사용중인 제품이 certify되지 않은 경우, 무조건 certify된 제품
    과 OS의 version으로 install하여 다시 시도를 해야 합니다.
    예를 들어, Windows OS의 경우 그 어떠한 Oracle 제품도 Windows Me 및
    Windows XP Home Edition에 certify되어 있지 않습니다.
    Windows 2000 Professional 이상에 Certify된 제품은 Oracle 8.1.6부터
    이며 XP Professional 이상에 Certify된 제품은 Oracle 9.0.1부터
    입니다.
    Oracle 제품은 software이기는 하나 매우 완벽한 수준의 제품이라고 할
    수 있습니다. 그러나 Oracle 제품은 하나의 OS의 process로써 실행이
    되고 시간이 지나며 많은 환경이 major upgrade가 되면서 그러한 환경
    에 따라 Oracle software도 새로운 version으로 제작이 되면서 다시
    certification이 이루어지게 됩니다.
    그렇기 때문에 고객들은 특히 다수의 client나 고가의 server를 계획하
    시는 고객들은 저희 certification matrix를 사전에 철저히 확인하셔야
    합니다.
    앞서 Certification Matrix이전에 Installation Guide에 명시된
    OS version만이 certify되어 있다고 생각하시면 되겠습니다.
    b. Unix에서는 Oracle Software를 install한 후 OS의 Networking patch를
    씌우고 사용하다보면 문제가 되는 경우가 있습니다.
    이런 경우 relink를 해주어 바뀐 OS환경에서 Oracle 실행 file들을 다
    시 만들어 주어야 합니다.
    자세한 내용은 http://metalink.oracle.com에서
    다음 글을 읽어 보시기 바랍니다.
    Note:131321.1 How to Relink Oracle Database Software on UNIX
    c. Certify된 환경에서도 원인을 찾을 수 없는 경우 trace file을 가지고
    Oracle Support Services에 문의를 합니다. (지원 계약 고객에 한함)
    Reference Documents
    Chapter 17 Trouble shooting Oracle Net Services
    Oracle 9i Net Services Administrator's Guide
    SQL*Net, Net8.x, Net Services 9.x Network Administration Guide/Reference

    제품 : SQL*NET
    작성날짜 : 2002-11-24
    TROUBLE SHOOTING PROBLEM ON SQL*NET, NET8.X, AND NET SERVICES
    (GENERATING TRACE FILE OF SQL*NET, NET8.X, AND NET SERVICES)
    ==========================================================
    PURPOSE
    이 글은 고객들이 Oracle Server의 Oracle Networking 제품들을 사용하다가
    Networking과 관련된 문제를 만났으나 스스로 해결할 수 없는 경우, 예를
    들어 http://metalink.oracle.com 에서 같은 case를 발견할 수 없는 경우,
    원인을 찾기 위하여 Networking 제품의 trace를 떠 보는 방법을 설명합니다.
    Explanation
    Oracle Networking 제품을 사용 중에 어떠한 문제를 겪는 경우 무엇보다도
    OS의 Networking Protocol Stack 쪽을 살펴보는 것이 선행되어야 합니다.
    일부 고객분들은 Oracle Networking 제품들이 OS의 Protocol Stack이 동작
    하는데 어떤 중대한 영향을 주는 것이 아닌가 하고 문의를 합니다만
    그러한 의문은 Oracle Networking 제품도 OS의 Protocol Stack을 사용하는
    하나의 network client라는 것을 이해함으로써 해소가 됩니다.
    Oracle Networking 제품도 OS의 Protocol Stack을 이용하는 하나의 network
    client이기 때문에 Oracle Networking 제품이 OS Protocol Stack의 동작에
    어떠한 식으로든 영향을 준다던가 하는 것은 있을 수 없기 때문입니다.
    고객의 관점에서 OS의 Protocol Stack은 정상적으로 설정이 되었다고 믿고
    있으며 기타 networking 환경을 정확히 판단할 수 없는, 예를 들어
    host설정은 잘 되어 있다고 믿고 있으나 firewall을 통해야만 하는 등의
    다소 접근하기 어려운 networking 환경에서 networking이 잘 되지 않는,
    예를 들어, Oracle Server에 연결이 잘 안되거나 연결 중 networking
    error가 발생하는 경우에는 http://metalink.oracle.com에서 같은 case를
    찾는 것이 가장 빠른 해결 방법입니다.
    그러나 드물게 http://metalink.oracle.com에서 같은 case가 나오지 않는
    경우 Oracle Networking 제품의 trace file을 떠서 원인을 찾게 됩니다.
    Oracle Networking 제품은 Oracle 7.x에서 SQL*Net, Oracle 8.x에서 Net 8.x,
    Oracle 9.x에서 Oracle Net Services라는 이름이 가지고 있으나 여기에서는
    편의상 모두 Oracle Networking 제품으로 부르도록 하겠습니다.
    아울러 여기서 언급하는 Trace File은 Oracle Server의 Trace File과
    다른 것입니다. Oracle Server의 Trace File은 database instance의 대한
    내용만을 기록하며 Oracle Networking 제품의 Trace File은 networking에
    대한 내용만을 기록합니다.
    Trace File의 작성 방법은 Oracle 7.x부터 9.x까지 같습니다.
    Solution Description
    1. Client가 되는 host에서 어떠한 문제를 경험한 경우, 간혹 문제의 발생
    빈도가 낮거나 network나 server 쪽에 이상을 느끼시면서도 문제를 확인하기
    여러운 경우가 있습니다. 이런 경우엔는 문제가 다시 발생될 때 까지
    Client에서 Client Trace File를 작성하여 보아야 합니다.
    a. prompt$ echo $TNS_ADMIN
    b. $TNS_ADMIN이 설정되어 있으면, prompt$ cd $TNS_ADMIN
    아니면, prompt$ cd $ORACLE_HOME/network/admin
    c. vi sqlnet.ora
    # 다음 line들을 추가
    TRACE_LEVEL_client=16
    TRACE_FILE_client=<filename>
    TRACE_DIRECTORY_client=<directory>
    TRACE_UNIQUE_client=TRUE
    :wq
    prompt$
    예를 들어, client가 Windows OS인 경우 다음과 같이 합니다.
    prompt> notepad sqlnet.ora
    TRACE_LEVEL_client=16
    TRACE_FILE_client=client
    TRACE_DIRECTORY_client=D:\temp
    TRACE_UNIQUE_client=TRUE
    prompt>
    d. SQL*Plus와 같은, 또는 사용하던 Client software를 계속 이용
    e. 다시 문제가 발생
    f. 작성된 trace file들의 날자를 보아 문제가 발생한 시간과
    거의 같은 시간에 작성된 file들이 있는지 확인
    prompt> dir D:\temp
    client_<PID1>.trc ...
    client_<PID2>.trc ...
    prompt>
    g. trace를 중단합니다.
    prompt$ vi sqlnet.ora
    TRACE_LEVEL_client=0
    :wq
    prompt$
    h. Trace Assistant를 이용하여 Oracle Networking 제품의 error code
    (이하 TNS error code)를 trace file에서 찾아냅니다.
    prompt$ cd <directory of TRACE_DIRECTORY_client>
    prompt$ trcasst <filename of TRACE_FILE_client>_<PID>.trc > trcasst.out
    prompt$ vi -R trcasst.out
    Trace Assistant (trcasst command)는 Oracle 8.x부터 제공되며,
    Oracle 9.x의 Trace Assistant를 사용할 것을 권합니다.
    i. oerr command로 tns error에 대한 error message를 봅니다.
    예를 들어, 흔한 경우 중에 listener가 실행 중이지 않거나 잘못된
    tnsnames.ora 설정으로 client가 listener가 service 중이지 않은
    network address로 연결을 시도하다가 TNS-12541 TNS-12560 TNS-511
    error가 차례대로 나왔다면 다음과 같이 하여 각 TNS error code에
    대한 message와 설명 및 해결방법을 볼 수 있습니다.
    prompt$ oerr tns 12541
    prompt$ oerr tns 12560
    prompt$ oerr tns 511
    j. Trace Assistant가 알려준 TNS error code를 http://metalink.oracle.com
    에서 검색하여 같은 case가 있는지 확인합니다.
    Web browser에서:
    1) Go to http://metalink.oracle.com, then login
    오른쪽 위 HTML frame에서 :
    2) "Advanced" Button을 누릅니다.
    오른쪽 아래 HTML frame에서:
    3) "Enter Keyword" text box에 tns error code를 모두 입력합니다.
    예를 들어, tns-12541 tns-12560 tns-511
    4) "Search" button을 누릅니다.
    k. http://metalink.oracle.com에서 검색이 거의 되지 않거나
    문제가 매우 이상한 경우 이 글 아래를 보시기 바랍니다.
    2. Client에서 SQL*Plus나 Oracle Client를 사용하는 다른 3rd party
    appliction은 잘 동작하나 유독 tnsping command에서 error가 나는 경우가
    드물게 있습니다. 이 때에는 tnsping command의 trace file을 작성해봅니다.
    prompt$ vi sqlnet.ora
    TNSPING_TRACE_LEVEL=16
    TNSPING_TRACE_DIRECTORY=<directory>
    :wq
    prompt$ tnsping <tns alias>
    3. Server, 즉 listener에 문제가 있다고 생각되는 경우 우선 listener의
    log file을 봅니다. listener의 log에 대해서는 bulletin.18364를
    이용합니다.
    4. listener의 trace file은 다음과 같이 설정합니다.
    listener의 trace 설정은 parameter 이름에 trace file을 작성하고자 하는
    listener의 이름이 오는 점, 설정 후 listener process를 restart해야 하는
    점 두 가지를 제외하면 나머지 절차가 앞서 설명드린 client와 같습니다.
    prompt$ vi listener.ora
    TRACE_LEVEL_<listener name>=16
    TRACE_FILE_<listener name>=<filename>
    TRACE_DIRECTORY_<listener name>=<directory>
    :wq
    prompt$ lsnrctl stop <listener name>
    prompt$ lsnrctl start <listener name>
    5. 만일 위와 같이 http://metalink.oracle.com을 검색하여도
    같은 case가 전혀 없거나 찾아낸 error message들이 원인과 관련이 없어
    보일정도로 매우 이상한 경우 다음과 같이 해봅니다.
    a. Oracle Software의 version과 OS의 version이 certification matrix에
    있는 지 확인합니다.
    Web browser에서:
    1) Go to http://metalink.oracle.com, then login
    왼쪽 menu에서 :
    2) "Certify & Availabilty" menu item을 click합니다.
    오른쪽 아래 HTML frame에서:
    3) 현재 사용중인 Product와 그 version 및 OS와 그 version을 선택하
    여 검색합니다.
    Certification Matrix는 매우 정확하게 정보를 보여주고 있습니다.
    Matrix에 없는 Oracle Product와 OS version은 certify되어 있지 않으며
    모든 Oracle 제품을 Certify되지 않은 OS version에서 사용하는 것은
    그 어떠한 이유로든 보증과 지원이 되지 않습니다.
    만일 사용중인 제품이 certify되지 않은 경우, 무조건 certify된 제품
    과 OS의 version으로 install하여 다시 시도를 해야 합니다.
    예를 들어, Windows OS의 경우 그 어떠한 Oracle 제품도 Windows Me 및
    Windows XP Home Edition에 certify되어 있지 않습니다.
    Windows 2000 Professional 이상에 Certify된 제품은 Oracle 8.1.6부터
    이며 XP Professional 이상에 Certify된 제품은 Oracle 9.0.1부터
    입니다.
    Oracle 제품은 software이기는 하나 매우 완벽한 수준의 제품이라고 할
    수 있습니다. 그러나 Oracle 제품은 하나의 OS의 process로써 실행이
    되고 시간이 지나며 많은 환경이 major upgrade가 되면서 그러한 환경
    에 따라 Oracle software도 새로운 version으로 제작이 되면서 다시
    certification이 이루어지게 됩니다.
    그렇기 때문에 고객들은 특히 다수의 client나 고가의 server를 계획하
    시는 고객들은 저희 certification matrix를 사전에 철저히 확인하셔야
    합니다.
    앞서 Certification Matrix이전에 Installation Guide에 명시된
    OS version만이 certify되어 있다고 생각하시면 되겠습니다.
    b. Unix에서는 Oracle Software를 install한 후 OS의 Networking patch를
    씌우고 사용하다보면 문제가 되는 경우가 있습니다.
    이런 경우 relink를 해주어 바뀐 OS환경에서 Oracle 실행 file들을 다
    시 만들어 주어야 합니다.
    자세한 내용은 http://metalink.oracle.com에서
    다음 글을 읽어 보시기 바랍니다.
    Note:131321.1 How to Relink Oracle Database Software on UNIX
    c. Certify된 환경에서도 원인을 찾을 수 없는 경우 trace file을 가지고
    Oracle Support Services에 문의를 합니다. (지원 계약 고객에 한함)
    Reference Documents
    Chapter 17 Trouble shooting Oracle Net Services
    Oracle 9i Net Services Administrator's Guide
    SQL*Net, Net8.x, Net Services 9.x Network Administration Guide/Reference

  • Oracle SQL*Net and TNS Protocol

    I need to get technical documents on Oracle SQL*Net and TNS Proticol, down to the bit-level definition. I have talked to serveral people in Oracle Documentation, Sales and Tech Support, but no one could give me any clue so far. Any one can help me on this?

    SQL*Net is installed by default with SQL*Plus and any of the clients (OEM uses the JDBC OCI driver and some native connectivity).
    It is likely that the version of the client you have installed is not one that TOAD can work with or it can't find the client (is the Oracle home/bin directory in the path?)

  • WINDOWS용 SQL*NET 사용시 TNS-12533

    제품 : SQL*NET
    작성날짜 : 1995-11-10
    TNS-12533에러는 대개 TNSNAMES.ORA에서 기술자의 ADDRESS 부분에 프로토콜
    CONNECT DESCRIPTOR의 매개 변수가 틀릴 때 발생합니다. TCP/IP 어댑터의 경우,
    프로토콜 특유의 매개 변수는 다음과 같습니다.
    (ADDRESS =
    [(COMMUNITY=community_name)]
    (PROTOCOL=TCP)
    (HOST=host_name 또는 ip_address)
    (PORT=port_number)
    TCP/IP 어댑터를 사용할 때 TNSNAMES.ORA 의 완전한 구문은 다음과 같습니다.
    구문 해설
    service_name=
    (DESCRIPTION=
    (ADDRESS_LIST= ADDRESS_LIST는 생략할 수 있다.
    (ADDRESS=
    (COMMUNITY=community_name) COMMUNITY는 생략할 수 있다.
    (PROTOCOL=TCP)
    (HOST=host_name 또는 ip_address)
    (PORT=port_number)
    (CONNECT_DATA=
    (SID=sid)
    TNSNAMES.ORA에 정의된 서버에 연결하려면, 연결중인 응용 프로그램의 Log On
    dialog box에서 호스트 스트링 필드에 연결 스트링 "TNS:service_name"을
    지정하십시요. 또한 WINDOWS\WIN.INI의 ORA_CONFIG가 지시하는 파일에 LOCAL
    매개 변수를 지정하여 기본 데이타베이스를 정의하는 것이 좋습니다.
    ORA_CONFIG는 대개 WINDOWS\ORACLE.INI를 지시합니다.
    ORACLE.INI에서 "LOCAL=TNS:service_name"행을 추가할 수 있습니다. 그 후,
    연결을 할 때는 호스트 스트링 필드를 비워 둘 수 있습니다.

  • 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

  • WINDOWS 용 SQL*NET 사용 시 TNS-12545

    제품 : SQL*NET
    작성날짜 : 1995-11-10
    WINDOWS 용 SQL*NET 사용 시 TNS-12545
    ====================================
    에러 TNS-12545 "TNS:name lookup failure"는 TCP/IP 프로토콜 어댑터를 가진
    SQL*NET V2를 통해 툴에서 연결하려는데 TCP/IP 프로토콜 어댑터가 TNSNAMES.ORA
    파일의 ADDRESS 부분에 제공된 호스트 이름을 분석할 수 없을 때 발생합니다.
    TNS-12545는 SQL*NET TCP/IP V1에서 발생하는
    ORA-6105 "NETTCP:remote host is unknown"과 비슷합니다.
    * TNS-12545를 진단하는 단계
    1. 호스트 이름을 이용하여 호스트에 대해 TELNET과 PING을 실행해 보십시요. 즉
    PING <server> 또는 TELNET <server>를 실행해 보십시요. 호스트 이름을
    사용하여 PING이나 TELNET을 성공적으로 실행할 수 없으면, 먼저 TCP/IP 구성을
    점검해야 합니다. PING나 TELNET의 WINDOWS 버전을 사용하여 해 보십시요. 몇몇
    DOS 버전이 잘 작동하더라도 WINDOWS 구성에 문제가 있으면 WINDOWS 버전에서
    에러가 발생할 수 있습니다.
    2. 서버에서 루프백을 수행하여 서버쪽이 정확하게 설정되었는지 확인하십시오.
    루프백을 수행하려면 데이타베이스가 있는 MACHINE에서 아무 툴이나 호출하고,
    TNSNAMES.ORA에 WINDOWS 클라이언트에 사용한 것과 같은 ADDRESS 매개 변수를
    사용하여 SQL*NET V2를 통해 데이타베이스에 연결해 보십시요.
    3. 다음에는 사용자의 TCP/IP 소프트웨어가 IP 주소의 이름 분석을 위해 PC에서
    DOMAIN NAME SERVICE(DNS)를 사용하는지 아니면 파일 찾아보기를 사용하는지
    점검하십시요.
    4. DNS를 사용한다면, DNS에 해당하는 모든 드라이버를 올리도록 하십시요. 예를
    들어, SUN PC/NFS는 RNMNIS.EXE를 올려야만 Naming Information Service를
    사용할 수 있게 됩니다.
    5. DNS를 사용하지 않는다면, HOST 파일에 연결해야 할 호스트의 항목이 있는
    지 확인하고, 만약 없으면 추가하십시요. WINDOWS용 TCP/IP 어댑터는 원래
    TCP/IP 업체가 예상한 디렉토리에 상주하는 HOST 화일을 사용합니다. HOST
    파일의 각 항목 뒤에는 반드시 키리지 리턴을 넣어야 합니다. 또한 그러한
    서비스에 필요한 드라이버를 모두 점검해야 합니다. 예를 들어, SUN PC/NFS는
    그러한 서비스를 올리려면 RNMFILE.EXE가 필요합니다.
    6. WINDOWS 호출을 사용하지 않고 open() 호출을 사용했기 때문에 파일 핸들이
    초과할 수 있습니다. SQL*NET V1은 여기에 해당하지 않습니다. 이 버그는 버전
    2.1.5에 와서 해결되었습니다.
    7. 연결을 시도하여 여전히 TNS-12545가 나오면, TNSNAMES.ORA 파일의 ADDRESS
    부분 아래에 있는 HOST 매개 변수에 호스트 이름을 지정하지 말고 IP 주소를
    지정하는 것도 한 가지 해결책이 될 수 있습니다. 다음 예를 참조하십시요.
    HOST=139.141.61.64

    I've downloaded 11i.10.2 from the edelivery site, and unzipped all files to E:, so
    my staging area looks like E:\startCD, E:\oraDB, etc.You have to correct the set up of the stage area directory. The installation file system must contain a directory, Stage11i, in which the downloaded files will be unzipped. The file structure under that top-level directory will be automatically created when unzipping the files.
    So, all what you need to do is the following:
    - Create new directory E:\Stage11i
    - Place all the zip files you have downloaded under this directory
    - Unizip the files within this directory
    By the end, you should have a directory structure similar to the following:
    E:\Stage11i\startCD
    E:\Stage11i\oraDB
    E:\Stage11i\oraAppDB
    E:\Stage11i\oraiAS
    E:\Stage11i\oraApps
    E:\Stage11i\oraNLS
    Run Rapid Install from the Stage11i directory.

  • OWF location sql*net type creation problem

    Hi,
    on owb design (client side) i tried to create a OWF location with sql*net type
    in test connection get 'Please test connection with host, port, service name' message
    any help?
    Thanks in Advance
    lukx
    OWB 10.2.0.1
    OWF 2.6.4
    RDMBS 10.2.0.4 EE
    Linux redhat 5
    RAC with two node
    tnsnames.ora entry
    COGNOSDW1 =
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = r00orac01-vip)(PORT = 1522))
    (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = cognosdw1.group.net)
    (INSTANCE_NAME = cognosdw1)
    Edited by: lukx on Jan 22, 2011 8:20 AM

    Hi
    Don't think SQL*Net connection to workflow is supported hence the message on host:port:service
    Cheers
    David

  • Sql net trace file

    Hi All,
    Our prod db is 2 nodes RAC 10g in MS window 2003 servers. It is located in a remote place. Recently one of our local app servers lost connection to this db although we can tnsping it but got ORA3113 error when we tried to logon using sql plus. Most of our local PCs did not have problem logon at all. We enabled the sql net trace on this app server and network administrators spent a lot of time on this and finally shutdown one of the app servers in the same remote location which seemed cause a lot of network traffic with a local app server. So the problem went away and the app server can logon to the db now. I (I know nothing about network) tried to read the sql net trace file generated during the trouble time using the help outlined in the “Examining Oracle Net Trace Files” written by Kevin Reardon. The error happened after client sending server character set and conversion graph it supports and before receiving character set and conversion graph from the server. It took a minute in this step and finally gave up. Following is a section of the trace file where error happens. My question is: even we know when the error happens and at what step how can we use this info to further identify the root cause: Is this because we have too much network traffic which caused timeout or other reason(s)? By the way our db servers have “INBOUND_CONNECT_TIMEOUT=180" (3 minutes) in the sqlnet.ora file and whole trace file starts at [06-NOV-2009 14:50:23:352] and ends at [06-NOV-2009 14:51:24:758] which is a little over 1 minute. Greatly appreciate your insights and thoughts.
    Shirley
    [06-NOV-2009 14:50:23:836] nsdo: normal exit
    [06-NOV-2009 14:50:23:836] nsdo: entry
    [06-NOV-2009 14:50:23:836] nsdo: cid=0, opcode=85, *bl=0, *what=0, uflgs=0x0, cflgs=0x3
    [06-NOV-2009 14:50:23:836] nsdo: rank=64, nsctxrnk=0
    [06-NOV-2009 14:50:23:836] nsdo: nsctx: state=8, flg=0x400d, mvd=0
    [06-NOV-2009 14:50:23:836] nsdo: gtn=127, gtc=127, ptn=10, ptc=32730
    [06-NOV-2009 14:50:23:836] nsdo: switching to application buffer
    [06-NOV-2009 14:50:23:836] nsrdr: entry
    [06-NOV-2009 14:50:23:836] nsrdr: recving a packet
    [06-NOV-2009 14:50:23:836] nsprecv: entry
    [06-NOV-2009 14:50:23:836] nsprecv: reading from transport...
    [06-NOV-2009 14:50:23:836] nttrd: entry
    [06-NOV-2009 14:51:24:742] nttrd: exit
    [06-NOV-2009 14:51:24:742] ntt2err: entry
    [06-NOV-2009 14:51:24:742] ntt2err: Read unexpected EOF ERROR on 644
    [06-NOV-2009 14:51:24:742] ntt2err: exit
    [06-NOV-2009 14:51:24:742] nsprecv: error exit
    [06-NOV-2009 14:51:24:742] nserror: entry
    [06-NOV-2009 14:51:24:742] nserror: nsres: id=0, op=68, ns=12537, ns2=12560; nt[0]=507, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
    [06-NOV-2009 14:51:24:742] nsrdr: error exit
    [06-NOV-2009 14:51:24:742] nsdo: nsctxrnk=0
    [06-NOV-2009 14:51:24:742] nsdo: error exit
    [06-NOV-2009 14:51:24:742] nioqer: entry
    [06-NOV-2009 14:51:24:742] nioqer: incoming err = 12151
    [06-NOV-2009 14:51:24:742] nioqce: entry
    [06-NOV-2009 14:51:24:742] nioqce: exit
    [06-NOV-2009 14:51:24:742] nioqer: returning err = 3113
    [06-NOV-2009 14:51:24:742] nioqer: exit
    [06-NOV-2009 14:51:24:742] nioqrc: exit
    [06-NOV-2009 14:51:24:742] nioqrs: entry

    I am certainly not an expert in this area, but these lines are of interest
    >
    06-NOV-2009 14:51:24:742 ntt2err: Read unexpected EOF ERROR on 644
    06-NOV-2009 14:51:24:742 nserror: nsres: id=0, op=68, ns=12537, ns2=12560; nt[0]=507, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
    06-NOV-2009 14:51:24:742 nioqer: incoming err = 12151
    >
    The TNS 12537, 12560 and 12151 codes indicate network errors.
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14219/tnsus.htm#sthref14851
    Is this a consistently reproducible error ? Do other applications on this network operate without error ?
    HTH
    Srini

  • SQL*NET 에서 PROTOCOL ADAPTER DEINSTALL (UNIX)

    제품 : SQL*NET
    작성날짜 : 1998-11-24
    SQL*NET 에서 불필요한 protocol adapters deinstall 하기(unix)
    SQL*NET 에서 PROTOCOL ADAPTERS 를 DEINSTALL 하려면 다음과 같이 하시면
    됩니다
    1. ORACLE 계정으로 LOGIN
    2. orainst directory 로 에서 ( % cd $ORACLE_HOME/orainst )
    3. installer 실행 ( % ./orainst )
    4. DEINSTALL 할 SOFTWARE 를 선택하시고
    5. DEINSTALL 할 PROTOCOL ADAPTER 를 선택합니다
    6. NETWORK 의 LIB 디렉토리에서 ( % cd $ORACLE_HOME/network/lib )
    7. 새로운 ntcontab.o FILE 을 생성합니다 ( "$ORACLE_HOME/lib" 에 MOVE )
    % make -f network.mk ntcontab.o
    For 7.3.x:
    % make -f ins_network.mk ntcontab.o
    8. "ORACLE_HOME/lib" 디렉토리에서
    % cd $ORACLE_HOME/lib
    9. "libsqlnet.a" FILE 에 새로운 "ntcontab.o" FILE 을 archive 합니다
    % ar cr libsqlnet.a ntcontab.o

    Mark Gleaves (guest) wrote:
    : When normal users try to use SQL*Net to log on to a local
    : database on a Linux box, they get the message "ORA-12546:
    : TNS:permission denied". An example of this would be the
    : command
    : sqlplus scott/tiger@MG8
    : The oracle unix account can execute the above without problems
    : and when a normal user sets ORACLE_SID and omits the SQL*Net
    : connect string it works fine.
    Check that your oracle executable is SUID oracle and SGID dba?
    I'd have thought that would cause problems with bequeath
    connections, so perhaps not.
    Wierd error. You might try running an strace on the sqlplus to
    see what system call fails.
    -michael
    null

  • SQL*Net over IPC fails for normal users

    When normal users try to use SQL*Net to log on to a local
    database on a Linux box, they get the message "ORA-12546:
    TNS:permission denied". An example of this would be the command:
    sqlplus scott/tiger@MG8
    The oracle unix account can execute the above without problems
    and when a normal user sets ORACLE_SID and omits the SQL*Net
    connect string it works fine.
    Oddly, this is only a problem for connections using the IPC
    protocol. If I omit the IPC section from my listener.ora
    (leaving only the TCP section), non-privileged users can log on
    to local databases through SQL*Net without problems.
    I suppose it's not a big deal (there's not that much overhead
    going through the TCP loopback port on Linux), but I'm wondering
    what's wrong. SQL*Net over IPC certainly works on Solaris.
    This is on a S.u.S.E 5.3 distribution of Linux.
    null

    Mark Gleaves (guest) wrote:
    : When normal users try to use SQL*Net to log on to a local
    : database on a Linux box, they get the message "ORA-12546:
    : TNS:permission denied". An example of this would be the
    : command
    : sqlplus scott/tiger@MG8
    : The oracle unix account can execute the above without problems
    : and when a normal user sets ORACLE_SID and omits the SQL*Net
    : connect string it works fine.
    Check that your oracle executable is SUID oracle and SGID dba?
    I'd have thought that would cause problems with bequeath
    connections, so perhaps not.
    Wierd error. You might try running an strace on the sqlplus to
    see what system call fails.
    -michael
    null

  • 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

  • SQL*Net and Datapump export disconnects with ORA-03113 error

    Hi,
    I have some trouble with an Oracle 11.2.0.1.0 server installation on a Windows 2008 R2 server.
    If I am connected with SQL*Plus on the database server to an instance it randomly disconnects me, but no longer than after 30-60 seconds even though I am active running simple select queries.
    I can connect again without any error and soon it disconnects me again.
    If I am running an expdp, datapump export it starts but displays error UDE-03113 and then ORA-03113. The datapump export continues in the background and finish successfully though.
    When having a look at the Alert.log for the database instance I see this error everytime it happens:
    Fatal NI connect error 12547, connecting to:
    (LOCAL=NO)
    VERSION INFORMATION:
         TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
         Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
         Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
    Time: 22-JUL-2012 21:10:40
    Tracing not turned on.
    Tns error struct:
    ns main err code: 12547
    TNS-12547: TNS:lost contact
    ns secondary err code: 12560
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
    opiodr aborting process unknown ospid (19800) as a result of ORA-609
    Mon Jul 23 02:00:00 2012
    I don't believe it is an network problem as each command I am running is on the server console. No other errors in the OS event log so I need some help where to start...
    Thanks in advance!
    Best Regards
    Martin Gabrielsson

    Thanks, no windows firewall turned on, I turned on SQL*Net tracing and this is the last part of the trc file after doing a simple select query on a table with 3 rows. After the select query has been runned I am disconnected... Any idea, help is really appreciated!
    +2012-07-30 18:15:28.658650 : nsbasic_brc:packet dump+
    +2012-07-30 18:15:28.658660 : nsbasic_brc:01 74 00 00 06 00 00 00 |.t......|+
    +2012-07-30 18:15:28.658668 : nsbasic_brc:00 00 06 01 1A 00 26 00 |......&.|+
    +2012-07-30 18:15:28.658676 : nsbasic_brc:00 00 00 00 0F 00 00 00 |........|+
    +2012-07-30 18:15:28.658684 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658693 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658701 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658708 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658717 : nsbasic_brc:00 00 00 00 07 96 2C 00 |......,.|+
    +2012-07-30 18:15:28.658725 : nsbasic_brc:25 06 4D 52 20 20 20 20 |%.MR....|+
    +2012-07-30 18:15:28.658734 : nsbasic_brc:03 C2 1A 5F 04 C3 02 10 |..._....|+
    +2012-07-30 18:15:28.658742 : nsbasic_brc:43 06 43 4C 4F 53 45 44 |C.CLOSED|+
    +2012-07-30 18:15:28.658750 : nsbasic_brc:FF FF FF FF FF FF FF FF |........|+
    +2012-07-30 18:15:28.658758 : nsbasic_brc:FF FF 06 4C 50 49 4D 20 |...LPIM.|+
    +2012-07-30 18:15:28.658767 : nsbasic_brc:20 FF FF FF FF FF FF FF |........|+
    +2012-07-30 18:15:28.658775 : nsbasic_brc:FF FF FF FF FF 0A 4D 41 |......MA|+
    +2012-07-30 18:15:28.658783 : nsbasic_brc:52 47 41 42 20 20 20 20 |RGAB....|+
    +2012-07-30 18:15:28.658791 : nsbasic_brc:FF 3C 77 68 65 65 6C 20 |.<wheel.|+
    +2012-07-30 18:15:28.658799 : nsbasic_brc:73 68 6F 70 20 20 20 20 |shop....|+
    +2012-07-30 18:15:28.658807 : nsbasic_brc:20 20 20 20 20 20 20 20 |........|+
    +2012-07-30 18:15:28.658815 : nsbasic_brc:20 20 20 20 20 20 20 20 |........|+
    +2012-07-30 18:15:28.658824 : nsbasic_brc:20 20 20 20 20 20 20 20 |........|+
    +2012-07-30 18:15:28.658832 : nsbasic_brc:20 20 20 20 20 20 20 20 |........|+
    +2012-07-30 18:15:28.658840 : nsbasic_brc:20 20 20 20 20 20 20 20 |........|+
    +2012-07-30 18:15:28.658848 : nsbasic_brc:20 20 20 20 20 20 02 C1 |........|+
    +2012-07-30 18:15:28.658856 : nsbasic_brc:05 07 78 66 05 03 10 09 |..xf....|+
    +2012-07-30 18:15:28.658864 : nsbasic_brc:38 02 C1 02 FF 03 C2 08 |8.......|+
    +2012-07-30 18:15:28.658872 : nsbasic_brc:42 FF 01 58 04 01 00 00 |B..X....|+
    +2012-07-30 18:15:28.658880 : nsbasic_brc:00 14 00 01 02 00 00 00 |........|+
    +2012-07-30 18:15:28.658888 : nsbasic_brc:7B 05 00 00 00 00 02 00 |{.......|+
    +2012-07-30 18:15:28.658897 : nsbasic_brc:00 00 03 00 20 00 00 00 |........|+
    +2012-07-30 18:15:28.658905 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658912 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658921 : nsbasic_brc:00 00 00 00 00 16 00 00 |........|+
    +2012-07-30 18:15:28.658929 : nsbasic_brc:01 00 00 00 36 01 00 00 |....6...|+
    +2012-07-30 18:15:28.658937 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658945 : nsbasic_brc:00 00 00 00 E0 53 D1 22 |.....S."|+
    +2012-07-30 18:15:28.658953 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658961 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658969 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658977 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658987 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.658996 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.659004 : nsbasic_brc:00 00 00 00 00 00 00 00 |........|+
    +2012-07-30 18:15:28.659012 : nsbasic_brc:00 00 00 00 17 4F 52 41 |.....ORA|+
    +2012-07-30 18:15:28.659021 : nsbasic_brc:2D 30 31 34 30 33 3A 20 |-01403:.|+
    +2012-07-30 18:15:28.659029 : nsbasic_brc:64 61 74 61 20 73 61 6B |data.sak|+
    +2012-07-30 18:15:28.659038 : nsbasic_brc:6E 61 73 0A |nas. |+
    +2012-07-30 18:15:28.659046 : nsbasic_brc:exit: oln=0, dln=362, tot=372, rc=0+
    +2012-07-30 18:15:28.659054 : nioqrc:exit+
    +2012-07-30 18:16:09.583993 : nioqsn:entry+
    +2012-07-30 18:16:09.584062 : nioqsn:exit+
    +2012-07-30 18:16:09.584086 : nioqrc:entry+
    +2012-07-30 18:16:09.584097 : nsbasic_bsd:entry+
    +2012-07-30 18:16:09.584107 : nsbasic_bsd:tot=0, plen=318.+
    +2012-07-30 18:16:09.584116 : nttfpwr:entry+
    +2012-07-30 18:16:09.584146 : ntt2err:entry+
    +2012-07-30 18:16:09.584162 : ntt2err:soc 564 error - operation=6, ntresnt[0]=530, ntresnt[1]=54, ntresnt[2]=0+
    +2012-07-30 18:16:09.584171 : ntt2err:exit+
    +2012-07-30 18:16:09.584178 : nttfpwr:exit+
    +2012-07-30 18:16:09.584192 : nserror:entry+
    +2012-07-30 18:16:09.584203 : nserror:nsres: id=0, op=67, ns=12571, ns2=12560; nt[0]=530, nt[1]=54, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0+
    +2012-07-30 18:16:09.584213 : nsbasic_bsd:exit (-1)+
    +2012-07-30 18:16:09.584224 : nioqrc:send failed: bl = 1, nicbl = 1+
    +2012-07-30 18:16:09.584234 : nioqper: error from nioqrc+
    +2012-07-30 18:16:09.584242 : nioqper: ns main err code: 12571+
    +2012-07-30 18:16:09.584250 : nioqper: ns (2) err code: 12560+
    +2012-07-30 18:16:09.584258 : nioqper: nt main err code: 530+
    +2012-07-30 18:16:09.584266 : nioqper: nt (2) err code: 54+
    +2012-07-30 18:16:09.584275 : nioqper: nt OS err code: 0+
    +2012-07-30 18:16:09.584285 : nioqer:entry+
    +2012-07-30 18:16:09.584293 : nioqer: incoming err = 12150+
    +2012-07-30 18:16:09.584301 : niomapnserror:entry+
    +2012-07-30 18:16:09.584311 : niqme:entry+
    +2012-07-30 18:16:09.584321 : niqme:reporting NS-12571 error as ORA-12571+
    +2012-07-30 18:16:09.584330 : niqme:exit+
    +2012-07-30 18:16:09.584337 : niomapnserror:exit+
    +2012-07-30 18:16:09.584344 : nioqce:entry+
    +2012-07-30 18:16:09.584352 : nioqce:exit+
    +2012-07-30 18:16:09.584359 : nioqer: returning err = 12571+
    +2012-07-30 18:16:09.584366 : nioqer:exit+
    +2012-07-30 18:16:09.584374 : nioqrc: returning error: 12571+
    +2012-07-30 18:16:09.584381 : nioqrc:exit+
    +2012-07-30 18:16:09.584396 : nioqrs:entry+
    +2012-07-30 18:16:09.584412 : nioqrs: state = interrupted (1)+
    +2012-07-30 18:16:09.584425 : nscontrol:entry+
    +2012-07-30 18:16:09.584435 : nscontrol:cmd=45, lcl=0x0+
    +2012-07-30 18:16:09.584442 : nscontrol:normal exit+
    +2012-07-30 18:16:09.584450 : nscontrol:entry+
    +2012-07-30 18:16:09.584457 : nscontrol:cmd=1, lcl=0x0+
    +2012-07-30 18:16:09.584464 : nscontrol:normal exit+
    +2012-07-30 18:16:09.584476 : nioqsm:entry+
    +2012-07-30 18:16:09.584485 : nioqsm: Sending break packet (1)...+
    +2012-07-30 18:16:09.584493 : nscontrol:entry+
    +2012-07-30 18:16:09.584500 : nscontrol:cmd=45, lcl=0x0+
    +2012-07-30 18:16:09.584508 : nscontrol:normal exit+
    +2012-07-30 18:16:09.584516 : nsdo:entry+
    +2012-07-30 18:16:09.584525 : nsdo:cid=0, opcode=67, *bl=1, *what=17, uflgs=0x100, cflgs=0x3+
    +2012-07-30 18:16:09.584534 : nsdo:rank=64, nsctxrnk=0+
    +2012-07-30 18:16:09.584543 : nsdo:nsctx: state=8, flg=0x400d, mvd=0+
    +2012-07-30 18:16:09.584552 : nsdo:gtn=32, gtc=32, ptn=10, ptc=8191+
    +2012-07-30 18:16:09.584560 : nsdofls:entry+
    +2012-07-30 18:16:09.584569 : nsdofls:DATA flags: 0x0+
    +2012-07-30 18:16:09.584577 : nsdofls:normal exit+
    +2012-07-30 18:16:09.584587 : nsdo:sending NSPTMK packet+
    +2012-07-30 18:16:09.584596 : nspsend:entry+
    +2012-07-30 18:16:09.584605 : nspsend:plen=11, type=12+
    +2012-07-30 18:16:09.584614 : nttwr:entry+
    +2012-07-30 18:16:09.584628 : ntt2err:entry+
    +2012-07-30 18:16:09.584638 : ntt2err:soc 564 error - operation=6, ntresnt[0]=530, ntresnt[1]=54, ntresnt[2]=0+
    +2012-07-30 18:16:09.584646 : ntt2err:exit+
    +2012-07-30 18:16:09.584657 : nttwr:exit+
    +2012-07-30 18:16:09.584668 : nspsend:0 bytes to transport+
    +2012-07-30 18:16:09.584677 : nspsend:transport write error+
    +2012-07-30 18:16:09.584684 : nspsend:error exit+
    +2012-07-30 18:16:09.584692 : nsdo:error sending NSPTMK packet+
    +2012-07-30 18:16:09.584700 : nserror:entry+
    +2012-07-30 18:16:09.584709 : nserror:nsres: id=0, op=67, ns=12571, ns2=12560; nt[0]=530, nt[1]=54, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0+
    +2012-07-30 18:16:09.584719 : nsdo:nsctxrnk=0+
    +2012-07-30 18:16:09.584726 : nsdo:error exit+
    +2012-07-30 18:16:09.584737 : nioqsm:send-break: failed to send break...+
    +2012-07-30 18:16:09.584746 : nioqper: error from send-marker+
    +2012-07-30 18:16:09.584753 : nioqper: ns main err code: 12571+
    +2012-07-30 18:16:09.584761 : nioqper: ns (2) err code: 12560+
    +2012-07-30 18:16:09.584769 : nioqper: nt main err code: 530+
    +2012-07-30 18:16:09.584776 : nioqper: nt (2) err code: 54+
    +2012-07-30 18:16:09.584784 : nioqper: nt OS err code: 0+
    +2012-07-30 18:16:09.584792 : nioqsm:exit+
    +2012-07-30 18:16:09.584799 : nioqer:entry+
    +2012-07-30 18:16:09.584808 : nioqer: incoming err = 12152+
    +2012-07-30 18:16:09.584817 : niomapnserror:entry+
    +2012-07-30 18:16:09.584824 : niqme:entry+
    +2012-07-30 18:16:09.584833 : niqme:reporting NS-12571 error as ORA-12571+
    +2012-07-30 18:16:09.584840 : niqme:exit+
    +2012-07-30 18:16:09.584847 : niomapnserror:exit+
    +2012-07-30 18:16:09.584854 : nioqce:entry+
    +2012-07-30 18:16:09.584861 : nioqce:exit+
    +2012-07-30 18:16:09.584868 : nioqer: returning err = 12571+
    +2012-07-30 18:16:09.584876 : nioqer:exit+
    +2012-07-30 18:16:09.584884 : nioqrs:nioqrs: Couldn't send break. returning 12571+
    +2012-07-30 18:16:09.584894 : nioqrs:exit+
    +2012-07-30 18:16:09.584912 : nioqds:entry+
    +2012-07-30 18:16:09.584921 : nioqds: disconnecting...+
    +2012-07-30 18:16:09.584933 : nsclose:entry+
    +2012-07-30 18:16:09.584945 : nsvntx_dei:entry+
    +2012-07-30 18:16:09.584953 : nsvntx_dei:exit+
    +2012-07-30 18:16:09.584964 : nstimarmed:entry+
    +2012-07-30 18:16:09.584973 : nstimarmed:no timer allocated+
    +2012-07-30 18:16:09.584980 : nstimarmed:normal exit+
    +2012-07-30 18:16:09.584994 : nttctl:entry+
    +2012-07-30 18:16:09.585009 : nttctl:entry+
    +2012-07-30 18:16:09.585021 : nsfull_cls:entry+
    +2012-07-30 18:16:09.585031 : nsfull_cls:cid=0, opcode=65, *bl=0, *what=0, uflgs=0x0, cflgs=0x0+
    +2012-07-30 18:16:09.585040 : nsfull_cls:nsctx: state=8, flg=0x4009, mvd=0+
    +2012-07-30 18:16:09.585048 : nsdo:entry+
    +2012-07-30 18:16:09.585056 : nsdo:cid=0, opcode=67, *bl=0, *what=1, uflgs=0x0, cflgs=0x1+
    +2012-07-30 18:16:09.585065 : nsdo:nsctx: state=8, flg=0x4009, mvd=0+
    +2012-07-30 18:16:09.585074 : nsdo:gtn=32, gtc=32, ptn=10, ptc=8191+
    +2012-07-30 18:16:09.585082 : nsdo:normal exit+
    +2012-07-30 18:16:09.585089 : nsdofls:entry+
    +2012-07-30 18:16:09.585097 : nsdofls:DATA flags: 0x40+
    +2012-07-30 18:16:09.585105 : nsdofls:sending NSPTDA packet+
    +2012-07-30 18:16:09.585113 : nspsend:entry+
    +2012-07-30 18:16:09.585120 : nspsend:plen=10, type=6+
    +2012-07-30 18:16:09.585128 : nttwr:entry+
    +2012-07-30 18:16:09.585140 : ntt2err:entry+
    +2012-07-30 18:16:09.585150 : ntt2err:soc 564 error - operation=6, ntresnt[0]=530, ntresnt[1]=54, ntresnt[2]=0+
    +2012-07-30 18:16:09.585158 : ntt2err:exit+
    +2012-07-30 18:16:09.585165 : nttwr:exit+
    +2012-07-30 18:16:09.585173 : nspsend:0 bytes to transport+
    +2012-07-30 18:16:09.585181 : nspsend:transport write error+
    +2012-07-30 18:16:09.585188 : nspsend:error exit+
    +2012-07-30 18:16:09.585196 : nserror:entry+
    +2012-07-30 18:16:09.585205 : nserror:nsres: id=0, op=67, ns=12571, ns2=12560; nt[0]=530, nt[1]=54, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0+
    +2012-07-30 18:16:09.585215 : nsdofls:exit (-1)+
    +2012-07-30 18:16:09.585223 : nsbfr:entry+
    +2012-07-30 18:16:09.585230 : nsbaddfl:entry+
    +2012-07-30 18:16:09.585239 : nsbaddfl:normal exit+
    +2012-07-30 18:16:09.585247 : nsbfr:normal exit+
    +2012-07-30 18:16:09.585254 : nsbfr:entry+
    +2012-07-30 18:16:09.585261 : nsbaddfl:entry+
    +2012-07-30 18:16:09.585268 : nsbaddfl:normal exit+
    +2012-07-30 18:16:09.585276 : nsbfr:normal exit+
    +2012-07-30 18:16:09.585283 : nsfull_cls:normal exit+
    +2012-07-30 18:16:09.585291 : nsiocancel:entry+
    +2012-07-30 18:16:09.585303 : nsiofrrg:entry+
    +2012-07-30 18:16:09.585313 : nsiofrrg:cur = 5e5f3f8+
    +2012-07-30 18:16:09.585321 : nsbfr:entry+
    +2012-07-30 18:16:09.585328 : nsbaddfl:entry+
    +2012-07-30 18:16:09.585335 : nsbaddfl:normal exit+
    +2012-07-30 18:16:09.585342 : nsbfr:normal exit+
    +2012-07-30 18:16:09.585350 : nsiofrrg:exit+
    +2012-07-30 18:16:09.585358 : nsiocancel:exit+
    +2012-07-30 18:16:09.585365 : nsclose:closing transport+
    +2012-07-30 18:16:09.585375 : nttdisc:entry+
    +2012-07-30 18:16:09.585438 : nttdisc:Closed socket 564+
    +2012-07-30 18:16:09.585453 : nttdisc:exit+
    +2012-07-30 18:16:09.585463 : nsclose:global context check-out (from slot 0) complete+
    +2012-07-30 18:16:09.585471 : nsnadisc:entry+
    +2012-07-30 18:16:09.585484 : nadisc:entry+
    +2012-07-30 18:16:09.585496 : nacomtm:entry+
    +2012-07-30 18:16:09.585506 : nacompd:entry+
    +2012-07-30 18:16:09.585513 : nacompd:exit+
    +2012-07-30 18:16:09.585521 : nacompd:entry+
    +2012-07-30 18:16:09.585527 : nacompd:exit+
    +2012-07-30 18:16:09.585535 : nacomtm:exit+
    +2012-07-30 18:16:09.585545 : nas_dis:entry+
    +2012-07-30 18:16:09.585553 : nas_dis:exit+
    +2012-07-30 18:16:09.585562 : nau_dis:entry+
    +2012-07-30 18:16:09.585577 : nau_dis:exit+
    +2012-07-30 18:16:09.585587 : naeetrm:entry+
    +2012-07-30 18:16:09.585596 : naeetrm:exit+
    +2012-07-30 18:16:09.585604 : naectrm:entry+
    +2012-07-30 18:16:09.585613 : naectrm:exit+
    +2012-07-30 18:16:09.585623 : nagbltrm:entry+
    +2012-07-30 18:16:09.585632 : nau_gtm:entry+
    +2012-07-30 18:16:09.585640 : nau_gtm:exit+
    +2012-07-30 18:16:09.585648 : nagbltrm:exit+
    +2012-07-30 18:16:09.585657 : nadisc:exit+
    +2012-07-30 18:16:09.585665 : nsnadisc:normal exit+
    +2012-07-30 18:16:09.585675 : nsvntx_dei:entry+
    +2012-07-30 18:16:09.585682 : nsvntx_dei:exit+
    +2012-07-30 18:16:09.585694 : nsopenfree_nsntx:nlhthdel from mplx_ht_nsgbu, ctx=5e5e0e0 nsntx=5e5e6c0+
    +2012-07-30 18:16:09.585703 : nsiocancel:entry+
    +2012-07-30 18:16:09.585710 : nsiofrrg:entry+
    +2012-07-30 18:16:09.585718 : nsiofrrg:exit+
    +2012-07-30 18:16:09.585725 : nsiocancel:exit+
    +2012-07-30 18:16:09.585732 : nsmfr:entry+
    +2012-07-30 18:16:09.585741 : nsmfr:2944 bytes at 0x5e5e6c0+
    +2012-07-30 18:16:09.585748 : nsmfr:normal exit+
    +2012-07-30 18:16:09.585755 : nsmfr:entry+
    +2012-07-30 18:16:09.585763 : nsmfr:240 bytes at 0x5f2a610+
    +2012-07-30 18:16:09.585771 : nsmfr:normal exit+
    +2012-07-30 18:16:09.585778 : nsmfr:entry+
    +2012-07-30 18:16:09.585785 : nsmfr:280 bytes at 0x63c010+
    +2012-07-30 18:16:09.585792 : nsmfr:normal exit+
    +2012-07-30 18:16:09.585803 : nladtrm:entry+
    +2012-07-30 18:16:09.585820 : nladtrm:exit+
    +2012-07-30 18:16:09.585828 : nsmfr:entry+
    +2012-07-30 18:16:09.585836 : nsmfr:1496 bytes at 0x5e5e0e0+
    +2012-07-30 18:16:09.585844 : nsmfr:normal exit+
    +2012-07-30 18:16:09.585851 : nsclose:normal exit+
    +2012-07-30 18:16:09.585859 : nioqds:exit+
    +2012-07-30 18:16:09.585868 : nsbfree:entry+
    +2012-07-30 18:16:09.585876 : nsbgetfl:entry+
    +2012-07-30 18:16:09.585884 : nsbgetfl:normal exit+
    +2012-07-30 18:16:09.585894 : nsbaddfl:entry+
    +2012-07-30 18:16:09.585901 : nsbaddfl:normal exit+
    +2012-07-30 18:16:09.585909 : nsbfree:normal exit+
    +2012-07-30 18:16:09.585916 : nsbfree:entry+
    +2012-07-30 18:16:09.585923 : nsbgetfl:entry+
    +2012-07-30 18:16:09.585930 : nsbgetfl:normal exit+
    +2012-07-30 18:16:09.585938 : nsbaddfl:entry+
    +2012-07-30 18:16:09.585945 : nsbaddfl:normal exit+
    +2012-07-30 18:16:09.585952 : nsbfree:normal exit+
    +2012-07-30 18:16:09.585961 : nigtrm:Count in the NI global area is now 2+
    +2012-07-30 18:16:09.585974 : nsbfrfl:entry+
    +2012-07-30 18:16:09.585982 : nsbrfr:entry+
    +2012-07-30 18:16:09.585991 : nsbrfr:nsbfs at 0x5f26470, data at 0x5f26520.+
    +2012-07-30 18:16:09.585999 : nsbrfr:normal exit+
    +2012-07-30 18:16:09.586006 : nsbrfr:entry+
    +2012-07-30 18:16:09.586015 : nsbrfr:nsbfs at 0x5f28540, data at 0x5f285f0.+
    +2012-07-30 18:16:09.586025 : nsbrfr:normal exit+
    +2012-07-30 18:16:09.586033 : nsbrfr:entry+
    +2012-07-30 18:16:09.586040 : nsbrfr:nsbfs at 0x5e5f480, data at 0x5e5f530.+
    +2012-07-30 18:16:09.586048 : nsbrfr:normal exit+
    +2012-07-30 18:16:09.586055 : nsbrfr:entry+
    +2012-07-30 18:16:09.586063 : nsbrfr:nsbfs at 0x5f2a610, data at 0x5f2a9f0.+
    +2012-07-30 18:16:09.586073 : nsbrfr:normal exit+
    +2012-07-30 18:16:09.586082 : nsbrfr:entry+
    +2012-07-30 18:16:09.586090 : nsbrfr:nsbfs at 0x62c7d0, data at 0x5f2ca10.+
    +2012-07-30 18:16:09.586098 : nsbrfr:normal exit+
    +2012-07-30 18:16:09.586106 : nsbfrfl:normal exit+
    +2012-07-30 18:16:09.586153 : nigtrm:Count in the NL global area is now 3+

  • OS/390 (MVS) to Unix - SQL*Net - Exists?

    I am going to start working with Oracle under MVS (OS/390).
    I am familiar conceptually with the concept of SQL*Net and its distributed architecture enablement.
    From a MVS perspective, does such a concept exist that would allow me, from MVS, to talk to an installation of Oracle on Unix via something like SQL*Net.
    I have searched the documentation without success on this subject.

    This is not a problem. You must configure SQL*Net, of course according to OS/390 rules and then you can connect to servers on any other platform. We do it at our site. Here's a working example for tnsnames, using TCP/IP:
    # TNS CONNECT DESCRIPTORS
    # LOOPBACK FUER ORA8
    # MVS-Loopback
    ORA8LOOP = (DESCRIPTION =
    (ADDRESS =
    (PROTOCOL = TCP)
    (HOST = hame)
    (SSN = NET8)
    (PORT = 1520)
    # Unix-Machine
    GISA = (DESCRIPTION =
    (ADDRESS =
    (PROTOCOL = TCP)
    (HOST = sqlhhp03)
    (SSN = NET8)
    (PORT = 1521)
    (CONNECT_DATA = (SID = GISA))
    Werner

Maybe you are looking for