FAQ
I'm running 11.2.0.2 Patch 10 on Windows x64 and I have a pl/sql procedure that is rather simple, but kept erroring out after some time with an out memory condition.
So, I decided to look and see what it is doing and it is encountering the "library cache: mutex X" event.

Browing Oracle Support, I found the note about it and it says:


* "P3 = "where" = location in code (internal identifier) where mutex is being waited for
@The meaning of the code for "where" can be found by looking in kgl0.h for entries with the prefix ""kglml_XXX". For example, if P3=2, then it corresponds to "kglml_kglget2". You can then search source code for this symbol to see where the mutex is acquired.

Well, that's not very helpful to me since I don't have access to the source code :) I understand that the engineers can use it.

Long story short, I decided to download the 11.2.0.3 patchset.

It is only *4 GIGABYTES*. I'm getting about 170k download speed on my work network so......


Chris Taylor
Sr. Oracle DBA
Ingram Barge Company
Nashville, TN 37205

"Quality is never an accident; it is always the result of intelligent effort."
-- John Ruskin (English Writer 1819-1900)

CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.

Search Discussions

  • Taylor, Chris David at Dec 8, 2011 at 6:13 pm
    Yeah I remembered that about Oracle going to full releases with the latest/greatest patchsets.
    The 'implications' of that decision though hadn't really sank in till today. For each major patchset I will be downloading (or requesting on media) a very large collection of data. And installing new Oracle home for each patchset downloaded.

    The download size is really the only negative in my mind.

    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.

    From: Niall Litchfield
    Sent: Thursday, December 08, 2011 12:04 PM
    To: Taylor, Chris David
    Cc: oracle-l@freelists.org
    Subject: Re: Fun with WAIT Event "library cache: mutex X"


    Chris, It's 4gb because its a complete release and not an old style patchset. You don't get access to the source code, but kernel function calls are often relevant to searchable MOS documents and so I'll often search for kglxgfde it whatever the particular failing call is.
    On Dec 8, 2011 4:48 PM, "Taylor, Chris David" wrote:
    I'm running 11.2.0.2 Patch 10 on Windows x64 and I have a pl/sql procedure that is rather simple, but kept erroring out after some time with an out memory condition.
    So, I decided to look and see what it is doing and it is encountering the "library cache: mutex X" event.

    Browing Oracle Support, I found the note about it and it says:


    * "P3 = "where" = location in code (internal identifier) where mutex is being waited for
    @The meaning of the code for "where" can be found by looking in kgl0.h for entries with the prefix ""kglml_XXX". For example, if P3=2, then it corresponds to "kglml_kglget2". You can then search source code for this symbol to see where the mutex is acquired.

    Well, that's not very helpful to me since I don't have access to the source code :) I understand that the engineers can use it.

    Long story short, I decided to download the 11.2.0.3 patchset.

    It is only *4 GIGABYTES*. I'm getting about 170k download speed on my work network so......


    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.
  • Gaja Krishna Vaidyanatha at Dec 8, 2011 at 6:25 pm
    Hi Chris,
    Just curious - are you using automatic SGA memory management?

    In my humble experience, I have seen the mutex waits that you refer to when resize operations happen at bad times (basically stealing away from the shared pool to give to the database buffer cache more memory because of a spurt of high I/O requests). In those cases, I have actually turned off automatic SGA memory management in exchange of stability and consistency. Not to mention the problem just goes away. I am big believer in automating the appropriate components in my database (thank you Oracle for automating among other components - UNDO :) ).

    But, I am still old school when it comes to buffer cache sizing, shared pool & other pools sizing. I believe it should be part of a DBA's job and should be automated ONLY in applications/databases that demonstrate consistent, predictable and static behavior in workloads. For more dynamic and inconsistent workloads, I personally would go with manual memory settings. It is worthwhile incurring the additional cost of allocating more memory for the required structures and gain stability and consistency in return. Plus, the CPU overhead of MMAN (if and where relevant) can be avoided.

    Cheers,

    Gaja


    Gaja Krishna Vaidyanatha,
    CEO & Founder, DBPerfMan LLC
    http://www.dbperfman.com
    http://www.dbcloudman.com

    Phone - +1-650-743-6060
    http://www.linkedin.com/in/gajakrishnavaidyanathaCo-author:Oracle Insights:Tales of the Oak Table - http://www.apress.com/book/bookDisplay.html?bID14
    Co-author:Oracle Performance Tuning 101 - http://www.amazon.com/gp/reader/0072131454/ref=sib_dp_pt/102-6130796-4625766


    ________________________________
    From: "Taylor, Chris David" <ChrisDavid.Taylor@ingrambarge.com>
    To: "'oracle-l@freelists.org'" <oracle-l@freelists.org>
    Sent: Thursday, December 8, 2011 8:45 AM
    Subject: Fun with WAIT Event "library cache: mutex X"

    I'm running 11.2.0.2 Patch 10 on Windows x64 and I have a pl/sql procedure that is rather simple, but kept erroring out after some time with an out memory condition.
    So, I decided to look and see what it is doing and it is encountering the "library cache: mutex X" event.

    Browing Oracle Support, I found the note about it and it says:


    *  "P3 = "where" = location in code (internal identifier) where mutex is being waited for
    @The meaning of the code for "where" can be found by looking in kgl0.h for entries with the prefix ""kglml_XXX".  For example, if P3=2, then it corresponds to "kglml_kglget2".  You can then search source code for this symbol to see where the mutex is acquired.

    Well, that's not very helpful to me since I don't have access to the source code :)  I understand that the engineers can use it.

    Long story short, I decided to download the 11.2.0.3 patchset.

    It is only *4 GIGABYTES*.  I'm getting about 170k download speed on my work network so......


    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.
  • Grzegorz Goryszewski at Dec 8, 2011 at 6:49 pm

    On 2011-12-08 19:24, Gaja Krishna Vaidyanatha wrote:
    But, I am still old school when it comes to buffer cache sizing, shared pool & other pools sizing. I believe it should be part of a DBA's job and should be automated ONLY in applications/databases that demonstrate consistent, predictable and static behavior in workloads. For more dynamic and inconsistent workloads, I personally would go with manual memory settings. It is worthwhile incurring the additional cost of allocating more memory for the required structures and gain stability and consistency in return. Plus, the CPU overhead of MMAN (if and where relevant) can be avoided.
    Please consider, despite of disabling AMM Oracle still fights back via:
    *"SGA Re-Sizes <javascript:;> Occurring Despite AMM/ASMM Being Disabled
    (MEMORY_TARGET <javascript:;>/SGA_TARGET <javascript:;>=0) [ID 1269139.1]"

    Regards
    GregG

    *
  • Gaja Krishna Vaidyanatha at Dec 8, 2011 at 6:59 pm
    Hi Greg,
    I am tempted to term the "fight back" as an "undocumented feature" :) In that case, we absolutely need to find a way to disable it -- call this our fight back :)

    Cheers,

    Gaja

    Gaja Krishna Vaidyanatha,
    CEO & Founder, DBPerfMan LLC
    http://www.dbperfman.com
    http://www.dbcloudman.com

    Phone - +1-650-743-6060
    http://www.linkedin.com/in/gajakrishnavaidyanathaCo-author:Oracle Insights:Tales of the Oak Table - http://www.apress.com/book/bookDisplay.html?bID14
    Co-author:Oracle Performance Tuning 101 - http://www.amazon.com/gp/reader/0072131454/ref=sib_dp_pt/102-6130796-4625766


    ________________________________
    From: Grzegorz Goryszewski <grzegorzof@interia.pl>
    To: gajav@yahoo.com
    Cc: "ChrisDavid.Taylor@ingrambarge.com" <ChrisDavid.Taylor@ingrambarge.com>; "'oracle-l@freelists.org'" <oracle-l@freelists.org>
    Sent: Thursday, December 8, 2011 10:49 AM
    Subject: Re: Fun with WAIT Event "library cache: mutex X"
    On 2011-12-08 19:24, Gaja Krishna Vaidyanatha wrote:
    But, I am still old school when it comes to buffer cache sizing, shared pool & other pools sizing. I believe it should be part of a DBA's job and should be automated ONLY in applications/databases that demonstrate consistent, predictable and static behavior in workloads. For more dynamic and inconsistent workloads, I personally would go with manual memory settings. It is worthwhile incurring the additional cost of allocating more memory for the required structures and gain stability and consistency in return. Plus, the CPU overhead of MMAN (if and where relevant) can be avoided.
    Please consider, despite of disabling AMM Oracle still fights back via:
    *"SGA Re-Sizes <javascript:;> Occurring Despite AMM/ASMM Being Disabled
    (MEMORY_TARGET <javascript:;>/SGA_TARGET <javascript:;>=0) [ID 1269139.1]"

    Regards
    GregG

    *
  • Mark W. Farnham at Dec 8, 2011 at 9:06 pm
    A few points my clients and I have observed:

    1) AMM makes pretty good recommendations, but when it is near perfect it
    tends to oscillate a few granules back and forth between shared pool and the
    buffer cache if either is at all lean. Once you've run it on a variety of
    your workloads, it can be very stabilizing if you can spare the memory on
    the system to bump both to at least the ceiling of the recommendations and
    then turn it off. [Perhaps turning it back on once in a while under, say,
    80% of peak pressure to see whether the recommendations have drifted.]

    2) If you turn AMM off, but anything is delaying clearing out long unused
    sql and new sql's need more space to avoid 4031 errors and the like, Oracle
    will still steal from the buffer cache to avoid the 4031 errors to some
    extent. I cannot completely enumerate which cases drive what yet, but I've
    seen server side automatic result cache leave thousands of duplicate (all
    but one marked invalid) result set queries stranded so they won't purge as
    one particularly reproducible case. (Which unfortunately the client would
    not spend the energy and cost on to file a SR/bug, because the ready
    solution was to turn off server side automatic result cache. So I've no idea
    whether this has been fixed or even whether Oracle has a good case in hand.)

    If there are other reasons (than error avoidance) that granule reallocation
    can take place when it is supposed to be turned off I'm not aware of them
    (but I can't enumerate the cases where it seems to "fight back" to prevent
    errors, either.)

    I agree with Gaja that we should have settings for how tightly this is
    restricted. My suggestions would be:

    Never shift granules (which might force a shutdown in imaginable cases in
    the event space cannot be found in which to perform a critical system
    recursive sql.)
    Allow for system panic only (which might still allow throwing some 4031s and
    the like, but would override if the alternative was a crash)
    What it currently does (which is steal a granule or four granules or so from
    the buffer cache if it needs parsing space to avoid an error)

    For getting routine systems up and running at minimum cost and with minimal
    capacity planning investment, all these automation tools really do speed up
    the deployment, reduce total cost of ownership, and mitigate the need to
    understand performance details.

    They can even provide good guidance in quite challenging systems. But at the
    margin, after you get the value from them, you often need to size things and
    turn off the automation, even if you need to schedule manual reallocations
    at ebbs of activity between workshifts of load that demand different
    settings.

    Regards,

    mwf

    -----Original Message-----
    From: oracle-l-bounce@freelists.org
    On Behalf Of Gaja Krishna Vaidyanatha
    Sent: Thursday, December 08, 2011 1:58 PM
    To: Grzegorz Goryszewski
    Cc: ChrisDavid.Taylor@ingrambarge.com; 'oracle-l@freelists.org'
    Subject: Re: Fun with WAIT Event "library cache: mutex X"

    Hi Greg,
    I am tempted to term the "fight back" as an "undocumented feature" :) In
    that case, we absolutely need to find a way to disable it -- call this our
    fight back :)

    Cheers,

    Gaja

    Gaja Krishna Vaidyanatha,
    CEO & Founder, DBPerfMan LLC
    http://www.dbperfman.com
    http://www.dbcloudman.com

    Phone - +1-650-743-6060
    http://www.linkedin.com/in/gajakrishnavaidyanathaCo-author:Oracle
    Insights:Tales of the Oak Table
    - http://www.apress.com/book/bookDisplay.html?bID14
    Co-author:Oracle Performance Tuning 101
    - http://www.amazon.com/gp/reader/0072131454/ref=sib_dp_pt/102-6130796-46257
    66


    ________________________________
    From: Grzegorz Goryszewski <grzegorzof@interia.pl>
    To: gajav@yahoo.com
    Cc: "ChrisDavid.Taylor@ingrambarge.com" <ChrisDavid.Taylor@ingrambarge.com>;
    "'oracle-l@freelists.org'" <oracle-l@freelists.org>
    Sent: Thursday, December 8, 2011 10:49 AM
    Subject: Re: Fun with WAIT Event "library cache: mutex X"
    On 2011-12-08 19:24, Gaja Krishna Vaidyanatha wrote:
    But, I am still old school when it comes to buffer cache sizing, shared
    pool & other pools sizing. I believe it should be part of a DBA's job and
    should be automated ONLY in applications/databases that demonstrate
    consistent, predictable and static behavior in workloads. For more dynamic
    and inconsistent workloads, I personally would go with manual memory
    settings. It is worthwhile incurring the additional cost of allocating more
    memory for the required structures and gain stability and consistency in
    return. Plus, the CPU overhead of MMAN (if and where relevant) can be
    avoided.
    Please consider, despite of disabling AMM Oracle still fights back via:
    *"SGA Re-Sizes <javascript:;> Occurring Despite AMM/ASMM Being Disabled
    (MEMORY_TARGET <javascript:;>/SGA_TARGET <javascript:;>=0) [ID 1269139.1]"

    Regards
    GregG

    *
  • Taylor, Chris David at Dec 8, 2011 at 6:59 pm
    Interesting thought. Yes I am using auto memory management.
    I can play with that and see. I'll let you know.

    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.

    From: Gaja Krishna Vaidyanatha
    Sent: Thursday, December 08, 2011 12:25 PM
    To: Taylor, Chris David; 'oracle-l@freelists.org'
    Subject: Re: Fun with WAIT Event "library cache: mutex X"

    Hi Chris,

    Just curious - are you using automatic SGA memory management?

    In my humble experience, I have seen the mutex waits that you refer to when resize operations happen at bad times (basically stealing away from the shared pool to give to the database buffer cache more memory because of a spurt of high I/O requests). In those cases, I have actually turned off automatic SGA memory management in exchange of stability and consistency. Not to mention the problem just goes away. I am big believer in automating the appropriate components in my database (thank you Oracle for automating among other components - UNDO :) ).

    But, I am still old school when it comes to buffer cache sizing, shared pool & other pools sizing. I believe it should be part of a DBA's job and should be automated ONLY in applications/databases that demonstrate consistent, predictable and static behavior in workloads. For more dynamic and inconsistent workloads, I personally would go with manual memory settings. It is worthwhile incurring the additional cost of allocating more memory for the required structures and gain stability and consistency in return. Plus, the CPU overhead of MMAN (if and where relevant) can be avoided.

    Cheers,

    Gaja


    Gaja Krishna Vaidyanatha,
    CEO & Founder, DBPerfMan LLC
    http://www.dbperfman.com<http://www.dbperfman.com/>
    http://www.dbcloudman.com<http://www.dbperfman.com/>
    Phone - +1-650-743-6060
    http://www.linkedin.com/in/gajakrishnavaidyanatha
    Co-author:Oracle Insights:Tales of the Oak Table - http://www.apress.com/book/bookDisplay.html?bID14
    Co-author:Oracle Performance Tuning 101 - http://www.amazon.com/gp/reader/0072131454/ref=sib_dp_pt/102-6130796-4625766

    ________________________________
    From: "Taylor, Chris David" <ChrisDavid.Taylor@ingrambarge.com>
    To: "'oracle-l@freelists.org'" <oracle-l@freelists.org>
    Sent: Thursday, December 8, 2011 8:45 AM
    Subject: Fun with WAIT Event "library cache: mutex X"

    I'm running 11.2.0.2 Patch 10 on Windows x64 and I have a pl/sql procedure that is rather simple, but kept erroring out after some time with an out memory condition.
    So, I decided to look and see what it is doing and it is encountering the "library cache: mutex X" event.

    Browing Oracle Support, I found the note about it and it says:


    * "P3 = "where" = location in code (internal identifier) where mutex is being waited for
    @The meaning of the code for "where" can be found by looking in kgl0.h for entries with the prefix ""kglml_XXX". For example, if P3=2, then it corresponds to "kglml_kglget2". You can then search source code for this symbol to see where the mutex is acquired.

    Well, that's not very helpful to me since I don't have access to the source code :) I understand that the engineers can use it.

    Long story short, I decided to download the 11.2.0.3 patchset.

    It is only *4 GIGABYTES*. I'm getting about 170k download speed on my work network so......


    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.
  • Taylor, Chris David at Dec 8, 2011 at 9:19 pm
    Well, in the spirit of full disclosure, I discovered I was the one with the bug.

    In the processing of a WHILE LOOP, I was checking against a count variable.

    The problem is, I was setting the count back to zero at a certain interval and doing a commit - inside the loop. So, I was never hitting the end of my WHILE LOOP. Such a simple mistake....

    Can I get away with saying it was 'performing as designed'?

    Some days....

    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.


    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Taylor, Chris David
    Sent: Thursday, December 08, 2011 12:57 PM
    To: 'Gaja Krishna Vaidyanatha'; 'oracle-l@freelists.org'
    Subject: RE: Fun with WAIT Event "library cache: mutex X"

    Interesting thought. Yes I am using auto memory management.
    I can play with that and see. I'll let you know.

    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.

    From: Gaja Krishna Vaidyanatha
    Sent: Thursday, December 08, 2011 12:25 PM
    To: Taylor, Chris David; 'oracle-l@freelists.org'
    Subject: Re: Fun with WAIT Event "library cache: mutex X"

    Hi Chris,

    Just curious - are you using automatic SGA memory management?

    In my humble experience, I have seen the mutex waits that you refer to when resize operations happen at bad times (basically stealing away from the shared pool to give to the database buffer cache more memory because of a spurt of high I/O requests). In those cases, I have actually turned off automatic SGA memory management in exchange of stability and consistency. Not to mention the problem just goes away. I am big believer in automating the appropriate components in my database (thank you Oracle for automating among other components - UNDO :) ).

    But, I am still old school when it comes to buffer cache sizing, shared pool & other pools sizing. I believe it should be part of a DBA's job and should be automated ONLY in applications/databases that demonstrate consistent, predictable and static behavior in workloads. For more dynamic and inconsistent workloads, I personally would go with manual memory settings. It is worthwhile incurring the additional cost of allocating more memory for the required structures and gain stability and consistency in return. Plus, the CPU overhead of MMAN (if and where relevant) can be avoided.

    Cheers,

    Gaja


    Gaja Krishna Vaidyanatha,
    CEO & Founder, DBPerfMan LLC
    http://www.dbperfman.com<http://www.dbperfman.com/>
    http://www.dbcloudman.com<http://www.dbperfman.com/>
    Phone - +1-650-743-6060
    http://www.linkedin.com/in/gajakrishnavaidyanatha
    Co-author:Oracle Insights:Tales of the Oak Table - http://www.apress.com/book/bookDisplay.html?bID14
    Co-author:Oracle Performance Tuning 101 - http://www.amazon.com/gp/reader/0072131454/ref=sib_dp_pt/102-6130796-4625766

    ________________________________
    From: "Taylor, Chris David" <ChrisDavid.Taylor@ingrambarge.com>
    To: "'oracle-l@freelists.org'" <oracle-l@freelists.org>
    Sent: Thursday, December 8, 2011 8:45 AM
    Subject: Fun with WAIT Event "library cache: mutex X"

    I'm running 11.2.0.2 Patch 10 on Windows x64 and I have a pl/sql procedure that is rather simple, but kept erroring out after some time with an out memory condition.
    So, I decided to look and see what it is doing and it is encountering the "library cache: mutex X" event.

    Browing Oracle Support, I found the note about it and it says:


    * "P3 = "where" = location in code (internal identifier) where mutex is being waited for @The meaning of the code for "where" can be found by looking in kgl0.h for entries with the prefix ""kglml_XXX". For example, if P3=2, then it corresponds to "kglml_kglget2". You can then search source code for this symbol to see where the mutex is acquired.

    Well, that's not very helpful to me since I don't have access to the source code :) I understand that the engineers can use it.

    Long story short, I decided to download the 11.2.0.3 patchset.

    It is only *4 GIGABYTES*. I'm getting about 170k download speed on my work network so......


    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.


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




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




    --
    http://www.freelists.org/webpage/oracle-l
  • Herring Dave - dherri at Dec 9, 2011 at 2:58 pm
    On the much less important point you made about " It is only *4 GIGABYTES*. I'm getting about 170k download speed on my work network so......", are you usin wget? I found speeds much faster using this, plus it allows direct download to my server instead of going to PC, then PC to server. It also appears to be only available through the flash version of MOS.

    DAVID HERRING
    DBA
    Acxiom Corporation
    EML   dave.herring@acxiom.com
    TEL    630.944.4762
    MBL   630.430.5988
    1501 Opus Pl, Downers Grove, IL 60515, USA
    WWW.ACXIOM.COM

    The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you.


    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Taylor, Chris David
    Sent: Thursday, December 08, 2011 10:46 AM
    To: 'oracle-l@freelists.org'
    Subject: Fun with WAIT Event "library cache: mutex X"

    I'm running 11.2.0.2 Patch 10 on Windows x64 and I have a pl/sql procedure that is rather simple, but kept erroring out after some time with an out memory condition.
    So, I decided to look and see what it is doing and it is encountering the "library cache: mutex X" event.

    Browing Oracle Support, I found the note about it and it says:


    * "P3 = "where" = location in code (internal identifier) where mutex is being waited for
    @The meaning of the code for "where" can be found by looking in kgl0.h for entries with the prefix ""kglml_XXX". For example, if P3=2, then it corresponds to "kglml_kglget2". You can then search source code for this symbol to see where the mutex is acquired.

    Well, that's not very helpful to me since I don't have access to the source code :) I understand that the engineers can use it.

    Long story short, I decided to download the 11.2.0.3 patchset.

    It is only *4 GIGABYTES*. I'm getting about 170k download speed on my work network so......


    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.


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


    --
    http://www.freelists.org/webpage/oracle-l
  • Taylor, Chris David at Dec 9, 2011 at 3:10 pm
    I'll take a look at that.

    Thanks,

    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.


    -----Original Message-----
    From: Herring Dave - dherri
    Sent: Friday, December 09, 2011 8:58 AM
    To: Taylor, Chris David; 'oracle-l@freelists.org'
    Subject: RE: Fun with WAIT Event "library cache: mutex X"

    On the much less important point you made about " It is only *4 GIGABYTES*. I'm getting about 170k download speed on my work network so......", are you usin wget? I found speeds much faster using this, plus it allows direct download to my server instead of going to PC, then PC to server. It also appears to be only available through the flash version of MOS.

    DAVID HERRING
    DBA
    Acxiom Corporation
    EML   dave.herring@acxiom.com
    TEL    630.944.4762
    MBL   630.430.5988
    1501 Opus Pl, Downers Grove, IL 60515, USA WWW.ACXIOM.COM

    The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you.


    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Taylor, Chris David
    Sent: Thursday, December 08, 2011 10:46 AM
    To: 'oracle-l@freelists.org'
    Subject: Fun with WAIT Event "library cache: mutex X"

    I'm running 11.2.0.2 Patch 10 on Windows x64 and I have a pl/sql procedure that is rather simple, but kept erroring out after some time with an out memory condition.
    So, I decided to look and see what it is doing and it is encountering the "library cache: mutex X" event.

    Browing Oracle Support, I found the note about it and it says:


    * "P3 = "where" = location in code (internal identifier) where mutex is being waited for
    @The meaning of the code for "where" can be found by looking in kgl0.h for entries with the prefix ""kglml_XXX". For example, if P3=2, then it corresponds to "kglml_kglget2". You can then search source code for this symbol to see where the mutex is acquired.

    Well, that's not very helpful to me since I don't have access to the source code :) I understand that the engineers can use it.

    Long story short, I decided to download the 11.2.0.3 patchset.

    It is only *4 GIGABYTES*. I'm getting about 170k download speed on my work network so......


    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.


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




    --
    http://www.freelists.org/webpage/oracle-l
  • Dustin Hayden at Dec 10, 2011 at 6:50 pm
    Had a similar problem in 11.0.1.
    Turned out to be a bug of some type.

    Use this query and see if your query has a very high cursor count.

    select a.cursors, a.sql_id,b.sql_text
    from
    (
    select count(*) as cursors, ssc.sql_id
    from v$sql_shared_cursor ssc
    group by ssc.sql_id
    order by cursors desc
    ) a,
    (
    select sa.sql_id, sa.sql_text from v$sqlarea sa
    ) b
    where a.sql_id=b.sql_id



    Then run:

    SELECT address||','||hash_value, version_count FROM v$sqlarea
    WHERE sql_id = '<your sql_id>';

    Then purge it from the shared pool with:
    EXECUTE dbms_shared_pool.purge('C0000004C29DEAA8,3868811517','C',1);

    Of course you need to substitute what the previous query retured.

    Then rerun your query that had the mutex X wait.

    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Taylor, Chris David
    Sent: Friday, December 09, 2011 10:10 AM
    To: 'Herring Dave - dherri'; 'oracle-l@freelists.org'
    Subject: RE: Fun with WAIT Event "library cache: mutex X"

    I'll take a look at that.

    Thanks,

    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.


    -----Original Message-----
    From: Herring Dave - dherri
    Sent: Friday, December 09, 2011 8:58 AM
    To: Taylor, Chris David; 'oracle-l@freelists.org'
    Subject: RE: Fun with WAIT Event "library cache: mutex X"

    On the much less important point you made about " It is only *4 GIGABYTES*. I'm getting about 170k download speed on my work network so......", are you usin wget? I found speeds much faster using this, plus it allows direct download to my server instead of going to PC, then PC to server. It also appears to be only available through the flash version of MOS.

    DAVID HERRING
    DBA
    Acxiom Corporation
    EML   dave.herring@acxiom.com
    TEL    630.944.4762
    MBL   630.430.5988
    1501 Opus Pl, Downers Grove, IL 60515, USA WWW.ACXIOM.COM

    The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you.


    -----Original Message-----
    From: oracle-l-bounce@freelists.org On Behalf Of Taylor, Chris David
    Sent: Thursday, December 08, 2011 10:46 AM
    To: 'oracle-l@freelists.org'
    Subject: Fun with WAIT Event "library cache: mutex X"

    I'm running 11.2.0.2 Patch 10 on Windows x64 and I have a pl/sql procedure that is rather simple, but kept erroring out after some time with an out memory condition.
    So, I decided to look and see what it is doing and it is encountering the "library cache: mutex X" event.

    Browing Oracle Support, I found the note about it and it says:


    * "P3 = "where" = location in code (internal identifier) where mutex is being waited for
    @The meaning of the code for "where" can be found by looking in kgl0.h for entries with the prefix ""kglml_XXX". For example, if P3=2, then it corresponds to "kglml_kglget2". You can then search source code for this symbol to see where the mutex is acquired.

    Well, that's not very helpful to me since I don't have access to the source code :) I understand that the engineers can use it.

    Long story short, I decided to download the 11.2.0.3 patchset.

    It is only *4 GIGABYTES*. I'm getting about 170k download speed on my work network so......


    Chris Taylor
    Sr. Oracle DBA
    Ingram Barge Company
    Nashville, TN 37205

    "Quality is never an accident; it is always the result of intelligent effort."
    -- John Ruskin (English Writer 1819-1900)

    CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.


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




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


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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedDec 8, '11 at 4:47p
activeDec 10, '11 at 6:50p
posts11
users6
websiteoracle.com

People

Translate

site design / logo © 2021 Grokbase