OS/390 (MVS) to Unix - SQL*Net - Exists?
I am going to start working with Oracle under MVS (OS/390).
I am familiar conceptually with the concept of SQL*Net and its distributed architecture enablement.
From a MVS perspective, does such a concept exist that would allow me, from MVS, to talk to an installation of Oracle on Unix via something like SQL*Net.
I have searched the documentation without success on this subject.
This is not a problem. You must configure SQL*Net, of course according to OS/390 rules and then you can connect to servers on any other platform. We do it at our site. Here's a working example for tnsnames, using TCP/IP:
# TNS CONNECT DESCRIPTORS
# LOOPBACK FUER ORA8
# MVS-Loopback
ORA8LOOP = (DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = hame)
(SSN = NET8)
(PORT = 1520)
# Unix-Machine
GISA = (DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = sqlhhp03)
(SSN = NET8)
(PORT = 1521)
(CONNECT_DATA = (SID = GISA))
Werner
Similar Messages
-
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 -
Process wait SQL*Net message from dblink /SQL*Net message from client
Hi There,
We have an ETL process that we kindly need your help with. The process been running since Sun, where it transfers the data from one server (via remote query). The process was running ok till last night where it appeared
to have stopped working and/or the session is just idling doing nothing.
Here are some tests that we did to figure out what's going on:
1. when looking at the session IO, we noticed that it's not changing:
etl_user@datap> select sess_io.sid,
2 sess_io.block_gets,
3 sess_io.consistent_gets,
4 sess_io.physical_reads,
5 sess_io.block_changes,
6 sess_io.consistent_changes
7 from v$sess_io sess_io, v$session sesion
8 where sesion.sid = sess_io.sid
9 and sesion.username is not null
10 and sess_io.sid=301
11 order by 1;
logical physical
SID BLOCK_GETS reads reads BLOCK_CHANGES CONSISTENT_CHANGES
301 388131317 97721268 26687579 223052804 161334
Elapsed: 00:00:00.012. Check there is nothing blocking the session
etl_user@datap> select * from v$lock where sid=301;
ADDR KADDR SID TY ID1 ID2 LMODE REQUEST CTIME BLOCK
684703F0 6847041C 301 DX 35 0 1 0 45237 0
684714C4 684714F0 301 AE 199675 0 4 0 260148 0
619651EC 6196521C 301 TM 52733 0 3 0 45241 0
67F86ACC 67F86B0C 301 TX 458763 52730 6 0 45241 03. Check if the session is still valid:
etl_user@datap> select status from v$session where sid=301;
STATUS
ACTIVE4. Check if there is anything in long ops that has not completed:
etl_user@datap> SELECT SID, SERIAL#, opname, SOFAR, TOTALWORK,
2 ROUND(SOFAR/TOTALWORK*100,2) COMPLETE, TIME_REMAINING/60
3 FROM V$SESSION_LONGOPS
4 WHERE
5 TOTALWORK != 0
6 AND SOFAR != TOTALWORK
7 order by 1;
no rows selected
Elapsed: 00:00:00.005. Check if there is anything in long ops for the session:
etl_user@datap> r
1* select SID,SOFAR,TOTALWORK,START_TIME,LAST_UPDATE_TIME,TIME_REMAINING,MESSAGE from V$SESSION_LONGOPS where sid=301
SID SOFAR TOTALWORK START_TIM LAST_UPDA TIME_REMAINING MESSAGE
301 0 0 22-JUL-12 22-JUL-12 Gather Table's Index Statistics: Table address_etl : 0 out of 0 Indexes done
Elapsed: 00:00:00.00This is a bit odd!! This particular step have actually completed successfully on the 22nd of July, and we don't know why it's still showing in long opps!? any ideas?
6. Looking at the sql and what's it actually doing:
etl_user@datap> select a.sid, a.value session_cpu, c.physical_reads,
2 c.consistent_gets,d.event,
3 d.seconds_in_wait
4 from v$sesstat a,v$statname b, v$sess_io c, v$session_wait d
5 where a.sid= &p_sid_number
6 and b.name = 'CPU used by this session'
7 and a.statistic# = b.statistic#
8 and a.sid=c.sid
9 and a.sid=d.sid;
Enter value for p_sid_number: 301
old 5: where a.sid= &p_sid_number
new 5: where a.sid= 301
CPU physical logical seconds
SID used reads reads EVENT waiting
301 1966595 26687579 97721268 SQL*Net message from dblink 45792
Elapsed: 00:00:00.037. We looked at the remote DB where the data resides on, and we noticed that the remote session was also waiting on the db link:
SYS@destp> select a.sid, a.value session_cpu, c.physical_reads,
2 c.consistent_gets,d.event,
3 d.seconds_in_wait
4 from v$sesstat a,v$statname b, v$sess_io c, v$session_wait d
5 where a.sid= &p_sid_number
6 and b.name = 'CPU used by this session'
7 and a.statistic# = b.statistic#
8 and a.sid=c.sid
9 and a.sid=d.sid;
Enter value for p_sid_number: 388
old 5: where a.sid= &p_sid_number
new 5: where a.sid= 390
SID SESSION_CPU PHYSICAL_READS CONSISTENT_GETS EVENT SECONDS_IN_WAIT
390 136 0 7605 SQL*Net message from client 46101
SYS@destp>We have had an issue in the past where the connection was being dropped by the network when the process runs for few days, hence we have added the following to the sqlnet.ora and listener.ora files:
sqlnet.ora:
SQLNET.EXPIRE_TIME = 1
SQLNET.INBOUND_CONNECT_TIMEOUT = 6000
listener.ora:
INBOUND_CONNECT_TIMEOUT_LISTENER = 6000What else can we do and/or further investigate to work out the root cause of the problem, and may be help resolve this. We don't want to just stop and start the process again as it took few days already. We have
had a chat to the infrastructure team and they've assured us that there have been no network outages.
Also, the alert logs for both instances (local and remote) shows no errors what so ever!
Your input is highly appreciated.
Thanks
Edited by: rsar001 on Jul 25, 2012 10:22 AMRan the query on both local/remote db, and no rows returned:
etl_user@datap> SELECT DECODE(request,0,'Holder: ','Waiter: ')||vl.sid sess, status,
2 id1, id2, lmode, request, vl.type
3 FROM V$LOCK vl, v$session vs
4 WHERE (id1, id2, vl.type) IN
5 (SELECT id1, id2, type FROM V$LOCK WHERE request>0)
6 and vl.sid = vs.sid
7 ORDER BY id1, request
8 /
no rows selected
Elapsed: 00:00:00.21 -
제품 : SQL*NET
작성날짜 : 1997-06-23
SQL*NET V2 SETUP (MTS)
======================
UNIX에서 SQL*NET V2를 사용하려면 ORACLE 인스톨 후에 다음과 같이 SETUP을 한
다음 사용하면 된다. 여기서
ORACLE_HOME DIRECTORY는 /usr/oracle7
ORACLE_SID는 ORA7
이라고 가정한다.
1. (단, MTS로 setting하지 않고 dedicated로 접속할 때에는 이 과정은 생략하도록
한다.)
Multi-threaded server 프로세스들을 먼저 기동을 하여야 한다.
$ORACLE_HOME/dbs/initSID.ora 화일에 다음과 같은 내용을 추가하고
DB 를 다시 startup 을 한다
# Filename : /usr/oracle7/dbs/initSID.ora
# Protocol : tcp
mts_dispatchers="tcp, 3"
mts_max_dispatchers=10
mts_servers=5
mts_max_servers=10
mts_service=ORA7
mts_listener_address="(ADDRESS=(PROTOCOL=tcp)(port=1521)
(host=hostname))"
2. tnsnames.ora 및 listener.ora 를 작성한다. 이 화일들은
/usr/oracle7/network/admin 디렉토리에 만들어야 하며 유닉스 환경변수를
TNS_ADMIN=$ORACLE_HOME/network/admin
과 같이 지정하고 사용하는 것이 좋다.
<EXAMPLE>
# File name : /usr/oracle7/network/admin/listener.ora
# This configuration supports tcp
LISTENER =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)
(HOST = hostname)
(PORT = 1521)
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER = 0
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = ORA7)
(ORACLE_HOME=/usr/oracle7)
# Filename : /usr/oracle7/network/admin/tnsnames.ora
TORA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)
(HOST = hostname)
(PORT=1521)
(CONNECT_DATA =
(SID = ORA7)
3. Listener process를 start한다.
$lsnrctl start
4. SQL*NET v2 를 사용하여 MTS 에 접속한다.(LOOPBACK TEST)
$ sqlplus scott/tiger@TORA
5. CLIENT에서 접속하는 경우라면 위에서 만든 tnsnames.ora 화일을 CLIENT의
$ORACLE_HOME/network/admin 디렉토리에 COPY 하기만 하면 된다.
6. 예를 들어 CLIENT가 WIN95라면 C:\ORAWIN95\NETWORK\ADMIN 디렉토리에
tnsnames.ora 화일을 COPY하면 된다. 만약 ORA-12154 에러가 발생하면
C:\ORAWIN95\NETWORK\ADMIN 디렉토리에 sqlnet.ora가 있는지 확인하고
이것을 sqlnet.old 같이 다른 이름으로 rename 한 후에 접속테스트를 해
보도록 한다. sql*plus(plus33.exe or plus33w.exe)로 접속하는 경우
다음과 같이 접속하면 된다.
USERNAME scott
PASSWORD tiger
HOST STRING TORA
* SERVER가 WINDOWS NT인 경우에는 다른 부분은 UNIX와 동일하게 setup하면
되고 단지 Listener를 띄우는 방법만 다르다.
제어판 -> SERVICES 에서 ORACLE 관련 SERVICE들을 모두 START 시켜주면 된다.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 -
제품 : SQL*NET
작성날짜 : 1997-10-10
Introduction
~~~~~~~~~~~~
For most problems you need to identify the relevant parts of a
connection to trace. To do this consider which scenario you are
having problems with and where tracing needs to be enabled.
Note that tracing produces a lot of output , especially at higher
trace levels.
There are 3 main areas of SQL*Net that can produce trace output:
1 = the SQL*Net 'client'
2 = the 'listener' process
3 = the SQL*Net 'server'.
a) Establishing a connection:
Client ----> Listener ----> Server
1 2 3
b) An established connection:
Client --------> Server
1 3
c) Opening a database link:
Client ----> Server ----> Listener -----> Server2
1 3 1 2 3
Note here that the Oracle server process is also a SQL*Net
client when it makes an outgoing call to a listener to
open a database link. Database links are OPENED when first
used. They should then remain open until closed.
d) An established database link:
Client ----> Server -----> Server2
1 3 1 3
In each case here there are several potential sampling points. You
should be able to identify quickly which of these scenarios matches
your setup. As these scenarios are likely to involve connections
between different machines you should remember that tracing for any
process is controlled by the configuration details that the process
reads WHEN IT IS STARTED. This is especially important when looking
at MTS connections as the SQL*Net server is the 'dispatcher' process.
Some dispatchers are started when the database instance is started
and others may start at a later time (on demand). Each dispatcher will
read their SQL*Net configuration WHEN THEY START.
7.2 Client Tracing
~~~~~~~~~~~~~~
For client TOOLS edit or create the file $HOME/.sqlnet.ora and add
the lines:
trace_level_client=16
trace_file_client=cli
trace_directory_client=/tmp # Or a known directory
trace_unique_client=true # Add '_pid' to trace filename
This will turn on FULL tracing for your user account only producing
output in a file called /tmp/cli_<PID>.trc .
(For some SQL*Net versions the file will be just /tmp/cli.trc)
For client 'ORACLE' process (as in the case of database links) put this
same information into $TNS_ADMIN/sqlnet.ora file.
On versions up to and including Oracle 7.0.16 client trace may not
add a process ID to the name of the trace file. This means two
processes may end up writing to the same trace file unless you
take care to control which processes write trace output to each file.
7.3 Listener Tracing
~~~~~~~~~~~~~~~~
Listener tracing can ONLY be configured in the listener.ora file.
Add the lines below to the listener.ora file:
trace_level_listener=16
trace_file_listener=listener
trace_directory_listener=/tmp # Or a known directory
This will define FULL listener tracing to the file /tmp/listener.trc.
You can enable this tracing by either:
lsnrctl reload
OR
lsnrctl stop;
lsnrctl start;
TCP/IP
~~~~~~
It is often useful to confirm that a listener is listening on a
specified address. Most Unix machines include a command called
'netstat' (Often in /etc or in /usr/etc). The command netstat -a
should list all TCP/IP end points on which a listener is listening.
Eg:
For a listener listening on HOST=... PORT=1580 there should be a
netstat entry of the form:
RecvQ SendQ Local Address Foreign Address TCP state
0 0 *.1580 *.* LISTEN
Note: Some versions of netstat will only list established connections
and not listen end points. See the man page on your machine.
7.4 Server Tracing
~~~~~~~~~~~~~~
Server side trace is not required as often as the other two traces
mainly because most problems are related to establishing a connection.
Once a connection has been established the client and server processes
are communicating. It is sometimes useful to see exactly what SQL
commands have been received by the server, and what data it has sent
back out.
The file $TNS_ADMIN/sqlnet.ora controls the server side tracing. Add
the lines below to this file:
trace_level_server=16
trace_file_server=server
trace_directory_server=/tmp # Or a known directory
Output should be sent to the file /tmp/server_<PID>.trc
Note: Server side tracing acts on the SQL*Net server side.
For dedicated connections this is the Oracle process on the
server machine.
For MTS connections this is the DISPATCHER and NOT the shared
server. Data is passed between the dispatcher and the shared
servers via the SGA and this does NOT involve SQL*Net.
It is also important to note that as a dispatcher handles
several client processes the dispatcher trace output can be a
mix of trace from many client processes making it VERY difficult
to follow. The general advice for such problems is:
a) See if the problem reproduces WITHOUT using MTS - if
so the trace is much cleaner
b) If a problem ONLY reproduces under MTS ensure the machine
is in a controlled environment so you can be sure that only
YOUR process is using the dispatcher.
7.5 Trace Summary
~~~~~~~~~~~~~
1) Identify where you need to trace.
2) Identify which files on which machines control tracing at these
points. Tracing is controlled in the following files:
Client Server Listener
~~~~~~ ~~~~~~ ~~~~~~~~
Files: $HOME/.sqlnet.ora sqlnet.ora listener.ora
sqlnet.ora
3) Add in the relevant trace parameters (See Below)
4) Restart any processes that need to read the new trace values.
Reload the listener as required.
5) Reproduce your problem
6) Save all your trace output immediately
7) Disable the tracing
7.6 Main Trace Parameters
~~~~~~~~~~~~~~~~~~~~~
trace_level_listener = off
trace_file_listener = Filename *1
trace_directory_listener = Directory *2
*1 Unquoted (") filenames will be translated into lower case.
*2 You CANNOT use environment variables in the Filename or Directory
name.
7.7 Diagnosing Trace output
~~~~~~~~~~~~~~~~~~~~~~~
Trace output can be very difficult to follow. Before looking at a
trace file make sure:
a) You are familiar with the sequence of events in setting up
a connection. SQL*Net connections follow a sequence of
events - you will need to determin where in the sequence
the problem occurs.
b) Do not be misled by error reports in the trace files. You
must follow the context of the errors - an error may be
quite valid at that point in a sequence. Eg: For client
connections a list of addresses to call is built - if the
first address yeilds no response the next address is tried.
This next address may yeild a response and the 'true' error
occurs at this point in the sequence.
c) Do not be misled by unusual 'Bequeath' connections in the
trace. If an error is received over SQL*Net the client
may use a "Bequeath" operation to spawn an oracle process
which it then uses to get the TEXT of the error. A very short
exchange of packets occurs and the bequethed process exits.
The 'TRUE' problem is likely to be before this bequeath
operation.
Useful trace 'tags':
The following are useful items to follow in trace files - these
are not guaranteed to be valid across all SQL*Net releases and
are for guidance only. Entries are assumed to be taken at trace
level 16 to allow data packets to be seen. This will produce a
LOT of trace output.
-<ERROR>-
Error information follows. Remember the error may be acceptable
osntns: Calling address
Shows address list constructed for a call OUT to a listener
nricall: Making call with following address information: ...
Shows the ACTUAL address being called from the above list
nsopen: entry
We are about to try and open a connection.
nsopen: transport is open
nsopen: error exit
A connection to the called address has been made / failed.
nsclose: ...
An established connection is being closed - check nearby
for errors.
nscall: redirected
The client has been redirected to a differenct address.
The next step should be to call the new address. The address
should appear in an earlier data packet.
nspsend / nsprecv
Outgoung / Incoming dataThis 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 -
CLIENT SIDE TRACING IN SQL*NET V2
제품 : SQL*NET
작성날짜 : 1997-10-10
Client Tracing
~~~~~~~~~~~~~~
1) Set the environment variable TNS_ADMIN to the directory where the
tnsnames.ora and listener.ora files exist.
The default location is $ORACLE_HOME/network/admin. Set $TNS_ADMIN
to this if it is not set. This ENSURES you know which files you are
using.
2) Start the listener: lsnrctl
> set password <password>
> start
Note any errors. If you do not have a password set then ignore the
set password command.
3) If the listener started, start the database.
4) Create a file in $HOME called .sqlnet.ora and add the lines:
trace_level_client= 16
trace_file_client=client
trace_directory_client= /tmp (or similar)
trace_unique_client=true
5) Try to connect from SQL*Plus thus:
sqlplus username/password@alias
or
sqlplus username/password
substituting a suitable alias.
6) If you get an error we may need to see the client trace file
/tmp/client_<PID>.trc where <PID> is the process ID of the
client process (*1).
This will be quite large so it is best to FAX or EMAIL it.
*1 Note: On earlier versions of SQL*Net the filename may NOT have
the process ID appended to it.
Listener Tracing:
~~~~~~~~~~~~~~~~~
1) Edit your $TNS_ADMIN/listener.ora file and add the lines:
TRACE_LEVEL_LISTENER = 16
TRACE_DIRECTORY_LISTENER = /tmp
TRACE_FILE_LISTENER = "listener"
2) Stop and restart the listener:
lsnrctl stop
lsnrctl start
Output should go to /tmp/listener.trcBy default in 11g traces will go to the ADR which is a new feature.
To disable that feature add the following line to your sqlnet.ora
diag_adr_enabled =OFF
[oops] saw that this is over a month old this post - sorry about that!
hope that helps
John
Edited by: Johnsung on Sep 27, 2012 3:59 PM -
Query started taking longer time with SQL*Net message from dblink
Hi,
Since Yesterday we started see one query which normally used to take 3 min but now it started taking 70 min after a small change do the query instead of accessing view we started accessing directly table.
Both Schema's are on same DB.
Oracle version=11.2.0.2
OS=Solaris 10
Existing Query
WITH ot_symbol_data_v AS
(SELECT dat.symbol, dat.startdate, dat.enddate, oi.currencycode,
dat.primarymarket, primsymb.symbol primarysymbol, dat.mic,
dat.universeid, dat.symbology
FROM onetick_symbol_data@refdata_link dat
LEFT JOIN
(SELECT symbology, universeid, mic, MAX (enddate) enddate
FROM onetick_symbol_data@refdata_link
GROUP BY symbology, universeid, mic) prim
ON prim.symbology = dat.symbology
AND prim.universeid = dat.universeid
AND prim.mic = dat.primarymarket
LEFT JOIN onetick_symbol_data@refdata_link primsymb
ON prim.symbology = primsymb.symbology
AND prim.universeid = primsymb.universeid
AND prim.mic = primsymb.mic
AND prim.enddate = primsymb.enddate
JOIN onetick_isincur_data@refdata_link oi
ON dat.universeid = oi.universeid
JOIN
(SELECT universeid, MAX (enddate) AS enddate
FROM onetick_isincur_data@refdata_link
GROUP BY universeid) oilatest
ON oi.universeid = oilatest.universeid
AND oi.enddate = oilatest.enddate
ORDER BY dat.universeid, dat.mic, dat.symbology, dat.enddate)
SELECT i.instrumentid
|| '||'
|| i.firsttradingdate
|| '000000|'
|| NVL (i.delisteddate, '30001231')
|| '000000|'
|| i.home_market
|| '|'
|| DECODE (imfm.feedid, 0, 'FIXN_RFA', 1, 'ALGO', 2, 'FIXNETIX')
|| '::'
|| osdv.primarysymbol
FROM tibex_meinstrumentview i JOIN tibex_instrumentmicfeedmapview imfm
ON i.isin = imfm.isin
AND i.currencycode = imfm.currencycode
AND i.home_market = imfm.mic
JOIN rd_universeview@refdata_link u
ON i.instrumentid = u.instrumentid AND i.instrumentstatus != 3
and active='Y'
JOIN
(SELECT universeid, DECODE (symbology, 1, 0, 2, 2, -1) feedid,
primarysymbol
FROM ot_symbol_data_v
GROUP BY universeid, symbology, primarysymbol) osdv
ON u.universeid = osdv.universeid
WHERE osdv.feedid = imfm.feedid
ORDER BY i.isin, i.currencycode, i.instrumentid;
New Query
WITH ot_symbol_data_v AS
(SELECT dat.symbol, dat.startdate, dat.enddate, oi.currencycode,
dat.primarymarket, primsymb.symbol primarysymbol, dat.mic,
dat.universeid, dat.symbology
FROM onetick_symbol_data@refdata_link dat
LEFT JOIN
(SELECT symbology, universeid, mic, MAX (enddate) enddate
FROM onetick_symbol_data@refdata_link
GROUP BY symbology, universeid, mic) prim
ON prim.symbology = dat.symbology
AND prim.universeid = dat.universeid
AND prim.mic = dat.primarymarket
LEFT JOIN onetick_symbol_data@refdata_link primsymb
ON prim.symbology = primsymb.symbology
AND prim.universeid = primsymb.universeid
AND prim.mic = primsymb.mic
AND prim.enddate = primsymb.enddate
JOIN onetick_isincur_data@refdata_link oi
ON dat.universeid = oi.universeid
JOIN
(SELECT universeid, MAX (enddate) AS enddate
FROM onetick_isincur_data@refdata_link
GROUP BY universeid) oilatest
ON oi.universeid = oilatest.universeid
AND oi.enddate = oilatest.enddate
ORDER BY dat.universeid, dat.mic, dat.symbology, dat.enddate)
SELECT i.instrumentid
|| '||'
|| i.firsttradingdate
|| '000000|'
|| NVL (i.delisteddate, '30001231')
|| '000000|'
|| i.home_market
|| '|'
|| DECODE (imfm.feedid, 0, 'FIXN_RFA', 1, 'ALGO', 2, 'FIXNETIX')
|| '::'
|| osdv.primarysymbol
FROM tibex_meinstrumentview i JOIN tibex_instrumentmicfeedmapview imfm
ON i.isin = imfm.isin
AND i.currencycode = imfm.currencycode
AND i.home_market = imfm.mic
JOIN universe@refdata_link u
ON i.instrumentid = u.instrumentid AND i.instrumentstatus != 3
and active='Y'
JOIN
(SELECT universeid, DECODE (symbology, 1, 0, 2, 2, -1) feedid,
primarysymbol
FROM ot_symbol_data_v
GROUP BY universeid, symbology, primarysymbol) osdv
ON u.universeid = osdv.universeid
WHERE osdv.feedid = imfm.feedid
ORDER BY i.isin, i.currencycode, i.instrumentid;Most of the wait event is
SQL*Net message from dblink
SQL*Net message to dblink
Regards
NMHi Kim,
uat_trd_owner@UAT001> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 741667790
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |IN-OUT|
| 0 | SELECT STATEMENT | | 1 | 137 | 21981 (2)| 00:04:24 | | |
| 1 | SORT ORDER BY | | 1 | 137 | 21981 (2)| 00:04:24 | | |
|* 2 | HASH JOIN OUTER | | 1 | 137 | 21980 (2)| 00:04:24 | | |
|* 3 | HASH JOIN OUTER | | 1 | 131 | 422 (4)| 00:00:06 | | |
| 4 | NESTED LOOPS | | | | | | | |
| 5 | NESTED LOOPS | | 1 | 125 | 107 (9)| 00:00:02 | | |
| 6 | NESTED LOOPS | | 20 | 1680 | 87 (11)| 00:00:02 | | |
|* 7 | HASH JOIN | | 1 | 64 | 86 (11)| 00:00:02 | | |
| 8 | VIEW | TIBEX_INSTRUMENTMICFEEDMAPVIEW | 1 | 34 | 84 (9)| 00:00:02 | | |
| 9 | HASH GROUP BY | | 1 | 166 | 84 (9)| 00:00:02 | | |
|* 10 | HASH JOIN RIGHT OUTER | | 267 | 44322 | 83 (8)| 00:00:01 | | |
| 11 | TABLE ACCESS FULL | TIBEX_BOARDFEEDMAP | 1 | 20 | 3 (0)| 00:00:01 | | |
| 12 | NESTED LOOPS OUTER | | 267 | 38982 | 80 (8)| 00:00:01 | | |
| 13 | NESTED LOOPS OUTER | | 267 | 21627 | 80 (8)| 00:00:01 | | |
|* 14 | HASH JOIN | | 267 | 17088 | 80 (8)| 00:00:01 | | |
| 15 | MERGE JOIN CARTESIAN | | 2004 | 88176 | 37 (0)| 00:00:01 | | |
| 16 | INDEX FULL SCAN | TIBEX_EDPDEFAULTFEED_PK | 1 | 3 | 1 (0)| 00:00:01 | | |
| 17 | BUFFER SORT | | 2004 | 82164 | 36 (0)| 00:00:01 | | |
|* 18 | TABLE ACCESS FULL | TIBEX_INSTRUMENT | 2004 | 82164 | 36 (0)| 00:00:01 | | |
| 19 | VIEW | TIBEX_EDPINSTRUMENTMARKETSVIEW | 22040 | 430K| 42 (12)| 00:00:01 | | |
| 20 | HASH GROUP BY | | 22040 | 430K| 42 (12)| 00:00:01 | | |
| 21 | VIEW | | 22040 | 430K| 41 (10)| 00:00:01 | | |
| 22 | SORT UNIQUE | | 22040 | 544K| 41 (57)| 00:00:01 | | |
| 23 | UNION-ALL | | | | | | | |
| 24 | INDEX FAST FULL SCAN| TIBEX_EDPFIXNETIXL1_R01 | 7578 | 162K| 18 (0)| 00:00:01 | | |
| 25 | TABLE ACCESS FULL | TIBEX_EDPIXSYMBOLS | 7494 | 197K| 12 (0)| 00:00:01 | | |
| 26 | TABLE ACCESS FULL | TIBEX_EDPRFALGOSUBSCRIPTION | 6968 | 183K| 7 (0)| 00:00:01 | | |
|* 27 | INDEX RANGE SCAN | TIBEX_MICFEEDMAP_PK | 1 | 17 | 0 (0)| 00:00:01 | | |
| 28 | TABLE ACCESS BY INDEX ROWID| TIBEX_INSTRUMENTFEEDMAP | 1 | 65 | 0 (0)| 00:00:01 | | |
|* 29 | INDEX UNIQUE SCAN | TIBEX_INSTRUMENTFEEDMAP_PK | 1 | | 0 (0)| 00:00:01 | | |
| 30 | VIEW | | 100 | 3000 | 1 (100)| 00:00:01 | | |
| 31 | REMOTE | | | | | | REFDA~ | R->S |
| 32 | REMOTE | UNIVERSE | 20 | 400 | 1 (0)| 00:00:01 | REFDA~ | R->S |
|* 33 | INDEX UNIQUE SCAN | XPKTIBEX_INSTRUMENT | 1 | | 0 (0)| 00:00:01 | | |
|* 34 | TABLE ACCESS BY INDEX ROWID | TIBEX_INSTRUMENT | 1 | 41 | 1 (0)| 00:00:01 | | |
| 35 | VIEW | TIBEX_MELASTEXPRICEINTVIEW | 36 | 216 | 314 (2)| 00:00:04 | | |
| 36 | HASH UNIQUE | | 36 | 1656 | 314 (2)| 00:00:04 | | |
|* 37 | HASH JOIN | | 36 | 1656 | 313 (1)| 00:00:04 | | |
| 38 | VIEW | VW_SQ_1 | 304 | 5776 | 157 (2)| 00:00:02 | | |
| 39 | HASH GROUP BY | | 304 | 7296 | 157 (2)| 00:00:02 | | |
|* 40 | TABLE ACCESS FULL | TIBEX_EXECUTION | 17462 | 409K| 156 (1)| 00:00:02 | | |
| 41 | TABLE ACCESS FULL | TIBEX_EXECUTION | 17463 | 460K| 156 (1)| 00:00:02 | | |
| 42 | VIEW | TIBEX_MSGSEQBYINSTRUMENT | 3908 | 23448 | 21558 (2)| 00:04:19 | | |
| 43 | HASH GROUP BY | | 3908 | 74252 | 21558 (2)| 00:04:19 | | |
| 44 | VIEW | | 11626 | 215K| 21556 (2)| 00:04:19 | | |
| 45 | UNION-ALL | | | | | | | |
| 46 | HASH GROUP BY | | 1460 | 26280 | 8906 (1)| 00:01:47 | | |
| 47 | TABLE ACCESS FULL | TIBEX_QUOTE | 1362K| 23M| 8866 (1)| 00:01:47 | | |
| 48 | HASH GROUP BY | | 677 | 12186 | 11750 (2)| 00:02:21 | | |
| 49 | TABLE ACCESS FULL | TIBEX_ORDER | 1790K| 30M| 11696 (1)| 00:02:21 | | |
| 50 | HASH GROUP BY | | 304 | 5472 | 157 (2)| 00:00:02 | | |
|* 51 | TABLE ACCESS FULL | TIBEX_EXECUTION | 17463 | 306K| 156 (1)| 00:00:02 | | |
| 52 | HASH GROUP BY | | 1 | 40 | 3 (34)| 00:00:01 | | |
|* 53 | TABLE ACCESS FULL | TIBEX_TSTRADE | 1 | 40 | 2 (0)| 00:00:01 | | |
| 54 | HASH GROUP BY | | 717 | 11472 | 229 (1)| 00:00:03 | | |
| 55 | INDEX FAST FULL SCAN | IX_BESTEXREL | 7323 | 114K| 228 (0)| 00:00:03 | | |
| 56 | HASH GROUP BY | | 1911 | 34398 | 13 (8)| 00:00:01 | | |
|* 57 | TABLE ACCESS FULL | TIBEX_MERESUMEPRDTRANSITION | 5216 | 93888 | 12 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
| 58 | HASH GROUP BY | | 3 | 51 | 5 (20)| 00:00:01 | | |
| 59 | TABLE ACCESS FULL | TIBEX_EDPUPDATEREJECT | 48 | 816 | 4 (0)| 00:00:01 | | |
| 60 | HASH GROUP BY | | 1587 | 46023 | 215 (2)| 00:00:03 | | |
|* 61 | HASH JOIN | | 35166 | 995K| 213 (1)| 00:00:03 | | |
| 62 | INDEX FULL SCAN | XPKTIBEX_CONFIGMEGROUP | 4 | 16 | 1 (0)| 00:00:01 | | |
| 63 | TABLE ACCESS FULL | TIBEX_INSTRUMENTADMIN | 87915 | 2146K| 212 (1)| 00:00:03 | | |
| 64 | HASH GROUP BY | | 6 | 102 | 5 (20)| 00:00:01 | | |
| 65 | TABLE ACCESS FULL | TIBEX_BESTEXECPRICELOG | 793 | 13481 | 4 (0)| 00:00:01 | | |
| 66 | HASH GROUP BY | | 1 | 40 | 3 (34)| 00:00:01 | | |
|* 67 | TABLE ACCESS FULL | TIBEX_AUCTIONPRICE | 1 | 40 | 2 (0)| 00:00:01 | | |
| 68 | HASH GROUP BY | | 1587 | 28566 | 236 (2)| 00:00:03 | | |
|* 69 | TABLE ACCESS FULL | TIBEX_ADMINACK | 87915 | 1545K| 233 (1)| 00:00:03 | | |
| 70 | HASH GROUP BY | | 1914 | 34452 | 26 (8)| 00:00:01 | | |
| 71 | INDEX FAST FULL SCAN | INSTRUMENTSTATEMSGSEQ | 23705 | 416K| 24 (0)| 00:00:01 | | |
| 72 | HASH GROUP BY | | 1458 | 26244 | 8 (13)| 00:00:01 | | |
| 73 | INDEX FAST FULL SCAN | TIBEX_FREEZEEOTPK | 5890 | 103K| 7 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
2 - access("A"."INSTRUMENTID"="C"."INSTRUMENTID"(+))
3 - access("A"."INSTRUMENTID"="B"."INSTRUMENTID"(+))
7 - access("OSDV"."FEEDID"="IMFM"."FEEDID")
10 - access("I"."PRIMARYSTATUSBOARDID"="BOARDFM"."BOARDID"(+))
14 - access("SUBSC"."ISIN"="I"."ISIN" AND "SUBSC"."CURRENCYCODE"="I"."CURRENCYCODE")
filter("SUBSC"."HOMEMARKET" IS NULL OR "SUBSC"."HOMEMARKET"="I"."HOME_MARKET")
18 - filter("I"."INSTRUMENTSTATUS"<>3)
27 - access("SUBSC"."MIC"="MICFM"."MIC"(+))
29 - access("I"."INSTRUMENTID"="INSTRFM"."INSTRUMENTID"(+))
33 - access("A"."INSTRUMENTID"="U"."INSTRUMENTID")
34 - filter("A"."INSTRUMENTSTATUS"<>3 AND TO_DATE("A"."FIRSTTRADINGDATE",'YYYYMMDD')<=SYSDATE@! AND "A"."ISIN"="IMFM"."ISIN"
AND "A"."CURRENCYCODE"="IMFM"."CURRENCYCODE" AND "A"."HOME_MARKET"="IMFM"."MIC")
37 - access("A"."MESSAGESEQUENCE"="MAX(B.MESSAGESEQUENCE)" AND "A"."INSTRUMENTID"="ITEM_0")
40 - filter(("B"."SELLENTITYTYPE"=0 OR "B"."SELLENTITYTYPE"=2) AND ("B"."BUYENTITYTYPE"=0 OR "B"."BUYENTITYTYPE"=2))
51 - filter("INSTRUMENTID" IS NOT NULL)
53 - filter("INSTRUMENTID" IS NOT NULL)
57 - filter("INSTRUMENTID" IS NOT NULL)
61 - access("ADMINUSER"="MEGROUPID")
67 - filter("INSTRUMENTID" IS NOT NULL)
69 - filter("INSTRUMENTID" IS NOT NULL)
Remote SQL Information (identified by operation id):
31 - EXPLAIN PLAN INTO PLAN_TABLE@! FOR SELECT "A1"."UNIVERSEID",DECODE("A1"."SYMBOLOGY",1,0,2,2,(-1)),"A1"."PRIMARYSYMBOL"
FROM (SELECT "A6"."SYMBOL" "SYMBOL","A6"."STARTDATE" "STARTDATE","A6"."ENDDATE" "ENDDATE","A3"."CURRENCYCODE"
"CURRENCYCODE","A6"."PRIMARYMARKET" "PRIMARYMARKET","A4"."SYMBOL" "PRIMARYSYMBOL","A6"."MIC" "MIC","A6"."UNIVERSEID"
"UNIVERSEID","A6"."SYMBOLOGY" "SYMBOLOGY" FROM "ONETICK_SYMBOL_DATA" "A6", (SELECT "A7"."SYMBOLOGY"
"SYMBOLOGY","A7"."UNIVERSEID" "UNIVERSEID","A7"."MIC" "MIC",MAX("A7"."ENDDATE") "ENDDATE" FROM "ONETICK_SYMBOL_DATA" "A7" GROUP
BY "A7"."SYMBOLOGY","A7"."UNIVERSEID","A7"."MIC") "A5","ONETICK_SYMBOL_DATA" "A4","ONETICK_ISINCUR_DATA" "A3", (SELECT
"A8"."UNIVERSEID" "UNIVERSEID",MAX("A8"."ENDDATE") "ENDDATE" FROM "ONETICK_ISINCUR_DATA" "A8" GROUP BY "A8"."UNIVERSEID") "A2"
WHERE "A3"."UNIVERSEID"="A2"."UNIVERSEID" AND "A3"."ENDDATE"="A2"."ENDDATE" AND "A6"."UNIVERSEID"="A3"."UNIVERSEID" AND
"A5"."ENDDATE"="A4"."ENDDATE"(+) AND "A5"."MIC"="A4"."MIC"(+) AND "A5"."UNIVERSEID"="A4"."UNIVERSEID"(+) AND
"A5"."SYMBOLOGY"="A4"."SYMBOLOGY"(+) AND "A5"."MIC"(+)="A6"."PRIMARYMARKET" AND "A5"."UNIVERSEID"(+)="A6"."UNIVERSEID" AND
"A5"."SYMBOLOGY"(+)="A6"."SYMBOLOGY" ORDER BY "A6"."UNIVERSEID","A6"."MIC","A6"."SYMBOLOGY","A6"."ENDDATE") "A1" GROUP BY
"A1"."UNIVERSEID","A1"."SYMBOLOGY","A1"."PRIMARYSYMBOL" (accessing 'REFDATA_LINK' )
32 - SELECT "INSTRUMENTID","UNIVERSEID" FROM "UNIVERSE" "U" WHERE "UNIVERSEID"=:1 (accessing 'REFDATA_LINK' )
127 rows selected.
For trace files
WAIT #18446741324892119016: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151855125079
WAIT #18446741324892119016: nam='SQL*Net message from client' ela= 182 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151855125694
=====================
PARSING IN CURSOR #18446741324892117968 len=52 dep=0 uid=474 oct=47 lid=474 tim=42151855125777 hv=1029988163 ad='af4d0890' sqlid='9babjv8yq8ru3'
BEGIN DBMS_OUTPUT.GET_LINES(:LINES, :NUMLINES); END;
END OF STMT
PARSE #18446741324892117968:c=0,e=42,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=42151855125769
WAIT #18446741324892117968: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151855126145
EXEC #18446741324892117968:c=0,e=262,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,plh=0,tim=42151855126176
*** 2012-11-20 15:18:56.839
WAIT #18446741324892117968: nam='SQL*Net message from client' ela= 10252982 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865379208
CLOSE #18446741324892119016:c=0,e=13,dep=0,type=1,tim=42151865379327
CLOSE #18446741324892117968:c=0,e=28,dep=0,type=3,tim=42151865379370
WAIT #18446741324892082152: nam='single-task message' ela= 47849 p1=0 p2=0 p3=0 obj#=-1 tim=42151865429221
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 107 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865429886
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865429945
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 926 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865430901
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865431578
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 2525 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865434125
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670108
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 58 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670178
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 0 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670235
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 60 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670310
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670337
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 59 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670407
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 0 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670464
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 60 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670539
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670566
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 59 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670636
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670693
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 60 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670768Regards
NM -
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 -
WINDOWS 용 SQL*NET V1 사용 시 ORA-6136 조치 방법
제품 : SQL*NET
작성날짜 : 1995-11-07
WINDOWS 용 SQL*NET V1 사용 시 ORA-6136 조치 방법
===============================================
Client and Server 환경에서 간혹 SQL*NET으로 Server에 접속하려고 할 때,
ORA-6136 Error가 발생하면서 Unix Server에서 $tcpctl stop 으로 orasrv의
Process를 정지시키려고 해도 아무런 반응없이 Holding되는 경우가 발생하면서
다음과 같은 메서지가 나타납니다.
06136, 00000, "NETTCP: error during connection handshake"
// *Cause: Network I/O failure occurred while communicating with the
// host's SQL*Net TCP/IP server.
// See the SQL*Net TCP/IP server log file for more details.
// *Action: Contact your customer support representative.
상기의 에러가 나타날 경우에는 아래와 같은 방법으로 orasrv를 기동시키십시오.
1. TCPCTL Utility를 이용하여 다음의 Option을 부여하여 Start하는 방법.
$tcpctl start listen=30 timeout=30 forkon
listen=<queue size>이며, 청취자 열의 크기를 지정.
timeout=<seconds>이며, 지정된 시간에 orasrv와의 응답 확인 시간을 나타냄.
forkon SQL*net이 orasrv process에 접근하는 방법을 나타냄.
System에 따라서 forkon option이 적용 않되는 경우도 있음.
2. Client에서 접속을 하여 사용하다가 비정상 종료(Session이 맺어진 상태에서
Client의 Power Off)를 하여 Server에 Processor가 남아 있고, orasrv를 통해
접속할 수 있는 Session의 수가 점점 줄어들 경우가 있는 데 이러한 경우에는
orasrv를(tcpctl stop or UNIX kill command를 이용)강제로 종료하시고 다음과
같이 Start 시켜 주십시오.
#nohup tcpctl start ( Client의 비정상 종료가 Orasrv에는 영향을 미치지 않음)
또는
#orasrv (ORACLE_HOME\bin directory에서 직접 orasrv processor를 띄운다) -
SQL*NET V1, V2의 STATUS를 확인하는 방법
제품 : SQL*NET
작성날짜 : 1995-11-06
* SQL*NET V 1의 적절한 사용 방법
ORASRV의 Permission, Owner 및 Group은 다음과 같이 설정이 되어 있어야 하며
파일의 Size는 Version에 따라 다를 수 있다.
-rwsr-xr-x 1 oracle dba 7544832 Jul 21 20:35 oracle
-rwsr-xr-x 1 root dba 303104 Jul 5 19:24 orasrv
만일 위와 같지 않다면 Unix 명령 프롬프트에서 다음을 수행하여 모드를 바꾸어
준다.
#chmod 4755 oracle
#chown root orasrv <= orasrv의 owner는 반드시 root로 되어야 합니다.
#chmod 4755 orasrv
1. SQL*NET V1을 사용하면서 가장 일반적으로 orasrv를 시작 및 정지 하는
경우이다.
#tcpctl start ( stop )
2. orasrv의 현상태를 확인하는 방법
#tcpctl status
tcputl: Status summary follows
Server is running :
Started : 4-OCT-95 15:58:48
Total connections : 0
Total rejections : 0
Active subprocesses : 0
ORACLE SIDs : RC,ORA722
Default SID : (null)
Logging mode is ENABLED.
DBA logins are DISABLED.
OPS$ logins are ENABLED.
OPS$ROOT logins are DISABLED.
Orasrv is detached from the terminal.
Break mode = OUT OF BAND.
Debug level = 1
Timeout (on orasrv handshaking) = 5 seconds.
Length of listen queue = 10
Orasrv logfile = /users2/oracle7/tcp/log/orasrv.log
Orasrv mapfile = /etc/oratab
* SQL*NET V2의 적절한 사용 방법
SQL*NET V2를 사용하는데 있어서 갖추야 할 파라미터 파일이 있다.
기본으로 listener.ora,tnsnames.ora,sqlnet.ora가 $ORACLE_HOME/network/admin
directory내에 있어야 합니다.(상기 파일에 대한 configuration은 SQL*NET
Administrator's Guide v 2.0을 참고하시기 바랍니다.)
1. SQL*NET V2을 사용하면서 가장 일반적으로 listener를 시작 및 정지 하는
경우이다.
#lsnrctl start (stop)
2. Oracle과 Listener의 Process를 확인하는 방법
$ ps -ef |grep ORA7
ora7 1343 1 7 Aug 22 ? 30:53 ora_dbwr_ORA7
ora7 1342 1 7 Aug 22 ? 0:32 ora_pmon_ORA7
ora7 1346 1 7 Aug 22 ? 0:00 ora_reco_ORA7
ora7 1347 1 7 Aug 22 ? 0:00 ora_s000_ORA7
ora7 1345 1 7 Aug 22 ? 12:25 ora_smon_ORA7
ora7 1344 1 7 Aug 22 ? 58:57 ora_lgwr_ORA7
ora7 1348 1 7 Aug 22 ? 0:00 ora_s001_ORA7
ora7 8036 1 7 Aug 22 ? 0:00 /ora/ora7/bin/tnslsnr LISTENER -
inherit
ora7 24279 1342 7 09:40:16 ? 0:05 ora_d001_ORA7
ora7 899 1342 7 14:54:36 ? 0:21 ora_d000_ORA7
3. Listener의 현상태를 확인하는 방법
$ lsnrctl service
LSNRCTL for 88open UNIX: Version 2.0.14.0.0 - Production on 24-AUG-94
09:19:37
Copyright (c) Oracle Corporation 1993. All rights reserved.
Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=ORA7))
Services Summary...
ORA7 has 3 service handlers
DEDICATED SERVER established:0 refused:0
DISPATCHER established:0 refused:0 current:0 max:60 state:ready
D000 (machine: AViiON, pid: 899)
(ADDRESS=(PROTOCOL=tcp)(DEV=6)(HOST=152.68.1.11)(PORT=2753))
DISPATCHER established:0 refused:0 current:0 max:60 state:ready
D002 (machine: AViiON, pid: 1357)
(ADDRESS=(PROTOCOL=ipc)(DEV=5)(KEY=#1357.1))
The command completed successfully
4. SQL*NET V2를 MTS와 DEDICATE방식으로 사용코자 할때.
MTS 방식 : ps -ef | grep s0 으로 시작하는 공유 process 를
띄어두고, tnsnames.ora 에 MTS 와 같은 alias 를
사용하여 접속한 session 들이 각각의 oracle process 를
띄우지 않고, 공유 process 를 사용하는 방법
dedicate 방식 :
tnsnames.ora 에 MTS_DED 와 같은 alias 를 사용하거나, alias 없이
server 에서 접속하는 유저들은 각각의 oracle process 를
기동시켜고 공유하지 않는다
$cd $ORACLE_HOME/network/admin/tnsnames.ora
MTS =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = Hostname)
(PORT = 1521)
(CONNECT_DATA =
(SID = ORA7)
MTS_DED =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = Hostname)
(PORT = 1521)
(CONNECT_DATA =
(SID = ORA7)
(SRVR = DEDICATED)
5. SQL*NET V2 Pipe Adapter를 사용중이라면 ps command를 통해서
oracleSID (LOACL=YES)라는 Shadow Process로써 확인 할 수 있다.오랬만에 게시판에 들어오니 좀 썰렁하네요..
자주 들어와서 확인좀 하겠습니다.
SQL*NET V1 프로세스 수동 기동 중지는
기동
tcpctl start 중이
tcpctl stop -
SQL*NET V1 사용 시 ORA-6107 조치 방법
제품 : SQL*NET
작성날짜 : 2005-11-06
* Windows용 SQL*NET TCP/IP Ver 1.X는 SQLTCP.DLL과 SQLTCP1.DLL 두 개의
DLL이 하나로 구성되어 있다. 이들 DLL은 ORACLE용 연결 스트링이 TCP/IP
프로토콜 스트링으로 확인되면 작업진행중에 OCI DLL에 의해 올려진다.
ORACLE Interface DLL은 SQLTCP.DLL을 먼저 올리려고 한다. 이것이 실패하면
DOS TSR 버전의 드라이버를 찾는다. 두 가지 모두 실패하면 ORA-3121
메세지가 나온다.
1. SQL*NET TCP/IP DLL이 올려지고 초기화가 되는 즉시 Logon 시도를 시작한다.
2. 이때 모든 것이 정상적이라면 logon시 제공된 연결 스트링내의 I.P
Address대신 Hostname을 사용하여 해결해 본다. 이러한 과정이 정상적이라면
클라이언트측의 통신관련 디렉토리에 있는 Services 화일에 Oracle Service's
Portnumber를 제대로 부여한 것이며 SQL*NET TCP/IP DLL이 ORACLE.INI ( 또는
WIN.INI의 [Oracle] session의 ORA_CONFIG=<path>\ORACLE.INI에 기술된 내용)
내에 기술된 TCP_SERVICES_FILE = <network protocol path> \services 을
사용한다는 것이다.
ORACLE Service를 받는 Part Number SERVICES files내에 "orasrv" 라고
기술된다. SERVICES File의 예를 보면 하단과 같다.
# This list has been derived from RFC1060
# TCP Ports
# Service Name Port/Protocol Aliases
echo 7/tcp
discard 9/tcp sink null
systat 11/tcp users
listener 1521/tcp oracle ？ SQL*NET V2 인 경우
orasrv 1525/tcp oracle ？ SQL*NET V1 인 경우
3. 만일 TCP_SERVICES_FILE에 SERVICES화일이 구성되어있지 않았다면
"orasrv"의 접속이 실패된다. 만일 SERVICES File Name이 제대로 구성되어
있다면 file내에 표현되어 있는 "orasrv" 항목을 점검한다. SERVICES File
내의 각 항목 끝에 <CARRIAGE RETURN> 이 없을 경우나 "orasrv" line 상에
<TAB>이 있을 경우에도 이러한 메세지를 수반한다.
* ORA-6107을 진단하는 방법
1. ORA-6107의 경우 ORACLE.INI내의 TCP_SERVICES_FILE이 무엇인지 (또는
WIN.INI내의 [ORACLE] Section에 ORA_CONFIG가 무엇인지)를 점검한다.
- ORACLE.INI의 경우
TCP_SERVICES_FILE=<path>\SERVICES
- WIN.INI의 경우
ORA_CONFIG=c:\windows\oracle.ini
- 만약 설정이 되어 있지 않았다면 Client상에서 사용하고 있는 특정 TCP/IP
Vendor에서 사용하고 있는 SERVICES 화일을 찾고 그 화일내에 Parameter를
설정한다.
2. 만일 TCP_SERVICES_FILE에 설정되어 있는 SERVICES 화일의 위치가 맞는다면
화일내에 "orasrv" 항목을 점검하여 본다. 화일내에 <TABS>를 확인해 본다.
화일내의 각 항목 끝에 <Carrige Return>이 있는지 확인한다.
3. 만일 이 모든 것이 정상적이라면 새로운 SERVICES 화일내에 "orasrv" 항목을
추가한다.
4. 만약 SERVICES 파일의 도움없이 개발 응용프로그램에서 직접 접속을 시도할
경우에는 명시적으로 다음과 같이 Connect String에서 Port Number을 사용하여
접속할 수 있다.
"t:<server name or ip address>/<port number>:<instance name>"
[주의] instance name = ORACLE SID
5. tcp_services_files=%drive1%\path%\services
[주의 1] ORACLE TCP/IP Listener의 기본 시작포트 번호는 십진수 1525 이다.
SERVICES 파일은 대부분의 장비에 /etc 디렉토리안에 있으며 또한, "tcpctl"
Utility를 사용하여 UNIX 장비상의 ORACLE orasrv 를 Start 시키고 Stop할
수 있다. Orasrv 를 정지하려면 "tcpctl stop"을 사용하고 다시 시작하려면
"tcpctl start"를 사용한다.
BUG 1 : 다음과 같은 경우에도 에러가 발생할 수가 있다.
orasrv 1525/tcp<CR>
위와 같이 기술되었을 경우 다음과 같이 하게되면 ora-6107 error 없이 접속이
가능하다. 즉, orasrv항목에서 <CR>전에 공란이 있을 경우에 에러없이
접속할수 있다.
orasrv 1525/tcp <CR>
* 이 버그는 v1.1.7.10.1 이후 버젼에서는 수정되었다.
BUG 2 : 동일한 응용 프로그램에서 동일한 Connect String으로 접속을
시도하였을 때 에러가 발생한다면 다음과 같이 Connect String에 Port
Number를 사용한다.
t:<host name>/<port number>:<oracle_SID>
* 이 버그는 v1.1.7.9 이후 버젼에서는 수정되었다. -
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 -
Are there a patch to sql*net v1 access version 2?
My client is MS-DOS and running sql*net v1
my server is Oracle E7.1.6 under Sco unix OpenServer 5.0.2 and running sql*net v1 and v2.
How can I upgrade my server to Oracle 7.3.x or 8.x. without upgrade my client version
Are there a patch to sql*net v1?
so I can use version 1 access version 2.
How can I get the patch?
Thanks.
nullYour question is unclear, and does not appear to be related to the Oracle Migration Workbench.
Turloch
Oracle Migration Workbench Team -
SQL*NET V1 FOR APPC/LU6.2 TEST
제품 : SQL*NET
작성날짜 : 1995-06-05
Olivetti system에서 SQL*Net V1 for APPC/LU6.2 test 결과입니다.
customer : 한국컴퓨터
Test System : Olivetti UNIX System 2대
O / S version : SVR4 2.4
1. Server Install
1.1 Shared Memory Parameter
SHMMAX8388608
SHMSEG6
SHMMIN1
SHMMNI100
1.2 Kernel Parameter
SVMMLIM0x7FFFFFFF
HVMMLIM0x7FFFFFFF
SFSZLIM0x7FFFFFFF
HFSZLIM0x7FFFFFFF
파라메터가 이보다 적으면 oracle kernel을 만들면서 에러가 발생함.
1.3 Oracle Server Install 시 relink option 에서 Yes 선택.
LU6.2를 사용하기 위해서 반드시 해주어야 함.
1.4 Version이 2.3이하인 경우 kernel 생성시 에러 발생.
2. SQL*Net Install
2.1 Transaction Program 을 Generate.
$ $ORACLE_HOME/bin/gentpn ORACLE_SID Max_RU_size Min_RU_size
RU_size는 256 에서 1024 범위내에서 set 해야함.
ex) $ gentpn ORA7 512 512
generate 후 TPORA7 이라는 Transaction Program 이 generate
되었다는 message가 떨어짐
TP name은 ORACLE_SID 앞에 TP가 붙어서 생성.
generate후 $ORACLE_HOME/lu62/server directory 에 TPORA7
이라는 binary file이 생성.
2.2 TPORA7을 APPC Services에 등록.
sysadm tool을 이용하여 등록.
TP_Name : TPORA7
TP_Filespec : /home/oracle7/lu62/server/TPORA7
3. Connection.
3.1 Connect String
- @L:remote_LU_name::local_LU_name:mode_name:TP_name
remote_LU_name, local_LU_name, mode_name 의 value는 APPC
service에 등록이 되어있슴.
ex) $ sqlplus scott/tiger@L:BBBBBBBB::AAAAAAAA:CCCCCCCC:TPORA7
4. 특이사항.
-. gentpn시 Max_RU_size와 Min_RU_size 256으로 set:
sqlplus에서 접속시 SQL> prompt가 떨어지지 않고 waiting 상태.
반면 상대방 remote system에 session 은 연결됨.
-. gentpn시 Max_RU_size와 Min_RU_size 512으로 set:
sqlplus에서 접속은 됨.
그러나 512를 넘어서는 데이타일경우에는 ORA-6412 에러가 떨어지면서
disconnect 가 되어버림. (ORA-6412:bad read length)
remote에서 select 된 데이타는 local system 까지는 가져옴.
data size 는 548.
sqlplus 에서 array size를 '1'로 하면 정상적으로 작동.
ex) 1). select empno, ename from emp; ----> 정상
2). select * from emp; ----> disconnect
3). select empno, ename, hiredate, sal,
mgr, comm, deptno
from emp; ----> disconnect
4). set array 1
select * from emp; ----> 정상
-. gentpn시 Max_RU_size와 Min_RU_size 1024으로 set:
데이타 사이즈가 1024를 넘어설경우 동일한 현상발생.great to hear some one talking of sql*net for dos
hi
you can't connect from v1 to net8
you can conn from v1 to v2
don't start net8
on the server
start sql*net 2.?? at the server
hope this helps
I need drivers for sql*net on dos
where can i down load these from
thnkx
Adrian Maier (guest) wrote:
: Here is my problem:
: I have some DOS applications written for Oracle 6 for DOS.
: I want that these connect to an Oracle Server using SQL*Net.
: For the start, I want to connect to the server with sqlplus,
: from DOS. For testing I have a small TCP/IP network with two
: computers:
: 1. the SERVER, running Linux(Debian 2.1) and Oracle 8.0.5
: 2. the CLIENT, running MSDOS, PSNFS as networking software
: and SQL*Net Client v1 for DOS.
: Question: Is this version of SQl*Net client compatible with
: Net8 which comes with Oracle8?
: From win95 I've bben able to connect to the server, so I
: believe the serevr is correctly configured. When I'm trying
: to connect from DOS with sqlplus, the ethernet card's leds
: blink two or three times, which means that some data is
: transmitted through network. After that, sqlplus waits for
: an indefinite period of time.
: If I stop the listener, sqlplus generates the error ORA-06136
: and asks for a new username. If I don't stop the listener,
: sqlplus remains blocked.
: In SQLNet documentation I've found:
: "ORA-06136: Error during connection handshake.
: Cause: The destination server was unable to obtain enough
: information to complete the connection.
: Action: Check that the configuration of the server is correct,
: blah, blah .... "
: I think that the server might not understand this version
: of client, but Net8 should be "backward compatible"!
: SQL*Net client v1 was the only DOS version I could find.
: Are there any other newer DOS SQl*Net clients available?
: If you have any idea about what could I do, please let me know.
: Best regards,
: Adrian Maier
: [email protected]
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
Maybe you are looking for
-
Hi folks, I am looking for a report that will provide Vendor price history for a material. Is there any standard SAP report or any table that gives this information? Sincerely, Sanjay
-
Salesforce Password not saving in CMC
I've got a couple of reports running successfully outside of BOE that query SFDC with a username/password prompt. These have been published to our BOE server, and the Database Configuration set to "Use same database logon as when report is run". I've
-
How to get a previous version of vyke freetxt for ...
Hi there, i was using vyke freetxt (i dont know the exact version of it) happily till today when i deleted it by mistake. I went on and downloaded the new version (1.03) from vyke.com. There is something i hate in the new version. When i change the s
-
Can I delete prior versions of Adobe CC?
Will it cause any problems if I delete the prior versions of Adobe CC?
-
Dynamic Item processor profiles
Please explain me what is the use of dynamic item processor profiles and profile in customer service Thanks in advance Rajesh