Tony Hinkle's questions

Durante a reindexação usando o procedimento armazenado IndexOptimize do Ola , as filas de envio de log para réplicas assíncronas remotas podem crescer bastante se houver muitas desfragmentações de índice grandes, exigindo logs de transação gigantescos. Há um parâmetro @Delay no script que pode ser usado para inserir um atraso entre cada operação de índice, mas ele não fornece a capacidade de atraso somente quando as filas de envio de log são altas.

Um mecanismo de limitação mais inteligente é necessário para controlar os tamanhos da fila de envio de log durante a reindexação pesada.

E sim, eu sei que a reindexação não é realmente necessária com nossos SSDs corporativos, mas fazemos isso para apaziguar as organizações de suporte de terceiros que culparão a fragmentação por qualquer problema de desempenho.

Se o tempdb ficar sem espaço, as transações que precisam de espaço de armazenamento de versão falham ou aguardam a liberação de espaço?

Um trabalho do SQL Agent com uma etapa do Pacote do SQL Server Integration Services falha com a seguinte mensagem:

Executado como usuário: DOMAIN\SQLAGENTACCOUNT. Microsoft (R) SQL Server Execute Package Utility Versão 13.0.4259.0 para 64 bits Copyright (C) 2016 Microsoft. Todos os direitos reservados. Uma opção de relatório inválida foi especificada. Apenas E, W, I, C, D, P, V e N são permitidos. Os parâmetros da linha de comando são inválidos. A etapa falhou.

Eu tenho um grupo de disponibilidade (AG) com vários bancos de dados (DB-A, DB-B, DB-C) e vários secundários (SEC-B, SEC-C) e um dos bancos de dados não retomará a sincronização em apenas um dos os secundários.

Para este exemplo, o DB-C não está sincronizando no SEC-C e nenhuma quantidade de reinicialização do SQL Server ou retomada do HADR fará com que ele seja iniciado novamente.

• Eu não quero remover a réplica (secundária SEC-C) do AG porque eu teria que ressincronizar todos os bancos de dados (DB-A, DB-B e DB-C), e isso levaria mais tempo do que é necessário.

• Também não quero remover completamente o banco de dados (DB-C) do AG porque existem outros secundários (SEC-B) onde não há problema e não quero ter que ressincronizá-lo ou perder temporariamente meu HADR no secundário onde está funcionando.

Como posso remover apenas este banco de dados secundário do AG, ressincronizá-lo e adicioná-lo novamente ao AG?

Supondo que o despejo de pilha em questão não possa ser mapeado para um problema conhecido, se um despejo de pilha não parecer causar um problema e tudo estiver funcionando depois, um incidente de suporte deve ser aberto para ele? Ou os incidentes devem ser abertos apenas quando causam uma interrupção ou perda de funcionalidade?

Tempdb está crescendo e são todos os dados de armazenamento de versão. Quando eu corro:

select hostname,elapsed_time_seconds,session_id, transaction_id, is_snapshot, blocked, lastwaittype, cpu, physical_io,  open_tran, cmd 
from sys.dm_tran_active_snapshot_database_transactions a
join master..sysprocesses b
on a.session_id=b.spid 
order by a.elapsed_time_seconds desc

Isso mostra duas sessões com decorridos_time_seconds quase 400.000 (~4,5 dias). No entanto, a coluna open_tran para essas sessões é zero toda vez que eu verifico. O aplicativo está usando transações implícitas - não tenho certeza se isso é relevante.

Além disso, o nome de host relatado para uma dessas sessões foi alterado (não, nem os endereços IP nem os nomes de host foram alterados) a partir desta manhã. Então, parece que talvez o cliente que tinha esse id de sessão esta manhã desconectado e outro cliente tem esse id de sessão agora.

Embora não mostre transações ativas para essas sessões na maioria das vezes, encontro transações que correspondem a transaction_id em sys.dm_tran_active_transactions com as seguintes propriedades:

transaction_begin_time: [~4.5 days ago]
name: DTCXact
transaction_type: 4
transaction_state: 2
transaction_status: 12
transaction_status2: 386
dtc_state: 1
dtc_status: 0
dtc_isolation_level: 4096

Existe uma maneira de explicar o que estou vendo? Se não houver transações abertas, por que eles ainda teriam algo ativo na loja de versões?

SQL Server 2014 SP2 12.0.5214.6

Em um sistema que tenha o isolamento de instantâneo confirmado de leitura habilitado, as estatísticas de leituras, gravações, CPU etc. retornadas por sp_whoisactive incluem a atividade associada à manutenção de versões no tempdb?

Recentemente, atualizamos um sistema SQL Server 2008 R2 de não produção para SP3 e, em seguida, as atualizações do Windows instalaram a atualização de segurança mais recente (10.50.6560.0). Vejo que o suporte a TLS 1.2 para 2008 R2 é fornecido em 10.50.6542.0, mas essa atualização não será instalada em cima de 6560. As tentativas de login estão falhando e posso ver no Visualizador de eventos que o cliente está solicitando o TLS 1.2, mas o servidor não não apoiá-lo.

O SSMS retorna:

...(provedor: Provedor SSL, erro: 0 - Uma conexão existente foi fechada à força pelo host remoto.)
(Microsoft SQL Server, Erro: 10054)

Log de eventos do sistema no servidor:

ID do evento 36874
Uma solicitação de conexão TLS 1.2 foi recebida de um aplicativo cliente remoto, mas nenhum dos conjuntos de codificação com suporte do aplicativo cliente é compatível com o servidor. A solicitação de conexão SSL falhou.

Eu tentei atualizar os vários clientes SQL no cliente e no servidor, habilitando o TLS 1.2 no registro no servidor (e reinicializando), sem sucesso. Então agora estou começando a pensar que o build 6560 não o suporta e, se for esse o caso, tenho que desinstalá-lo de alguma forma para poder instalar o build 6542 primeiro.

Temos outros servidores executando a mesma compilação que funcionam bem, então estou tentando descobrir o que há de diferente nesse servidor - ainda sem sorte.

Na saída de sp_WhoIsActive, colunas como leituras, gravações, CPU e wait_info são cumulativas para a sessão ou apenas cumulativas para o lote? Temos uma consulta que está bloqueando muito e mostrando milhões de leituras, mas quando executo as oito consultas no lote do SSMS, as leituras estão em um dígito, então estou tentando entender se algo diferente está ocorrendo com o maneira como o aplicativo o está executando para fazer com que ele leia muito mais.

Ou pode ser algo diferente? Percebo que a sessão tem 2 transações abertas. Essas estatísticas podem representar todas as transações que a sessão tem atualmente ativas?

Após a implantação de um pacote SSIS de um servidor de desenvolvimento para outro ambiente, a execução e validação do pacote falham com o seguinte erro:

Erro: A versão de #5) Source - ODBC - Greenplum [nome do objeto] não é compatível com esta versão do DataFlow

As versões do driver ODBC do SQL Server e Greenplum são as mesmas em todos os servidores relevantes. Os servidores estão executando o SQL Server 2016 e o ​​SQL Server Management Studio 2017 está sendo usado para implantar o pacote entre servidores.

Supondo que uma organização tenha tudo o que é necessário para usar os Grupos de Disponibilidade com sucesso e que ela esteja usando os Grupos de Disponibilidade com sucesso por alguns anos, há algum motivo pelo qual o envio de logs seria uma solução de DR melhor? Parece que as pessoas ainda estão colocando o log shipping só porque ele pode atender o RPO e o RTO. Mas se não custa nada extra usar um AG em vez disso, e a equipe do DBA tem experiência com AGs, por que o envio de logs seria melhor?

A única coisa em que consigo pensar é que o atraso interno do envio de logs permite que se recupere rapidamente no caso de alguém esquecer de colocar uma cláusula WHERE em uma instrução UPDATE ou DELETE - se for detectada a tempo. Improvável, e não é algo que nos preocupe.

Minha experiência geral é que o envio de logs requer mais intervenção e ajustes à medida que a carga do banco de dados aumenta, é mais difícil de fazer failover e geralmente é um pouco uma máquina de Rube Goldberg (embora um espécime bastante bem-sucedido dessa classe de máquina).

Estamos trabalhando sob a exigência de que todas as conexões com o SQL Server sejam criptografadas. Depois de configurar um Reporting Server (2016), vejo uma conexão não criptografada com o SQL Server. Ainda não há fontes de dados configuradas, portanto, esta não é uma conexão associada a fontes de dados de relatório, é apenas a conexão que o RS faz com o banco de dados ReportServer. Não vejo uma opção para criptografar a conexão em nenhum lugar da configuração em que o banco de dados e as credenciais estão configurados.

Como essa conexão pode ser configurada do lado do cliente para usar criptografia? Não quero forçar a criptografia no lado do servidor, pois isso pode interromper outras conexões (que estamos trabalhando para criptografar). Sim, temos um certificado instalado e funcionando - podemos conectar com criptografia do SSMS e outros clientes.

Não se trata de configurar o RS para usar HTTPS no portal. Isso está configurado e funcionando.

Em um sistema SQL Server 2014 12.0.4237.0, os seguintes erros foram registrados periodicamente (11 vezes nos últimos 66 dias):

2018-03-22 09:28:11.170 Erro: 50101, Gravidade: 16, Estado: 10.
2018-03-22 09:28:11.170 Falha de procedimento armazenado interno - ID_TransUserActionCreate - Erro SQL número 0

Ainda não encontrei nenhuma referência a um erro com o código 50101, e o Google, surpreendentemente, não retorna absolutamente nada para "ID_TransUserActionCreate".

Quanto a "o que está acontecendo no momento em que isso é registrado", ainda não sei, pois existem vários bancos de dados no sistema e ainda não começamos a coletar informações detalhadas para responder a essa pergunta. Portanto, esta pergunta é para perguntar se alguém sabe, ou tem uma boa ideia, o que essa mensagem significa e/ou se é algo com que eu deveria me preocupar.

Estou tentando descobrir qual consulta (ou consultas) precisa ser executada para determinar se há algum tipo de problema com um grupo de disponibilidade. Eu tenho usado:

SELECT @@SERVERNAME AS 'primary_replica', cs.database_name, rs.synchronization_health_desc
FROM sys.dm_hadr_database_replica_states rs
join sys.dm_hadr_database_replica_cluster_states cs on rs.replica_id = 
    cs.replica_id and rs.group_database_id = cs.group_database_id
WHERE rs.is_local = 1

Acontece que a integridade da sincronização ( select * from sys.dm_hadr_availability_group_states) pode ser NOT_HEALTHY, mas a consulta acima não apresenta nenhum problema com a réplica. Eu tentei olhar através de todos os vários DMs que contêm informações, mas é um labirinto ou palavras e não consigo encontrar o caminho para o queijo SQL que deve estar lá em algum lugar.

Qual é a única consulta que indicará que há um problema que precisa ser resolvido? Não preciso que seja específico ou designe a causa, só preciso saber que há um problema. Eu sei que durante o failover alguns dos estados serão NOT_HEALTHY, e nós explicamos isso exigindo x minutos de insalubridade antes de enviar um alerta.

Estou usando KB2977316 e KB3045324 para este exemplo. Estas são atualizações de segurança para o SQL Server 2014 RTM.

• KB2977316 é a versão 12.0.2381.0 publicada em 02/06/2015
• KB3045324 é a versão 12.0.2269.0 publicada em 13/07/2015

Se eu tiver um sistema SQL Server 2014 RTM, preciso instalar os dois, apenas o último lançado ou aquele com o número de versão mais alto? A atualização 2381 é um download de 600 MB, enquanto a versão 2269 tem 183 MB, então a lógica ditaria que 2269 não contém todas as correções incluídas no 2381 e eu preciso instalar ambas. Acho que o que está me atrapalhando é que parece estranho que o número da versão diminua à medida que as atualizações mais recentes são instaladas.

Limite o escopo das respostas e comentários apenas às atualizações de segurança. Esta pergunta não tem nada a ver com CUs ou SPs (exceto que diferentes atualizações de segurança serão aplicadas com base no nível específico de CU ou SP). Obrigado!