Chaves estrangeiras podem causar deadlocks e atrapalhar LER INSTANTÂNEO CONFIRMADO?

Esta é uma pergunta de acompanhamento de: https://stackoverflow.com/questions/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically

Ainda estou tendo situações de impasse/tempo limite no aplicativo ASP.NET ao executar grandes relatórios simultaneamente, embora READ_COMMITTED_SNAPSHOT ON.

Então eu tenho duas perguntas:

1. Como posso verificar se o Instantâneo do Nível de Isolamento da Transação está funcionando conforme o esperado?
2. Estou assumindo que as chaves estrangeiras (nas tabelas da Web-Application para as tabelas-relatório) são as responsáveis ​​pelos deadlocks. Achei este artigo interessante :

Observação SQL Server adquire bloqueios compartilhados ao validar chaves estrangeiras, mesmo se a transação estiver usando instantâneo de leitura confirmada (leitura confirmada usando controle de versão de linha) ou nível de isolamento de instantâneo. Lembre-se disso ao examinar gráficos de deadlock de transações quando esses níveis de isolamento de transação são usados. Se você vir bloqueios compartilhados, verifique se os bloqueios são obtidos em um objeto referenciado por uma chave estrangeira.

Como posso verificar se o FK é realmente responsável pelas situações de Deadlock/Timeout, isso significa que eu poderia excluir essas chaves estrangeiras para evitar deadlocks (o que seria um esforço aceitável)?

Nota : Estou apenas lendo as tabelas que causam impasses.

Quaisquer pensamentos sobre este tópico são muito apreciados.

Editar Aqui está um Gráfico de Deadlock . Talvez alguém possa me ajudar a entender o que causa o impasse. Parece que ocorreu sem nenhum relatório em execução causado apenas pelo aplicativo da web, quando duas transações desejam gravar a mesma tabela (uma atualização e uma inserção, a inserção é como procedimento armazenado). Por que ele adquire bloqueios de página e como habilitar apenas os bloqueios de linha? A Insert-SP já usa TRANSACTION ISOLATION LEVEL REPEATABLE READ.

Tenho uma forte suspeita de que dois gatilhos (um update e um insert) são os responsáveis ​​pelos impasses. Aqui está o gatilho de inserção:

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

Portanto, esse gatilho atualiza a RMA-Table, o que faz com que o gatilho de atualização seja acionado (o que é semelhante). O gráfico de impasse confirma minha suposição? Acho que vou deletar esses gatilhos e criar um SP que está sendo executado uma vez por dia, o que seria perfeitamente suficiente, porque essas colunas são apenas para um SSAS-Cube (Molap).

Editar : A propósito, não houve mais impasse desde que excluí esses gatilhos :)