O artigo BOL de compatibilidade de versão do SQL informa que a versão mínima do driver JDBC compatível para SQL Server 2019 é 7.4.
Um driver JDBC mais antigo ainda pode se conectar ao SQL Server 2019? Ou apenas as versões de driver listadas como compatíveis podem se conectar às versões especificadas do SQL Server?
Temos um AG de 4 nós configurado em dois data centers usando 4 réplicas com uma testemunha de compartilhamento de arquivos. Os nós 1 e 2 estão no datacenter 1 e os nós 3 e 4 no datacenter 2. O nó 1 é primário e está configurado para confirmação síncrona com failover automático para o nó 2 no mesmo datacenter. O nó 1 é configurado para confirmação assíncrona para os nós 3 e 4 no datacenter 2. A ponderação do nó é configurada para um para os nós 1 e 3 (nó principal em cada datacenter) e zero para os nós 2 e 4.
Por favor, alguém pode me dizer qual seria o comportamento se tivéssemos um SQL Server inesperado desligado no nó 1?
O AG tentaria fazer failover para o nó 3 no data center 2 devido à ponderação do nó, falharia e não tentaria fazer failover para outras réplicas. Ou o grupo AG ignoraria o nó 3 por ser assíncrono e tentaria fazer failover para a primeira réplica síncrona com failover automático com base na lista do proprietário preferencial?
É meu entendimento que, quando você reconstruir um índice, o SQL classificará as páginas em ordem no final do arquivo de dados, aumentando o arquivo de dados até que todas as páginas sejam ordenadas e, em seguida, descarte o índice antigo, deixando extensões não contíguas vazias no arquivo de dados.
O que acontece então quando você recria um segundo índice? O SQL executa a mesma ação, aumentando o arquivo de dados ou move o segundo índice para as antigas extensões fragmentadas deixadas pelo primeiro índice? Se ele usar as extensões antigas, a reconstrução criaria um novo índice fisicamente fragmentado?
Editado: Por que os relatórios de sessões estão sendo bloqueados, mas aguardando com tipos de espera PAGELATCH_*não relacionados?LCK_M_
Presumi anteriormente que o servidor SQL reportaria apenas as sessões de bloqueio na coluna blocking_session_Id. Se as sessões bloqueadas estivessem esperando por um bloqueio lógico e nada mais, como um arquivo PAGELATCH_*.
O SQL Server não está retornando todas as informações do nó quando destruo o XML de impasse do evento 2012 system_health Extended.
Quando executo a seguinte consulta
SELECT CAST(event_data.value('(event/data/value)[1]','varchar(max)') AS XML) AS DeadlockGraph
FROM (
SELECT XEvent.query('.') AS event_data
FROM ( -- Cast the target_data to XML
SELECT CAST(target_data AS XML) AS TargetData
FROM sys.dm_xe_session_targets st
INNER JOIN
sys.dm_xe_sessions s
ON s.address = st.event_session_address
WHERE name = 'system_health'
AND target_name = 'ring_buffer'
) AS Data -- Split out the Event Nodes
CROSS APPLY
TargetData.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData ( XEvent )
) AS tab ( event_data )
em nossa instância do Microsoft SQL Server 2008 R2 (SP3) - 10.50.6000.34, todas as informações do nó são retornadas junto com as descrições, ou seja,
<deadlock>
<victim-list>
<victimProcess id="process10e26bc8" />
</victim-list>
<process-list>
<inputbuf>
Proc [Database Id = 26 Object Id = 1641213047]
</inputbuf>
</process-list>
...
...
...
</deadlock>
No entanto, quando eu o executo em nossa instância do Microsoft SQL Server 2012 - 11.0.5548.0, todas as informações e descrições do nó são removidas e apenas o texto é retornado, ou seja,
Proc [Database Id = 26 Object Id = 1641213047]
O que pode causar isso? A hierarquia XML completa é gerada em nossa instância de 2012 se eu remover a SELECT CAST(event_data.value('(event/data/value)[1]','varchar(max)')parte da consulta.
Estamos vendo tipos de espera PAGELATCH_EX e PAGELATCH_SH muito altos junto com esperas WRITELOG altas. Eu diagnostiquei a consulta que causa as esperas PAGELATCH e posso eliminá-las reduzindo a taxa de inserção em uma chave primária agrupada ocupada definida com um valor IDENTITY. Entendo que esse fenômeno é conhecido como contenção de trava de inserção da última página.
No entanto, minha pergunta é quando um novo registro é inserido, o SQL Server pega um PAGELATCH_EX exclusivo em uma página de buffer, insere o registro na página do buffer, grava o registro no log de transações e libera o PAGELATCH_EX exclusivo conforme detalhado https:// www.microsoft.com/en-ie/download/details.aspx?id=26665 Página 24. Ou ele grava o registro no log de transações primeiro antes de usar o PAGELATCH_EX conforme detalhado "Resolvendo a contenção de PAGELATCH em cargas de trabalho INSERT altamente simultâneas - Informações básicas Guia do SQLCAT para: Mecanismo Relacional
Se o registro for gravado fora do mecanismo de travamento, posso descartar gravações lentas no disco como causa de altas esperas de PAGELATCH. Mas se a trava for mantida até que o registro seja endurecido para log, provavelmente devo levar o WRITELOG em consideração.
Além disso, ter vários índices não clusterizados faria com que a trava PAGELATCH_* fosse mantida por mais tempo, ou seja, se uma tabela tivesse um cluster e vários índices não clusterizados fossem adicionados e liberados para cada uma das páginas do buffer de índice simultaneamente?
Atualização 1 Depois de ler o slide dois do confio-sql-server-writelog-wait e a arquitetura geral do WAL. Agora entendo que a etapa "Registrar uma entrada de log de que a linha foi modificada" detalhada em ambos os white papers refere-se ao SQL Server registrando uma alteração no cache do log de transações, não no disco. Assim que a transação for concluída ou o buffer estiver cheio, todos os registros serão imediatamente descarregados no disco.
Um de nossos editores é assinado por três assinantes, cada assinante é hospedado em seu próprio servidor físico. Dois desses assinantes são 2008R2 e o terceiro 2012. O assinante 2012 está experimentando latência diariamente durante os horários de pico.
Depois de executar algum rastreamento de evento estendido por alguns dias, posso ver que a latência coincide com tempos de execução sp_MSget_repl_commands lentos no distribuidor e, mais especificamente, a consulta de seleção final encontrada na linha 724 "-- Mini join junto. Apenas agent_id e colunas article_id em dbo.MSsubscriptions". O tempo de execução dessa instrução pode chegar a >= 20 minutos.
O thread do leitor do distribuidor espera que toda a execução de sp_MSget_repl_commands seja concluída antes de começar a gravar comandos replicados nos buffers de comando? Ou ele começa a gravar comandos replicados nos buffers de comando assim que são retornados pelo SP? Vejo que a declaração problemática é sugerida com OPTION (FAST 1), o que pode sugerir que esse é o caso. Se o thread do leitor aguardar a conclusão de sp_MSget_repl_commands antes de começar a gravar comandos replicados no buffer de comando, isso pode explicar a latência, caso contrário, não tenho certeza. Há mais alguma coisa óbvia que eu possa monitorar?
O MSdistribution_history.comments sugere que o assalto está no assinante. No entanto, nenhum procedimento armazenado de assinante replicado está sendo concluído em >= 100 ms e não há nenhuma contenção de recursos do servidor físico óbvio. Descartei a rede porque também há outros bancos de dados de assinantes no mesmo servidor físico sendo preenchidos na mesma rede que não estão experimentando latência.
Depois de ler o Guia de desempenho de carregamento de dados , ainda não tenho certeza se é necessário adicionar a dica de tabela TABLOCK a uma tabela temporária vazia, definida com um índice clusterizado, para obter um registro mínimo.
Obviamente, a tabela temporária é criada no TempDB, que opera no modo de recuperação SIMPLE, então eu pensei que era um candidato perfeito para log mínimo; no entanto, não consigo encontrar uma passagem para confirmá-lo.
Uma tabela temporária é candidata para registro mínimo e, em caso afirmativo, vale a pena adicionar a dica TABLOCK conforme recomendado para tabelas permanentes?
A coluna de comentário de distribuidor.dbo.MSdistribution_history contém comentários como
<stats state="2" fetch="11554" wait="214007" cmds="17898546" callstogetreplcmds="106880">
<sincelaststats elapsedtime="300" fetch="8" wait="291" cmds="1948689" cmdspersec="6495.000000" />
</stats>
O valor do estado se traduz em
STATE Indication
1 Normal Log
2 Reader Thread has to WAIT for Writer
3 Writer Thread has to WAIT for Reader
O comentário está me dizendo que o thread do leitor está aguardando o thread do gravador, mas leu 1948689 cmds desde a última entrada de estatísticas. Ou está me dizendo que o thread do leitor está esperando pelo thread do gravador e o thread do gravador escreveu 1948689 cmds desde a última entrada de estatísticas?