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.oMark 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.
nullMark 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. -
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: entryI 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,
VinodhVinodh 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, MattThis 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
작성날짜 : 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
Andreauser585511 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
-
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
-
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