Grokbase › Groups › Oracle › oracle-l › January 2012
FAQ
Hello,
We are getting 100% waits for "Others' event class for instance 1 and
instance 2 at times in RAC 11.2.0.2.3, 7 nodes environment (Redhat Linux
5).
The ADDM report showing these findings; (see below);

The questions are:

*1- How to identify the root cause of these "other" waits and fix them?*
*2- How to find the default threshold set for these metrics to see it makes
sense to increase the threshold?*
*
*
*
*

Finding 3: Unusual "Other" Wait Event
Impact is 0 active sessions, 4.92% of total activity.
------------------------------------------------
-----
Wait event "IPC send completion sync" in wait class "Other" was consuming
significant database time.

Recommendation 1: Application Analysis
Estimated benefit is 0 active sessions, 4.92% of total activity.
-------------------------------------
---------------------------
Action
Investigate the cause for high "IPC send completion sync" waits. Refer
to Oracle's "Database Reference" for the description of this wait
event.

Symptoms That Led to the Finding:
---------------------------------
Wait class "Other" was consuming significant database time.
Impact is .02 active sessions, 56.98% of total activity.


Finding 4: Unusual "Other" Wait Event
Impact is 0 active sessions, 4.02% of total activity.
--------------------------------------------
---------
Wait event "enq: PS - contention" in wait class "Other" was consuming
significant database time.

Recommendation 1: Application Analysis
Estimated benefit is 0 active sessions, 4.02% of total activity.
-------------------------------------
---------------------------
Action
Investigate the cause for high "enq: PS - contention" waits. Refer to
Oracle's "Database Reference" for the description of this wait event.

Symptoms That Led to the Finding:
---------------------------------
Wait class "Other" was consuming significant da
tabase time.
Impact is .02 active sessions, 56.98% of total activity.

Search Discussions

  • Niall Litchfield at Jan 4, 2012 at 12:34 pm ⇧
    Hi Sidi (?)
    This may sound daft, but are you sure you have a problem? I ask because
    your ADDM extract says - emphasis mine

    Symptoms That Led to the Finding:
    ---------------------------------
    Wait class "Other" was consuming significant database time.
    * Impact is .02 active sessions, 56.98% of total activity. *
    *
    *
    That implies to me that 100% of activity would be 0.035 active sessions -
    that is 1 second of database activity for about every 28 seconds of wall
    clock time. That's a pretty idle RAC node! This is one area where I don't
    like the wording of the ADDM report. I'd prefer

    *Wait class "%S" was consuming a significant share of total database time. *

    Then it would make it clearer that one also has to look at total database
    time in relation to the report period.
    On Wed, Jan 4, 2012 at 12:04 PM, mek s wrote:

    Hello,
    We are getting 100% waits for "Others' event class for instance 1 and
    instance 2 at times in RAC 11.2.0.2.3, 7 nodes environment (Redhat Linux
    5).
    The ADDM report showing these findings; (see below);

    The questions are:

    *1- How to identify the root cause of these "other" waits and fix them?*
    *2- How to find the default threshold set for these metrics to see it makes
    sense to increase the threshold?*
    *
    *
    *
    *

    Finding 3: Unusual "Other" Wait Event
    Impact is 0 active sessions, 4.92% of total activity.
    ------------------------------------------------
    -----
    Wait event "IPC send completion sync" in wait class "Other" was consuming
    significant database time.

    Recommendation 1: Application Analysis
    Estimated benefit is 0 active sessions, 4.92% of total activity.
    -------------------------------------
    ---------------------------
    Action
    Investigate the cause for high "IPC send completion sync" waits. Refer
    to Oracle's "Database Reference" for the description of this wait
    event.

    Symptoms That Led to the Finding:
    ---------------------------------
    Wait class "Other" was consuming significant database time.
    Impact is .02 active sessions, 56.98% of total activity.


    Finding 4: Unusual "Other" Wait Event
    Impact is 0 active sessions, 4.02% of total activity.
    --------------------------------------------
    ---------
    Wait event "enq: PS - contention" in wait class "Other" was consuming
    significant database time.

    Recommendation 1: Application Analysis
    Estimated benefit is 0 active sessions, 4.02% of total activity.
    -------------------------------------
    ---------------------------
    Action
    Investigate the cause for high "enq: PS - contention" waits. Refer to
    Oracle's "Database Reference" for the description of this wait event.

    Symptoms That Led to the Finding:
    ---------------------------------
    Wait class "Other" was consuming significant da
    tabase time.
    Impact is .02 active sessions, 56.98% of total activity.


    --
    http://www.freelists.org/webpage/oracle-l


    --
    Niall Litchfield
    Oracle DBA
    http://www.orawin.info


    --
    http://www.freelists.org/webpage/oracle-l
  • Mek s at Jan 4, 2012 at 12:48 pm ⇧
    Thanks very much Niall, ; this is a recently installed RAC environment and
    recently pushed in production.
    One more question; How to find the default threshold set for these metrics
    to see it makes sense to increase the threshold?
  • Niall Litchfield at Jan 4, 2012 at 1:31 pm ⇧
    The threshold is set in terms of contributions to the time model statistic
    "db time" which is essentially non-idle database work expressed in seconds
    (active sessions can be thought of as db time per second). There will
    always be some DB Time, and then there will always be a breakdown of that
    activity. I wouldn't be wanting to delve too much into the actual
    thresholds (which is why I don't know what they are off hand) but I
    definitely would be interested in either
    - responding to complaints about poor performance from users in terms of
    "where does the time go"
    - generally ensuring that DB Time per Second is at a reasonable level (
    < n seconds per second where n is the cpu core count is my rule of thumb).

    Rule 1 above trumps rule 2. Always.

    So I wouldn't be changing thresholds, but I would be keeping communication
    channels open with my users and sanity checking ADDM reports against the
    period of time for which they report.

    HTH
    On Wed, Jan 4, 2012 at 12:47 PM, mek s wrote:

    Thanks very much Niall, ; this is a recently installed RAC environment and
    recently pushed in production.
    One more question; How to find the default threshold set for these metrics
    to see it makes sense to increase the threshold?


    --
    Niall Litchfield
    Oracle DBA
    http://www.orawin.info


    --
    http://www.freelists.org/webpage/oracle-l

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedJan 4, '12 at 12:05p
activeJan 4, '12 at 1:31p
posts4
users2
websiteoracle.com

2 users in discussion

Niall Litchfield: 2 posts Mek s: 2 posts

Content

People

Support

Translate

site design / logo © 2022 Grokbase