Miranda's questions

Se eu tiver um índice com fator de preenchimento padrão de 100% e as modificações resultarem em uma grande fragmentação interna (divisões de páginas, espaço livre etc.), de modo que muitas páginas fiquem cerca de 60% cheias em vez de 100%, seria uma reconstrução/reorganização de índice compacta os dados em menos páginas de dados, resultando em mais espaço disponível relatado no banco de dados?

Se o anterior for verdadeiro, faz sentido reorganizar os índices antes de executar uma operação de redução para maximizar o espaço ganho pela redução (seguida por outra reorganização após a redução para reduzir a fragmentação causada pela redução)?

Finalmente, o DBCC Shrinkfile compacta as páginas de dados da mesma forma que uma reconstrução ou apenas move as páginas de dados?

Para a consulta abaixo, estou tentando descobrir por que o índice sugerido pelo SQL Server na tabela sysjobhistory, que também é o índice que resulta em uma busca, foi criado na coluna Job_Id com as outras colunas incluídas:

Job_Id inclui (Run_date, Run_time, Instance_id)

No meu entender, as colunas em uma cláusula where devem estar presentes na chave do índice para que as buscas sejam possíveis. Run_date e Run_time estão presentes na cláusula where da consulta abaixo, então como podemos colocá-los na inclusão de um índice em vez de tê-los como colunas-chave?

A pergunta:

SELECT TOP 10000 run_date
     FROM msdb.dbo.sysjobhistory sh
     WHERE EXISTS (SELECT 1 FROM msdb.dbo.sysjobs sj WHERE sh.job_id = sj.job_id
     AND EXISTS (SELECT 1 FROM msdb.dbo.sysjobschedules sjs WHERE sjs.job_id = sj.job_id
     AND EXISTS (SELECT 1 FROM msdb.dbo.sysschedules ss WHERE ss.schedule_id = sjs.schedule_id 
     AND ss.freq_subday_type = 2
     AND ss.freq_subday_interval = 10 ))) 
     AND CAST(CAST([run_date] AS CHAR(8)) + ' ' + STUFF(STUFF(RIGHT('000000' + CAST([run_time] AS VARCHAR(6)), 6), 3, 0, ':'), 6, 0, ':') AS DATETIME) < dateadd(hh,-12,getdate()) 

Nota: não estou usando junções porque esta consulta faz parte de um cte do qual eu excluo, portanto, junções não são possíveis.

É possível associar um computador Windows Server 2016 a um cluster de failover de 2 nós do Windows Server 2022 existente? O cluster é independente de domínio.

Configuração hipotética:

1. Nó 1 (servidor windows 2022 + Sql Server 2022)
2. Nó 2 (Windows Server 2022 + Sql Server 2022) Os nós 1 e 2 estarão em um cluster de failover
3. Nó 3 (servidor windows 2016 + Sql Server 2016)

Meu objetivo é associar o computador Windows Server 2016 que executa o SQL Server 2016 a um cluster de failover do Windows Server 2022 que executa o SQL Server 2022. Esta será uma configuração do Grupo de Disponibilidade Always On.

Depois que os Nó 1 e 2 estiverem sincronizados com o Nó 3, planejo fazer failover para o Nó 1 e remover o nó 3 do cluster.

Eu sei que os Grupos de Disponibilidade Always on podem ser configurados em um cluster de failover do Windows Server sem integração com o Active Directory.

Mas uma solução de alta disponibilidade de Instância de Cluster de Failover do SQL Server pode ser criada sem a integração do Active Directory? Não encontrei nada sobre o assunto na internet.

No momento, estou pensando em usar a solução Index Maintenance de Ola Hallengren para atualizar as estatísticas uma vez por dia. Qual é o benefício desta solução se um banco de dados tiver AUTO_UPDATE_STATISTICS ativado?

Estou no SQL Server 2016.