SQL*NET V2에서 LOG 와 TRACE의 PARAMETER

제품 : SQL*NET
작성날짜 : 1997-06-23
SQL*NET V2에서 LOG 와 TRACE의 PARAMETER
=======================================
<< SQLNET.ORA >>
=======================================================================
PARAMETERS     | Values     | Example (CLIENT, UNIX)
=======================================================================
* CLIENT side
=======================================================================
TRACE_LEVEL_CLIENT | OFF/USER/ADMIN     | TRACE_LEVEL_CLIENT=USER
TRACE_FILE_CLIENT | string     | TRACE_FILE_CLIET=client.trc
TRACE_DIRECTORY_CLIENT | valid directory | TRACE_DIRECTORY_CLIENT = | | c:\temp\trace
TRACE_UNIQUE_CLIENT | OFF/ON     | TRACE_UNIQUE_CLIENT=ON
LOG_FILE_CLIENT     | string     | LOG_FILE_CLIENT=client.log
LOG_DIRECTORY_CLIENT | valid directory | LOG_DIRECTORY_CLIENT=c:\temp
| | \log
=======================================================================
* SERVER side
=======================================================================
TRACE_LEVEL_SERVER | OFF/USER/ADMIN     | TRACE_LEVEL_SERVER=USER
TRACE_FILE_SERVER | string     | TRACE_FILE_SERVER=server.trc
TRACE_DIRECTORY_SERVER | valid directory | TRACE_DIRECTORY_SERVER =
| | c:\temp\trace
LOG_FILE_SERVER     | string     | LOG_FILE_SERVER=server.log
LOG_DIRECTORY_SERVER | valid directory | LOG_DIRECTORY_SERVER=c:\temp
| | \log
=======================================================================
* TNSPING          
=======================================================================
TNSPING.TRACE_LEVEL | OFF/USER/ADMIN     | TNSPING.TRACE_LEVEL=USER
TNSPING.TRACE_DIRECTORY| valid directory | TNSPING.TRACE_DIRECTORY
| | =/oracle/network/trace
=======================================================================
<< LISTENER.ORA >>
=======================================================================
PARAMETERS | VALUES | EXAMPLE (CLIENT,UNIX)
=======================================================================
TRACE_LEVEL_LISTENER | OFF/USER/ADMIN | TRACE_LEVEL_LISTENER=OFF
TRACE_FILE_LISTENER     | string | TRACE_FILE_LISTENER =
| | listener.trc
TRACE_DIRECTORY_LISTENER | valid directory | TRACE_DIRECTORY_LISTENER=
| | /oracle/network/trace
LOG_FILE_LISTENER     | string | LOG_FILE_LISTENER =
| | listener.log
LOG_DIRECTORY_LISTENER     | valid directory | LOG_DIRECTORY_LISTENER =
| | /oracle/network/log
=======================================================================

제품 : SQL*NET
작성날짜 : 1997-06-23
SQL*NET V2에서 LOG 와 TRACE의 PARAMETER
=======================================
<< SQLNET.ORA >>
=======================================================================
PARAMETERS     | Values     | Example (CLIENT, UNIX)
=======================================================================
* CLIENT side
=======================================================================
TRACE_LEVEL_CLIENT | OFF/USER/ADMIN     | TRACE_LEVEL_CLIENT=USER
TRACE_FILE_CLIENT | string     | TRACE_FILE_CLIET=client.trc
TRACE_DIRECTORY_CLIENT | valid directory | TRACE_DIRECTORY_CLIENT = | | c:\temp\trace
TRACE_UNIQUE_CLIENT | OFF/ON     | TRACE_UNIQUE_CLIENT=ON
LOG_FILE_CLIENT     | string     | LOG_FILE_CLIENT=client.log
LOG_DIRECTORY_CLIENT | valid directory | LOG_DIRECTORY_CLIENT=c:\temp
| | \log
=======================================================================
* SERVER side
=======================================================================
TRACE_LEVEL_SERVER | OFF/USER/ADMIN     | TRACE_LEVEL_SERVER=USER
TRACE_FILE_SERVER | string     | TRACE_FILE_SERVER=server.trc
TRACE_DIRECTORY_SERVER | valid directory | TRACE_DIRECTORY_SERVER =
| | c:\temp\trace
LOG_FILE_SERVER     | string     | LOG_FILE_SERVER=server.log
LOG_DIRECTORY_SERVER | valid directory | LOG_DIRECTORY_SERVER=c:\temp
| | \log
=======================================================================
* TNSPING          
=======================================================================
TNSPING.TRACE_LEVEL | OFF/USER/ADMIN     | TNSPING.TRACE_LEVEL=USER
TNSPING.TRACE_DIRECTORY| valid directory | TNSPING.TRACE_DIRECTORY
| | =/oracle/network/trace
=======================================================================
<< LISTENER.ORA >>
=======================================================================
PARAMETERS | VALUES | EXAMPLE (CLIENT,UNIX)
=======================================================================
TRACE_LEVEL_LISTENER | OFF/USER/ADMIN | TRACE_LEVEL_LISTENER=OFF
TRACE_FILE_LISTENER     | string | TRACE_FILE_LISTENER =
| | listener.trc
TRACE_DIRECTORY_LISTENER | valid directory | TRACE_DIRECTORY_LISTENER=
| | /oracle/network/trace
LOG_FILE_LISTENER     | string | LOG_FILE_LISTENER =
| | listener.log
LOG_DIRECTORY_LISTENER     | valid directory | LOG_DIRECTORY_LISTENER =
| | /oracle/network/log
=======================================================================

Similar Messages

  • NET8의 LOGGING과 TRACE 관련 PARAMETER에 대한 Q & A

    제품 : SQL*NET
    작성날짜 : 2002-05-07
    NET8의 LOGGING과 TRACE 관련 PARAMETER에 대한 Q & A
    =================================================
    PURPOSE
    Net8을 이용하면서 발생하는 문제를 추적 하기위해 oracle의 configuration
    file에 들어갈 수 있는 parameter와 logging과 tracing을 하는 방법에 대해
    질의/응답을 통해 알아 보도록 한다.
    Explanation
    1) NET8에서 trace를 사용하는 이유와 어떤 component들에 trace를 할 수 있나?
    Trace의 특징은 네트워크을 수행하게 될때 network event들을 기술한다
    즉 trace와 관련된 일련의 문장들이 자세하게 생성된다.
    "Tracing"의 운영으로 log파일에 제공되어 있는 것 보다 NET8의 component들의
    내부적인 정보를 보다 많이 얻을 수 있다.
    이러한 정보는 에러의 결과로 인하여 발생하는 동일한 event들로 파일들에
    결과가 생성되어 이를 이용하여 문제의 원인을 판단할 수 있다.
    주의 : trace의 기능을 이용하는 경우 충분한 disk space와 system performance의
    현격한 저하를 가져올 수 있다 즉 trace의 기능은 반드시 필요할
    경우에만 사용할 것을 권한다.
    << trace의 기능을 이용하여 trace를 할 수 있는 component들 >>
    * Network listener
    * Net8 components on the client and server
    * Connection Manager
    * Oracle Names Server
    * Oracle Names Control Utility
    * TNSPING utility
    2) 어떤 parameter들을 설정하면 trace 기능을 이용할 수 있는가 ?
    tracing을 하기 위해서는 특정 trace parameter들을 설정함으로써 가능하며
    아래에 주어진 방법들과 또는 utility들중 하나를 선택하여 설정함으로써
    사용할 수 있다.
    * Component Configuration Files
    * Component Control Utilities
    * Oracle Trace
    component의 configuration 파일을 이용하여 traceing parameter를 설정하려면
    1.component의 configuration 파일에 다음의 traceing parameter를 설정한다.
    - SQLNET.ORA for client or server, LISTENER.ORA for listener:
    TRACE_LEVEL_<CLIENT/LISTENER/SERVER>=(0/4/10/16)
    TRACE_DIRECTORY_<CLIENT/LISTENER/SERVER>=<directory name>
    LOG_DIRECTORY_<CLIENT/LISTENER/SERVER>=<directory name>
    2.만일 component들이 수행중인 동안 configuration 파일의 수정이 있었다면
    병경된 parameter들을 사용하기 위해 component들을 다시 시작하여야 한다.
    component control utility들을 이용하여 trace parameter들을 설정하려면
    1. listener의 경우, Listener Control Utility(lsnrctl)에서 TRACE 명령어를
    이용하여 listener가 수행중인 동안에도 trace level을 설정할 수 있다.
    EX)
         RC80:/mnt3/rctest80> lsnrctl
         LSNRCTL for SVR4: Version 8.0.4.0.0 - Production on 01-SEP-98 15:16:52
         (c) Copyright 1997 Oracle Corporation. All rights reserved.
         Welcome to LSNRCTL, type "help" for information.
         LSNRCTL> trace admin
         Connecting to (ADDRESS=(PROTOCOL=ipc)(KEY=PNPKEY))
         Opened trace file: /mnt4/coe/app/oracle/product/8.0.4/network/trace/
    lsnr_coe.trc
         The command completed successfully
         LSNRCTL> trace off
         Connecting to (ADDRESS=(PROTOCOL=ipc)(KEY=PNPKEY))
         The command completed successfully
         LSNRCTL> exit
         RC80:/mnt3/rctest80>
    2. Oracle Names의 경우, Names Control Utility(namesctl)에서 TRACE_LEVEL
    명령어를 이용하여 Oracle Names가 수행중인 동안에도 trace level을
    설정할 수 있다.
    주의 : Connection Manager의 경우, trace level은 configuration 파일인 CMAN.ORA
    에서만 설정할 수 있다.
    Oracle Enterprose manager(이하 OEM)에 있는 Oracle Trace는 trace parameter들을
    설정하고 GUI를 통해 trace data의 형태를 볼수 있도록 하는 tracing tool이다.
    3) trace된 data를 해석할 수 있는 다른 utility들이 있다면 ?
    Trace Assistant를 사용하면 사용자의 *.trc 파일 (SQL*Net v2의 형식에 의해
    생성된) 또는 *.txt (Orace Trace 과 TRCFMT에 의해 생성된 출력물)을 통해
    trac된 정보를 해석할 수 있다.
    이 유틸리티 네트워크의 문제들로 인해 발생하는 문제점들을 진단하고
    해결하는 데 보다 많은 정보를 제공하여 사용자의 이해를 돕는다.
    * the source and destination of trace files
    * the flow of packets between network nodes
    * which component of Net8 is failing
    * pertinent error codes
    다음에 주어진 명령어를 수행하므로써 Trace Assistant 실행할 수 있다.
    trcasst [options] <filename>
    Trace Assistant Text Formatting Options
    -o Displays connectivity and Two Task Common (TTC) information.
    After the -o the following options may be used:
    c (for summary connectivity information)
    d (for detailed connectivity information)
    u (for summary TTC information)
    t (for detailed TTC information)
    q (displays SQL commands enhancing summary TTC information)
    -p Oracle Internal Use Only
    -s Displays statistical information
    -e Enables display of error information After the -e, zero
    or one error decoding level may follow:
    0 or nothing : translates the NS error numbers dumped from the
    nserror function plus lists all other errors
    1 : displays only the NS error translation from the nserror function
    2 : displays error numbers without translation
    만일 option들이 제공되지 않는다면 기본적으로 -odt -e -s가 지정되어 자세한
    connectivity, Two-Task Common, 에러 level 0 그리고 통계정보들이 tracing 된다.
    4) SQL*Net v2 tracing과 어떻게 다른가 ?
    Net8 tracing에서는 이전 버전인 SQL*NET V2에서 제공 되는 모든 option을
    포함하고 있고 Oracle Trace의 기능이 추가되었다.
    이것은 Oracle Trace Repository를 OEM 콘솔을 통하여 사용자의 trace 정보를
    관리할 수 있도록 허용한다.
    5) *.cdf와 *.dat은 어떤 파일 인가 ?
    *.cdf 와 *.dat 파일들은 Oracle Trace에 의해 생성되는 파일들로서 이 파일들을
    읽기 위해서는 반드시 trcfmt utility를 이용해야만 한다.
    trcfmt는 binary (*.dat와 *.cdf의 확장자) 파일내에 있는 data를
    일반 text(.txt의 확장자)로 정보를 추출한다. 이 tool을 사용하기 위해서는
    다음의 명령어를 이용하면 된다.
    trcfmt collection.cdf
    주의 : .cdf와 .dat파일이 존재하는 디렉토리가 아닌 곳에서 이 tool을 이용
         한다면 path가 포함되야 한다. 만일 하나의 .cdf 와 .dat 파일들내에
         여러 프로세스들의 tracing정보가 수집된다면 그것들은 process_id.txt의
    이름과 함께 파일이 추출될 것이다.
    6) trac관련 configuration은 어떤 것이 있으며 설정할 수 있는 parameter는
    무엇이 있는가 ?
    ==========================================================================
    || SQLNET.ORA Parameters ||
    ==========================================================================
    DAEMON.TRACE_DIRECTORY
    Purpose: Controls the destination directory of the Oracle
    Enterprise Manager daemon trace file
    Default Value: $ORACLE_HOME/network/trace
    Description
    Available Oracle Enterprise Manager Installation Guide
    Example: DAEMON.TRACE_DIRECTORY=/oracle/traces
    DAEMON.TRACE_LEVEL
    Purpose: Turns tracing on/off to a certain specified level for
    the Oracle Enterprise Manager daemon.
    Default Value: 0 or OFF
    * 0 or OFF - No trace output
    * 4 or USER - User trace information
    Available Values
    * 10 or ADMIN - Administration trace information
    * 16 or SUPPORT - WorldWide Customer Support trace
    information
    Description
    Available Oracle Enterprise Manager Installation Guide
    Example: DAEMON.TRACE_LEVEL=10
    DAEMON.TRACE_MASK
    Purpose: Specifies that only the Oracle Enterprise Manager daemon
    trace entries are logged into the trace file.
    Default Value: $ORACLE_HOME/network/trace
    Description
    Available Oracle Enterprise Manager Installation Guide
    Example: DAEMON.TRACE_MASK=(106)
    LOG_DIRECTORY_CLIENT
    Purpose: Controls the directory for where the log file is written
    Default Value: Current directory where executable is started from.
    Example: LOG_DIRECTORY_CLIENT=/oracle/network/trace
    LOG_DIRECTORY_SERVER
    Purpose: Controls the directory for where the log file is written
    Default Value: Current directory where executable is started from.
    Valid in File: SQLNET.ORA
    Example: LOG_DIRECTORY_SERVER=/oracle/network/trace
    LOG_FILE_CLIENT
    Purpose: Controls the log output filename for an Oracle client.
    Default Value: SQLNET.LOG
    Example: LOG_FILE_CLIENT=client
    LOG_FILE_SERVER
    Purpose: Controls the log output filename for an Oracle server.
    Default Value: SQLNET.LOG
    Example: LOG_FILE_SERVER=svr
    NAMESCTL.TRACE_LEVEL
    Purpose: Indicates the level at which the NAMESCTL program should
    be traced.
    Default Value: OFF
    Values: OFF, USER, or ADMIN
    Example: NAMESCTL.TRACE_LEVEL=ADMIN
    NAMESCTL.TRACE_FILE
    Purpose: Indicates the file in which the NAMESCTL trace output is
    placed.
    Default Value: namesctl_PID.cdf and namesctl_PID.dat
    Example: NAMESCTL.TRACE_FILE=NMSCTL
    NAMESCTL.TRACE_DIRECTORY
    Purpose: Indicates the directory where trace output from the NAMESCTL
    utility is placed.
    Default
    Value: $ORACLE_HOME/network/trace
    Example: NAMESCTL.TRACE_DIRECTORY=/ORACLE/TRACE
    NAMESCTL.TRACE_UNIQUE
    Indicates whether a process identifier is appended to the
    Purpose: name of each trace file generated, so that several can
    coexist.
    Default
    Value: OFF
    Values: OFF or ON
    Example: NAMESCTL.TRACE_UNIQUE = ON
    TNSPING.TRACE_DIRECTORY
    Purpose: Control the destination directory of the trace file
    Default Value: $ORACLE_HOME/network/trace
    Example: TNSPING.TRACE_DIRECTORY=/oracle/traces
    TNSPING.TRACE_LEVEL
    Purpose: Turns tracing on/off to a certain specified level
    Default Value: 0 or OFF
    * 0 or OFF - No trace output
    * 4 or USER - User trace information
    Available Values
    * 10 or ADMIN - Administration trace information
    * 16 or SUPPORT - WorldWide Customer Support trace
    information
    Example: TNSPING.TRACE_LEVEL=10
    TRACE_DIRECTORY_CLIENT
    Purpose: Control the destination directory of the trace file
    Default Value: $ORACLE_HOME/network/trace
    Example: TRACE_DIRECTORY_CLIENT=/oracle/traces
    TRACE_DIRECTORY_SERVER
    Purpose: Control the destination directory of the trace file
    Default Value: $ORACLE_HOME/network/trace
    Example: TRACE_DIRECTORY_SERVER=/oracle/traces
    TRACE_FILE_CLIENT
    Purpose: Controls the name of the client trace file
    Default Value: SQLNET.CDF and SQLNET.DAT
    Example: TRACE_FILE_CLIENT=cli
    TRACE_FILE_SERVER
    Purpose: Controls the name of the server trace file
    Default Value: SVR_PID.CDF and SVR_PID.DAT
    Example: TRACE_FILE_SERVER=svr
    TRACE_LEVEL_CLIENT
    Purpose: Turns tracing on/off to a certain specified level
    Default Value: 0 or OFF
    * 0 or OFF - No trace output
    * 4 or USER - User trace information
    Available Values
    * 10 or ADMIN - Administration trace information
    * 16 or SUPPORT - WorldWide Customer Support trace
    information
    Example: TRACE_LEVEL_CLIENT=10
    TRACE_LEVEL_SERVER
    Purpose: Turns tracing on/off to a certain specified level
    Default Value: 0 or OFF
    * 0 or OFF - No trace output
    * 4 or USER - User trace information
    Available Values
    * 10 or ADMIN - Administration trace information
    * 16 or SUPPORT - WorldWide Customer Support trace
    information
    Example: TRACE_LEVEL_SERVER=10
    TRACE_UNIQUE_CLIENT
    Used to make each client trace file have a unique name to
    Purpose: prevent each trace file from being overwritten with the next
    occurrence of the client. The PID is attached to the end of
    the filename.
    Default
    Value: OFF
    Example: TRACE_UNIQUE_CLIENT=ON
    USE_CMAN
    If the session is in an Enhanced Discovery Network with a
    Purpose: Names Server, this parameter forces all sessions to go
    through a Connection Manager to get to the server.
    Default
    Value: FALSE
    Values: TRUE or FALSE
    Example: USE_CMAN=TRUE
    ==========================================================================
    || LISTENER.ORA Parameters ||
    ==========================================================================
    LOG_DIRECTORY_listener_name
    Purpose: Controls the directory for where the log file is written
    Default Value: Current directory where executable is started from.
    Example: LOG_DIRECTORY_LISTENER=/oracle/traces
    LOG_FILE_listener_name
    Purpose: Specifies the filename where the log information is
    written
    Default Value: listener_name.log
    Example: LOG_FILE_LISTENER=lsnr
    TRACE_DIRECTORY_listener_name
    Purpose: Control the destination directory of the trace file
    Default Value: $ORACLE_HOME/network/trace
    Example: TRACE_DIRECTORY_LISTENER=/oracle/traces
    TRACE_FILE_listener_name
    Purpose: Controls the name of the listener trace file
    Default Value: LISTENER_NAME.CDF and LISTENER_NAME.DAT
    Example: TRACE_FILE_LISTENER=lsnr
    TRACE_LEVEL_listener_name
    Purpose: Turns tracing on/off to a certain specified level
    Default Value: 0 or OFF
    * 0 or OFF - No trace output
    * 4 or USER - User trace information
    Available Values
    * 10 or ADMIN - Administration trace information
    * 16 - WorldWide Customer Support trace information
    Example: TRACE_LEVEL_LISTENER=10
    ==========================================================================
    || NAMES.ORA Parameters ||
    ==========================================================================
    NAMES.TRACE_DIRECTORY
    Purpose: Indicates the name of the directory to which trace files
    from a Names Server trace session are written.
    Default
    Value: platform specific
    Example: names.trace_directory = complete_directory_name
    NAMES.TRACE_FILE
    Purpose: Indicates the name of the output file from a Names Server
    trace session. The filename extension is always.trc
    Default
    Value: names
    Example: names.trace_file = filename
    NAMES.TRACE_LEVEL
    Purpose: Indicates the level at which the Names Server is to be
    traced.
    Default Value: OFF
    Example: names.trace_level = OFF
    NAMES.TRACE_UNIQUE
    indicates whether each trace file has a unique name, allowing
    Purpose: multiple trace files to coexist. If the value is set to ON, a
    process identifier is appended to the name of each trace file
    generated.
    Default
    Value: OFF
    Example: names.trace_unique = ON
    names.trace_file = names_05.trc
    ==========================================================================
    CMAN.ORA Parameters
    ==========================================================================
    TRACING
    Default
    Value: NO
    Example: TRACING = NO
    References
    7) listener.log 파일에 loggin정보를 남기지 않게 하는 방법이 있나요 ?
    고객이 개발하여 사용중인 application에서 NET8을 이용하여 접속하거나 접속을
    종료하는 경우 listener.log에 이와 관련된 정보가 남으며, 수 많흔 사용자가
    접속을 하게되므로서 급속하게 listener.log 파일이 커져 file system이 꽉
    차거나 데이터베이스가 hang이 되는 결과를 초래하는 경우가 있다.
    고객들은 listener.log에 write할수 있는 메세지의 양에 제한을 두기를 원하는
    경우가 있으나 이러한 기능은 제공되지 않는다. 하지만 listener의 logging은
    on 또는 off를 할 수는 있다.
    Net8에서는 listener.ora에 "LOGGING_(the listener name)=off"를 설정하게 되면
    listener의 logging을 멈출 수 있다.
    ** SQL*NET 2.3.x 에서도 이 parameter가 유효한가요 ? **
    물론 사용이 가능합니다. NET8에서 사용하는 것과 동일하게 parameter를
    listener.ora에 설정함으로서 가능합니다.
    EX)
    LOGGING_LISTENER=OFF
    이 parameter는 listener의 전체 logging을 disable하는 parameter로 일부만
    여과하여 logging할 수 있는 기능은 아니다.
    이 parameter는 NET8에 알려진 parameter로 SQL*NET 2.3.x manuals에 나와
    있지는 않지만 정상적으로 사용할 수 있다.
    Reference Ducumment
    ---------------------

  • SQL*NET waits in trace file

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

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

  • NET8의 LOGGING AND TRACE관련 PARAMETER에 대한 Q & A

    제품 : SQL*NET
    작성날짜 : 1999-07-30
    NET8의 LOGGING AND TRACE관련 PARAMETER에 대한 Q & A
    ==================================================
    PURPOSE
    NET8의 LOGGING AND TRACE관련 PARAMETER에 대해 알아 보도록한다
    Explanation
    1. NET8에서 trace를 왜 사용하고 어떤 component들에 trace를 할 수 있나요 ?
    Trace의 특징은 네트워크을 수행하게 될때 network event들을 기술한다
    즉 trace와 관련된 일련의 문장들이 자세하게 생성된다.
    "Tracing"의 운영으로 log파일에 제공되어 있는 것 보다 NET8의 component들의
    내부적인 정보를 보다 많이 얻을 수 있다.
    이러한 정보는 에러의 결과로 인하여 발생하는 동일한 event들로 파일들에
    결과가 생성되어 이를 이용하여 문제의 원인을 판단할 수 있다.
    주의 : trace의 기능을 이용하는 경우 충분한 disk space와 system
    performance의 현격한 저하를 가져올 수 있다.
    즉 trace의 기능은 반드시 필요할 경우에만 사용할 것을 권한다.
    Example
    Reference Ducumment
    << trace의 기능을 이용하여 trace를 할수 있는 component들 >>
    * Network listener
    * Net8 components on the client and server
    * Connection Manager
    * Oracle Names Server
    * Oracle Names Control Utility
    * TNSPING utility
    2. 어떤 parameter들을 설정하면 trace 기능을 이용할 수 있는가 ?
    tracing을 하기 위해서는 특정 trace parameter들을 설정함으로써 가능하며
    아래에 주어진 방법들과 또는 utility들중 하나를 선택하여 설정함으로써
    사용할 수 있다.
    * Component Configuration Files
    * Component Control Utilities
    * Oracle Trace
    component의 configuration 파일을 이용하여 traceing parameter를 설정하려면
    1) component의 configuration 파일에 다음의 traceing parameter를 설정한다.
    - SQLNET.ORA for client or server, LISTENER.ORA for listener:
    TRACE_LEVEL_<CLIENT/LISTENER/SERVER>=(0/4/10/16)
    TRACE_DIRECTORY_<CLIENT/LISTENER/SERVER>=<directory name>
    LOG_DIRECTORY_<CLIENT/LISTENER/SERVER>=<directory name>
    2) 만일 component들이 수행중인 동안 configuration 파일의 수정이 있었다면
    변경된 parameter들을 사용하기 위해 component들을 다시 시작하여야 한다.
    component control utility들을 이용하여 trace parameter들을 설정하려면
    1) listener의 경우, Listener Control Utility(lsnrctl)에서 TRACE 명령어를
    이용하여 listener가 수행중인 동안에도 trace level을 설정할 수 있다.
    EX)
    RC80:/mnt3/rctest80> lsnrctl
    LSNRCTL for SVR4: Version 8.0.4.0.0 - Production on 01-SEP-98 15:16:52
    (c) Copyright 1997 Oracle Corporation. All rights reserved.
    Welcome to LSNRCTL, type "help" for information.
    LSNRCTL> trace admin
    Connecting to (ADDRESS=(PROTOCOL=ipc)(KEY=PNPKEY))
    Opened trace file: /mnt4/coe/app/oracle/product/8.0.4/network/trace/
    lsnr_coe.trc
    The command completed successfully
    LSNRCTL> trace off
    Connecting to (ADDRESS=(PROTOCOL=ipc)(KEY=PNPKEY))
    The command completed successfully
    LSNRCTL> exit
    RC80:/mnt3/rctest80>
    2) Oracle Names의 경우, Names Control Utility(namesctl)에서 TRACE_LEVEL
    명령어를 이용하여 Oracle Names가 수행중인 동안에도 trace level을
    설정할 수 있다.
    주의 : Connection Manager의 경우, trace level은 configuration 파일인
    CMAN.ORA 에서만 설정할 수 있다.
    Oracle Enterprose manager(이하 OEM)에 있는 Oracle Trace는 trace parameter
    들을 설정하고 GUI를 통해 trace data의 형태를 볼수 있도록 하는 tracing tool
    이다.
    3. Trace된 data를 해석할 수 있는 다른 utility들이 있다면 ?
    Trace Assistant를 사용하면 사용자의 *.trc 파일 (SQL*Net v2의 형식에 의해
    생성된) 또는 *.txt (Orace Trace 과 TRCFMT에 의해 생성된 출력물)을 통해
    trac된 정보를 해석할 수 있다.
    이 유틸리티 네트워크의 문제들로 인해 발생하는 문제점들을 진단하고
    해결하는 데 보다 많은 정보를 제공하여 사용자의 이해를 돕는다.
    * the source and destination of trace files
    * the flow of packets between network nodes
    * which component of Net8 is failing
    * pertinent error codes
    다음에 주어진 명령어를 수행하므로써 Trace Assistant 실행할 수 있다.
    trcasst [options] <filename>
    Trace Assistant Text Formatting Options
    -o Displays connectivity and Two Task Common (TTC) information.
    After the -o the following options may be used:
    c (for summary connectivity information)
    d (for detailed connectivity information)
    u (for summary TTC information)
    t (for detailed TTC information)
    q (displays SQL commands enhancing summary TTC
    information)
    -p Oracle Internal Use Only
    -s Displays statistical information
    -e Enables display of error information After the -e, zero
    or one error decoding level may follow:
    0 or nothing (translates the NS error numbers dumped
    from the nserror function plus lists all
    other errors)
    1 (displays only the NS error translation from
    the nserror function)
    2 (displays error numbers without translation)
    만일 option들이 제공되지 않는다면 기본적으로 -odt -e -s가 지정되어 자세한
    connectivity, Two-Task Common, 에러 level 0 그리고 통계정보들이 tracing
    된다.
    4. SQL*Net v2 tracing과 어떻게 다른가 ?
    Net8 tracing에서는 이전 버전인 SQL*NET V2에서 제공 되는 모든 option을
    포함하고 있고 Oracle Trace의 기능이 추가되었다.
    이것은 Oracle Trace Repository를 OEM 콘솔을 통하여 사용자의 trace 정보를
    관리할 수 있도록 허용한다.
    5. *.cdf와 *.dat은 어떤 파일 인가 ?
    *.cdf 와 *.dat 파일들은 Oracle Trace에 의해 생성되는 파일들로서 이 파일들을
    읽기 위해서는 반드시 trcfmt utility를 이용해야만 한다.
    trcfmt는 binary (*.dat와 *.cdf의 확장자) 파일내에 있는 data를 일반text
    (.txt의 확장자)로 정보를 추출한다. 이 tool을 사용하기 위해서는 다음의
    명령어를 이용하면 된다.
    $ trcfmt collection.cdf
    주의 : .cdf와 .dat파일이 존재하는 디렉토리가 아닌 곳에서 이 tool을 이용
    한다면 path가 포함되야 한다. 만일 하나의 .cdf 와 .dat 파일들내에
    여러 프로세스들의 traceing정보가 수집된다면 그것들은 process_id.txt
    의 이름과 함께 파일이 추출될 것이다.
    6. trac관련 configuration은 어떤 것이 있으며 설정할 수 있는 parameter는
    무엇이 있는가 ?
    ==========================================================================
    || SQLNET.ORA Parameters ||
    ==========================================================================
    DAEMON.TRACE_DIRECTORY
    Purpose: Controls the destination directory of the Oracle
    Enterprise Manager daemon trace file
    Default Value: $ORACLE_HOME/network/trace
    Description
    Available Oracle Enterprise Manager Installation Guide
    Example: DAEMON.TRACE_DIRECTORY=/oracle/traces
    DAEMON.TRACE_LEVEL
    Purpose: Turns tracing on/off to a certain specified level for
    the Oracle Enterprise Manager daemon.
    Default Value: 0 or OFF
    * 0 or OFF - No trace output
    * 4 or USER - User trace information
    Available Values
    * 10 or ADMIN - Administration trace information
    * 16 or SUPPORT - WorldWide Customer Support trace
    information
    Description
    Available Oracle Enterprise Manager Installation Guide
    Example: DAEMON.TRACE_LEVEL=10
    DAEMON.TRACE_MASK
    Purpose: Specifies that only the Oracle Enterprise Manager daemon
    trace entries are logged into the trace file.
    Default Value: $ORACLE_HOME/network/trace
    Description
    Available Oracle Enterprise Manager Installation Guide
    Example: DAEMON.TRACE_MASK=(106)
    LOG_DIRECTORY_CLIENT
    Purpose: Controls the directory for where the log file is written
    Default Value: Current directory where executable is started from.
    Example: LOG_DIRECTORY_CLIENT=/oracle/network/trace
    LOG_DIRECTORY_SERVER
    Purpose: Controls the directory for where the log file is written
    Default Value: Current directory where executable is started from.
    Valid in File: SQLNET.ORA
    Example: LOG_DIRECTORY_SERVER=/oracle/network/trace
    LOG_FILE_CLIENT
    Purpose: Controls the log output filename for an Oracle client.
    Default Value: SQLNET.LOG
    Example: LOG_FILE_CLIENT=client
    LOG_FILE_SERVER
    Purpose: Controls the log output filename for an Oracle server.
    Default Value: SQLNET.LOG
    Example: LOG_FILE_SERVER=svr
    NAMESCTL.TRACE_LEVEL
    Purpose: Indicates the level at which the NAMESCTL program should
    be traced.
    Default Value: OFF
    Values: OFF, USER, or ADMIN
    Example: NAMESCTL.TRACE_LEVEL=ADMIN
    NAMESCTL.TRACE_FILE
    Purpose: Indicates the file in which the NAMESCTL trace output is
    placed.
    Default Value: namesctl_PID.cdf and namesctl_PID.dat
    Example: NAMESCTL.TRACE_FILE=NMSCTL
    NAMESCTL.TRACE_DIRECTORY
    Purpose: Indicates the directory where trace output from the NAMESCTL
    utility is placed.
    Default
    Value: $ORACLE_HOME/network/trace
    Example: NAMESCTL.TRACE_DIRECTORY=/ORACLE/TRACE
    NAMESCTL.TRACE_UNIQUE
    Indicates whether a process identifier is appended to the
    Purpose: name of each trace file generated, so that several can
    coexist.
    Default
    Value: OFF
    Values: OFF or ON
    Example: NAMESCTL.TRACE_UNIQUE = ON
    TNSPING.TRACE_DIRECTORY
    Purpose: Control the destination directory of the trace file
    Default Value: $ORACLE_HOME/network/trace
    Example: TNSPING.TRACE_DIRECTORY=/oracle/traces
    TNSPING.TRACE_LEVEL
    Purpose: Turns tracing on/off to a certain specified level
    Default Value: 0 or OFF
    * 0 or OFF - No trace output
    * 4 or USER - User trace information
    Available Values
    * 10 or ADMIN - Administration trace information
    * 16 or SUPPORT - WorldWide Customer Support trace
    information
    Example: TNSPING.TRACE_LEVEL=10
    TRACE_DIRECTORY_CLIENT
    Purpose: Control the destination directory of the trace file
    Default Value: $ORACLE_HOME/network/trace
    Example: TRACE_DIRECTORY_CLIENT=/oracle/traces
    TRACE_DIRECTORY_SERVER
    Purpose: Control the destination directory of the trace file
    Default Value: $ORACLE_HOME/network/trace
    Example: TRACE_DIRECTORY_SERVER=/oracle/traces
    TRACE_FILE_CLIENT
    Purpose: Controls the name of the client trace file
    Default Value: SQLNET.CDF and SQLNET.DAT
    Example: TRACE_FILE_CLIENT=cli
    TRACE_FILE_SERVER
    Purpose: Controls the name of the server trace file
    Default Value: SVR_PID.CDF and SVR_PID.DAT
    Example: TRACE_FILE_SERVER=svr
    TRACE_LEVEL_CLIENT
    Purpose: Turns tracing on/off to a certain specified level
    Default Value: 0 or OFF
    * 0 or OFF - No trace output
    * 4 or USER - User trace information
    Available Values
    * 10 or ADMIN - Administration trace information
    * 16 or SUPPORT - WorldWide Customer Support trace
    information
    Example: TRACE_LEVEL_CLIENT=10
    TRACE_LEVEL_SERVER
    Purpose: Turns tracing on/off to a certain specified level
    Default Value: 0 or OFF
    * 0 or OFF - No trace output
    * 4 or USER - User trace information
    Available Values
    * 10 or ADMIN - Administration trace information
    * 16 or SUPPORT - WorldWide Customer Support trace
    information
    Example: TRACE_LEVEL_SERVER=10
    TRACE_UNIQUE_CLIENT
    Used to make each client trace file have a unique name to
    Purpose: prevent each trace file from being overwritten with the next
    occurrence of the client. The PID is attached to the end of
    the filename.
    Default
    Value: OFF
    Example: TRACE_UNIQUE_CLIENT=ON
    USE_CMAN
    If the session is in an Enhanced Discovery Network with a
    Purpose: Names Server, this parameter forces all sessions to go
    through a Connection Manager to get to the server.
    Default
    Value: FALSE
    Values: TRUE or FALSE
    Example: USE_CMAN=TRUE
    ==========================================================================
    || LISTENER.ORA Parameters ||
    ==========================================================================
    LOG_DIRECTORY_listener_name
    Purpose: Controls the directory for where the log file is written
    Default Value: Current directory where executable is started from.
    Example: LOG_DIRECTORY_LISTENER=/oracle/traces
    LOG_FILE_listener_name
    Purpose: Specifies the filename where the log information is
    written
    Default Value: listener_name.log
    Example: LOG_FILE_LISTENER=lsnr
    TRACE_DIRECTORY_listener_name
    Purpose: Control the destination directory of the trace file
    Default Value: $ORACLE_HOME/network/trace
    Example: TRACE_DIRECTORY_LISTENER=/oracle/traces
    TRACE_FILE_listener_name
    Purpose: Controls the name of the listener trace file
    Default Value: LISTENER_NAME.CDF and LISTENER_NAME.DAT
    Example: TRACE_FILE_LISTENER=lsnr
    TRACE_LEVEL_listener_name
    Purpose: Turns tracing on/off to a certain specified level
    Default Value: 0 or OFF
    * 0 or OFF - No trace output
    * 4 or USER - User trace information
    Available Values
    * 10 or ADMIN - Administration trace information
    * 16 - WorldWide Customer Support trace information
    Example: TRACE_LEVEL_LISTENER=10
    ==========================================================================
    || NAMES.ORA Parameters ||
    ==========================================================================
    NAMES.TRACE_DIRECTORY
    Purpose: Indicates the name of the directory to which trace files
    from a Names Server trace session are written.
    Default
    Value: platform specific
    Example: names.trace_directory = complete_directory_name
    NAMES.TRACE_FILE
    Purpose: Indicates the name of the output file from a Names Server
    trace session. The filename extension is always.trc
    Default
    Value: names
    Example: names.trace_file = filename
    NAMES.TRACE_LEVEL
    Purpose: Indicates the level at which the Names Server is to be
    traced.
    Default Value: OFF
    Example: names.trace_level = OFF
    NAMES.TRACE_UNIQUE
    indicates whether each trace file has a unique name, allowing
    Purpose: multiple trace files to coexist. If the value is set to ON, a
    process identifier is appended to the name of each trace file
    generated.
    Default
    Value: OFF
    Example: names.trace_unique = ON
    names.trace_file = names_05.trc
    ==========================================================================
    CMAN.ORA Parameters
    ==========================================================================
    TRACING
    Default
    Value: NO
    Example: TRACING = NO
    References
    7. listener.log 파일에 loggin정보를 남기지 않게 하는 방법이 있나요 ?
    고객이 개발하여 사용중인 application에서 NET8을 이용하여 접속하거나 접속을
    종료하는 경우 listener.log에 이와 관련된 정보가 남으며, 수 많은 사용자가
    접속을 하게 되므로서 급속하게 listener.log 파일이 커져 $ORACLE_HOME이 있는
    file system이 꽉 차서 데이터베이스가 hang이 되는 결과를 초래하는 경우가 있다.
    고객들은 listener.log에 write할수 있는 메세지의 양에 제한을 두기를 원하는
    경우가 있으나 이러한 기능은 제공되지 않는다. 하지만 listener의 logging은
    ON 또는 OFF는 설정을 통해서 가능하다.
    Net8에서는 listener.ora에 "LOGGING_(the listener name)=off"를 설정하게
    되면 listener의 logging을 멈출 수 있다.
    물론 설정후 listener stop후 재기동을 하셔야 변경된 paramerter에 의해
    이 기능이 enable됩니다.
    참고 : SQL*NET 2.3.x 에서도 이 parameter가 유효한가요 ?
    물론 사용이 가능합니다. NET8에서 사용하는 것과 동일하게 parameter를
    listener.ora에 설정함으로서 가능합니다.
    EX)
    LOGGING_LISTENER=OFF
    이 parameter는 listener의 전체 logging을 disable하는 parameter로 일부만
    여과하여 logging할 수 있는 기능은 아니다.
    이 parameter는 NET8에 알려진 parameter로 SQL*NET 2.3.x manuals에 나와
    있지는 않지만 정상적으로 사용할 수 있다.

  • 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

  • High SQL*Net message values in trace file.

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

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

  • 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 message from client - huge wait in trace file

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

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

  • 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

  • VMS : SQL*NET V2.0 ARCHITECTURE

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

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

  • SQL*NET V2 최적화하기

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

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

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

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

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

  • Extract SQL history from 10046 trace files

    Hi all,
    I need to extract the complete sql history from sql trace files to "debug" a client application.
    I know I can read the raw trc file and rebuild the sql history looking for the PARSING / EXEC / FETCH entries.
    However, this is a very long and boring manual task: do you know if there is some free tool to automate this task?
    thanks
    Andrea

    user585511 wrote:
    I agree that the 10046 trace captures everything. If I do read the raw trc file I see the DML. The problem is that tkprof's record does not record the DML (maybe it thinks that some DML is recursive sql and it gets misleaded... I am not sure) so I am looking for an alternate tool to process 10046 trace files
    Regards
    AndreaReally?
    Generate a trace of some dml:
    oracle:orcl$
    oracle:orcl$ sqlplus /nolog
    SQL*Plus: Release 11.2.0.1.0 Production on Thu May 16 08:28:55 2013
    Copyright (c) 1982, 2009, Oracle.  All rights reserved.
    SQL> conn snuffy/snuffy
    Connected.
    SQL> alter session set tracefile_identifier = "snuffy_session";
    Session altered.
    SQL> alter session set events '10046 trace name context forever, level 12';
    Session altered.
    SQL> insert into mytest values (sysdate);
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> ALTER SESSION SET EVENTS '10046 trace name context off';
    Session altered.
    SQL> exitrun tkprof on the trace
    oracle:orcl$ ls -l $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/trace/*snuffy
    *.trc
    -rw-r----- 1 oracle asmadmin 3038 May 16 08:29 /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snuffy_session.trc
    oracle:orcl$ tkprof /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snu
    ffy_session.trc snuffy.rpt waits=YES sys=NO explain=system/halftrack
    TKPROF: Release 11.2.0.1.0 - Development on Thu May 16 08:31:32 2013
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.Look at the report:
    oracle:orcl$ cat snuffy.rpt
    TKPROF: Release 11.2.0.1.0 - Development on Thu May 16 08:31:32 2013
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    Trace file: /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snuffy_session.trc
    Sort options: default
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    SQL ID: 938dgt554gu98
    Plan Hash: 0
    insert into mytest           <<<<<<<<<<<<<<<< oh my!  Here is the insert statement
    values
    (sysdate)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          1          5           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          0          1          5           1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 86  (SNUFFY)
    Rows     Row Source Operation
          0  LOAD TABLE CONVENTIONAL  (cr=1 pr=0 pw=0 time=0 us)
    error during execute of EXPLAIN PLAN statement
    ORA-00942: table or view does not exist
    parse error offset: 83
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       1        0.00          0.00
      SQL*Net message from client                     1        3.35          3.35
    SQL ID: 23wm3kz7rps5y
    Plan Hash: 0
    commit
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          1           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          0          0          1           0
    Misses in library cache during parse: 0
    Parsing user id: 86  (SNUFFY)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      SQL*Net message from client                     2        4.72          8.50
      log file sync                                   1        0.00          0.00
    SQL ID: 0kjg1c2g4gdcr
    Plan Hash: 0
    ALTER SESSION SET EVENTS '10046 trace name context off'
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
    Parsing user id: 86  (SNUFFY)
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        3      0.00       0.00          0          0          0           0
    Execute      3      0.00       0.00          0          1          6           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        6      0.00       0.00          0          1          6           1
    Misses in library cache during parse: 0
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       3        0.00          0.00
      SQL*Net message from client                     3        4.72         11.86
      log file sync                                   1        0.00          0.00
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        0      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
        3  user  SQL statements in session.
        0  internal SQL statements in session.
        3  SQL statements in session.
        0  statements EXPLAINed in this session.
    Trace file: /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snuffy_session.trc
    Trace file compatibility: 11.1.0.7
    Sort options: default
           1  session in tracefile.
           3  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           3  SQL statements in trace file.
           3  unique SQL statements in trace file.
          58  lines in trace file.
           8  elapsed seconds in trace file.
    oracle:orcl$

Maybe you are looking for

  • ADHOC Query in Production System

    Can I create a ADHOC query in Production system?Coz I can able to do that. Thanks Sriram

  • [WIFI detail]Is there general build-in method to fetch WiFi SSID detail in windows?

    In Windows 8/10 taskmgr [performance] tab, select one ethernet and right click the moving graph, we can view network detail statistics. But there is no difference of counters/properties type between WIFI and cable connection. WIFI has its important p

  • Installion of Developer Workplace fails at Phase 11

    Hi, I'm trying to install the Developer Workplace 7.01 MaxDB on a Virtual  Box instance running Windows XP SP2. The Virtual Machine has 1 GB of RAM and about 8 GB of free disk space. (The aim is to run a local version of the ISA Webshop. When install

  • Unable to update a record using PAI, in Module pool

    Hi Experts,                     I m unable to update the records in to the table using P A I in module pool, could any one help me out dear. The prg is as follows: INCLUDE MZFIRSTPAGETOP                          .    " global Data TABLES: ZCHP_CUST_I

  • Question About Updating SDK

    According to the releae notes, updating the SDK in Flash Builder 4.7 has changed or something. In the past we overlayed the AIR SDK over the Flex SDK. If I follow the instructions in the release notes does it mean I would no longer have to overlay th