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

Similar Messages

  • 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

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

  • SQL*Net more data to dblink event for hours or days

    Hello Everyone,
    in our production database when we commit a transaction we call a remote procedure over dblink.
    usually the call succeeds ,but every now and then a couple of sessions hang up,
    when I use the session browser of Toad I notice that these sessions are waiting with the event SQL*Net more data to dblink
    below are some queries and their results:
    select sid,event,wait_class,wait_time,seconds_in_wait,state from gv$session_wait where sid=225
    rslt:
    225 SQL*Net more data to dblink Network -1 18279 WAITED SHORT TIME
    select * from gv$session_wait_history where sid=225
    rslt:
    INST_ID     SID     SEQ#     EVENT#     EVENT     P1TEXT     P1     P2TEXT     P2     P3TEXT     P3     WAIT_TIME     WAIT_TIME_MICRO     TIME_SINCE_LAST_WAIT_MICRO
    2     225     1     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8144          0     0     8     41
    2     225     2     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8143          0     0     13     39
    2     225     3     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8149          0     0     7     37
    2     225     4     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8145          0     0     8     40
    2     225     5     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8145          0     1     11394     37
    2     225     6     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8143          0     0     7     37
    2     225     7     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8145          0     0     7     36
    2     225     8     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8138          0     0     8     37
    2     225     9     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8149          0     0     8     38
    2     225     10     344     SQL*Net more data to dblink     driver id     1413697536     #bytes     8149          0     1     11476     37I'm not sure but from the above results ,is it safe to conclude that I get stuck because I am caught in infinite loop trying to write to dblink?
    additional notes:
    <li>some times when I look at the current statement I find that the statement is a query or insert into a local table.
    <li>there were some network outages.
    <li>when viewing the database log files I found:Error 3135 trapped in 2PC on transaction 7.6.306086. Cleaning up.
    Error stack returned to user:
    ORA-03135: connection lost contact
    ORA-02063: preceding line from MPF//where MPF is the name of dblinkeven though we use the DBLink to execute the procedure only without any changes on the remote DB, and we don't use 2PC.
    <li> the local DB is a RAC
    select * from dba_blockers
    rslt:
    no rows
    select * from dba_waiters
    rslt:
    no rows
    select * from gv$lock where sid=225
    rslt:
    INST_ID     ADDR     KADDR     SID     TYPE     ID1     ID2     LMODE     REQUEST     CTIME     BLOCK
    2     0000000199D54F60     0000000199D54FB8     225     AE     100     0     4     0     20152     2
    2     000000018EA18108     000000018EA18180     225     TX     1114138     251539     6     0     19654     2
    select * from gv$session where sid=225
    rslt:
    INST_ID     SADDR     SID     SERIAL#     AUDSID     PADDR     USER#     USERNAME     COMMAND     OWNERID     TADDR     LOCKWAIT     STATUS     SERVER     SCHEMA#     SCHEMANAME     OSUSER     PROCESS     MACHINE     PORT     TERMINAL     PROGRAM     TYPE     SQL_ADDRESS     SQL_HASH_VALUE     SQL_ID     SQL_CHILD_NUMBER     SQL_EXEC_START     SQL_EXEC_ID     PREV_SQL_ADDR     PREV_HASH_VALUE     PREV_SQL_ID     PREV_CHILD_NUMBER     PREV_EXEC_START     PREV_EXEC_ID     PLSQL_ENTRY_OBJECT_ID     PLSQL_ENTRY_SUBPROGRAM_ID     PLSQL_OBJECT_ID     PLSQL_SUBPROGRAM_ID     MODULE     MODULE_HASH     ACTION     ACTION_HASH     CLIENT_INFO     FIXED_TABLE_SEQUENCE     ROW_WAIT_OBJ#     ROW_WAIT_FILE#     ROW_WAIT_BLOCK#     ROW_WAIT_ROW#     TOP_LEVEL_CALL#     LOGON_TIME     LAST_CALL_ET     PDML_ENABLED     FAILOVER_TYPE     FAILOVER_METHOD     FAILED_OVER     RESOURCE_CONSUMER_GROUP     PDML_STATUS     PDDL_STATUS     PQ_STATUS     CURRENT_QUEUE_DURATION     CLIENT_IDENTIFIER     BLOCKING_SESSION_STATUS     BLOCKING_INSTANCE     BLOCKING_SESSION     FINAL_BLOCKING_SESSION_STATUS     FINAL_BLOCKING_INSTANCE     FINAL_BLOCKING_SESSION     SEQ#     EVENT#     EVENT     P1TEXT     P1     P1RAW     P2TEXT     P2     P2RAW     P3TEXT     P3     P3RAW     WAIT_CLASS_ID     WAIT_CLASS#     WAIT_CLASS     WAIT_TIME     SECONDS_IN_WAIT     STATE     WAIT_TIME_MICRO     TIME_REMAINING_MICRO     TIME_SINCE_LAST_WAIT_MICRO     SERVICE_NAME     SQL_TRACE     SQL_TRACE_WAITS     SQL_TRACE_BINDS     SQL_TRACE_PLAN_STATS     SESSION_EDITION_ID     CREATOR_ADDR     CREATOR_SERIAL#     ECID
    2     00000001993E4F58     225     445     1353611     0000000198E2FA10     198     <schema>     47     2147483644     000000018EA18108          ACTIVE     DEDICATED     198     <schema>     oracle     1234     <cluster name>     49993     unknown     JDBC Thin Client     USER     00000001968A1250     3198676106     72y8ztfzagv4a     2     02/04/2013 11:18:22 ص     33554852     00000001968A18E0     3992616824     03mm4u3qznzvs     0     02/04/2013 11:18:22 ص     33554730     158207     1     158207     1     JDBC Thin Client     2546894660          0          12206     122409     8     49354     0     94     02/04/2013 10:53:20 ص     19559     NO     NONE     NONE     NO          DISABLED     ENABLED     ENABLED     0          NOT IN WAIT               NOT IN WAIT               42844     344     SQL*Net more data to dblink     driver id     1413697536     0000000054435000     #bytes     8144     0000000000001FD0          0     00     2000153315     7     Network     -1     19553     WAITED SHORT TIME     8          19553325216     SYS$USERS     DISABLED     FALSE     FALSE     FIRST EXEC     100     0000000198E2FA10     2     004qLk^iPyp0bqw5wFDCiW0002fR000B^f

    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.

  • SQL*NET SESSION의 DEAD CONNECTION 처리 방법

    제품 : SQL*NET
    작성날짜 : 1996-04-03
    SQL*NET SESSION의 DEAD CONNECTION 처리 방법
    ==========================================
    server에서 수행 중이던 프로그램이 비정상 종료한 경우에는 오라클의 smon이
    자동으로 detection하여 수행 중이던 transaction을 rollback하여
    정리하여 준다.
    그러나, Client Server 환경에서 PC를 Client로 사용 시 비정상적인 방법으로
    Server와 Disconnect 하면 Server 쪽에 있는 Dedicated Server가 남아 있다.
    이는 Sql*net V1 & V2에서 발생하던 문제로 Sql*net V2.1 이후에는 아래와
    같은 방법을 이용하면 Dead connection이 정상적으로 Disconnect 된다.
    * 환경 : Server - Sql*net tcp/ip V2.1.3
    Client - Sql*net V2.0
    * Setup 방법 : Server와 Client에 있는
    $ORACLE_HOME/network/admin/sqlnet.ora에
    sqlnet.expire_time=n
    으로 setting 한다.
    여기서 n은 분 단위이며 실제 disconnect는 n분보다 더 걸린다.
    일반적으로 sqlnet.expire_time=1로 설정하면 적당하다.

    Hi,
    Probe send - client and application still there - all fine
    Network cable on the client is removedAt the above stage if the Sever sents a probe then if does not receive any message from Client it is treated as DCD. (It will receive any error code or negative response from client instead of any active status communication)
    Application is shut down
    (Optionally the computer is rebooted)
    Network cable is reattached
    Next probe send from server
    At this point, the client is reachable, the Oracle NET component on the client is there, but the application on the client is gone without properly saying good bye to the DB server.
    Would DCD detect the dead connection in this sceanrio?If my above comment is dismissed and your case or assumptions continues, then we need to check the SQL_EXPIRE time which you have connected. If the every thing happens with in the time setted for Expire time then, still it will treat as DCD, your session is getting terminated the system got rebooted.
    You understanding with DCD is correct.
    We see sessions in V$SESSIONS that don't have a process on the client any more. We have SQLNET.EXPIRE_TIME set to 2 minutes on the server, but still these sessions show up after days. Sessions show up as inactive and are waiting on "SQL*NET message from client" for hours and days.See basically INACTIVE and DCD are different. Slight difference exits. As you said you find inactive sessions. If you want to cleanup those inactive sessions, as per oracle documenation, you can create a custom profile as per your requrement and assign some IDLE_TIME and update the respective user profile. That might help you out.
    - Pavan Kumar N

  • 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

  • WINDOWS 용 SQL*NET 사용 시 TNS-12203

    제품 : SQL*NET
    작성날짜 : 2004-11-09
    WINDOWS 용 SQL*NET 사용 시 TNS-12203
    ====================================
    PURPOSE
    TNS-12203 "TNS:unable to connect to destination"은 여러가지 원인 때문에
    발생할 수 있습니다. 여기서는 가장 일반적인 몇 가지 원인을 설명합니다.
    1. WINDOWS 용 TCP/IP 어댑터를 설치하지 않은 상태에서 연결하려 하면 TNS-
    12203이 발생할 수 있습니다. SQL*NET TCP/IP V2는 SQL*NET V2와 V2 TCP/IP
    어댑터 등 두가지 제품으로 구성됩니다. 이들은 별도의 두 키트로 되어 있는데,
    반드시 두 키트를 모두 설치해야 합니다.
    2. TNS-12203 에러는 WINDOWS 용 ORACLE SQL*NET소프트웨어가 ORACLE HOME
    디렉토리를 찾을 수 없다는 의미일 수 있습니다. 이 문제를 해결하려면, 먼저
    WIN.INI 화일의 ORACLE 부분에 다음 항목이 있는지 확인하십시오.
    [ORACLE]
    ORA_CONFIG=C:\WINDOWS\ORACLE.INI
    WINDOWS디렉토리가 C:\WINDOWS가 아니면, 위 행의 C:\WINDOWS 부분을 그
    이름으로 바꾸십시오. 그런 다음, ORACLE 소프트웨어를 다시 설치하십시오.
    ORACLE.INI 화일이 있으면 그 ORACLE.INI 화일에 다음 행이 있는지
    확인하십시오.
    ORACLE_HOME=C:\ORAWIN
    ORACLE 홈 디렉토리가 C:\ORAWIN이 아니면 위 행의 C:\ORAWIN 부분을 그
    이름으로 바꾸십시오.
    3. TNSNAMES.ORA가 ORACLE 홈 디렉토리 아래의 NETWORK\ADMIN에 있는지
    확인하십시요. ORACLE 홈 디렉토리는 ORACLE.INI(또는 WIN.INI의
    ORA_CONFIG 매개변수가 지시하는 파일)의 ORACLE_HOME 에 의해 정의됩니다.
    4. 서버 쪽에서 실행 중인 SQL*NET V2 TCP/IP Listener가 없어도 TNS-12203이
    발생할 수 있습니다. 서버 쪽에서 실행 중인 SQL*NET V2가 있는지 확인하십시오.
    서버 쪽에서 Listener Control 유틸리티(LSNRCTL)를 사용하면 서버의 V2
    Listener가 실행 중인지 확인할 수 있습니다. 서버에서 "LSNRCTL STATUS"
    명령을 실행하십시오. Listener Control 유틸리티에 대해서는 SQL*NET
    Administrator's Guide를 참조하십시오.
    5. 연결할 SERVICES 이름에 대해 CONNECT DESCRIPTOR에 정확한 ADDRESS
    매개 변수를 지정했는지 확인하십시오. 정확한 ADDRESS 매개변수를 사용 중인지
    확인하는 방법은, WINDOWS 클라이언트에서 사용 할 것과 같은 ADDRESS 매개
    변수를 가진 TNSNAMES.ORA를 사용하여 서버에서 루프백을 해 보는 것입니다.
    루프백을 수행한다는 것은 데이타베이스와 같은 기계에서 SQL*DBA 등을
    호출하고 연결 스트링을 지정함으로써 SQL*NET V2를 통해 연결한다는 뜻입니다.
    6. JSB VSL 소켓이 초기화되지 않으면 TNS-12203이 발생할 수 있습니다. 이
    문제를 해결하려면 다음 사항을 점검하여 JSB VSL 레이어가 정확하게
    초기화되었는 지 확인하십시요.
    1) ORACLE.INI 파일(또는 WIN.INI의 ORA_CONFIG 매개변수가 지시하는 파일)의
    업체키 매개변수 TCP_VENDOR가 정확하게 설정되었는 지 확인하십시요
    2) ORACLE_HOME\BIN 디렉토리에 MSOCKLIB.DLL이 있는지 확인하십시요.
    3) ORACLE_HOME\BIN 디렉토리에 선택된 JSB 업체 특유의 DLL이 있는지, 또는
    그 JSB 업체 특유의 TSR 파일이 실행되는 지 확인하십시요.
    4) WINDOWS 홈 디렉토리에 VSL.INI 파일이 있는 지 확인하십시요.
    7. TNS-12203에 이어 실제 문제가 무엇인지 더 자세하게 나타내 주는
    또 다른 에러가 발생할 수 있습니다. 화면에서 다른 에러가 보이지 않으면
    ORACLE_HOME\NETWORK\LOG 디렉토리의 SQLNET.LOG 파일을 점검하십시오.

    change (Port = 1526) to 1521 and try to connect
    add the entry to tnsnames.ora file on both client and server
    ORCL =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST =192.168.25.16 )(PORT = 1521))
        (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = orcl)
    EXTPROC_CONNECTION_DATA =
      (DESCRIPTION =
        (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
        (CONNECT_DATA =
          (SID = PLSExtProc)
          (PRESENTATION = RO)
      )Edited by: rajeysh on May 15, 2011 3:02 PM

  • 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

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

  • 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

Maybe you are looking for