user541852587's questions

Outro dia, alguém me disse que um recurso do SQL Server 2016 envolvendo secundários somente leitura para geração de relatórios era que o secundário somente leitura poderia ter índices diferentes do primário. Eu procurei por isso em todos os lugares e não achei que fosse esse o caso. Na verdade, a Microsoft parece indicar o contrário aqui (desta forma, a indexação é semelhante a 2012).

Apenas curioso para saber se estou lendo isso corretamente; secundários somente leitura com indexação diferente forneceriam uma opção para geração de relatórios, mas não os vejo compatíveis com grupos AG em nenhuma versão do SQL Server.

Com a replicação de mesclagem, se o assinante ficar sem identidades para um intervalo quando ocorrerem inserções nele, o assinante lançará um erro na inserção na tabela, porque é a publicação que deve conceder mais identidades - e a inserção está acontecendo no assinante. Uma prática melhor seria fazer com que o editor seja apenas o receptor das inserções, mas em alguns ambientes ou situações, as inserções podem ocorrer tanto para o editor quanto para o assinante, portanto, muitas pessoas estendem o intervalo.

Estou curioso para saber como as sequências se comparam às identidades aqui, pois não consigo encontrar nenhuma indicação de que as sequências sejam limitadas por configurações de replicação de mesclagem, como os campos de identidade.

Acredito que Aaron Bertrand ou outro MVP tem sido muito bom em sequências e tenho tentado forçar minha organização a usá-las em vez de identidades, mas é uma longa jornada.

Cenário: Tenho uma tabela OLTP pesada com um índice. Vejo muitas inserções, atualizações e exclusões e o índice fragmenta-se fortemente em um dia ou menos. Enquanto no primeiro dia da criação do índice, o otimizador usa o índice, no segundo ou terceiro dia, o otimizador o ignora totalmente. Isso é exatamente para a mesma consulta.

Pergunta na minha cabeça: por que alguns planos de consulta pulariam o índice, já que o índice é criado para ajudar a otimizar esses planos?

Pergunta para esta postagem: o otimizador pode ignorar um índice altamente fragmentado, como um cenário em que temos 1 bilhão de registros e um índice é criado e, duas horas depois, todos os bilhões de registros são removidos e temos quinhentos milhões de novos registros?

Estou começando a pensar que adicionar um índice a esta tabela não ajudará em nada, devido à natureza da tabela (dados entram rapidamente, dados saem rapidamente), mas só quero entender por que um dia, o otimizador irá usar o índice em seus planos, mas dia dois, não.

Suponha que eu tenha uma tabela com 1000 registros e tenho a consulta abaixo, que retornaria 7 registros no total:

SELECT *
FROM MyTable
WHERE IndexedColumn > 5000
     AND OtherIndexedColumn = 2

Como as duas colunas têm índices atualizados, o SQL Server pode fazer suposições e encontrar os valores mais rapidamente e ambas as consultas são SARGable (idealmente menos leituras). No entanto, suponha que eu precise ter certeza de que o valor não é igual a outro valor, digamos 12 para uma coluna diferente, então eu teria que adicionar

AND AnotherIndexedColumn <> 12

Se essa for a última instrução da WHEREcláusula, o SQL Server usa o SARGability nas duas primeiras instruções WHERE para primeiro filtrar, obter as 7 linhas e, em seguida, verificar se cada linha das 7 não é igual a 12 ou se aplica o <>para cada linha no conjunto de dados original de 1000 linhas?

O motivo que estou perguntando é porque estou ciente que poderia usar uma subconsulta ou CTE para fazer a primeira parte do filtro SARGable, depois das 7 linhas, olhe e veja se cada uma não é igual, mas é a consulta otimizador já está fazendo isso nos bastidores, ou é melhor fazer isso sozinho?