Les clés étrangères peuvent-elles provoquer des blocages et entraver la lecture de l'instantané validé?

Il s'agit d'une question de suivi de: /programming/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically

Je rencontre toujours des situations de blocage / délai d'attente dans l'application ASP.NET lors de l'exécution simultanée de rapports volumineux READ_COMMITTED_SNAPSHOT ON.

J'ai donc deux questions:

1. Comment puis-je vérifier si l' instantané de niveau d'isolement de transaction fonctionne comme prévu / du tout?
2. Je suppose que les clés étrangères (dans les tables de l'application Web aux tables de rapport) sont responsables des blocages. J'ai trouvé cet article intéressant :

Remarque SQL Server acquiert des verrous partagés lors de la validation des clés étrangères, même si la transaction utilise un instantané de lecture validée (lecture validée à l'aide du versionnement de ligne) ou un niveau d'isolement d'instantané. Gardez cela à l'esprit lorsque vous examinez les graphiques de blocage des transactions lorsque ces niveaux d'isolement des transactions sont utilisés. Si vous voyez des verrous partagés, vérifiez si les verrous sont pris sur un objet référencé par une clé étrangère.

Comment puis-je vérifier si le FK est vraiment responsable des situations de blocage / délai d'attente, cela signifie-t-il que je pourrais supprimer ces clés étrangères pour éviter les blocages (ce qui serait un effort acceptable)?

Remarque : je ne fais que lire les tableaux qui provoquent des blocages.

Toute réflexion sur ce sujet est grandement appréciée.

Edit Voici un Deadlock-Graph . Peut-être que quelqu'un pourrait m'aider à comprendre les causes de l'impasse. Il semble que cela se soit produit sans aucun rapport généré uniquement par l'application Web, lorsque deux transactions veulent écrire la même table (une mise à jour et une insertion, l'insertion est en tant que procédure stockée). Pourquoi acquiert-il des verrous de page et comment activer uniquement les verrous de ligne? Le Insert-SP utilise déjà TRANSACTION ISOLATION LEVEL REPEATABLE READ.

Je soupçonne fortement que deux déclencheurs (une mise à jour et un insert) sont responsables des blocages. Voici le déclencheur d'insertion:

CREATE TRIGGER [dbo].[CreateRMAFiDates] 
   ON  [dbo].[RMA] 
   AFTER INSERT
AS 
BEGIN
    SET NOCOUNT ON;

    UPDATE RMA 
    SET [fiCreationDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.Creation_Date, 112) = tdefDate.Text),
        [fiPopDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.POP_Date, 112) = tdefDate.Text),
        [fiManufactureDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.Manufacture_Date, 112) = tdefDate.Text)
    FROM INSERTED;
END

Donc, ce déclencheur met à jour la table RMA ce qui provoque le déclenchement du déclencheur de mise à jour (ce qui fait similaire). Le graphique de blocage confirme-t-il mon hypothèse? Je pense que je vais supprimer ces déclencheurs et créer un SP qui fonctionne une fois par jour, ce qui serait parfaitement suffisant, car ces colonnes sont uniquement destinées à un SSAS-Cube (Molap).

Edit : Au fait, il n'y avait plus de blocage depuis que j'ai supprimé ces déclencheurs :)

Si l'équipe SQLCAT dit que la validation FK se fait à l'aide de l'isolement validé en lecture, elle doit savoir de quoi elle parle. Accent sur la validation . La vraie question est pourquoi un rapport déclencherait-il la validation FK ? La validation a lieu lors des écritures et les rapports sont censés être lus . Soit vos rapports provoquent des écritures, auquel cas les niveaux d'isolement des instantanés n'aideront en rien, soit la cause du blocage est différente.

La seule façon de progresser est de capturer le graphique de blocage.

Quant à l'autre question, comment pouvez-vous vérifier si vous opérez sous isolement de cliché: regardez sys.dm_tran_active_snapshot_database_transactions.

La validation de la clé étrangère doit se produire sous (verrouillage) lu engagé pour l'exactitude. Voir Isolement de cliché: une menace pour l'intégrité? par Hugo Kornelis pour plus de détails.

Le graphique de blocage montre deux exécutions simultanées de RM2.dbo.RMAprovoquer le blocage. Vos déclencheurs n'ont pas de condition de jointure entre RMAet inserted.

Il semble probable qu'il s'agisse d'une erreur et que votre déclencheur met accidentellement à jour toutes les lignes dans RMAainsi des blocages sont extrêmement susceptibles de se produire s'il y a plus d'une exécution de déclencheur simultanée.