Problema estranho do SQL Server com índices e planejador de consulta

Tivemos várias falhas e restaurações alguns dias atrás e, após elas, o banco de dados do SQL Server tem agido de maneira estranha. Sabemos que houve alguns problemas com os clusters de failover devido aos quais tivemos que inicializar os servidores novamente para finalmente fazer o banco de dados aparentemente funcionar.

Um dos problemas a seguir é que executamos um grande script que eliminava dinamicamente os índices existentes e os recriava com a única diferença de que agora eles eram filtrados com a coluna WHERE NOT NULL. Por algum motivo, no entanto, quando escolho SCRIPT INDEX -> CREATE TO -> NEW QUERY WINDOW do SSMS Object Explorer, ele oferece o script básico de criação de índice em que o índice NÃO é filtrado. Quando nosso cliente com permissões totais faz o mesmo, o script de criação mostra corretamente que está filtrado.

Isso poderia ser um problema de permissão (não encontrei nenhum no Google) ou existe a possibilidade de que, embora o script tenha registrado as alterações corretamente, os nós ou o otimizador de consulta ou o que quer que esteja de alguma forma fora de sincronia?

Da mesma forma, várias consultas que anteriormente funcionavam bem (e ainda funcionam bem em um banco de dados diferente que é uma cópia deste), agora mostram por meio do plano de execução que estão se comportando de maneira diferente. Um deles tem, por exemplo, os seguintes problemas:

1. Por padrão, o planejador de execução mostra que o SQL Server usa o índice errado, produzindo milhões de linhas nos loops aninhados em vez de 2 como deveria.
2. Outro índice está correto, mas produz milhões de loops aninhados onde na cópia deste servidor obtemos apenas 3.
3. Quando a cópia é forçada a usar o mesmo índice errado do banco de dados problemático na seção 1, ela ainda retorna apenas 2 linhas em loops aninhados.

O que poderia ser a causa desses problemas e como começar a diagnosticar o problema? Como dito, os bancos de dados são cópias uns dos outros. A única diferença é que o banco de dados com problema travou onde o banco de dados foi movido para um cluster de failover e, em seguida, retornou ao nó correto novamente. Os índices não estão fragmentados, as estatísticas acabaram de ser atualizadas e parece haver uma carga extrema do planejador de consultas do SQL Server.

Eu realmente apreciaria alguns conselhos de especialistas sobre qual poderia ser a causa e como eu faria para diagnosticar o problema real, obrigado.