FAQ
Greetings.

This was something that happened today in one of the database and I am
looking for list's
response on this. This is a Oracle 9.2.0.7 database running solaris 9.

Around 10am the Unix group called me and told me that one of the osprocess
is taking more cputime
then what it normally takes. and upon investigation I found that this
database was running on
shared server mode with the osprocess being the only dispatcher at that
time . So I created another
3 dispatcher and stopped the existing dispatcher d000.

and everything was going fine until 2.30pm when the user called me and told
me that he is not able to
make connection using servicename. so I did a test

test1- sqlplus '/as sysdba'
test2- sqlplus scott/tiger
test3- sqlplus scott/tiger_at_tnsname

I was able to logon to database successfully with test1 and test2 . However
when I did test3
it just hangs and it didnt allow me to interrupt it also.

I checked if the dispatchers were busy or not and didnt found anything
significant.
The listener logging was not enabled so the initial reaction was to shutdown
and start the
listener which I did and at this time the test3 worked fine . However the
user was still not able to
access its application and I observed a large number of session in
dba_blocker and dba_waiter
and also few deadlock error in alert log file . So I killed the session on
the beginning of the queue
and it immediately releases all the sessions in dba_blockers and dba_waiters
and the user was
able to access the application.

Here comes the hard part what is the root cause of this issue?

Please advise.

Thanks
-Prasad

Search Discussions

  • Jack van Zanen at Apr 17, 2008 at 5:54 am
    maybe check the size of your listener.log file

    I have seen occasions where a large log file saw this behaviour

    Jack
    On 17/04/2008, Prasad wrote:

    Greetings.

    This was something that happened today in one of the database and I am
    looking for list's
    response on this. This is a Oracle 9.2.0.7 database running solaris 9.

    Around 10am the Unix group called me and told me that one of the osprocess
    is taking more cputime
    then what it normally takes. and upon investigation I found that this
    database was running on
    shared server mode with the osprocess being the only dispatcher at that
    time . So I created another
    3 dispatcher and stopped the existing dispatcher d000.

    and everything was going fine until 2.30pm when the user called me and
    told me that he is not able to
    make connection using servicename. so I did a test

    test1- sqlplus '/as sysdba'
    test2- sqlplus scott/tiger
    test3- sqlplus scott/tiger_at_tnsname


    I was able to logon to database successfully with test1 and test2 .
    However when I did test3
    it just hangs and it didnt allow me to interrupt it also.

    I checked if the dispatchers were busy or not and didnt found anything
    significant.
    The listener logging was not enabled so the initial reaction was to
    shutdown and start the
    listener which I did and at this time the test3 worked fine . However the
    user was still not able to
    access its application and I observed a large number of session in
    dba_blocker and dba_waiter
    and also few deadlock error in alert log file . So I killed the session on
    the beginning of the queue
    and it immediately releases all the sessions in dba_blockers and
    dba_waiters and the user was
    able to access the application.

    Here comes the hard part what is the root cause of this issue?

    Please advise.

    Thanks
    -Prasad
    --
    J.A. van Zanen

    --
    http://www.freelists.org/webpage/oracle-l
  • David cheyne at Apr 17, 2008 at 10:09 am
    Prasad,

    You say that the listener log was not enabled. Have you switched off the
    logging or was it not updating? You don't say which O/S your on, but you
    can easily automate its management.

    Without bringing the listener down on Unix/Linux:

    cp listener.log listener.OLD
    cat /dev/null > listener.log

    This copies the log to another name and blanks the current log. You just
    may need to watch disk space if your keeping multiple copies (tar/zip?)

    David Cheyne
    On 17/04/2008, Jack van Zanen wrote:

    maybe check the size of your listener.log file

    I have seen occasions where a large log file saw this behaviour

    Jack

    On 17/04/2008, Prasad wrote:

    Greetings.

    This was something that happened today in one of the database and I am
    looking for list's
    response on this. This is a Oracle 9.2.0.7 database running solaris 9.

    Around 10am the Unix group called me and told me that one of the
    osprocess is taking more cputime
    then what it normally takes. and upon investigation I found that this
    database was running on
    shared server mode with the osprocess being the only dispatcher at that
    time . So I created another
    3 dispatcher and stopped the existing dispatcher d000.

    and everything was going fine until 2.30pm when the user called me and
    told me that he is not able to
    make connection using servicename. so I did a test

    test1- sqlplus '/as sysdba'
    test2- sqlplus scott/tiger
    test3- sqlplus scott/tiger_at_tnsname


    I was able to logon to database successfully with test1 and test2 .
    However when I did test3
    it just hangs and it didnt allow me to interrupt it also.

    I checked if the dispatchers were busy or not and didnt found anything
    significant.
    The listener logging was not enabled so the initial reaction was to
    shutdown and start the
    listener which I did and at this time the test3 worked fine . However
    the user was still not able to
    access its application and I observed a large number of session in
    dba_blocker and dba_waiter
    and also few deadlock error in alert log file . So I killed the session
    on the beginning of the queue
    and it immediately releases all the sessions in dba_blockers and
    dba_waiters and the user was
    able to access the application.

    Here comes the hard part what is the root cause of this issue?

    Please advise.

    Thanks
    -Prasad


    --
    J.A. van Zanen
    --
    ~~~~~~~~~~~~~~~~~~~~~~~
    David Cheyne
    BA(hons.)
    Oracle Database Administrator

    -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too
    dark to read.
    Groucho Marx

    --
    http://www.freelists.org/webpage/oracle-l
  • Prasad at Apr 17, 2008 at 11:57 am
    Hi David/Jack,

    Listener Logging was switched off on this database . This is a solaris 9
    server .

    Thanks
    Prasad

    On Thu, Apr 17, 2008 at 3:09 AM, David cheyne
    wrote:
    Prasad,

    You say that the listener log was not enabled. Have you switched off the
    logging or was it not updating? You don't say which O/S your on, but you
    can easily automate its management.

    Without bringing the listener down on Unix/Linux:

    cp listener.log listener.OLD
    cat /dev/null > listener.log

    This copies the log to another name and blanks the current log. You just
    may need to watch disk space if your keeping multiple copies (tar/zip?)



    David Cheyne

    On 17/04/2008, Jack van Zanen wrote:

    maybe check the size of your listener.log file

    I have seen occasions where a large log file saw this behaviour

    Jack

    On 17/04/2008, Prasad wrote:

    Greetings.

    This was something that happened today in one of the database and I am
    looking for list's
    response on this. This is a Oracle 9.2.0.7 database running solaris 9.

    Around 10am the Unix group called me and told me that one of the
    osprocess is taking more cputime
    then what it normally takes. and upon investigation I found that this
    database was running on
    shared server mode with the osprocess being the only dispatcher at
    that time . So I created another
    3 dispatcher and stopped the existing dispatcher d000.

    and everything was going fine until 2.30pm when the user called me and
    told me that he is not able to
    make connection using servicename. so I did a test

    test1- sqlplus '/as sysdba'
    test2- sqlplus scott/tiger
    test3- sqlplus scott/tiger_at_tnsname


    I was able to logon to database successfully with test1 and test2 .
    However when I did test3
    it just hangs and it didnt allow me to interrupt it also.

    I checked if the dispatchers were busy or not and didnt found
    anything significant.
    The listener logging was not enabled so the initial reaction was to
    shutdown and start the
    listener which I did and at this time the test3 worked fine . However
    the user was still not able to
    access its application and I observed a large number of session in
    dba_blocker and dba_waiter
    and also few deadlock error in alert log file . So I killed the
    session on the beginning of the queue
    and it immediately releases all the sessions in dba_blockers and
    dba_waiters and the user was
    able to access the application.

    Here comes the hard part what is the root cause of this issue?

    Please advise.

    Thanks
    -Prasad


    --
    J.A. van Zanen



    --
    ~~~~~~~~~~~~~~~~~~~~~~~
    David Cheyne
    BA(hons.)
    Oracle Database Administrator

    -- Outside of a dog, a book is a man's best friend. Inside of a dog it's
    too dark to read.
    Groucho Marx
    --
    http://www.freelists.org/webpage/oracle-l
  • Krish.hariharan_at_quasardb.com at Apr 18, 2008 at 3:13 am
    Prasad,



    A long shot, and perhaps as a process of elimination:



    Do you have any logon triggers (I am not sure personally, if the
    logon trigger fires before acknowledgement it sent back to the client)
    As perhaps a consequence, I wonder if you reached the max sessions
    per dispatchers and max dispatchers and got blocked

    Again a longshot given that things cleared up when you killed the session in
    the beginning of the queue



    -Krish



    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Prasad
    Sent: Thursday, April 17, 2008 5:57 AM
    To: David cheyne
    Cc: ORACLE-L
    Subject: Re: sqlplus scott/tiger_at_tnsname hangs



    Hi David/Jack,

    Listener Logging was switched off on this database . This is a solaris 9
    server .

    Thanks
    Prasad

    On Thu, Apr 17, 2008 at 3:09 AM, David cheyne
    wrote:

    Prasad,



    You say that the listener log was not enabled. Have you switched off the
    logging or was it not updating? You don't say which O/S your on, but you
    can easily automate its management.



    Without bringing the listener down on Unix/Linux:



    cp listener.log listener.OLD

    cat /dev/null > listener.log


    This copies the log to another name and blanks the current log. You just
    may need to watch disk space if your keeping multiple copies (tar/zip?)







    David Cheyne





    On 17/04/2008, Jack van Zanen wrote:

    maybe check the size of your listener.log file



    I have seen occasions where a large log file saw this behaviour



    Jack



    On 17/04/2008, Prasad wrote:

    Greetings.

    This was something that happened today in one of the database and I am
    looking for list's
    response on this. This is a Oracle 9.2.0.7 <http://9.2.0.7/> database
    running solaris 9.

    Around 10am the Unix group called me and told me that one of the osprocess
    is taking more cputime
    then what it normally takes. and upon investigation I found that this
    database was running on
    shared server mode with the osprocess being the only dispatcher at that
    time . So I created another
    3 dispatcher and stopped the existing dispatcher d000.

    and everything was going fine until 2.30pm when the user called me and told
    me that he is not able to
    make connection using servicename. so I did a test

    test1- sqlplus '/as sysdba'
    test2- sqlplus scott/tiger
    test3- sqlplus scott/tiger_at_tnsname

    I was able to logon to database successfully with test1 and test2 . However
    when I did test3
    it just hangs and it didnt allow me to interrupt it also.

    I checked if the dispatchers were busy or not and didnt found anything
    significant.
    The listener logging was not enabled so the initial reaction was to shutdown
    and start the
    listener which I did and at this time the test3 worked fine . However the
    user was still not able to
    access its application and I observed a large number of session in
    dba_blocker and dba_waiter
    and also few deadlock error in alert log file . So I killed the session on
    the beginning of the queue
    and it immediately releases all the sessions in dba_blockers and dba_waiters
    and the user was
    able to access the application.

    Here comes the hard part what is the root cause of this issue?

    Please advise.

    Thanks
    -Prasad

    --
    J.A. van Zanen

    --

    David Cheyne
    BA(hons.)
    Oracle Database Administrator

    Outside of a dog, a book is a man's best friend. Inside of a dog it's too
    dark to read.
    Groucho Marx

    --
    http://www.freelists.org/webpage/oracle-l
  • Prasad at Apr 18, 2008 at 9:29 am
    Hi Krish,
    There is no logon triggers on this datbase. and also this database was
    running with 1 dispatcher and i increased it to 4 so it should not maxed
    out. the listener logging was not enabled so i could not get a clear picture
    on this issue.

    thanks
    Prasad
    On Thu, Apr 17, 2008 at 8:13 PM, wrote:

    Prasad,



    A long shot, and perhaps as a process of elimination:



    1. Do you have any logon triggers (I am not sure personally, if the
    logon trigger fires before acknowledgement it sent back to the client)
    2. As perhaps a consequence, I wonder if you reached the max
    sessions per dispatchers and max dispatchers and got blocked



    Again a longshot given that things cleared up when you killed the session
    in the beginning of the queue



    -Krish


    ------------------------------

    *From:* oracle-l-bounce_at_freelists.org [mailto:
    oracle-l-bounce@freelists.org] *On Behalf Of *Prasad
    *Sent:* Thursday, April 17, 2008 5:57 AM
    *To:* David cheyne
    *Cc:* ORACLE-L
    *Subject:* Re: sqlplus scott/tiger_at_tnsname hangs



    Hi David/Jack,

    Listener Logging was switched off on this database . This is a solaris 9
    server .

    Thanks
    Prasad

    On Thu, Apr 17, 2008 at 3:09 AM, David cheyne
    wrote:

    Prasad,



    You say that the listener log was not enabled. Have you switched off the
    logging or was it not updating? You don't say which O/S your on, but you
    can easily automate its management.



    Without bringing the listener down on Unix/Linux:



    cp listener.log listener.OLD

    cat /dev/null > listener.log


    This copies the log to another name and blanks the current log. You just
    may need to watch disk space if your keeping multiple copies (tar/zip?)







    David Cheyne





    On 17/04/2008, *Jack van Zanen* wrote:

    maybe check the size of your listener.log file



    I have seen occasions where a large log file saw this behaviour



    Jack



    On 17/04/2008, *Prasad* wrote:

    Greetings.

    This was something that happened today in one of the database and I am
    looking for list's
    response on this. This is a Oracle 9.2.0.7 database running solaris 9.

    Around 10am the Unix group called me and told me that one of the osprocess
    is taking more cputime
    then what it normally takes. and upon investigation I found that this
    database was running on
    shared server mode with the osprocess being the only dispatcher at that
    time . So I created another
    3 dispatcher and stopped the existing dispatcher d000.

    and everything was going fine until 2.30pm when the user called me and
    told me that he is not able to
    make connection using servicename. so I did a test

    test1- sqlplus '/as sysdba'
    test2- sqlplus scott/tiger
    test3- sqlplus scott/tiger_at_tnsname


    I was able to logon to database successfully with test1 and test2 .
    However when I did test3
    it just hangs and it didnt allow me to interrupt it also.

    I checked if the dispatchers were busy or not and didnt found anything
    significant.
    The listener logging was not enabled so the initial reaction was to
    shutdown and start the
    listener which I did and at this time the test3 worked fine . However the
    user was still not able to
    access its application and I observed a large number of session in
    dba_blocker and dba_waiter
    and also few deadlock error in alert log file . So I killed the session on
    the beginning of the queue
    and it immediately releases all the sessions in dba_blockers and
    dba_waiters and the user was
    able to access the application.

    Here comes the hard part what is the root cause of this issue?

    Please advise.

    Thanks
    -Prasad



    --
    J.A. van Zanen



    --
    ~~~~~~~~~~~~~~~~~~~~~~~
    David Cheyne
    BA(hons.)
    Oracle Database Administrator

    -- Outside of a dog, a book is a man's best friend. Inside of a dog it's
    too dark to read.
    Groucho Marx

    --
    http://www.freelists.org/webpage/oracle-l
  • Dan Norris at Apr 18, 2008 at 11:26 pm
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

    If restarting the listener "fixed" the problem, then I'd have to
    believe that your issue was either related to networking issues on the
    DB server, the listener process somehow became unresponsive, or your
    dispatcher(s) became unresponsive. The only way to investigate would be
    to reproduce the issue with SQL*Net tracing on (trace_level_client=16)
    and see what's in the trace.
    It might also be interesting to know how many connection requests the
    listener is servicing. I suppose it's possible that the tcp queuedepth
    is too small to handle all the requests if there some some sort of a
    login storm or something. Without listener logging enabled, you'd only
    be able to check v$sysstat (where name = 'logons cumulative')
    periodically to see how many logins are occurring. Statspack should
    also be gathering that information, so consult there for historical
    purposes.
    Dan
    Prasad wrote:

    On 17/04/2008, Prasad
    wrote:
    Greetings.

    This was something that happened today in one of the database and I am
    looking
    for list's
    response on this. This is a Oracle 9.2.0.7
    database running solaris 9.

    Around 10am the Unix group called me and told me that one of the
    osprocess is
    taking more cputime
    then what it normally takes. and upon investigation I found that this
    database
    was running on
    shared server mode with the  osprocess being the only dispatcher at
    that
    time . So I created another
    3 dispatcher and stopped the existing dispatcher d000.

    and everything was going fine until 2.30pm when the user called me and
    told me
    that he is not able to
    make connection  using servicename. so I did a test

    test1- sqlplus '/as sysdba'
    test2- sqlplus scott/tiger
    test3- sqlplus scott/tiger@tnsname

    I was able to logon to database successfully with test1 and test2 .
    However
    when I did test3
    it just hangs and it didnt allow me to interrupt it also.

    I checked if the dispatchers were busy or not  and didnt found anything
    significant.
    The listener logging was not enabled so the initial reaction was to
    shutdown
    and start the
    listener which I did and at this time the test3 worked fine . However
    the user
    was still not able to
    access its application and I observed a large number of session in
    dba_blocker
    and dba_waiter
    and also few deadlock error in alert log file . So I killed the session
    on the
    beginning of the queue
    and it immediately releases all the sessions in dba_blockers and
    dba_waiters
    and the user was
    able to access the application.

    Here comes the hard part what is the root cause of this issue?

    Please advise.

    Thanks
    -Prasad
  • Prasad at Apr 19, 2008 at 3:55 am
    Thanks Dan/Krish .

    I was not able to get any valuable info so far . For time being I have
    suggested to enable the listener logging with trace_level_client=16 and wait
    for the next occurrance. I heard that they have a similar issue before 2
    months . so hopefully I will be able to catch it the next time by following
    both of your suggestion..

    Thanks
    -Prasad
    On Fri, Apr 18, 2008 at 4:26 PM, Dan Norris wrote:

    If restarting the listener "fixed" the problem, then I'd have to believe
    that your issue was either related to networking issues on the DB server,
    the listener process somehow became unresponsive, or your dispatcher(s)
    became unresponsive. The only way to investigate would be to reproduce the
    issue with SQL*Net tracing on (trace_level_client=16) and see what's in the
    trace.

    It might also be interesting to know how many connection requests the
    listener is servicing. I suppose it's possible that the tcp queuedepth is
    too small to handle all the requests if there some some sort of a login
    storm or something. Without listener logging enabled, you'd only be able to
    check v$sysstat (where name = 'logons cumulative') periodically to see how
    many logins are occurring. Statspack should also be gathering that
    information, so consult there for historical purposes.

    Dan


    Prasad wrote:
    On 17/04/2008, *Prasad* wrote:

    Greetings.

    This was something that happened today in one of the database and I am
    looking for list's
    response on this. This is a Oracle 9.2.0.7 database running solaris 9.

    Around 10am the Unix group called me and told me that one of the
    osprocess is taking more cputime
    then what it normally takes. and upon investigation I found that this
    database was running on
    shared server mode with the osprocess being the only dispatcher at that
    time . So I created another
    3 dispatcher and stopped the existing dispatcher d000.

    and everything was going fine until 2.30pm when the user called me and
    told me that he is not able to
    make connection using servicename. so I did a test

    test1- sqlplus '/as sysdba'
    test2- sqlplus scott/tiger
    test3- sqlplus scott/tiger_at_tnsname


    I was able to logon to database successfully with test1 and test2 .
    However when I did test3
    it just hangs and it didnt allow me to interrupt it also.

    I checked if the dispatchers were busy or not and didnt found anything
    significant.
    The listener logging was not enabled so the initial reaction was to
    shutdown and start the
    listener which I did and at this time the test3 worked fine . However
    the user was still not able to
    access its application and I observed a large number of session in
    dba_blocker and dba_waiter
    and also few deadlock error in alert log file . So I killed the session
    on the beginning of the queue
    and it immediately releases all the sessions in dba_blockers and
    dba_waiters and the user was
    able to access the application.

    Here comes the hard part what is the root cause of this issue?

    Please advise.

    Thanks
    -Prasad
    --
    http://www.freelists.org/webpage/oracle-l
  • Dan Norris at Apr 19, 2008 at 5:14 am
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

    Careful--I wouldn't enable trace until you know you can reproduce the
    issue. Too much logging will not only affect performance, but if it
    isn't managed, it can create a denial of service if a filesystem fills
    or the listener is too busy logging to service requests.
    I'll be interested in your results if/when you do get to dig deeper
    into diagnosis.
    Dan
    Prasad wrote:
    Thanks Dan/Krish .

    I was not able to get any valuable info so far . For time being I have
    suggested to enable the listener logging with trace_level_client=16 and
    wait for the next occurrance. I heard that they have a similar issue
    before 2 months . so hopefully I will be able to catch  it the next
    time by following both of your suggestion..

    Thanks
    -Prasad

    On Fri, Apr 18, 2008 at 4:26 PM, Dan Norris
    wrote:

    If restarting the listener
    "fixed" the problem, then I'd have to
    believe that your issue was either related to networking issues on the
    DB server, the listener process somehow became unresponsive, or your
    dispatcher(s) became unresponsive. The only way to investigate would be
    to reproduce the issue with SQL*Net tracing on (trace_level_client=16)
    and see what's in the trace.

    It might also be interesting to know how many connection requests the
    listener is servicing. I suppose it's possible that the tcp queuedepth
    is too small to handle all the requests if there some some sort of a
    login storm or something. Without listener logging enabled, you'd only
    be able to check v$sysstat (where name = 'logons cumulative')
    periodically to see how many logins are occurring. Statspack should
    also be gathering that information, so consult there for historical
    purposes.

    Dan

    Prasad wrote:

    On 17/04/2008, Prasad
    wrote:
    Greetings.

    This was something that happened today in one of the database and I am
    looking
    for list's
    response on this. This is a Oracle 9.2.0.7
    database running solaris 9.

    Around 10am the Unix group called me and told me that one of the
    osprocess is
    taking more cputime
    then what it normally takes. and upon investigation I found that this
    database
    was running on
    shared server mode with the  osprocess being the only dispatcher at
    that
    time . So I created another
    3 dispatcher and stopped the existing dispatcher d000.

    and everything was going fine until 2.30pm when the user called me and
    told me
    that he is not able to
    make connection  using servicename. so I did a test

    test1- sqlplus '/as sysdba'
    test2- sqlplus scott/tiger
    test3- sqlplus scott/tiger@tnsname

    I was able to logon to database successfully with test1 and test2 .
    However
    when I did test3
    it just hangs and it didnt allow me to interrupt it also.

    I checked if the dispatchers were busy or not  and didnt found anything
    significant.
    The listener logging was not enabled so the initial reaction was to
    shutdown
    and start the
    listener which I did and at this time the test3 worked fine . However
    the user
    was still not able to
    access its application and I observed a large number of session in
    dba_blocker
    and dba_waiter
    and also few deadlock error in alert log file . So I killed the session
    on the
    beginning of the queue
    and it immediately releases all the sessions in dba_blockers and
    dba_waiters
    and the user was
    able to access the application.

    Here comes the hard part what is the root cause of this issue?

    Please advise.

    Thanks
    -Prasad
  • Jared Still at Apr 21, 2008 at 5:40 pm

    On Fri, Apr 18, 2008 at 4:26 PM, Dan Norris wrote:
    It might also be interesting to know how many connection requests the
    listener is servicing. I suppose it's possible that the tcp queuedepth is
    too small to handle all the requests if there some some sort of a login
    storm or something. Without listener logging enabled, you'd only be able to
    check v$sysstat (where name = 'logons cumulative') periodically to see how
    many logins are occurring. Statspack should also be gathering that
    information, so consult there for historical purposes.
    In regards to the thought on TCP, this is from the OP:

    test1- sqlplus '/as sysdba'
    test2- sqlplus scott/tiger
    test3- sqlplus scott/tiger_at_tnsname

    It would appear that these login attempts are taking place on the server.

    If that is the case, is this connection via TCP, or IPC?

    Doing a tnsping from the box you are testing on will show that.

    Is this the same box the user was trying to connect from?

    Also, as you are on solaris, have you done a truss on the the sqlplus
    session?

    That would show what is happening when the connection appears to hang.

    --
    Jared Still
    Certifiable Oracle DBA and Part Time Perl Evangelist

    --
    http://www.freelists.org/webpage/oracle-l
  • Yong Huang at Apr 19, 2008 at 8:41 pm
    Prasad,

    Did you get any TNS- or ORA- errors in the listener log during the period
    SQL*Net and application couldn't login? I remember we had similar issues a few
    times during logon storm and saw

    TNS-12518: TNS:listener could not hand off client connection
    TNS-12540: TNS:internal limit restriction exceeded

    We restarted the listener and it went away. Never completely figured out the
    root cause. It was shared server config on 9.2.0.5 Solaris. I suspect the
    listener process file descriptor limit was reached. But we didn't check the
    descriptors opened during the crisis.

    Yong Huang

    Be a better friend, newshound, and
    know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
  • Jared Still at Apr 23, 2008 at 12:51 am

    On Mon, Apr 21, 2008 at 5:47 PM, Prasad wrote:
    virtual circuit buffers 34,514,923
    virtual circuit queues 15,313,379
    virtual circuits 7,641,167

    logon cumulative doesnt show very high

    logons cumulative 1,382 0.2 0.0
    Sorry, I don't know too much about shared servers.

    I also don't know over what period of time the VC stats took place.

    Without the time component, and an indication that the shared servers
    are the bottleneck, it's rather difficult to make any statement about it.

    Does your database have a very large number of simultaneous connections?

    Just curious why shared servers are being used.

    --
    Jared Still
    Certifiable Oracle DBA and Part Time Perl Evangelist
    --
    http://www.freelists.org/webpage/oracle-l
  • Prasad at Apr 24, 2008 at 2:29 am
    Thanks Jared. As you mentioned this is one of the Bank's high hitter
    application. I tried to find out why the database is running on shared
    server mode but could not find any answer from the people who are managing
    the database . opened a SR but the support wants me to trace a event on the
    next occurrance and get back to me . which may not be a small wait . so I
    will just keep my fingers crossed until the next occurrance.
    On Tue, Apr 22, 2008 at 5:51 PM, Jared Still wrote:
    On Mon, Apr 21, 2008 at 5:47 PM, Prasad wrote:

    virtual circuit buffers 34,514,923
    virtual circuit queues 15,313,379
    virtual circuits 7,641,167

    logon cumulative doesnt show very high

    logons cumulative 1,382 0.2 0.0
    Sorry, I don't know too much about shared servers.

    I also don't know over what period of time the VC stats took place.

    Without the time component, and an indication that the shared servers
    are the bottleneck, it's rather difficult to make any statement about it.

    Does your database have a very large number of simultaneous connections?

    Just curious why shared servers are being used.


    --
    Jared Still
    Certifiable Oracle DBA and Part Time Perl Evangelist
    --
    http://www.freelists.org/webpage/oracle-l

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedApr 17, '08 at 4:30a
activeApr 24, '08 at 2:29a
posts13
users7
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase