Rauf Asadov's questions

Eu enfrentei um comportamento incomum associado ao failover automático para que o failover automático não funcionasse no caso de desligar o serviço SQL Server. Parece que os discos clusterizados ainda permanecem anexados ao nó com falha, mas não consigo descobrir o problema final que causa esse comportamento. Ficarei muito grato a você se puder me ajudar a entender esse problema.

Para fins de teste, criei o destino iSCSI no controlador de domínio com 2 iniciadores conectados a ele:

Aqui estão os detalhes sobre meu cluster:

Aqui estão os detalhes sobre meu serviço SQL Server:

Aqui estão os detalhes sobre discos em cluster (adicionei apenas detalhes para um dos discos porque dois discos são idênticos):

Agora, quando desativo o serviço SQL Server, o failover automático de serviços não ocorre:

Testei outros cenários em que o failover automático funciona com sucesso:

1. Failover manual
2. Desligando o nó ativo
3. Desativando o adaptador no nó ativo
4. matando o processo do servidor sql no gerenciador de tarefas
5. matando o processo de serviço do agente sql no gerenciador de tarefas

Em todos os cenários acima, os recursos falharam com êxito em outro nó.

Você poderia me ajudar a descobrir o que está errado com o failover automático quando eu desligo o serviço do SQL Server no nó ativo?

Estou tentando fazer um backup diferencial do meu banco de dados primário conectando-me à réplica primária, mas não consigo. Usamos o SQL Server 2017 EE com o CU mais recente . O banco de dados está em modelo de recuperação total e os backups completos são feitos todos os dias à noite. A opção de backup somente cópia e o botão OK estão esmaecidos. Alguém poderia ajudar a entender porque não é possível realizar a ação mencionada?

Estou um pouco confuso sobre esses locais. Alguém poderia dar uma definição curta para esses locais.

Como o "limite de memória" para o processo de backup é realmente calculado?

Precisa da sua ajuda. Meu trabalho sql não pode fazer backup para a pasta compartilhada, embora a conta de domínio, na qual a conta de serviço do agente sql está sendo executada, tenha permissão total nessa pasta compartilhada.

Além disso, minha conta de serviço sql usa o login virtual padrão. Portanto, quando altero essa conta para a conta de domínio que também usei para a conta de serviço do agente sql, o problema é corrigido.

Por que não posso fazer backup para a pasta compartilhada usando a conta de serviço do agente sql?

Gostaria de fazer uma pergunta sobre o processo de recuperação ao restaurar a operação do banco de dados. Digamos que eu restaurei um backup completo NORECOVERYseguido pela restauração de dois backups t-log com NORECOVERY. Por fim, vou restaurar o último backup do 3º t-log com a palavra- RECOVERYchave.

A questão é: quando eu restauro o último backup t-log com palavra- RECOVERYchave, o SQL Server executa as fases de redo e desfazer ou apenas a fase de desfazer?

Parece-me que quando restauramos o backup com palavra- NORECOVERYchave, o SQL Server também realiza a fase de redo. A mesma coisa com a restauração de backups t-log com a palavra-chave standby. Nesse caso, o SQL Server cria um arquivo separado com o nome que contém apenas " desfazer " e não qualquer " refazer ".

o first_lsn do primeiro backup do log de transações não deveria ser 36000000022400001 em vez de 36000000022100001 ? Nesse caso, é igual a first_lsn do backup completo.

Eu tenho uma instância que é executada na instância do SQL Server 2017 Developer Edition. Eu restaurei o banco de dados ContosoRetailDW que tinha nível de compatibilidade 100. Após a operação de restauração, executo a seguinte consulta:

CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactOnlineSales ON dbo.FactOnlineSales

O índice columnstore foi criado com sucesso.

Minha pergunta está relacionada ao nível de compatibilidade. Até onde eu sei, o próprio conceito de índice columnstore foi lançado no SQL Server 2012. Além disso, o índice columnstore clusterizado foi lançado no SQL Server 2014. Como o banco de dados com nível de compatibilidade 100 suporta índice columnstore clusterizado? Parece que o banco de dados ainda herda recursos da instância atual.

Encontrei apenas essas duas declarações do BOL sobre esse método de sincronização de dados inicial:

Link 1

A propagação automática usa o transporte de fluxo de log para transmitir o backup usando VDI para a réplica secundária de cada banco de dados do grupo de disponibilidade usando os pontos de extremidade configurados.

Link 2

Durante a propagação automática, o SQL Server executa um backup pela rede para inicialização.

Examinando os logs de erro do SQL Server de réplicas primárias e secundárias, esses dois logs chamaram minha atenção:

Na réplica primária

Na réplica secundária

Minha pergunta está relacionada à natureza de trabalho da propagação automática, ou seja, onde o backup obtido é armazenado antes de restaurar na réplica secundária?

Eu tenho apenas 1 réplica secundária e apenas um banco de dados no meu grupo de disponibilidade. As réplicas primárias e secundárias estão no modo de disponibilidade de confirmação síncrona. Inseri 1000 registros na tabela e a transação foi confirmada nos bancos de dados primários e secundários. Também foram emitidos postos de controle. Agora, quando eu suspendo o banco de dados secundário e tento fazer backup de log do meu banco de dados primário para truncar o log de transações, ele não será truncado com o seguinte valor log_reuse_wait_desc: AVAILABILITY_REPLICA. Por que não é truncado?

Até onde eu sei, desde que os logs estejam inativos e o VLF seja preenchido, o log de transações pode ser truncado. Alguns de vocês podem responder de uma maneira: o SQL Server está aguardando para enviar logs para a réplica secundária do Always On Availability Group, mas minha pergunta é se 1000 registros já foram confirmados em ambos os lados e os pontos de verificação foram emitidos, quais logs estão aguardando para ser enviado para a réplica secundária?

esta pergunta foi feita duas vezes aqui, mas ainda não há resposta satisfatória. Alguém poderia explicar a principal diferença entre esses dois tempos limite?

Alguém poderia explicar qual é a principal diferença entre esses dois tipos de espera?

Simulei uma corrupção do banco de dados do modelo no ambiente de teste apenas para fins de aprendizado. Ao ler outros blogs e artigos sobre isso, fiquei na pergunta: qual é a diferença entre iniciar o SQL Server Service com sinalizadores -T3608 e -f não documentados?

Quando tentei iniciar o serviço com -f, recebi uma mensagem de erro e o serviço não foi iniciado. No entanto, no caso de -T3608, começou sem problemas. Para o sinalizador -T3608, li que -T3608 inicia todos os bancos de dados sem executar a recuperação e -f inicia a instância com configurações mínimas. O que é configuração mínima, não consigo encontrar informações sobre isso.

Eu tenho um arquivo de dados com os seguintes parâmetros:

Quando executo DBCC SHRINKFILE (DBAtools_data,1) , ele mostra os seguintes resultados:

Eu estou bem com isso. Minha reclamação é sobre o comando DBCC SHRINKFILE (DBAtools_data,0) . Quando executo nada muda. Eu pensei que isso reduziria o arquivo de dados até a última extensão alocada, em palavras de ordem, o mesmo resultado acima. Alguém poderia me esclarecer?

Eu uso o evento rpc_completed para capturar sprocs executados. Também devo visualizar a instrução e os parâmetros passados ​​usando a seguinte maneira:

clique com o botão direito do mouse em evento estendido -> Assistir a dados ao vivo e, finalmente, veja instrução + parâmetros

No entanto quero ver os dados capturados em formato de tabela, mas não consegui implementar. Quando executo a consulta abaixo, ele mostra a instrução sem parâmetros. Como posso ver os parâmetros no formulário da tabela? Precisa de suas sugestões.

IF OBJECT_ID('tempdb..#capture_waits_data') IS NOT NULL
DROP TABLE #capture_waits_data
SELECT CAST(target_data as xml) AS targetdata
INTO #capture_waits_data
FROM sys.dm_xe_session_targets xet
JOIN sys.dm_xe_sessions xes
ON xes.address = xet.event_session_address
WHERE xes.name = 'LongRunningQueries'
AND xet.target_name = 'ring_buffer';
--*/
/**********************************************************/
SELECT
CONVERT(datetime2,SWITCHOFFSET(CONVERT(datetimeoffset,xed.event_data.value('(@timestamp)[1]', 'datetime2')),DATENAME(TzOffset, SYSDATETIMEOFFSET()))) AS datetime_local,
xed.event_data.value('(@name)[1]', 'varchar(50)') AS event_type,
xed.event_data.value('(data[@name="statement"]/value)[1]', 'varchar(max)') AS statement,
xed.event_data.value('(data[@name="duration"]/value)[1]', 'bigint')/1000 AS duration_ms,
xed.event_data.value('(data[@name="physical_reads"]/value)[1]', 'bigint') AS physical_reads,
xed.event_data.value('(data[@name="logical_reads"]/value)[1]', 'bigint') AS logical_reads
FROM #capture_waits_data
CROSS APPLY targetdata.nodes('//RingBufferTarget/event') AS xed (event_data)
WHERE 1=1 and xed.event_data.value('(action[@name="username"]/value)[1]', 'varchar(255)') <> 'NT SERVICE\SQLSERVERAGENT'

Aqui está o evento estendido usado real:

CREATE EVENT SESSION [LongRunningQueries] ON SERVER 
ADD EVENT sqlserver.rpc_completed(
    ACTION(package0.collect_system_time,sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_id,sqlserver.username)
    WHERE ([duration]>(4000000) AND [sqlserver].[database_name]='mydb')),
ADD EVENT sqlserver.sql_statement_completed(
    ACTION(package0.collect_system_time,sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_id,sqlserver.username)
    WHERE ([duration]>(4000000) AND [sqlserver].[database_name]='mydb')) 
ADD TARGET package0.ring_buffer(SET max_events_limit=(0),max_memory=(102400))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=5 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

Se o Oracle detectar que uma recuperação de instância é necessária (como a emissão do comando shutdown abort ou ocorrer uma falha), ele inicializará o processo de recuperação. E o SQL Server? Ele se comporta da mesma forma?

Em outras palavras, se eu executar o desligamento limpo da instância do SQL Server (como Parar o sql server usando o console de serviços ou emitir o comando de desligamento no SSMS) e, em seguida, inicializar a instância, o processo de recuperação será executado ou não?

Tenho o banco de dados AdventureWorks2014 instalado no meu SQL Server 2014 de teste. Estou planejando executar a seguinte consulta:

SELECT *
FROM Sales.SalesOrderDetail sod
INNER JOIN Production.Product p ON sod.ProductID = p.ProductID
ORDER BY Style

Antes de realmente executá-lo, tenho a seguinte imagem dos meus threads de trabalho:

Durante a execução da consulta, verifiquei novamente o estado dos threads de trabalho:

Como você pode ver, o total de active_workers_count na 2ª imagem é maior do que na 1ª captura de tela. A partir da segunda captura de tela, posso supor que o total de threads de trabalho necessários para a execução da consulta foi 1+2+1+2=6. No entanto, quando dou uma olhada nas propriedades do operador de varredura de índice no meu plano de execução, vejo:

Parece que meu grau de paralelismo era 4, o que significa que 4 threads estavam processando linhas paralelamente.

Estou confuso e não consigo determinar quantos threads estavam sendo executados durante a execução da consulta. Alguém pode me explicar por que active_workers_count é diferente de DOP?

Li um ótimo artigo publicado por Brent Ozar e fiz algumas perguntas relacionadas à concessão de memória. Não consigo responder às minhas perguntas na seção de comentários do artigo dele, então pensei em obter ajuda aqui.

1. Pergunta: Quantos dados são derramados no disco? 400 MB ou 60 MB (7643 KB*8)?

no artigo ele afirma:

E não importa quantas vezes eu atualize as estatísticas, ainda obterei um vazamento de ~ 400 MB no disco.

estou meio confuso aqui (

2. Pergunta: Se tudo estiver bem com as estimativas, as estatísticas estiverem atualizadas, a caixa tiver memória suficiente e nenhuma consulta estiver sendo executada naquele momento, por que ocorre o vazamento para o disco?

observe o número estimado de linhas versus o número real de linhas. Eles são idênticos. As estatísticas estão boas.

Também não estou usando um servidor pequeno: minha máquina virtual tem 32 GB de RAM e aloquei 28 GB disso para o SQL Server. Não há outras consultas em execução ao mesmo tempo - é apenas uma consulta solitária, derramando no disco...

Instalei um provedor Oracle OraOLEDB.Oracle. Agora quero remover esse provedor da lista. Como eu posso fazer isso?

Estou tentando entender o gerenciamento de memória do SQL Server. Tenho um Windows Server 2019 em ambiente virtual com 64 GB de RAM. Também tenho o SQL Server 2019 instalado com Max Server Memory 59776 MB. Usando a seguinte consulta, encontrei a lista de todos os funcionários de memória:

SELECT  [type] AS [ClerkType], SUM(pages_kb) / 1024 AS [SizeMb]
FROM sys.dm_os_memory_clerks WITH (NOLOCK)
GROUP BY [type]
ORDER BY SUM(pages_kb) DESC

A soma total de todos os funcionários de memória foi igual a 23523 MB.

Value for MEMORYCLERK_SQLBUFFERPOOL memory clerk is 18387 MB.

Também verifiquei alguns contadores de desempenho:

Total Server Memory (KB) = 32262 MB.
Database Cache Memory (KB) = 18387 MB.

Por favor, corrija-me se alguma das afirmações abaixo estiver errada,

Max Server Memory for SQL Server 2019 = Buffer Pool Memory + Non-Buffer Pool Memory.

Total Server Memory (KB) - The committed memory from the Buffer Pool.

Data Cache Memory (KB) performance counter is equivalent to MEMORYCLERK_SQLBUFFERPOOL memory clerk and both represents data cache used size.

Above query shows all memory clerks for both Buffer Pool Memory and Non-Buffer Pool Memory.

Minha dúvida relacionada a este assunto:

Se o Total Server Memeory (KB) está relacionado à memória do Buffer Pool, então por que seu tamanho (32262 MB) é maior do que o total de memória total dos funcionários (23523 MB), o que representa tanto a Memória Buffer Poll quanto a Memória Non-Buffer Pool?

EDIT: Resultado da seleção * de sys.dm_os_process_memory