Bonjour,
Cette requête elle vérifie que les clés primaires sont bien indexées 8OCitation:
MAIS CETTE REQUETE CORRESPOND ELLE BIEN A CELLE QU'IL ME FAUT EFFECTUER POUR VERIFIER QUE TOUTES LES CLEFS ETRANGERES SONT BIEN INDEXEES ???
car le r_constraint_name d'une contrainte 'R' c'est la contrainte référencée (donc la clé unique ou primaire de la table référencée).
Voici une requête possible: http://asktom.oracle.com/pls/asktom/...26568859366976
Sinon, ton fichier attaché montre que 285 a fait du DML sur TAB_FAC_ACMPT et que 304 est en attente là dessus pour poser son Share lock.
Tu est pile-poil dans le pb de la foreign key non indexée:
1- Session 285 fait un insert dans TAB_FAC_ACMPT
2- Session 304 veut faire un update sur TABDOS et il update aussi la primary key (NUMDOS=69110) On va dire que l'ancienne valeur est 68000 mais si ça se trouve, c'est la même valeur.
Pour celà la session 285 doit s'assurer qu'il n'y a aucun enregistrement dans TAB_FAC_ACMPT qui ait NUMDOS=68000 comme foreign key, sinon ce serait violation de contrainte parce que cette valeur va disparaître de la table parent.
Or il y a un insert non commité dans cette table.
Si cet insert en question avait NUMDOS=68000, alors il y aurait violation de contrainte. il faut donc attendre que cet insert soit commité ou rollbacké pour savoir si on peut ou non faire l'insert.
Et celà ne dépends pas de la valeur dans l'insert. L'insert fait NUMDOS=67456 alors que l'update se fait sur 68000.
Mais le problème, c'est qu'oracle n'a nulle part où poser un verrou sur la valeur précise 68000 alors il pose le verrou Share sur la table entière.
Par contre, s'il existe un index sur la foreign key, alors oracle se sert de cet index pour poser le verrou sur cette valeur en posant un verrou sur la première entrée d'index correpondant à celà. donc il ne bloque que si le conflit se fait sur la première valeur.
Masi à mon avis, le vrai bug dans tout ça, c'est pas le masue d'index sur la foreign key (même si une index là dessus serait probablement utile, ne serai-ce que pour vérifier la contrainte d'intégrité sans aller faire un full scan) mais c'est surtout cet update que va modifier toutes les colonnes d'une table, même la cléf !
T'as déjà identifié la cause du problème, quelle requête bloque quelle requête, et avec que verrous, c'est pas mal déjà. :ccool:Citation:
Je reviens vers vous car je ne m'en sorts toujours pas.:aie:
Franck.
