Recherche de la cause de l'erreur de blocage à partir du fichier de trace Oracle

J'ai été faire ce "ora-00060 blocage détecté lors de l'attente pour la ressource" erreur souvent maintenant dans ma demande, lorsque plusieurs utilisateurs utilisent l'application. J'ai le fichier de trace à partir de l'oracle Admin, mais ont besoin d'aide dans la lecture. Ci-dessous les bits de données à partir du fichier de trace, qui, je l'espère, aidera à trouver la cause.

*** 2013-06-25 09:37:35.324
DEADLOCK DETECTED ( ORA-00060 )

[Transaction Deadlock]

The following deadlock is not an ORACLE error. It is a deadlock due 
to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:

Deadlock graph:
                   ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TM-000151a2-00000000       210      72    SX   SSX      208      24    SX   SSX
TM-000151a2-00000000       208      24    SX   SSX      210      72    SX   SSX

session 72: DID 0001-00D2-000000C6  session 24: DID 0001-00D0-00000043 
session 24: DID 0001-00D0-00000043  session 72: DID 0001-00D2-000000C6 

Rows waited on:
 Session 72: no row
 Session 24: no row

----- Information for the OTHER waiting sessions -----
Session 24:
 sid: 24 ser: 45245 audsid: 31660323 user: 90/USER
  flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
  flags2: (0x40009) -/-/INC
 pid: 208 O/S info: user: zgrid, term: UNKNOWN, ospid: 2439
   image: oracle@xyz.local
 client details:
   O/S info: user: , term: , ospid: 1234
   machine: xyz.local program: 
 current SQL:
  delete from EMPLOYEE where EMP_ID=:1

 ----- End of information for the OTHER waiting sessions -----

Information for THIS session:

 ----- Current SQL Statement for this session (sql_id=dyfg1wd8xa9qt) -----
 delete from EMPLOYEE where EMP_ID=:1
===================================================

Je vous serais reconnaissant si quelqu'un peut me dire quel est le "graphique de Blocage::", c'est dire. Aussi les lignes attendu sur la section dit pas de lignes.

J'ai également lu dans certains blogs que "sqltxt" la section du fichier de trace peut suggérer la cause. Ci-dessous est la requête que je vois dans cette section.

 select /*+ all_rows */ count(1) from "USERS"."EMPLOYEE_SALARY" where EMPSAL_EMP_ID=:1

La employee_salary table a foreignkey contrainte sur EMPSAL_EMP_ID colonne.

L'astuce sql dit "all_rows", fait-il dire que ce tableau obtient le tableau de niveau de verrouillage lors de la suppression d'enregistrements à partir de la table des employés? je n'ai pas un index sur la colonne de clé étrangère actuellement. Serait l'ajout d'un index sur cette colonne aider?

De bien vouloir publier, dans le cas d'un complément d'informations est nécessaire.

Grâce

source d'informationauteur shashikanthb

  1. 27

    Tout d'abord, select déclaration ne jamais verrouiller n'importe quoi dans Oracle, juste utilise la dernière version cohérente des données. Ce n'est pas un cas pour select ... for update qui verrouille les données comme update depuis Oracle 9i, mais il n'y a pas for update clause dans la requête à partir de la question. 

    Resource Name          process session holds waits  process session holds waits
TM-000151a2-00000000       210      72    SX   SSX      208      24    SX   SSX

    Session #72 tient au niveau de la table lock (TM) avec la Ligne "Exclusif" de type (SX) et que vous souhaitez acquérir "Share Row Exclusive" (SSX) de verrouillage sur la même table. Cette session bloquée par Session #24 qui en détient déjà au niveau de la table de verrouillage d'un même type (SX) et attend que SSX la serrure serait disponible.

    Resource Name          process session holds waits  process session holds waits
TM-000151a2-00000000       208      24    SX   SSX      210      72    SX   SSX

    Cette (deuxième ligne) démontre exactement la même situation, mais dans la direction opposée: Session n ° 24 attend SSX de verrouillage sont disponibles, mais bloqué par Session #72 qui en détient déjà SX de verrouillage sur la même table.

    Donc, Séances n ° 24 et la Session #72 blocs les uns des autres: blocage se produit.

    Les deux types de verrou (SX et SSX) sont au niveau de la table des verrous.

    Pour comprendre la situation, je vous recommande de lire cet article par Franck Pachot.

    Ci-dessous est la citation de cet article, qui sont directement pertinents à votre situation(à noter que SSX et SRX abréviations sont équivalentes):

    L'intégrité référentielle acquiert également TM serrures. Par exemple, la commune
    problème avec indexée clés étrangères conduit à S de verrous sur table enfant lorsque
    vous émettez une suppression ou mise à jour sur la clé, sur la table parent. C'est
    parce que sans index, Oracle a pas qu'un seul niveau inférieur de ressources pour
    de verrouillage afin d'empêcher un concurrent à l'insertion qui peut violer l'
    l'intégrité référentielle.

    Lorsque les colonnes de clé étrangère sont la principale
    les colonnes dans un index normal, puis à la première entrée d'index avec le parent
    la valeur peut être utilisé comme une ressource unique et fermée avec un niveau de ligne TX
    verrouillage.

    Et si l'intégrité référentielle est un delete cascade? Dans
    outre le mode S, il y a l'intention de mettre à jour les lignes dans la
    table d'enfant, comme avec la Ligne X (RX) mode. C'est là la part ligne
    exclusif (SRX) se produit: S+RX=SRX.

    Donc, le plus probable variante est que la Session #72 et Session #24 supprime des lignes dans EMPLOYEE table en même temps, et il y a on delete cascade contrainte pour EMPSAL_EMP_ID en conjonction avec l'absence d'index sur EMPLOYEE_SALARY table dans laquelle EMPSAL_EMP_ID colonne premier de la liste.