처음 사용자를 위한 SQL*NET V1/V2

제품 : SQL*NET
작성날짜 : 1997-10-10
처음 사용자를 위한 SQL*NET V1/V2
===============================
오라클에서는 기존의 통신프로토콜(TCP/IP 등)에 기반한 오라클 고유의 middleware
인 SQL*NET을 이용하여 client/server 간의 통신을 하게 됩니다.
sql*net은 v1,v2 의 두가지 버젼이 있는데 이것은 upgrade 차원의 개념이 아니고
독립적인 방식을 취하고 있기 때문에 서로간의 호환성이 없습니다.
따라서 client 에서 v1를 사용한다면 server에서도 v1을 지원해야만 접속이
가능합니다.
일반적으로는 서버와 클라이언트 양쪽에 sql*net v1,v2를 모두 다 인스톨
해놓고 사용합니다.
오라클 db 에 접속하려면 우선 db 를 startup 시켜야 하며 클라이언트
접속을 처리하기 위해서는 sql*net 프로세스도 함께 구동시켜야 합니다.
NT에서는 이들이 모두 제어판의 SERVICES에서 관리되므로 SERVICES에서 Oracle
이라는 문장이 들어 있는 모든 서비스들을 Started 상태로 기동시켜 주시면 됩니다.
단, v1 은 인스톨 후에 특별한 셋업과정이 필요없지만 v2의 경우는 간단한
셋업 과정이 필요합니다. (뒷부분 참조)
이렇게 해 둔 상태에서 client 에서 접속할 수 있습니다.
다음은 SQL*NET V1,V2를 사용하여 접속하는 방법입니다.
여기서 서버의 hostname은 krunix, <ORACLE SID>는 ORA7 이라고 가정합니다.
NT의 경우에는 DEFAULT로 <ORACLE SID>가 ORCL 입니다.
참고로 UNIX의 경우 <ORACLE SID>는 서버에 오라클 유저로 들어간 다음
echo $ORACLE_SID
라고 치면 확인할 수 있습니다.
그리고, 사용하는 유저는 오라클 인스톨시에 기본적으로 생성되는 scott 유저
(패스워드는 tiger)를 사용하도록 합니다.
그리고 hostname(krunix)가 들어가는 곳에 직접 ip address를 써 주어도 상관
없습니다 (접속 속도는 조금 빨라집니다)
========================
SQL*NET V1 으로 접속하기
========================
우선 서버에서 SQL*NET V1 프로세스를 구동하여야 합니다.
서버에 오라클 유저로 들어간 다음
tcpctl start
하면 됩니다.
NT의 경우에는 제어판의 서비스에서 OracleTCPListener가 기동된
상태이어야 합니다.
다음에 클라이언트에서는 다음과 같이 하여 접속을 할 수 있습니다.
역시 오라클 유저로 유닉스에 들어간 다음
sqlplus scott/tiger@t:krunix:ORA7
하면 접속이 됩니다.
PC에서 접속하는 경우에도 유사한 방법으로 하면 됩니다.
======================
SQL*NET V2 로 접속하기
======================
SQL*NET V2는 SQL*NET V1처럼 바로 사용할 수 없고 다음과 같이 간단한 셋업 과정을
거쳐야 합니다.
서버상에 오라클 유저로 접속한 다음,
1) Multi-threaded server 프로세스들을 먼저 기동을 하여야 한다.
기동하는 방법은 ORACLE_HOME/dbs/init<SID>.ora 화일에 다음과 같은 내용을
추가하고 DB 를 다시 startup 을 한다. <SID>를 ORA7이라고 가정하면 실제의
화일이름은 initORA7.ora 가 됩니다.
# Filename : $ORACLE_HOHE/dbs/init<SID>.ora
# Protocol : tcp
mts_dispatchers="tcp,3"
mts_max_dispatchers=10
mts_servers=2
mts_max_servers=10
mts_service=ORA7
mts_listener_address="(ADDRESS=(PROTOCOL=tcp)(port=1521)(host=krunix)"
mts_service 에는 <ORACLE SID>를 입력하는 것입니다.
2) /etc/services file 에 다음내용을 추가한다. services 화일은 Machine에
따라 디렉토리가 다를 수 있다. 이 작업은 root 유저로 합니다.
listener 1521/tcp
3) tnsnames.ora 및 listener.ora 를 작성한다. 이 화일들은 유닉스 환경변수를
TNS_ADMIN=$ORACLE_HOME/network/admin 와 같이 지정한 다음
$ORACLE_HOME/network/admin 디렉토리에 만들어 주면 된다.
예)
# File name : $ORACLE_HOME/network/admin/listener.ora
LISTENER =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)
(HOST = krunix)
(PORT=1521)
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER = 0
TRACE_LEVEL_LISTENER = off
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = ORA7)
(ORACLE_HOME=/usr/oracle7)
여기서 <ORACLE SID>는 ORA7, ORACLE HOME DIRECTORY를 /usr/oracle7
이라고 가정하였습니다.
# Filename : $ORACLE_HOME/network/admin/tnsnames.ora
TORA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = tcp)
(HOST = krunix)
(PORT=1521)
(CONNECT_DATA =
(SID = ORA7)
4)listener 프로세스를 start 한다(오라클 유저로 START한다.)
$lsnrctl start
여기서 에러가 발생하면 listener.ora 가 잘못 만들어진 것입니다.
정상적으로 start가 되면 tnslsnr이라는 프로세스가 뜹니다.
5)클라이언트에 앞에서 만든 tnsnames.ora 화일을
$ORACLE_HOME/network/admin 디렉토리에 copy 한 다음
다음과 같이 접속한다.
sqlplus scott/tiger@TORA
=======================================================================
<PC의 SQLPLUS에서 접속>
SQL*Plus 등에서 username, password, connect string 주는 부분을 다음과 같이
주면 됩니다.
username scott
password tiger
connect string t:hostname:SID
여기서 hostname 대신에 server의 ip address 를 써도 되고 SID 부분은
WORKGROUP SERVER 라면 DEFAULT가 ORCL 입니다. 확인하려면 Unix 에 oracle
유저로 들어가서 env 를 쳐보시면 환경변수가 출력되는데 거기서 ORACLE_SID로
지정된 부분입니다.
v2 의 경우는 tnsnames.ora 라는 화일에 alias 와 관련정보를 기록한 다음
connect string에 alias 를 바로 주면 연결이 됩니다.
SQL*NET V2는 서버와 PC 양쪽에 간단하게 셋업을 해주셔야 합니다.
PC쪽은 서버쪽의 $ORACLE_HOME/network/admin 디렉토리에 있는 화일들을
모두 PC 의 C:\orawin\network\admin 디렉토리로 COPY 하기만 하면 됩니다.
그리고 connect 시에 connect string 으로 tnsnames.ora 에 등록한
service name(자료에는 TORA 로 되어 있음)을 주면 접속이 됩니다. 위와 같이
셋업을 하였을 경우라면 예를 들면 다음과 같습니다.
username scott
password tiger
connect string TORA
그리고 PC의 c:\orawin\network\admin 디렉토리의 sqlnet.ora 화일은 삭제하고
접속하시기 바랍니다.
<WINDOWS NT의 경우>
간단히 말씀드리면 V2의 경우에는 c:\orant\network\admin 디렉토리에 listener.ora
를 만들어 주어야 하고 PC의 c:\orawin\network\admin 디렉토리에는 tnsnames.ora
를 만들어 주어야 합니다.
NT는 인스톨 하게 되면 기본적으로 SQL*NET V1,V2 프로세스가 자동으로 서비스에
등록되어서 실행이 되기 때문에 서버쪽에서 특별히 셋업하실 것은 없고 클라이언
쪽만 셋업을 하시면 됩니다(V2만 셋업하면 됩니다.)

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

Similar Messages

How to decipher SQL*Net protocols/packets?

hi,
we have a customer that sells compliance solutions that basically track and audit information at the packet level. in order to expand their customer base they would like to offer their solutions to customer that have business systems built on Oracle Forms 6.x and Pro*C. to do this they need to understand how our network communication works. is this something that is generally available? here are some details for what the partner wants from us ...
Their product intercepts the communication between a typical Db client and Db server at packet level, performs analysis on the packets and extracts the information required for SOX compliance. It's been successfully installed and working for various versions of Oracle servers and Clients, however it does not handle Oracle Forms and pro*C clients.
It also wrks for pro*c client except for bind variables and arrays.
We need information on packet formats during communication between Oracle database and Forms and pro*c clients. This will help our product to work for SOX compliance for the customers who have FORMS and pro*c clients without replacing them
I know that form Forms to DB its SQL*Net, not sure what the protocol is for PRO*C to DB communication but do we have documentation on both?

Assuming you are on Windows, you can download the client installable from
http://download.oracle.com/otn/nt/oracle10g/10201/10201_client_win32.zip -- for Oracle 10g client
http://download.oracle.com/otn/nt/oracle11g/win32_11gR1_client.zip -- for Oracle 11g client
If you are looking for any other version, please mention the same.

How to find out the size of files transferred over the SQL * Net?

I am trying to test the Advanced Compress (AC) for 11g Data Guard. When the AC is turned on, the archived log files are supposed to be compressed on the primary database server and sent over SQL*Net, then decompressed on the standby db server. We will see the file sizes are the same on both primary and standby servers. I want to verify that the AC works by monitoring how much data are sent over SQL*Net. Per Oracle, AC uses 35% less of the bandwith. That means the size of the files transferred should be at least 65% of the original size.
Is there a way to find out the size through Oracle utilities? If not, how to find out by OS utilities? OS is Solaris 5.10.
Thanks.

I'm not sure this can be done via SQL*Net, but a network packet sniffer between the two servers should be able to help - you might want to contact your network team.
HTH
Srini

TRACING IN SQL*NET V2

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

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

Process wait SQL*Net message from dblink /SQL*Net message from client

Hi There,
We have an ETL process that we kindly need your help with. The process been running since Sun, where it transfers the data from one server (via remote query). The process was running ok till last night where it appeared
to have stopped working and/or the session is just idling doing nothing.
Here are some tests that we did to figure out what's going on:
1. when looking at the session IO, we noticed that it's not changing:
etl_user@datap> select sess_io.sid,
2         sess_io.block_gets,
3         sess_io.consistent_gets,
4         sess_io.physical_reads,
5         sess_io.block_changes,
6         sess_io.consistent_changes
7    from v$sess_io sess_io, v$session sesion
8   where sesion.sid = sess_io.sid
9     and sesion.username is not null
10     and sess_io.sid=301
11 order by 1;
                    logical   physical
SID BLOCK_GETS      reads      reads BLOCK_CHANGES CONSISTENT_CHANGES
301 388131317   97721268   26687579     223052804             161334
Elapsed: 00:00:00.012. Check there is nothing blocking the session
etl_user@datap> select * from v$lock where sid=301;
ADDR     KADDR           SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
684703F0 6847041C        301 DX         35          0          1          0      45237          0
684714C4 684714F0        301 AE     199675          0          4          0     260148          0
619651EC 6196521C        301 TM      52733          0          3          0      45241          0
67F86ACC 67F86B0C        301 TX     458763      52730          6          0      45241          03. Check if the session is still valid:
etl_user@datap> select status from v$session where sid=301;
STATUS
ACTIVE4. Check if there is anything in long ops that has not completed:
etl_user@datap> SELECT SID, SERIAL#, opname, SOFAR, TOTALWORK,
2      ROUND(SOFAR/TOTALWORK*100,2) COMPLETE, TIME_REMAINING/60
3      FROM   V$SESSION_LONGOPS
4      WHERE
5      TOTALWORK != 0
6      AND    SOFAR != TOTALWORK
7     order by 1;
no rows selected
Elapsed: 00:00:00.005. Check if there is anything in long ops for the session:
etl_user@datap> r
1* select SID,SOFAR,TOTALWORK,START_TIME,LAST_UPDATE_TIME,TIME_REMAINING,MESSAGE from V$SESSION_LONGOPS where sid=301
SID      SOFAR TOTALWORK START_TIM LAST_UPDA TIME_REMAINING MESSAGE
301          0          0 22-JUL-12 22-JUL-12                Gather Table's Index Statistics: Table address_etl : 0 out of 0 Indexes done
Elapsed: 00:00:00.00This is a bit odd!! This particular step have actually completed successfully on the 22nd of July, and we don't know why it's still showing in long opps!? any ideas?
6. Looking at the sql and what's it actually doing:
etl_user@datap> select a.sid, a.value session_cpu, c.physical_reads,
2 c.consistent_gets,d.event,
3 d.seconds_in_wait
4 from v$sesstat a,v$statname b, v$sess_io c, v$session_wait d
5 where a.sid= &p_sid_number
6 and b.name = 'CPU used by this session'
7 and a.statistic# = b.statistic#
8 and a.sid=c.sid
9 and a.sid=d.sid;
Enter value for p_sid_number: 301
old   5: where a.sid= &p_sid_number
new   5: where a.sid= 301
             CPU   physical    logical                                   seconds
SID       used      reads      reads EVENT                             waiting
301    1966595   26687579   97721268 SQL*Net message from dblink         45792
Elapsed: 00:00:00.037. We looked at the remote DB where the data resides on, and we noticed that the remote session was also waiting on the db link:
SYS@destp> select a.sid, a.value session_cpu, c.physical_reads,
2 c.consistent_gets,d.event,
3 d.seconds_in_wait
4 from v$sesstat a,v$statname b, v$sess_io c, v$session_wait d
5 where a.sid= &p_sid_number
6 and b.name = 'CPU used by this session'
7 and a.statistic# = b.statistic#
8 and a.sid=c.sid
9 and a.sid=d.sid;
Enter value for p_sid_number: 388
old   5: where a.sid= &p_sid_number
new   5: where a.sid= 390
       SID SESSION_CPU PHYSICAL_READS CONSISTENT_GETS EVENT                                                    SECONDS_IN_WAIT
       390         136              0            7605 SQL*Net message from client                                        46101
SYS@destp>We have had an issue in the past where the connection was being dropped by the network when the process runs for few days, hence we have added the following to the sqlnet.ora and listener.ora files:
sqlnet.ora:
SQLNET.EXPIRE_TIME = 1
SQLNET.INBOUND_CONNECT_TIMEOUT = 6000
listener.ora:
INBOUND_CONNECT_TIMEOUT_LISTENER = 6000What else can we do and/or further investigate to work out the root cause of the problem, and may be help resolve this. We don't want to just stop and start the process again as it took few days already. We have
had a chat to the infrastructure team and they've assured us that there have been no network outages.
Also, the alert logs for both instances (local and remote) shows no errors what so ever!
Your input is highly appreciated.
Thanks
Edited by: rsar001 on Jul 25, 2012 10:22 AM

Ran the query on both local/remote db, and no rows returned:
etl_user@datap> SELECT DECODE(request,0,'Holder: ','Waiter: ')||vl.sid sess, status,
2 id1, id2, lmode, request, vl.type
3 FROM V$LOCK vl, v$session vs
4 WHERE (id1, id2, vl.type) IN
5 (SELECT id1, id2, type FROM V$LOCK WHERE request>0)
6 and vl.sid = vs.sid
7 ORDER BY id1, request
8 /
no rows selected
Elapsed: 00:00:00.21

Oracle12c SQL*NET blocked by Windows 2008 firewall - what is the correct solution?

Hello,
I have a question with regards to the SQL*NET traffic being blocked by the Windows 2008 firewall. This document shows that disabling the firewall can resolve the problem:
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=166773506396122&id=1472931.1&displayIndex=13&_afrWindowMode=0&_adf.ctrl-state=o4dq0hlih_112
Is this really the solution?
From what I understand from other documents is that just enabling port 1521 will not resolve any issues, as SQL*NET can use redirection to other random ports. That is probably the reason why the Oracle installation does not alter any firewall settings.
What other methods do people use to connect a client to a DB server?
This document shows what other methods to use, but who uses them?
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=166043735580557&id=68652.1&_afrWindowMode=0&_adf.ctrl-state=o4dq0hlih_78
Does anyone use the Oracle Connection Manager for example?
Thanks
Richard

I configure firewall to allow DB Server to start new network connections

Sql*net patch version 2.3.2.1.12 down load

While I am migrating 7.3 database to 8i, system is asking for install sql net patch version 2.3.2.1.12. How can I get this patch. Is it possible to download.
Thanks/Rgds
Biju

I know that I should first download and apply the AD related patches separetly. But, what is the best practice for downloading the rest of them? How does an experienced Applications DBA handle this kind of situation? I was trying to use the Patching Wizard on OAM, but the request errored out stating that "****No codeline specified". Where do I specify this when I download a list of patches? I just pasted a comma separated list of 249 patches into the PatchList field on Download Patches page.Please see these docs.
'Analyze specific Patch' via Patchwizard is failing with java.lang.NullPointerException [ID 1066985.1]
Patch Wizard Utility [ID 976188.1]
Patch Wizard FAQ [ID 976688.1]
Patch Wizard : Overview [ID 1077813.1]
Thanks,
Hussein

How to connect to DB in repository assistant using SQL*net

Hi all,
We are in RAC enviroment. When I try to connecting to oracle DB in repository assistant (the page that asks for SYS account), I check the SQL*net, and enter the net service name (absolutly also enter the SYS and SYS psw field), but the 'next' button is grey out.
according to installation guide, in a RAC environment, do not type the host name, port number and oracle service name. But in my case, I have to enter all these fields to enable the 'next' button.
any idea of how to fix it?
thanks

I forget to say that I can connect to the repository browser using SQL*net. So I suppose that net service name is correct.
thanks for any suggestion.

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.

TCP/IP IN SQL*NET & SLIP / PPP

제품 : SQL*NET
작성날짜 : 1997-10-10
SLIP (Serial Line Internet Protocol)
SLIP 과 Ethernet 은 TCP/IP 을 구현하는 매체에 규정되어지는 두개의
PROTOCOL 입니다
SLIP은 serial/modem lines 에 사용되어지며, Ethernet은 Coaxial
cable 에 사용되어집니다
SQL*NET 에서는 이 두가지가 차이가 없으며, SQL*NET 은 이 두 가지를
단지 TCP/IP 로 볼 뿐입니다.
그림으로 보면 다음과 같읍니다
| SQL*Net |
| Tcp/ip |
-------------------+
| SLIP | Ether |
-------------------+
| Serial| Coax |
SLIP 대신에 PPP 를 사용하는 것은 serial TCP/IP 통신을 하는 새로운
방법입니다
이러한 방법은 SQL*NET 과는 직접적인 관련이 없으며, SQL*NET 은
Serial Line 을 통해 바로 접속이 됩니다.
따라서 Serial line (Modem)과 Ethernet (Lan card) 을 통한 접속은
TCP/IP 설정만 올바르게 되어있다면 SQL*NET 이상없이 접속할수
있으며 이상유무를 SQL*NET 에서 볼수는 없읍니다

When someone answers you, please forward the answer to my email. I am trying to connect to an Oracle db from Visual Basic, and need the component. I have downloaded software from this site, but it did not have the SQL Net.

Using blobs with SQL*Net 8

Hello,
Can someone please help me get oriented in the following:
Clients have Oracle Forms Developer 6i installed on 100 machines. This is from 1996 I think. It comes with SQL*Net 8.
They want a simple utility that uploads a file into a blob field on the remote database.
I already developed the utility thinking that they have Oracle 9i2 installed - so I used OCCI. This is not a possibility with the old technology they are actually using..
So what is the place to start?
Thank you!!
david

You can try with PRO-C

Oracle SQL*Net and TNS Protocol

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

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

CLIENT SIDE TRACING IN SQL*NET V2

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

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

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
NM

Hi 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

Getting SQL*Net more data from client waits when running a query through web based interface

Hi, you all,
We are having this weird behavior when running query through web based interface, we get a lot of "SQL*Net more data from client" waits, the OEM indicates that the current wait event is SQL*Net more data from client
It's just a very simple query wich invokes a db link.
When I execute the same query on any PL/SQL tool like toad or sql developer it works fine, but that query inside an application executed through a web based interface, it hangs for ever.
Where can I start looking for the problem.
We are working on a 3 Node RAC 11gr2, both databases are on the same RAC.
Thanks.

Hi ,
we managed to reproduce the case in test environment, below are the steps:
1)have 2 databases on different machines, will call the first one local, the other one remote.
2)in the local database create:
a - DBLink to remote database.
b - read data from remote database(we simply used select count(*) from dummy_table )
c - insert data into a table on the local database
d - terminate the connection between the 2 databases (disconnect either machine from the network)
e - commit on local database.
what we noticed was the following:
1)when the local database is disconnected from the network(the machine is not connected to any network at the moment): almost immediately throws an error, and issuing the following:
select * from dba_2pc_pending;we found some data .
2) when the remote database was disconnected(the local database is still connected to the network):
after 7-8 seconds an error is thrown, and issuing the following:
select * from dba_2pc_pending;did not return any data.
since this is pretty similar to our case ,we concluded that it's a network issue.
is this the correct behavior ?
as a temporary solution till the network issue is fixed ,we did the following:
1) changed the call of the remote procedure to calling a local procedure that calls the remote procedure.
2) added pragma autonomous_transaction to the local procedure.
3) at the end of the local procedure rollback the autonomous transaction.
it seems that since the global transaction does not use the DBLink database does not issue a 2PC commit.
this works in my cases since the DBLink is only issed to read data.

How to configure SQL*Net to survive minor dropouts?

Hi,
We have recently started developing over a VPN to our server. The VPN is not brilliant and we get minor dropouts for a second or so. This is causing SQL*Net to dropout and we need to re-connect and re-start all our Apps (SQL*Plus, Forms Builder, etc).
Is there an SQL*Net setting which can keep the connection open, even if the network drops for 1-2 seconds?
Cheers,
Tim.

Yes, a VPN is extremely important. Just as it's the job of DBAs to protect and maintain data, it is the job of a Network Administrator to keep the network functioning correctly. I'd say that having your NAs take care of the VPN problem is paramount to not only solving your issue, but also in keeping your company's infrastructure on-track and maintainable.
P.S. I was an NA in one of my previous lives :(

처음 사용자를 위한 SQL*NET V1/V2

Similar Messages

Maybe you are looking for