Le chiavi esterne possono causare deadlock e ostacolare LETTURA SNAPSHOT IMPEGNATA?

Questa è una domanda di follow-up da: /programming/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically

Tuttavia, ho ancora situazioni di deadlock / timeout nell'applicazione ASP.NET quando eseguo report di grandi dimensioni contemporaneamente READ_COMMITTED_SNAPSHOT ON.

Quindi ho due domande:

1. Come posso verificare se l' istantanea del livello di isolamento della transazione funziona come previsto / a tutti?
2. Suppongo che le chiavi esterne (nelle tabelle dell'applicazione Web alle tabelle dei report) siano responsabili dei deadlock. Ho trovato questo interessante articolo :

Nota SQL Server acquisisce i blocchi condivisi durante la convalida delle chiavi esterne, anche se la transazione utilizza lo snapshot di commit della lettura (read commit utilizzando il controllo delle versioni di riga) o il livello di isolamento dello snapshot. Prestare attenzione a ciò quando si esaminano i grafici di deadlock dalle transazioni quando vengono utilizzati questi livelli di isolamento delle transazioni. Se vedi i blocchi condivisi, controlla se i blocchi vengono acquisiti su un oggetto a cui fa riferimento una chiave esterna.

Come posso verificare se l'FK è realmente responsabile delle situazioni di deadlock / timeout, ciò significa che potrei eliminare quelle chiavi esterne per evitare deadlock (quale sarebbe uno sforzo accettabile)?

Nota : sto leggendo solo dalle tabelle che causano deadlock.

Qualsiasi pensiero su questo argomento è molto apprezzato.

Modifica Ecco un grafico a deadlock . Forse qualcuno potrebbe aiutarmi a capire cosa causa lo stallo. Sembra che si sia verificato senza alcun report in esecuzione causato solo dall'applicazione Web, quando due transazioni vogliono scrivere la stessa tabella (un aggiornamento e un inserto, l'inserimento è come Stored-Procedure). Perché acquisisce i blocchi di pagina e come abilitare solo i blocchi di riga? Insert-SP utilizza già TRANSACTION ISOLATION LEVEL REPEATABLE READ.

Ho il forte sospetto che due trigger (un aggiornamento e un inserto) siano responsabili dei deadlock. Ecco il trigger di inserimento:

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

Quindi questo trigger aggiorna la tabella RMA cosa provoca l'attivazione del trigger di aggiornamento (cosa fa simile). Il diagramma di deadlock conferma la mia ipotesi? Penso che eliminerò quei trigger e creerò un SP che è in esecuzione una volta al giorno ciò che sarebbe perfettamente sufficiente, perché queste colonne sono solo per un cubo SSAS (Molap).

Modifica : A proposito, non ho più avuto deadlock da quando ho eliminato questi trigger :)

Se il team SQLCAT afferma che la convalida FK viene eseguita utilizzando l'isolamento con commit della lettura, devono sapere di cosa stanno parlando. Enfasi sulla convalida . La vera domanda è: perché un rapporto dovrebbe attivare la convalida FK ? La convalida si verifica nelle scritture e si suppone che le relazioni siano letture . O i rapporti causano scritture, nel qual caso i livelli di isolamento dell'istantanea non aiuteranno nulla, o la causa del deadlock è diversa.

L'unico modo per fare progressi è acquisire il grafico del deadlock.

Per quanto riguarda l'altra domanda, come si può verificare se si opera sotto isolamento di istantanee: guardare dentro sys.dm_tran_active_snapshot_database_transactions.

La convalida della chiave esterna deve essere eseguita sotto (blocco) letto commesso per correttezza. Vedi Isolamento snapshot: una minaccia per l'integrità? di Hugo Kornelis per i dettagli.

Il grafico del deadlock mostra due esecuzioni simultanee di RM2.dbo.RMAcausare il deadlock. Nei trigger non è presente una condizione di join tra RMAe inserted.

Sembra probabile che si tratti di una svista e che il trigger stia aggiornando accidentalmente tutte le righe in RMAmodo che i deadlock siano estremamente probabili se si verifica più di un'esecuzione di trigger simultanea.