Dale K's questions

Tendo executado sp_BlitzIndex no meu banco de dados, encontrei vários "Índices Agressivos" ( https://www.brentozar.com/blitzindex/sp_blitzindex-aggressive-indexes/ ). Não só, mas estou descobrindo que o número de "índices agressivos" está aumentando lentamente.

Eu sou um dev que se interessa pelo lado DBA das coisas e não consigo descobrir como ir das informações fornecidas pelo sp_BlitzIndex sobre índices agressivos para melhorá-los.

Estou bem em ajustar o desempenho de uma consulta individual, mas não sei como descobrir qual consulta pode estar acontecendo quando o índice fica agressivo e estou assumindo que os bloqueios estão acontecendo porque o servidor está sob carga - o que não t ser o caso se eu ajustar uma consulta individual.

Qualquer dica sobre como investigar mais seria apreciada.

Estou recebendo erros quando executo a seguinte consulta:

SELECT (
        SELECT 1
        FROM dbo.AccountEntry AE
        WHERE AE.Account = P.Account
        )
FROM dbo.Proposal P
WHERE P.id = @Id

Quando executado via ADO.NET, ele fornece:

Aviso: o erro fatal 3624 ocorreu em 20 de junho de 2016 às 2h28. Anote o erro e a hora e entre em contato com o administrador do sistema. Um erro severo ocorreu no comando atual. Os resultados, se existirem, deveriam ser descartados.

Quando executado no SSMS, ele fornece

Local: statutil.cpp:4128
Expressão: iKey <m_statBlob.GetHeader()->GetKeyCount()
SPID: 59 ID do processo: 1732
Msg 3624, nível 20, estado 1, linha 1
Falha na verificação de asserção do sistema. Verifique o log de erros do SQL Server para obter detalhes. Normalmente, uma falha de asserção é causada por um bug de software ou corrupção de dados. Para verificar a corrupção do banco de dados, considere executar DBCC CHECKDB. Se você concordou em enviar dumps para a Microsoft durante a instalação, um mini dump será enviado para a Microsoft. Uma atualização pode estar disponível na Microsoft no Service Pack mais recente ou em um QFE do Suporte técnico.
Msg 0, Level 20, State 0, Line 0
Ocorreu um erro grave no comando atual. Os resultados, se existirem, deveriam ser descartados.

Curiosamente, este código funciona ao definir @Account para P.Account:

select 1 from dbo.AccountEntry AE where AE.Account = @Account

Já tentei reiniciar o servidor.

Eu tentei descartar todos os índices e estatísticas.

Executei o DBCC CHECKDB e ele não retornou erros.

Não acreditamos que nada tenha mudado no servidor desde sexta-feira, quando ele estava funcionando normalmente.

Versão SQL: Microsoft SQL Server 2012 - 11.0.5343.0 (X64) 4 de maio de 2015 19:11:32 Copyright (c) Microsoft Corporation Standard Edition (64 bits) no Windows NT 6.2 (Build 9200: ) (Hypervisor)

Eu tenho 2 consultas que quando executadas ao mesmo tempo estão causando um impasse.

Consulta 1 - atualize uma coluna que está incluída em um índice (index1):

update table1 set column1 = value1 where id = @Id

Pega o X-Lock na table1 e tenta um X-Lock no index1.

Consulta 2:

select columnx, columny, etc from table1 where {some condition}

Pega um S-Lock no index1 e tenta um S-Lock na table1.

Existe uma maneira de evitar o impasse mantendo as mesmas consultas? Por exemplo, posso de alguma forma fazer um X-Lock no índice na transação de atualização antes da atualização para garantir que a tabela e o acesso ao índice estejam na mesma ordem - o que deve evitar o impasse?

O nível de isolamento é Read Committed. Os bloqueios de linha e página estão ativados para os índices. É possível que o mesmo registro esteja participando das duas consultas - não sei dizer pelo gráfico de deadlock, pois não mostra os parâmetros.

Gráfico de impasse