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

Similar Messages

  • 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를 띄운다)

  • ORA-6107 조치 방법

    제품 : SQL*NET
    작성날짜 : 1996-07-02
    PC에서 SQL*NET V1을 사용하여 서버에 접속시
    "ORA-6107 NETTCP: ORACLE network server not found "
    에러가 발생하는 경우 다음과 같은 원인을 생각해 볼 수 있습니다.
    (1)orasrv 가 PC의 TCP/IP services 화일에 등록이 안되어 있는 경우
    C:\ 상태에서
         dir services /s
    명령으로 services 화일을 찾은 다음 이것을 editor 로 열어서 다음과 같은
    문장이 있는지 확인하고 없으면 추가해 줍니다.
         orasrv          1525/tcp
    1525 는 orasrv 가 사용하는 port 번호인데 services 화일은 port 번호가
    작은 것부터 큰 순으 정렬이 되어 있어야 하므로 이 라인을 적절한 곳에
    끼워 넣으면 됩니다.
    (2)오라클이 services 화일을 인식하지 못하는 경우
    이 경우에는 PC에서 TCP_SERVICSE_FILE이라는 파라미터를 oracle.ini에 세팅하면 됩니다.
    예를 들어 services 화일이 C:\FUTURE\ETC 디렉토리에 있다고 가정하면
    oracle.ini에서
         TCP_SERVICES_FILE=C:\FUTURE\ETC\SERVICES
         와 같이 해주면 됩니다.
    Windows95 의 경우에는 이 값을 REGISTRY에 세팅을 해야 합니다.
    다음과 같이 하면 됩니다. 즉,
    DOS 창에서 REGEDIT32.EXE 실행
    HKEY_LOCAL_MACHINE -> SOFTWARE -> ORACLE 선택
    TCP_SERVICES_FILE 등록
    (3)계속 해결이 안되면 접속시에 직접 PORT 번호를 지정해서 접속하도록 합니다.
    다음과 같이 하면 됩니다.
    username = scott
    password = tiger
    connect string = t:hostname/1525:<SID>

  • 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

  • SQL*NET V1,V2 사용 시 ORA-9241, ORA-9301 조치방법

    제품 : SQL*NET
    작성날짜 : 1995-11-07
    SQL*Net V1, V2 사용 시 ORA-9241, ORA-9301 조치 방법
    ==================================================
    ORA-9241, ORA-9301 에러는 개발 툴이 해당 툴 또는 SQL*Net에 필요한 메세지
    화일을 찾을 수 없을 때 발생한다.
    * SQL*NET V 1
    1. DOS 환경에서 SET을 수행하여 CLIENT상에 CONFIG라는 환경변수가 설정되어
    있는지 확인한다.
    2. 설정되어 있지 않으면 ROOT directory에서 CONFIG.ORA 또는 ORACLE.INI라는
    화일을 찾는다. (Directory Search)
    (상기의 화일은 보통 \ ORACLE_HOME 또는 \ WINDOWS Directory 내에 있다.)
    상기의 화일이 존재하면 DOS환경에서 다음의 CONFIG 환경변수를 추가한다.
    C:\> SET CONFIG = <PATH> \ORACLE.INI
    이로써 문제가 해결될 수 있으며, DOS 환경에서 SET과 PATH 명령을 수행하여
    ORACLE_HOME 디렉토리가 PATH에 설정되어 있는지, 그리고 CONFIG가 DOS환경에
    설정되어 있는지 확인하고 WINDOWS를 실행해야 한다.
    3. 환경변수 CONFIG가 이미 설정되어 있고 ORACLE.INI 또는 CONFIG.ORA를
    지시하고 있는데도 ORA-9241 또는 ORA-9301 에러가 계속 발생한다면
    WINDOWS를 완전히 빠져나와서 ORACLE.INI를 CONFIG.ORA 라는 또 다른 화일로
    복사를 하고 DOS 환경에서 환경변수 CONFIG를 추가한다.
    C:\> SET CONFIG = <path> \CONFIG.INI
    4. 만일 ORACLE.INI 를 autoexec.bat 파일에 SET CONFIG = <PATH> \ORACLE.INI
    와 같이 추가하여도 계속 에러가 발생한다면 ORACLE.INI 파일에
    LOCAL = t:hostname:sid 을 추가한다.
    5. 단계2 또는 단계3 에서 문제가 해결된다면 이를 AUTOEXEC.BAT 화일에 SET
    CONFIG문을 추가한다.
    * SQL*NET V 2
    1. ORACLE.INI 파일에 LOCAL = <V2 service name>을 추가한다. 만일 ORACLE.INI
    파일에 LOCAL 파라미터를 추가한 후에도 계속 ora-9301 에러가 계속 발생한다면
    autoexec.bat 파일에 SET CONFIG = <PATH> \ORACLE.INI를 추가한다.
    [주의 1] CONFIG가 ORACLE.INI를 지시하도록 설정하면 나중에 다시 설치할
    문제가 발생할 수 있다. 그럴 때는 AUTOEXEC.BAT 에서 SET CONFIG 행을
    삭제하고 다시 Booting 한후 설치를 시작한다.
    [주의 2] MS ACCESS를 이용하여 ORACLE의 데이타를 질의할 경우는 환경변수를
    다음과 같이 설정한다.
    SET CONFIG_FILES = <path> \ORACLE.INI
    [주의 3] SET 다음의 CONFIG 나 CONFIG_FILES 은 반드시 대문자 이어야 한다.

  • WINDOWS 용 SQL*NET 사용 시 ORA-6122

    제품 : SQL*NET
    작성날짜 : 1995-11-10
    WINDOWS 용 SQL*NET 사용 시 ORA-6122
    ===================================
    ORA-6122 "NETTCP: setup failure"는 SQL*NET 구성이 적절하게 설정되지 않은
    상태에서 WINDOWS 용 SQL*NET TCP/IP를 가지고 연결하려 할 때 발생합니다.
    구성을 점검하여 다음 사항을 제대로 설정했는지 확인하십시오.
    1. WINDOWS\WIN.INI를 조사해 보십시오. ORA_CONFIG 매개 변수를 정의하는
    ORACLE 부분이 있어야 합니다.
    [Oracle]
    ORA_CONFIG=C:\WINDOWS\ORACLE.INI
    2. ORACLE.INI(또는 ORA_CONFIG 매개변수가 지시하는 파일)을 보십시오.
    ORACLE_HOME이 WINDOWS용 SQL*NET TCP/IP와 다른 Oracle Windows 응용 프로
    그램이 설치된 디렉토리를 지시하는지 확인하십시오.
    디폴트는 다음과 같습니다.
    ORACLE_HOME=\ORAWIN
    3. 또한 ORACLE.INI에 TCP_VENDOR를 정확하게 설정했는지도 확인하십시오.
    유효한 업체 키 목록은 WINDOWS용 SQL*NET TCP/IP 설정의 표 3-4 '업체키'를
    참조하십시요.
    4. 경로에 C:\ORAWIN\BIN(또한 ORACLE_HOME을 설정한 BIN 디렉토리)이 있는지
    확인하십시오.
    DOS 프롬프트에서 SET을 입력하고 <return>을 누르면 됩니다.
    이 명령은 경로를 보여줍니다.
    5. ORAWIN\BIN 디렉토리에 SQLTCP.DLL과 SQLTCP1.DLL이 모두 있는지 확인하십시오.
    6. 경로의 다른 어떤 디렉토리에도 SQLTCP.DLL이 없는 것을 확인하십시오.
    7. ORAWIN\BIN 디렉토리와 경로의 다른 디렉토리에 MSOCKLIB.DLL이 있는지
    확인하십시오.
    또한 파일의 두 복사본을 가지고 있지 않도록 하십시오.
    복사본이 둘일 경우, 이전 복사본의 이름을 바꾸면 문제가 줄어들 수 있습니다.
    8. WINDOWS 디렉토리에 VSL.INI 파일이 있는지 확인하십시오.
    만약 없으면 ORACLE INSTALLER를 통해 SQL*NET를 다시 입력하십시오.

  • 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

  • WINDOWS용 SQL*NET 사용시 ORA-6106

    제품 : SQL*NET
    작성날짜 : 1995-11-08
    다음은 먼저 WINDOWS용 SQL*NET TCP/IP와 ORA-6106을 간단하게 소개한 다음 ORA
    -6106을 진단하는 방법을 설명하겠습니다.
    * WINDOWS용 SQL*NET TCP/IP
    WIN V1.X용 SQL*NET TCP/IP는 현재로서는 SQLTCP.DLL과 SQLTCP1.DLL 등 두개
    의 DLL이 한 세트로 되어 있습니다. 이들 DLL은 ORACLE용 연결 스트링이 TCP/IP
    프로토콜 스트링으로 변환되면 OCI DLL에 의해 작업 진행중에 올려집니다.
    ORACLE INTERFACE DLL은 SQLTCP.DLL을 먼저 올리려고 합니다. 이것이 실패하면
    DOS TSR 버전의 드라이버를 찾습니다. 두 가지 모두 실패하면 ORA-3121
    메세지가 나옵니다.
    1. SQL*NET DLL은 올려지자마자 MSOCKLIB.DLL(ORACLE에서 제공됨)이 올려집니다.
    이 DLL은 ORACLE.INI로부터 TCP_VENDOR 스트링으로 전달받습니다ㅏ. 그 후, 이
    MSOCKLIB.DLL은 TCP_VENDOR 스트링을 사용하여 항상 WINDOWS 디렉토리에 있는
    VSL.INI라는 파일을 엽니다. VSL 파일은 JSB 호출을 각 업체 고유의 API에
    대응시킵니다. VSL.INI가 없으면 MSOCKLIB.DLL이 초기화에 실패하여 ORA-6120
    "NETTCP : network driver not loaded" 메세지가 나오게 됩니다. 이것은 고객이
    다른 기계에서 SQL*NET DLL을 복사하거나 XCOPY 명령으로 ORAWIN 디렉토리
    전체를 복사하기만 하고 이 VSL.INI 파일을 복사하지 않을 때 자주 발생합니다.
    2. VSL.INI가 있다 하더라도 TCP_VENDOR 매개 변수에 ORA-6120 또는 ORA-6106
    "NETTCP : socket creation failure"를 유발할 수 있는 오류가 적지 않습니다.
    3. 이 문제의 다른 원인은 MSOCKLIB.DLL이 대응을 제대로 결정할 수 있지만
    MSOCKLIB.DLL API를 해당 업체의 TRANSPORT 인터페이스 또는 API에 결합하도록
    글루(glue)에 지시할 수 없는 것입니다. 이 글루는 SQL*NET TCP/IP를 설치할 때
    선택하는 TCP/IP 업체에 따라 DLL 또는 TSR일 수 있습니다. 예를 들면, WINDOWS
    로 들어가기 전에 글루 DLL이 실패할 수도 있고 (이를테면 MNOVLWP.DLL) 벤더
    고유의 TSR(예를 들면 MFTP.EXE)이 올려지지 않았을 수도 있습니다. 이 글루를
    구성하는 DLL과 TSR의 목록은 다음과 같습니다.
    . m3open.dll : 3Com 3+Open v2.0
    . mhparpa.dll : HP ARPA v2.0 & v2.1 그리고 Micorsoft TCP V1.0
    (LAN Manager v2.2의 번들)
    . mnovlwp.dll : Novell LAN WorkPlace v4.0, v4.01, & v4.1
    . mpcnfs4.dll : Sun PC-NFS v4.0a
    . mpathsay.dll : Wollongong Runtime TCP v1.1 & v1.2
    . mwinsock.dll : VSL 일반형 windows sockets DLL 버전 1.1
    . Frontier Technology Super - TCP v3.0
    . NetManage Chameleon TCP v3.1과 v3.22
    . FTP PCTCP v2.2 - Winsock Interface
    (1993년 5월 4일자 WINSOCK.DLL)
    . SUN PC/NFS 5.0 - Winsock Interface
    (1993년 3월 2일자 WINSOCK.DLL)
    . DOS용 IBM TCP v2.1.0.2
    (1993년 3월 30일자 WINSOCK.DLL)
    . m3open.exe : 3Com 3+Open v1.1 & v1.2 및 DOS용 Digital
    Pathworks(TCP/IP) v4.1
    . mb2.exe : Beame 및 Whiteside TCP/IP v3.0
    . mftp.exe : FTP PC/TCP v2.1 부터 v2.2까지
    . mpcnfs.exe : Sun PC-NFS v3.0
    . mpcnfs2.exe : Sun PC-NFS v3.5
    | Oracle Win App |
    |
    | (연결)
    |
    | OCI 레이어 : |
    | ORA6WIN.DLL 또는|
    | ORA7WIN.DLL |
    |
    | (진행중에 올려지며 진입점을 갖게 됨)
    | (여기서 ORA-3121이 발생할 수 있음)
    |
    --------------------- (DLL의 초기화 -- Windows가 인핸스드 모드에
    | SQLTCP1.DLL | 있지 않으면 실패함.
    --------------------- -- ORA-3121이 발생)
    | |
    | (연결) |-----------------| (연결)
    | |
    |ORA7WIN.DLL -- | |MSOCKLIB.DLL -- |
    | SQL*NET에서 일부 | | 모든 TCP/IP API의 |
    | 찾아보기 루틴을 | | 진입됨 |
    | 위해 사용됨 | ----------------------
    -------------------- | |
    | | |
    | (연결) | |
    | | |
    | COREWIN.DLL | VSL.INI와 TCP_VENDOR를 사용하여 업체 특유의
    -------------------- 인터페이스(예를 들면, MONVLWP.DLL)을 올리거나
    인터페이스 TSR(예를 들면, MFTP.EXE)에 접속함.
    여기서 ORA-3120 또는 ORA-6106이 발생할 수 있음.
    4. 지원되는 TCP/IP 패키지 또는 버전을 설치하지 않은 것도 ORA-6106의 원인이
    될 수 있습니다. 예를 들어서 TCP_VENDOR=PCNFS4를 가지고 있는 데 Sun PC-NFS
    v4.0를 실행하면, TCP_VENDOR=PCNFS4 를 실행할 때 반드시 사용해야 하는
    버전인 Sun PC_NFS v4.0a를 올리자 않았기 때문에 ora-6106이 발생할 수
    있습니다. 우리는 SUN PC-NFS v4.0을 지원하지 않습니다. 지원되는 버전과
    지원되는 TCP/IP 제품을 사용중인지 확인하십시요. (3단계 참조)
    5. 지원되는 TCP/IP패키지와 버전을 설치 했더라도 TCP/IP 패키지에 필요한 실행
    파일을 모두 설치하지 않았으면 ORA-6106이 발생할 수 있습니다. 예를 들어,
    RTM과 RNMFILE(또는 NIS를 사용할 경우 RNMNIS)를 올리지 않았다면 PC-NFS를
    사용할 때 ORA-6106이 발생할 수 있습니다. Microsoft TCP를 사용할 경우에는
    반드시 SOCKETS.EXE를 올려야 합니다.
    6. 또한 CONFIG.SYS의 FILES와 BUFFERS를 충분히 높게 설정하지 않으면
    ORA-6106이 발생할 수 있습니다. 다음은 이들 매개변수의 최소 요구사항입니다.
    BUFFERS = 16
    FILES = 60
    7. ORA-6106의 또 다른 원인은 실제 메모리의부족입니다.
    * ORA-6106을 진단하는 단계
    1. TCP/IP 업체의 PING과 TELNET이 잘 작동하는 지 점검하십시요. 이들
    유틸리티의 GUI 버전이 도움이 될수 있습니다. 이들 유틸리티가 작동하지
    않으면 TCP/IP 설치 책자를 참조하거나 TCP/IP 업체에 연락하십시요.
    2. 이들 유틸리티가 작동하지 않으면 WINDOWS 디렉토리에 VSL.INI 파일이 있는
    지 점검 하십시요. 만약, 없으면 WINDOWS용 SQL*NET TCP/IP를 다시 설치하거나
    다른 곳에서 복사해 오십시요.
    3. WINDOWS 디렉토리에 VSL.INI가 있으면 TCP/IP 업체를 바르게 선택을 하면서
    TCP/IP를 설치 했는지 점검 하십시요.
    4. 제대로 설치했으면 ORACLE.INI의 TCP_VENDOR 매개 변수를 읽어 보십시요.
    TCP_VENDOR의 값에 정확한 TCP/IP 패키지와 버전을 사용중인지 확인하십시요.
    그런다음 VSL.INI로 가서 그 TCP_VENDOR의 프로파일을 살펴 보십시요.
    프로파일의 "netmodule"은 무엇입니까? "netinterface"가 DLL이라면. 그 DLL을
    찾을 수 있습니까? 필요할 때 WINDOWS가 DOS PATH를 통해 그 DLL을 올릴 수
    있습니까? "netinterface"가 TSR이라면 WINDOWS로 들어가기 전에 반드시 그
    TSR을 실제로 올리십시요.
    5. CONFIG.SYS의 FILES와 BUFFERS를 충분히 높게 설정했는 지 확인 하십시요.
    다음은 이들 두 매개변수의 최소 요구사항입니다.
    BUFFERS = 16
    FILES = 60
    6. 앞서 말한 단계를 다 수행했는데도 여전히 ORA-6106이 발생하면 기본
    메모리의 일부를 해제해 (불필요한 TSR을 내리거나 일부 TSR을 상위 메모리로
    올려서) 보십시요.
    7. Micorsoft TCP/IP를 사용 한다면 TCPUTILS.INI의 SCOKETS값을 점검하십시요.
    값이 너무 낮으면 올리십시요. 또한 SOCKETS.EXE를 호출했는 지도
    확인하십시요.
    8. WINDOWS를 통해 SUN PC-NFS V5를 사용할 때 문제점이 생길 때가 있습니다.
    그러한 경우에는 SQL*NET TCP/IP를 다시 설치하고, SUN PC-NFS V4.0a(V5가
    아니라)를 업체로 선택해 보십시요. 이 때 RTM과 RNMFILE(또는 NIS를 사용할
    경우 RNMNIS)을 반드시 올려야 합니다.

  • 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를 재기동합니다.

  • 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+

  • ORA-00604: error occurred at recursive SQL level 1 ORA-01003: no statement

    Hi ,
    we pass Query to ref cursor using with clause and it works fine on oracle Sql but raise an error when called from
    ADO.net
    for example
    create or replace package body abc_details
    as
    proedure initial (p_refcursor out sys_refcursor)
    is
    begin
    v_sql='with a as (select ..
    , b as (select * from table(emppkg.empdetails))
    open p_refcursor for v_sql;
    end;
    with oracle 10g it works fine on Sql prompt and fetches the results but when called from ado.net it
    intermitantly fetches and error "ORA-00604: error occurred at recursive SQL level 1 ORA-01003: no statement "
    Please suggest
    Thanks in advance.

    wild guess here,
    but emppkg.empdetails type look's like a pl/sql type,
    while it should be a sql type.
    Amiel

  • TRACING IN SQL*NET V2

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

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

  • 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

  • CLIENT SIDE TRACING IN SQL*NET V2

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

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

  • 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

Maybe you are looking for