¿Pueden las claves foráneas causar puntos muertos e impedir la LECTURA DE LA INSTANTÁNEA COMPROMETIDA?

Esta es una pregunta de seguimiento de: /programming/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically

Sin embargo, todavía tengo situaciones de punto muerto / tiempo de espera en la aplicación ASP.NET cuando ejecuto grandes informes simultáneamente READ_COMMITTED_SNAPSHOT ON.

Entonces tengo dos preguntas:

1. ¿Cómo puedo verificar si la Instantánea de nivel de aislamiento de transacción funciona como se esperaba / en absoluto?
2. Supongo que las claves externas (en las tablas de la aplicación web para las tablas de informes) son responsables de los puntos muertos. Encontré este interesante artículo :

Nota SQL Server adquiere bloqueos compartidos al validar claves foráneas, incluso si la transacción está utilizando una instantánea confirmada de lectura (lectura confirmada utilizando el control de versiones de fila) o un nivel de aislamiento de instantánea. Tenga esto en cuenta al examinar los gráficos de punto muerto de las transacciones cuando se utilizan estos niveles de aislamiento de transacciones. Si ve bloqueos compartidos, verifique si los bloqueos se toman en un objeto al que hace referencia una clave foránea.

¿Cómo puedo verificar si los FK son realmente responsables de las situaciones de punto muerto / tiempo de espera, eso significa que podría eliminar esas claves foráneas para evitar puntos muertos (lo que sería un esfuerzo aceptable)?

Nota : Solo estoy leyendo de las tablas que causan puntos muertos.

Cualquier idea sobre este tema es muy apreciada.

Editar aquí es un gráfico de punto muerto . Quizás alguien podría ayudarme a comprender qué causa el punto muerto. Parece que ocurrió sin que se ejecutaran informes solo causados ​​por la aplicación web, cuando dos transacciones desean escribir la misma tabla (una actualización y una inserción, la inserción es como Procedimiento almacenado). ¿Por qué adquiere bloqueos de página y cómo habilitar solo bloqueos de fila? El Insert-SP ya lo usa TRANSACTION ISOLATION LEVEL REPEATABLE READ.

Tengo una fuerte sospecha de que dos factores desencadenantes (una actualización y una inserción) son responsables de los puntos muertos. Aquí está el disparador de inserción:

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

Entonces, este activador actualiza la tabla RMA, lo que hace que se active el activador de actualización (lo que hace similar). ¿El gráfico de punto muerto confirma mi suposición? Creo que eliminaré esos disparadores y crearé un SP que se ejecuta una vez al día, lo que sería perfectamente suficiente, porque estas columnas son solo para un Cubo SSAS (Molap).

Editar : Por cierto, ya no hubo un punto muerto desde que eliminé estos desencadenantes :)

Si el equipo de SQLCAT dice que la validación de FK se realiza mediante aislamiento de lectura confirmada, entonces deben saber de qué están hablando. Énfasis en la validación . La verdadera pregunta es ¿Por qué un informe desencadenaría la validación FK ? La validación ocurre en escrituras , y se supone que los informes son lecturas . O bien sus informes están causando escrituras, en cuyo caso los niveles de aislamiento de instantáneas no ayudarán en nada, o la causa del punto muerto es diferente.

La única forma de avanzar es capturar el gráfico de punto muerto.

En cuanto a la otra pregunta, ¿cómo puede verificar si opera con aislamiento de instantánea sys.dm_tran_active_snapshot_database_transactions?

La validación de clave externa tiene que ocurrir bajo (bloqueo) lectura confirmada para su corrección. Consulte Aislamiento de instantáneas: ¿una amenaza para la integridad? por Hugo Kornelis para más detalles.

El gráfico de punto muerto muestra dos ejecuciones simultáneas de RM2.dbo.RMAcausar el punto muerto. A sus desencadenantes les falta una condición de unión entre RMAy inserted.

Parece probable que esto sea un descuido y que su desencadenante actualice accidentalmente todas las filas, por RMAlo que es muy probable que se produzcan puntos muertos si hay más de una ejecución de desencadenante concurrente.