2010-05-24 7 views
6

J'ai un progiciel Oracle DB qui provoque régulièrement ce que je crois être un interblocage ITL (Interested Transaction List). La partie pertinente d'un fichier de trace est ci-dessous.Identification et résolution d'un interblocage Oracle ITL

Deadlock graph: 
         ---------Blocker(s)-------- ---------Waiter(s)--------- 
Resource Name   process session holds waits process session holds waits 
TM-0000cb52-00000000  22  131   S  23  143   SS 
TM-0000ceec-00000000  23  143 SX    32  138 SX SSX 
TM-0000cb52-00000000  30  138 SX    22  131   S 
session 131: DID 0001-0016-00000D1C session 143: DID 0001-0017-000055D5 
session 143: DID 0001-0017-000055D5 session 138: DID 0001-001E-000067A0 
session 138: DID 0001-001E-000067A0 session 131: DID 0001-0016-00000D1C 
Rows waited on: 
Session 143: no row 
Session 138: no row 
Session 131: no row 

Il n'y a pas d'index de mappage sur cette table, ce n'est donc pas la cause. Pour autant que je sache, l'absence de "Lignes attendues" plus le "S" dans la colonne Waiter Wait indique probablement qu'il s'agit d'une impasse ITL. En outre, la table est écrite assez souvent (environ 8 insertions ou mises à jour simultanément, aussi souvent que 240 fois par minute), donc une impasse ITL semble être une forte possibilité.

J'ai augmenté le paramètre INITRANS de la table et ses index à 100 et augmenté le PCT_FREE sur la table de 10 à 20 (reconstruit ensuite les index), mais les blocages sont toujours en cours. L'impasse semble se produire le plus souvent au cours d'une mise à jour, mais cela pourrait être une coïncidence, car je l'ai seulement retrouvé quelques fois.

Mes questions sont doubles:
1) S'agit-il réellement d'une impasse ITL?
2) S'il s'agit d'une impasse ITL, que peut-on faire d'autre pour l'éviter?


Il se trouve que cela n'a pas été un problème de blocage de ITL du tout, mais plutôt un problème avec les clés étrangères indexées sur l'ONU. J'ai découvert cela grâce à la réponse de dpbradley, qui m'a fait comprendre que ce n'était pas un problème de l'ITL et m'a incité à découvrir quelles pourraient être les autres causes d'un blocage avec «pas de lignes».

+0

Vous pouvez envisager de poster ceci sur serverfault. Ma première réaction a été de savoir à quoi cela appartenait, mais il y a aussi une touche de programmation à la question. En tout cas, vous pouvez attraper une autre paire d'yeux qui ne sont pas là. – DCookie

Répondre

5

La meilleure indication de la pression ITL est des vues de performance:

select event, total_waits, time_waited, average_wait 
from v$system_event 
where event like 'enq: TX%' 
order by 2 desc; 

montre attend contention TX, et

select OBJECT_NAME, SUBOBJECT_NAME, TABLESPACE_NAME, 
     OBJECT_TYPE, STATISTIC_NAME, VALUE 
    from v$segment_statistics 
    where statistic_name = 'ITL waits' 
    and value > 0 
    order by value desc; 

montre les tables et les index impliqués.

(Comme toutes les v$ vues, les résultats sont du moment où l'instance a été commencé.)

Si cela montre que vous avez en effet ITL attend, puis les INITRANS et les paramètres PCTFREE sont les principaux boutons tourner (mais INITRANS = 100 me semble assez élevé et ça coûte de l'espace).

Si les attentes ITL ne sont pas un problème, alors le code de l'application doit être examiné.

+0

La première requête montre 23000+ "enq: TX - contention" attend, mais la deuxième requête affiche seulement 1 attente ITL (sur un index pour une table sur laquelle je n'ai pas vu de blocage). Si je comprends bien, cela semble indiquer que ce n'est pas vraiment une impasse ITL? – Allan

+0

Oui, et je vois à partir de votre vérification que vous avez depuis découvert le problème sous-jacent. Les FK non indexés peuvent certainement être un problème de verrouillage - il y a beaucoup de scripts flottants qui signaleront les clés étrangères non indexées dans un schéma. – dpbradley

2

La meilleure option est de l'augmenter si nécessaire (commencer par défaut 10 et augmenter de 10). Si vous voyez une réduction des attentes ITL, vous êtes défini. Habituellement, ces paramètres liés sont ajustés par essais et erreurs à la fois dans Oracle et SQL Server. Ajuster ces paramètres en temps réel ne posera pas trop de problème, à moins que la ressource ne soit extrêmement occupée. Vous pouvez utiliser la requête suivante pour voir après chaque incrément, si le ITL attend soit aller ou est très réduite:

SELECT t.OWNER, t.OBJECT_NAME, t.OBJECT_TYPE, t.STATISTIC_NAME, t.VALUE 
    FROM v$segment_statistics t 
    WHERE t.STATISTIC_NAME = 'ITL waits' AND t.VALUE > 0 
    ORDER BY t.value desc; 

Nous avons effectué plusieurs accordages pour les scénarios de blocage Oracle en raison de ITL attend avec cette méthode. Remarque: Assurez-vous que l'index est reconstruit, si le initrans est modifié pour les index. Assurez-vous également que les statistiques ne sont pas périmées. Pour une vérification rapide, vous pouvez utiliser SQL Tuning Advisor pour voir l'état complet de la requête/index et des statistiques.