Mutexes table takes 100% CPU in Oracle

Hi,

We are experiencing a very estrange behavior in a Production Environment running on Oracle11g.  Sessions created by eB are executing multiple select statements against de MUTEXES table and hangs the hole database instance.  MUTEX table is empty.  We have double-checked that no transactions are pending.  The DB instance was shutdown twice as the eB Services and Package were shutdown multiple times.

Any idea where to look to find out what is happening?

Thanks in advance, kind regards,

Sebastian.

Parents
  • Hi Sebastian,

    I am copying the exchange we had via email to add to the Communities records. If possible please confirm this Answer with the button below.

    I found the MUTEXES table in a 15.6.1 DB I have here. I have not seen such hang behavior in Oracle eB DB. I did a quick search on my help records and can’t find any prior issues I have worked on related to that MUTEXES table.

    The table is empty so you could try to recreate it to see if that addresses the problem. Since this system was working fine before it is possible that the table definition became corrupted? Can you see via EM if there is some sort of lock on that table ?

    Another option would be to run the Maintenance scripts and/or DB upgrade scripts. Maintenance scripts should fix any inconsistencies in eB environment. DB upgrade will recreate some indexes, and all stored procedures and functions on the DB. Since this is production do a backup prior to running DB maintenance and/or upgrade scripts. Also remember you will have to recreate any custom scripts or triggers defined for it. That is why maybe you want to first try recreating just the MUTEXES table.


    thanks,

    Roberto Garcia

                                          

    Address: Bentley | 10052 Mesa Ridge Court Suite
    100 | San Diego | CA | 92121 | USA



    Answer Verified By: Sebastian Fernandez Pacheco 

  • Hi Roberto, sorry for my late update on this but this is the first week from Monday to Friday without incident. All your recommendations were correct.

    First, we ran the Maintenance Scripts and the problem was solved and the system overall speed was improved. This confirmed that something in the db causes the issues.

    But then new incidents shown up every Monday. Possible due to full db backups the customer run every weekend.-

    After a complete analysis of the MUTEXES table the DBA found that most of the time is empty and was store in 256 "blocks" (2MB) but It index was store in 4992 "blocks" (39MB). Then found that SELECT COUNT(*) FROM MUTEXES is called many many many times from ebp_get_explode. So, he re-created the MUTEXES table as you suggested. The new one now is store in 8 blocks (64 KB) and It index in another 8 blocks (64 KB). No incident shown up since then and the system overall speed has improved even more.

    Thank you very much for your help, as always we really appreciate your outstanding support.

    Kind regards,
    Sebastian.
Reply
  • Hi Roberto, sorry for my late update on this but this is the first week from Monday to Friday without incident. All your recommendations were correct.

    First, we ran the Maintenance Scripts and the problem was solved and the system overall speed was improved. This confirmed that something in the db causes the issues.

    But then new incidents shown up every Monday. Possible due to full db backups the customer run every weekend.-

    After a complete analysis of the MUTEXES table the DBA found that most of the time is empty and was store in 256 "blocks" (2MB) but It index was store in 4992 "blocks" (39MB). Then found that SELECT COUNT(*) FROM MUTEXES is called many many many times from ebp_get_explode. So, he re-created the MUTEXES table as you suggested. The new one now is store in 8 blocks (64 KB) and It index in another 8 blocks (64 KB). No incident shown up since then and the system overall speed has improved even more.

    Thank you very much for your help, as always we really appreciate your outstanding support.

    Kind regards,
    Sebastian.
Children
No Data