SQL*Net break/reset to client

OMS itself is sometimes getting this on the statement:      BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END;
What's that all about? It seems to happen when things generally get busy, especially with I/O. Looking at the ...sysman/log logs and traces, I don't see anything happening at those times different than other times.
hp-ux 11.23 Itanium, dbconsole for 10.2.0.4

See MOS note: https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=PROBLEM&id=734536.1&
DBConsole BEGIN EMD_NOTIFICATION.QUEUE_READY Consuming High CPU [ID 734536.1]
Eric

Similar Messages

  • SQL*Net break/reset to client wait event

    Hi,
    Can you please explain me about "SQL*Net break/reset to client" wait event. One of my session was waiting for this event and when I looked which is causing the problem there are many duplicates in the input which were geting rejecting due ot the primary key. I didn't exactly get how the duplicate reject causing this wait event.
    I appreciate your help !!
    Thanks
    Anand
    Edited by: user509266 on Sep 4, 2009 10:58 AM

    Better place to ask is over in the Database forums.

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

  • 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

  • TNS: connection closed error with SQL*net

    Hi all,
    I've got a new installation of Oracle 11.1.0.6.0 enterprise (Linux). It works fine with direct sqlplus connections but I'm having problems with SQL*net and JDBC thin client connections.
    The database is built correctly and works fine:
    user@cthulhu bash[61]: sqlplus user/pwd
    SQL*Plus: Release 11.1.0.6.0 - Production on Mon Aug 4 12:59:53 2008
    Copyright (c) 1982, 2007, Oracle. All rights reserved.
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
    SQL> select * from v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
    PL/SQL Release 11.1.0.6.0 - Production
    CORE 11.1.0.6.0 Production
    TNS for Linux: Version 11.1.0.6.0 - Production
    NLSRTL Version 11.1.0.6.0 - Production
    SQL>
    but if I try to connect using SQL*net I get errors. I have my TNS listener configured and it starts without errors, reporting the database as a service, and tnsping is fine:
    user@cthulhu bash[62]: tnsping cthulhu_mar
    TNS Ping Utility for Linux: Version 11.1.0.6.0 - Production on 04-AUG-2008 13:02:07
    Copyright (c) 1997, 2007, Oracle. All rights reserved.
    Used parameter files:
    Used TNSNAMES adapter to resolve the alias
    Attempting to contact (DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.2.30)(PORT=1521)) (CONNECT_DATA=(SID=mar)))
    OK (10 msec)
    user@cthulhu bash[63]: sqlplus user/pwd@cthulhu_mar
    SQL*Plus: Release 11.1.0.6.0 - Production on Mon Aug 4 13:02:41 2008
    Copyright (c) 1982, 2007, Oracle. All rights reserved.
    ERROR:
    ORA-12537: TNS:connection closed
    Enter user-name:
    In listener.log:
    Mon Aug 04 13:02:41 2008
    04-AUG-2008 13:02:41 * (CONNECT_DATA=(SID=mar)(CID=(PROGRAM=sqlplus)(HOST=cthulhu)(USER=marbur))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.2.30)(PORT=41754)) * establish * mar * 12518
    TNS-12518: TNS:listener could not hand off client connection
    TNS-12547: TNS:lost contact
    TNS-12560: TNS:protocol adapter error
    TNS-00517: Lost contact
    Linux Error: 32: Broken pipe
    This is a new instance of Oracle so there is no problem with listener.log being too large (as I've seen elsewhere). I've also tried increasing PROCESSES and SESSIONS in the initSID.ora file without any impact. The listener ports are open through the firewall (and disabling it temporarily makes no difference).
    Any suggestions?!
    Thanks, Matt

    This means nothing to me, but it could to someone else......
    from listener trace:
    2008-08-04 16:19:05.135381 : nlpcaini:env[161] = OLDPWD=/u01/app/oracle/product/11.1.0/db_1
    2008-08-04 16:19:05.135407 : nlpcaini:env[162] = ORA_NET2_DESC=12,15
    2008-08-04 16:19:05.135432 : nlpcaini:env[163] = ORACLE_SPAWNED_PROCESS=1
    2008-08-04 16:19:05.135465 : nlpcaini:exit
    2008-08-04 16:19:05.135498 : nsc2addr:normal exit
    2008-08-04 16:19:05.135536 : nsbeqaddr:entry
    2008-08-04 16:19:05.135566 : nsbeqaddr:connecting...
    2008-08-04 16:19:05.135603 : nsopen:entry
    2008-08-04 16:19:05.135633 : nsmal:entry
    2008-08-04 16:19:05.135667 : nsmal:1012 bytes at 0x81a8538
    2008-08-04 16:19:05.135694 : nsmal:normal exit
    2008-08-04 16:19:05.135722 : nsopenmplx:entry
    2008-08-04 16:19:05.135749 : nsmal:entry
    2008-08-04 16:19:05.135779 : nsmal:2020 bytes at 0x81a8930
    2008-08-04 16:19:05.135804 : nsmal:normal exit
    2008-08-04 16:19:05.135831 : nsiorini:entry
    2008-08-04 16:19:05.135861 : nsbal:entry
    2008-08-04 16:19:05.135889 : nsbgetfl:entry
    2008-08-04 16:19:05.135918 : nsbgetfl:normal exit
    2008-08-04 16:19:05.135966 : nsmal:entry
    2008-08-04 16:19:05.135995 : nsmal:84 bytes at 0x81b3dd8
    2008-08-04 16:19:05.136020 : nsmal:normal exit
    2008-08-04 16:19:05.136057 : nsbal:normal exit
    2008-08-04 16:19:05.136085 : nsiorini:exit (0)
    2008-08-04 16:19:05.136112 : nscpxget:entry
    2008-08-04 16:19:05.136139 : nscpxget:normal exit
    2008-08-04 16:19:05.136168 : nsopenalloc_nsntx:nlhthput on mplx_ht_nsgbu:ctx=81a8538, nsntx=81a8930
    2008-08-04 16:19:05.136196 : nsopenmplx:normal exit
    2008-08-04 16:19:05.136225 : ntpcon:entry
    2008-08-04 16:19:05.136253 : ntpcon:toc = 6
    2008-08-04 16:19:05.136283 : ntpcon:exit
    2008-08-04 16:19:05.136313 : nsopen:opening transport...
    2008-08-04 16:19:05.136341 : ntpcon:entry
    2008-08-04 16:19:05.136367 : ntpcon:toc = 1
    2008-08-04 16:19:05.136404 : sntpcall:entry
    2008-08-04 16:19:05.157048 : sntpcall:detaching from parent with additional fork
    2008-08-04 16:19:05.157304 : sntpcall:hdl[IR]=17, hdl[IW]=16
    2008-08-04 16:19:05.157350 : ntpcon:exit
    2008-08-04 16:19:05.157390 : nserror:entry
    2008-08-04 16:19:05.157428 : nsoptions:entry
    2008-08-04 16:19:05.157459 : nsoptions:lcl[0]=0x0, lcl[1]=0x2006, gbl[0]=0x0, gbl[1]=0x0, cha=0x0
    2008-08-04 16:19:05.157488 : nsoptions:Vectored IO not supported.
    2008-08-04 16:19:05.157518 : nsoptions:lcl[0]=0xf4ffe9ff, lcl[1]=0x6016, gbl[0]=0xe881, gbl[1]=0x0
    2008-08-04 16:19:05.157545 : nsoptions:normal exit
    2008-08-04 16:19:05.157574 : nsnainit:entry
    2008-08-04 16:19:05.157603 : nsnainit:normal exit
    2008-08-04 16:19:05.157642 : nsopen:global context check-in (to slot 6) complete
    2008-08-04 16:19:05.157675 : nsopen:lcl[0]=0xf4ffe9ff, lcl[1]=0x6016, gbl[0]=0xe881, gbl[1]=0x0, tdu=4096, sdu=8192
    2008-08-04 16:19:05.157706 : nsfull_opn:entry
    2008-08-04 16:19:05.157735 : nsfull_opn:cid=6, opcode=65, bl=0, what=0, uflgs=0x0, cflgs=0x0
    2008-08-04 16:19:05.157761 : nsfull_opn:nsctx: state=7, flg=0x4001, mvd=0
    2008-08-04 16:19:05.157790 : nsfull_opn:normal exit
    2008-08-04 16:19:05.157816 : nsopen:normal exit
    2008-08-04 16:19:05.157854 : nsevreg:entry
    2008-08-04 16:19:05.157884 : nsevreg:begin registration process for 6
    2008-08-04 16:19:05.157912 : nsevregPrePost:entry
    2008-08-04 16:19:05.157940 : nsevregPrePost:normal exit
    2008-08-04 16:19:05.157968 : nsevreg:sgt=0, evn=1, evt[2]=0x0
    2008-08-04 16:19:05.157996 : nsevreg:begin notification process for 6
    2008-08-04 16:19:05.158022 : nsevregAffectNotif:entry
    2008-08-04 16:19:05.158050 : nsevregAffectNotif:exit (0)
    2008-08-04 16:19:05.158078 : nsevreg:rdm=0, sgt=0, evt[0]=0x800, [1]=0x800, [2]=0x0, nrg=0
    2008-08-04 16:19:05.158105 : nsevreg:registering for 0x800
    2008-08-04 16:19:05.158135 : ntpctl:entry
    2008-08-04 16:19:05.158162 : ntpctl:exit
    2008-08-04 16:19:05.158203 : nsevreg:normal exit
    2008-08-04 16:19:05.158260 : nsbeqaddr:error exit
    2008-08-04 16:19:05.158289 : nsbequeath:error exit
    2008-08-04 16:19:05.158342 : nsglhe:exit

  • JDBC, SQL*Net wait interface, performance degradation on 10g vs. 9i

    Hi All,
    I came across performance issue that I think results from mis-configuration of something between Oracle and JDBC. The logic of my system executes 12 threads in java. Each thread performs simple 'select a,b,c...f from table_xyz' on different tables. (so I have 12 different tables with cardinality from 3 to 48 millions and one working thread per table).
    In each thread I'm creating result set that is explicitly marked as forward_only, transaction is set read only, fetch size is set to 100000 records. Java logic processes records in standard while(rs.next()) {...} loop.
    I'm experiencing performance degradation between execution on Oracle 9i and Oracle 10g of the same java code, on the same machine, on the same data. The difference is enormous, 9i execution takes 26 hours while 10g execution takes 39 hours.
    I have collected statspack for 9i and awr report for 10g. Below I've enclosed top wait events for 9i and 10g
    ===== 9i ===================
    Avg
    Total Wait wait Waits
    Event Waits Timeouts Time (s) (ms) /txn
    db file sequential read 22,939,988 0 6,240 0 0.7
    control file parallel write 6,152 0 296 48 0.0
    SQL*Net more data to client 2,877,154 0 280 0 0.1
    db file scattered read 26,842 0 91 3 0.0
    log file parallel write 3,528 0 83 23 0.0
    latch free 94,845 0 50 1 0.0
    process startup 93 0 5 50 0.0
    log file sync 34 0 2 46 0.0
    log file switch completion 2 0 0 215 0.0
    db file single write 9 0 0 33 0.0
    control file sequential read 4,912 0 0 0 0.0
    wait list latch free 15 0 0 12 0.0
    LGWR wait for redo copy 84 0 0 1 0.0
    log file single write 2 0 0 18 0.0
    async disk IO 263 0 0 0 0.0
    direct path read 2,058 0 0 0 0.0
    slave TJ process wait 1 1 0 12 0.0
    ===== 10g ==================
    Avg
    %Time Total Wait wait Waits
    Event Waits -outs Time (s) (ms) /txn
    db file scattered read 268,314 .0 2,776 10 0.0
    SQL*Net message to client 278,082,276 .0 813 0 7.1
    io done 20,715 .0 457 22 0.0
    control file parallel write 10,971 .0 336 31 0.0
    db file parallel write 15,904 .0 294 18 0.0
    db file sequential read 66,266 .0 257 4 0.0
    log file parallel write 3,510 .0 145 41 0.0
    SQL*Net more data to client 2,221,521 .0 102 0 0.1
    SGA: allocation forcing comp 2,489 99.9 27 11 0.0
    log file sync 564 .0 23 41 0.0
    os thread startup 176 4.0 19 106 0.0
    latch: shared pool 372 .0 11 29 0.0
    latch: library cache 537 .0 5 10 0.0
    rdbms ipc reply 57 .0 3 49 0.0
    log file switch completion 5 40.0 3 552 0.0
    latch free 4,141 .0 2 0 0.0
    I put full blame for the slowdown on SQL*Net message to client wait event. All I could find about this event is that it is a network related problem. I assume it would be true if database and client were on different machines.. However in my case they are on them very same machine.
    I'd be very very grateful if someone could point me in the right direction, i.e. give a hint what statistics should I analyze further? what might cause this event to appear? why probable cause (that is said be outside db) affects only 10g instance?
    Thanks in advance,
    Rafi.

    Hi Steven,
    Thanks for the input. It's a fact that I did not gather statistics on my tables. My understanding is that statistics are useful for queries more complex than simple select * from table_xxx. In my case tables don't have indexes. There's no filtering condition as well. Full table scan is what I actually want as all software logic is inside the java code.
    Explain plans are as follows:
    ======= 10g ================================
    PLAN_TABLE_OUTPUT
    Plan hash value: 1141003974
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 259 | 2 (0)| 00:00:01 |
    | 1 | TABLE ACCESS FULL| xxx | 1 | 259 | 2 (0)| 00:00:01 |
    In sqlplus I get:
    SQL> set autotrace traceonly explain statistics;
    SQL> select * from xxx;
    36184384 rows selected.
    Elapsed: 00:38:44.35
    Execution Plan
    Plan hash value: 1141003974
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 259 | 2 (0)| 00:00:01 |
    | 1 | TABLE ACCESS FULL| xxx | 1 | 259 | 2 (0)| 00:00:01 |
    Statistics
    1 recursive calls
    0 db block gets
    3339240 consistent gets
    981517 physical reads
    116 redo size
    26535700 bytes received via SQL*Net from client
    2412294 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    36184384 rows processed
    ======= 9i =================================
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | | | |
    | 1 | TABLE ACCESS FULL | xxx | | | |
    Note: rule based optimization
    In sqlplus I get:
    SQL> set autotrace traceonly explain statistics;
    SQL> select * from xxx;
    36184384 rows selected.
    Elapsed: 00:17:43.06
    Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE
    1 0 TABLE ACCESS (FULL) OF 'xxx'
    Statistics
    0 recursive calls
    1 db block gets
    3306118 consistent gets
    957515 physical reads
    100 redo size
    23659424 bytes sent via SQL*Net to client
    26535867 bytes received via SQL*Net from client
    2412294 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    36184384 rows processed
    Thanks for pointing me difference in table scans. I infer that 9i is doing single-block full table scan (db file sequential read) while 10g is using multi-block full table scan (db file scattered read).
    I now have theory that 9i is faster because sequential reads use continuous buffer space while scattered reads use discontinuous buffer space. Since I'm accessing data 'row by row' in jdbc 10g might have an overhead in providing data from discontinuous buffer space. This overhead shows itself as SQL*Net message to client wait. Is that making any sense?
    Is there any way I could force 10g (i.e. with hint) to use sequential reads instead of scattered reads for full table scan?
    I'll experiment with FTS tuning in 10g by enabling automatic multi-block reads tuning (i.e. db_file_multiblock_read_count=0 instead of 32 as it is now). I'll also check if response time improves after statistics are gathered.
    Please advice if you have any other ideas.
    Thanks & regards,
    Rafi.

  • WINDOWS 용 SQL*NET V1 사용 시 ORA-6136 조치 방법

    제품 : SQL*NET
    작성날짜 : 1995-11-07
    WINDOWS 용 SQL*NET V1 사용 시 ORA-6136 조치 방법
    ===============================================
    Client and Server 환경에서 간혹 SQL*NET으로 Server에 접속하려고 할 때,
    ORA-6136 Error가 발생하면서 Unix Server에서 $tcpctl stop 으로 orasrv의
    Process를 정지시키려고 해도 아무런 반응없이 Holding되는 경우가 발생하면서
    다음과 같은 메서지가 나타납니다.
    06136, 00000, "NETTCP: error during connection handshake"
    // *Cause:  Network I/O failure occurred while communicating with the
    // host's SQL*Net TCP/IP server.
    //     See the SQL*Net TCP/IP server log file for more details.
    // *Action: Contact your customer support representative.
    상기의 에러가 나타날 경우에는 아래와 같은 방법으로 orasrv를 기동시키십시오.
    1. TCPCTL Utility를 이용하여 다음의 Option을 부여하여 Start하는 방법.
    $tcpctl start listen=30 timeout=30 forkon
    listen=<queue size>이며, 청취자 열의 크기를 지정.
    timeout=<seconds>이며, 지정된 시간에 orasrv와의 응답 확인 시간을 나타냄.
    forkon SQL*net이 orasrv process에 접근하는 방법을 나타냄.
    System에 따라서 forkon option이 적용 않되는 경우도 있음.
    2. Client에서 접속을 하여 사용하다가 비정상 종료(Session이 맺어진 상태에서
    Client의 Power Off)를 하여 Server에 Processor가 남아 있고, orasrv를 통해
    접속할 수 있는 Session의 수가 점점 줄어들 경우가 있는 데 이러한 경우에는
    orasrv를(tcpctl stop or UNIX kill command를 이용)강제로 종료하시고 다음과
    같이 Start 시켜 주십시오.
    #nohup tcpctl start ( Client의 비정상 종료가 Orasrv에는 영향을 미치지 않음)
    또는
    #orasrv (ORACLE_HOME\bin directory에서 직접 orasrv processor를 띄운다)

  • High SQL*Net message values in trace file.

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

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

  • SQL*NET waits in trace file

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

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

  • SQL net easy configuration

    I can't connect Developer 2000 at a client site with the Database on th Server:
    AFTER INSTALLING THE DEVELOPER 2000 R2.1 ON THE CLIENT MACHINE(WIN 98),
    I NEED TO CONNECT HIM TO THE ORACLE DATABASE(ORACLE 8 ENTERPRISE EDITION)
    ON THE SERVER(WINNT),
    I DEFINED THE FOLLOWING SERVICE (DB ALIAS) ON THE ORACLE SERVER(TNSNAMES.ORA):
    XXX.WORLD =
    (DESCRIPTION =
    (ADDRESS =
    (PROTOCOL = TCP)
    (HOST = 3.1.1.1)
    (PORT = 1521)
    (CONNECT_DATA = (SID = ORCL)
    WHAT I DID WAS THAT I WENT TO SQL NET EASY CONFIGURATION, AT CLIENT MACHINE
    AND SELECT TO ADD DATABASE ALIAS,
    THEN I ENTERED THE DB ALIAS NAME: KOKO (FOR EXAMPLE)
    THEN I ENTERED THE TCP\IP ADDRESS OF THE SERVER: 3.1.1.1,
    THEN I ENTERED THE DATA BASE INSTANCE : ORCL,
    THEN I CONFIRMED THE OPERATION AND EXIT THE SQL NET EASY CONFIGURATION.
    THEN I WENT TO THE TNSNAMES.ORA FILE, AND CHECK FOR THE DEFININTION, AND IT
    WAS OK. AND AS FOLLOWS:
    KOKO.WORLD =
    (DESCRIPTION =
    (ADDRESS_LIST =
    (ADDRESS =
    (COMMUNITY = TCP.WORLD)
    (PROTOCOL = TCP)
    (HOST = 3.1.1.1)
    (PORT = 1521)
    (ADDRESS =
    (COMMUNITY = TCP.WORLD)
    (PROTOCOL = TCP)
    (HOST = 3.1.1.1)
    (PORT = 1526)
    (CONNECT_DATA = (SID = ORCL)
    THEN I TRYED TO CONNECT TO THE DATABASE USING SQLPLUS8 FROM THE USER MACHINE,
    BUT I GET THIS ERR MSG;
    ERROR:
    ORA-12154: TNS:COULD NOT RESOLVE SERVICE NAME
    I TRYED TO GO TO ORACLE REGISTRY FILE AND ADD A STRING LOCAL: XXX
    THIS XXX IS THE NAME OF THE DATABASE ALIAS ON THE SERVER.
    AFTER THAT I TRYED TO CONNECT TO THE DATABSE, AND I GOT THE SAME ERR MSG:
    ERROR MSG:
    ERROR:
    ORA-12154: TNS:COULD NOT RESOLVE SERVICE NAME
    IF YOU HAVE AN IDEA, I WILL APPRECIATE SHARING IT.
    null

    hi,
    If you are installing D2K on '98 please insure the following:
    1. does the cient machine have orawin95/98 folder?
    2. In orawin95/net80/admin you said you have TNSNAMES.ORA but do you also have SQLNET.ORA with a proper configuration pointing to TNSNAMES.ORA?
    Tushar

  • SQL Net Problem

    I am trying to connect from an Oracle client 9i-V1 to an Oracle server 8i-V3 over the internet and through MS ISA Firwall , tnsping is working correctly and returing latency as between 250 and 330 M/Second.
    When trying to connect using SQL+ I get ORA-12535 despite that I have adjusted the CONNECT_TIMEOUT on the listener and reloaded it , I have adjusted the parameter to 0 but still getting the error.
    We are running Oracle Apps 11i from the same location using the same internet line and its working at a remarkable speed , also all the required ports are opened and secured on the firewall.
    Could you advise something.

    These two waits in your statspack report:
    SQL*Net more data from dblink
    SQL*Net message from dblink
    refer to a database link. (A connection between this database and another database.)
    http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref4564
    It looks like a lot if the time during that snapshot was consumed waiting for data over the database link.
    It looks like that would be the place to look for improvements.
    The SQL*Net more data to client wait was only a tiny percentage.

  • Oracle - Informatica transfer speed fetch size and SQL*Net message from c

    Hi,
    I'm testing how fast informatica can take data from our 10.2.0.3 and using large (140GB 1 200 000 000 rows) table as source and doing simple
    select * from large_table .
    Here goes quite interesting wait time analyze :) .
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch   186994    131.84     198.25     127545     314167          0    25431184
    total   186994    131.84     198.25     127545     314167          0    25431184
    Misses in library cache during parse: 0
    Parsing user id: 400
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file scattered read                       9122        0.33         64.71
      SQL*Net more data to client                529327        0.00          8.34
      SQL*Net message from client                186994        0.21        478.74
      SQL*Net message to client                  186994        0.00          0.30
      db file sequential read                       145        0.01          0.49
      gc cr multi block request                    6998        0.01          6.30
      gc current grant 2-way                          9        0.00          0.00
      gc cr grant 2-way                              67        0.00          0.03The interesting part is ' SQL*Net message from client 186994 0.21 478.74'
    so looks like from Informaticka point of view (client side) is lagging 478 sec , so its lagging .
    Doing some math 25431184/186994 = 136 .
    Could You share with me Your experience in that matter ?
    Looks like to speed up I need to :
    1. increase fetch size (not sure how to do that).
    2. increase SDU client and probably server side .
    Network is 100Mbit ethernet so about 10MBytes per second .
    Regards
    GregG

    Have you solve your problem ?
    If yes I'm strongly interest by the solution.
    If you have a question of issue create your own thread and provide the particulars of your use case. This thread is year old.
    OP likely did NOT have any problem. As OP stated the max throughput for a 100 Mbit network is about 10 MB per second. So do the math for moving 140 GB and you will see that the network itself will be the limiting factor.

  • 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

  • SQL*Net message from client - huge wait in trace file

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

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

Maybe you are looking for