Perguntas[sql-server-2019](dba)

Não consigo encontrar detalhes sobre como SNAPSHOT ISOLATIONfunciona. Testei a seguinte consulta no SQL Server 2019 (com o ADR desabilitado):

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRAN;
WAITFOR DELAY '00:00:20'; -- insert of one record to dbo.MARA_CT in different session
SELECT
    *
FROM dbo.MARA_CT AS mc;
WAITFOR DELAY '00:00:20'; -- insert of one record to dbo.Album in different session
SELECT
    *
FROM dbo.Album AS a;
WAITFOR DELAY '00:00:20';
SELECT
    *
FROM dbo.MARA_CT AS mc;
SELECT
    *
FROM dbo.Album AS a;
COMMIT;

Conforme observado no comentário, inseri uma linha em dbo.MARA_CTe, durante a segunda WAITFOR DELAY, inseri um registro em dbo.Album. De acordo com a documentação da Microsoft:

The term "snapshot" reflects the fact that all queries in the transaction see the same version, or snapshot, of the database, based on the state of the database at the moment in time when the transaction begins.

Os resultados que obtive da minha consulta são os seguintes:

1. dbo.MARA_CT contém o registro inserido durante o primeiro WAITFOR DELAY '00:00:20'.
2. dbo.Album não contém o registro inserido durante o segundo WAITFOR DELAY '00:00:20'.

Parece-me que o "primeiro contato" com qualquer tabela na consulta cria um "instantâneo" de toda a transação, em vez de capturar o estado do banco de dados no momento em que a transação começa. Em relação a isso SNAPSHOT ISOLATION, tenho perguntas adicionais:

1. O ISOLAMENTO DE SNAPSHOT armazena todas as versões desde o início da transação para todas as linhas do banco de dados ou apenas para as tabelas usadas na consulta? Como isso funciona?

2. Se o RCSI estiver habilitado e posteriormente habilitarmos o ISOLAMENTO DE SNAPSHOT, o SQL Server armazenará novos valores/versões no tempdb?

3. O objetivo do uso, SNAPSHOT ISOLATIONno meu caso, é testar novas versões de procedimentos e visualizações (novo esquema). Tanto os procedimentos novos quanto os antigos precisam retornar o mesmo número de registros e utilizar os mesmos dados, mesmo que as tabelas envolvidas passem por constantes inserções, atualizações e exclusões. Considerei usar um snapshot do banco de dados, mas agora vejo que SNAPSHOT ISOLATIONpode ser ainda mais vantajoso, já que o RCSI já está habilitado nos bancos de dados.

Tenho um banco de dados em uma instância do SQL Server 2019 que tem o armazenamento de consultas habilitado e já faz isso há muitos anos

De repente, o estado do repositório de consultas retornou por

SELECT actual_state_desc FROM sys.database_query_store_options

foi para

ERRO

então eu reativei

ALTER DATABASE [BOB] SET QUERY_STORE (OPERATION_MODE = READ_WRITE)

e tudo estava bem. No entanto, algumas horas depois, a mesma coisa aconteceu e notei a seguinte mensagem no log do SQL Server na mesma hora

Erro interno FILESTREAM: falha ao acessar a tabela de coleta de lixo.

Parece que os dois estão relacionados, embora eu não tenha certeza de como exatamente.

Nosso banco de dados não possui nenhum arquivo filestream:

SELECT  COUNT(*)
FROM    sys.database_files
WHERE   type_desc = 'FILESTREAM'

retorna 0

Reativei o armazenamento de consultas mais uma vez, mas gostaria de entender o que está acontecendo aqui para evitar que isso aconteça novamente no futuro.

Alguém pode me dizer o que está acontecendo e como posso consertar?

Eu uso o script a seguir para fazer um .bak de um banco de dados de produção e salvá-lo em um servidor de teste onde ele pode ser restaurado se necessário. O script não declara para compactar o arquivo. Executando o SQL Server 2019 Enterprise.

BACKUP DATABASE [PINK] 
    TO DISK = N'\\TestServer\Transfer\PINK.bak' 
    WITH NOFORMAT, INIT,  NAME = N'PINK', SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM
GO

DECLARE @backupSetId AS int

SELECT @backupSetId = position 
FROM msdb..backupset 
WHERE database_name = N'PINK' 
  AND backup_set_id = (SELECT MAX(backup_set_id) 
                       FROM msdb..backupset 
                       WHERE database_name = N'PINK')

IF @backupSetId IS NULL
BEGIN
    RAISERROR(N'Verify failed. Backup information for database ''PINK'' not found.', 16, 1) 
END

RESTORE VERIFYONLY 
    FROM DISK = N'\\TestServer\Transfer\PINK.bak' 
    WITH FILE = @backupSetId, NOUNLOAD, NOREWIND
GO

Ele .bakvai para o servidor de teste e, dependendo de onde você olha no Explorer, ele tem 162 GB ou 154 GB:

Para economizar espaço, tentei compactar .bakadicionando COMPRESSIONao script:

BACKUP DATABASE [PINK] 
    TO DISK = N'\\TestServer\Transfer\PINK.bak' 
    WITH NOFORMAT, INIT, NAME = N'PINK', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10, CHECKSUM
GO

DECLARE @backupSetId AS int

SELECT @backupSetId = position 
FROM msdb..backupset 
WHERE database_name = N'PINK' 
  AND backup_set_id = (SELECT MAX(backup_set_id) 
                       FROM msdb..backupset 
                       WHERE database_name = N'PINK')

IF @backupSetId IS NULL
BEGIN
    RAISERROR(N'Verify failed. Backup information for database ''PINK'' not found.', 16, 1) 
END

RESTORE VERIFYONLY 
    FROM DISK = N'\\TestServer\Transfer\PINK.bak' 
    WITH FILE = @backupSetId, NOUNLOAD, NOREWIND
GO

Após executar com o COMMPRESSIONcomando incluído, ele caiu no mesmo tamanho no servidor de teste. Eu verifiquei os arquivos .ndfe .mdfe eles totalizam 770 GB ou 732 GB, dependendo de onde você olha. Além disso, ele inclui cerca de 23 GB de informações de índice.

Isso .bakjá está compactado, mesmo que eu não tenha dito isso?

Tenho usado o SQL Server Agent do SQL Server 2016 com configuração e script inferiores nos últimos 3 anos. Estava/está funcionando bem.

Mas, agora, estou migrando tudo para o SQL Server 2019, mas o mesmo comando não funciona.

Então, estou me perguntando se há algo que preciso modificar (em termos de script) porque estou usando o SQL Server 2019.

Quando uso o SQL Server Agent para executar outro script do Powershell (que executa algo dentro do Powershell), ele funciona.

Quando executo o Powershell agora, recebo esta mensagem de erro:

Executando o SQL Server 2019 Enterprise. Eu tenho um grupo de arquivos PRIMÁRIO, mas também adicionei quatro arquivos ndf em um grupo de arquivos Data1 que criei. Como esperado, tive que aumentar o espaço disponível no grupo de arquivos Data1 à medida que mais dados eram adicionados, mas o grupo de arquivos PRIMARY mdf permaneceu relativamente estático em tamanho. Nos últimos meses tive que aumentar o espaço no grupo de arquivos PRIMARY. Começou com 5 GB e expandi para 10 GB há algumas semanas. Fiquei sem espaço novamente e acabei de chegar a 15 GB. O grupo de arquivos Data1 é o grupo de arquivos padrão. Por que o grupo de arquivos PRIMARY estaria crescendo repentinamente agora, quando não é o padrão? Cada um dos arquivos Data1 está configurado para 160 GB, então PRIMARY ainda é consideravelmente menor. Gostaria de saber se existe uma maneira de determinar por que ele está crescendo inesperadamente quando estava estagnado no passado.

Tenho uma editora Standard 2019 que atua como distribuidora própria, com cerca de 150 assinantes em todo o mundo. São 4 publicações, das quais apenas 2 estão ativas. As alterações de dados são muito limitadas (cerca de 5 gravações por dia). Os assinantes são todos da edição SQL Express.

Meu principal problema aqui é que muitas vezes algum agente de distribuição decide que não deseja iniciar corretamente; ou seja, o trabalho fica preso na execução do agente em um loop de nova tentativa. Quando olho para o monitor de replicação, a mensagem diz para procurar no histórico de trabalhos do agente. O histórico de tarefas do agente aponta para o monitor de replicação.

Já tentei aumentar o histórico e o detalhamento da saída, e enviar informações para o arquivo, para os agentes que estavam apresentando o problema, mas parece que isso só começa quando o agente passa da fase de inicialização.

Lendo on-line, encontrei um artigo antigo sobre o esgotamento do heap da área de trabalho, mas também parece que se refere ao WS anterior a 2016 (e estou executando o WS 2019), então não tenho certeza se isso realmente se aplica.

Pesquisas adicionais no Google não produziram nada de valor. Você conhece um método para depurar/solucionar esses problemas, exceto um ticket para a MS ou algum recurso para tentar seguir?

Edite conforme solicitado, aqui está uma cópia e colagem das mensagens que posso ver:

Monitor de replicação: Mensagens de erro:

• O agente 'PublisherName-PublicationName-SubscriberName-AgentID' está tentando novamente após um erro. 74 tentativas tentadas. Consulte o histórico de trabalhos do agente na pasta Trabalhos para obter mais detalhes.

Resultados de

SELECT jh.*FROM msdb.dbo.sysjobhistory jh
INNER JOIN distribution1.dbo.MSdistribution_agents da
   ON da.job_id = jh.job_id
WHERE da.name = ''
ORDER BY jh.instance_id DESC

(captura de tela apenas da iteração mais recente)

Após a CU mais recente do SQL Server 2019, KB5037331, recebo a seguinte mensagem repetidamente em alguns dos meus logs do SqlServer Server: "Chamada de API assíncrona longa: a imparcialidade do agendamento do agendador pode ser impactada por uma invocação de API assíncrona excedendo inesperadamente [grandes 8 dígitos número] senhora."

Vi nas notas de atualização a seguinte alteração:

"Adiciona a seguinte mensagem de log quando altas latências de E/S são detectadas no Bufferpool Lazy Writer (chamada de sistema ntdll!ZwWriteFile) devido a um problema de desempenho no armazenamento subjacente:

AVISO Chamada de API assíncrona longa: a imparcialidade do agendamento do agendador pode ser afetada por uma chamada de API assíncrona que exceda inesperadamente xxx ms."

O problema é que não sei o que devo fazer com essas informações além da solução básica de problemas de E/S. O que preciso matar para fazer esta mensagem parar? E como identifico quais arquivos/objetos estão envolvidos no problema de E/S para resolver o problema subjacente?

Crie o banco de dados mais simples possível:

CREATE DATABASE DatabaseCheck

Adicione este banco de dados a um Grupo de Disponibilidade, onde o secundário não é legível

Na execução primária:

DBCC CHECKDB ('DatabaseCheck') WITH EXTENDED_LOGICAL_CHECKS

É bem-sucedido:

CHECKDB encontrou 0 erros de alocação e 0 erros de consistência no banco de dados 'DatabaseCheck'. Execução do DBCC concluída. Se o DBCC imprimir mensagens de erro, entre em contato com o administrador do sistema.

Execute o mesmo comando DBCC no secundário. Ele falha mesmo que nenhum erro tenha sido encontrado:

CHECKDB encontrou 0 erros de alocação e 0 erros de consistência no banco de dados 'DatabaseCheck'. Msg 0, Nível 11, Estado 0, Linha 1 Ocorreu um erro grave no comando atual. Os resultados, se existirem, deveriam ser descartados.

• Remover COM EXTENDED_LOGICAL_CHECKSfaz com que o erro desapareça
• Tornar a réplica secundária legível faz com que o erro desapareça
• Fazer um failover e verificar o novo primário faz com que o erro desapareça. Verificar o novo secundário mostra o erro novamente.

Alguma ideia do que se trata? A verificação da documentação DBCC CHECKDB não diz nada sobre EXTENDED_LOGICAL_CHECKS não ser compatível com réplica secundária não legível. Parece um bug no próprio comando para mim.

Uma coisa que notei na saída do comando é que ele verifica estatísticas como aqui:

Integridade verificada das estatísticas 'sys.sysrscols.clst'. Integridade verificada das estatísticas 'sys.sysrowsets.clust'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000002_00000005'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000003_00000005'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000006_00000005'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000004_00000005'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000005_00000005'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000008_00000005'.

Eles estão ausentes quando executados no secundário

Reproduzido em:

Microsoft SQL Server 2019 (RTM-CU23) (KB5030333) - 15.0.4335.1 (X64) 21 de setembro de 2023 17:28:44 Copyright (C) 2019 Microsoft Corporation Developer Edition (64 bits) no Windows Server 2019 Standard 10.0 (Build 17763 :)

Editar:

A única mensagem no log de erros é esta:

DBCC CHECKDB (DatabaseCheck) executado por Domain\user encontrou 0 erros e reparou 0 erros. Tempo decorrido: 0 horas 0 minutos 0 segundos. O instantâneo do banco de dados interno tem ponto de divisão LSN = 00000034:000001b1:0001 e primeiro LSN = 00000034:000001af:0002.

Não há dumps recentes em sys.dm_server_memory_dumps

Tenho que criar o DACPAC a partir do banco de dados de produção. Gostaria de fazer isso por meio do Visual Studio 2022 (SQL Server Object Explorer e "Extract - Data-tier application"). É possível bloquear algum processo/consulta ou utilizar mais CPU/memória para fazer isso?

Tenho os seguintes JSONs que gostaria de combinar. No meu JSON tenho a parte 'kenmerken' onde gostaria de adicionar mais alguns itens. Achei que isso poderia ser feito usando JSON_MODIFY. Porém quando eu uso o comando abaixo, ele irá substituir os itens 1, 2 e 3. E quando eu incluir 'append' antes de $.kenmerken, ele só mostrará os novos. Como posso conseguir ter ambos no objeto kenmerken?

DECLARE @FirstJSON NVARCHAR(MAX) = N'
{
    "message id": "B673A8E4-3652-4544-A02D-BA9726BD71ED",
    "volgnummer": 61000233530024,
    "debug": null,
    "kenmerken": {
        "item 1": 1,
        "item 2": 1,
        "item 3": 1
    }
}
';

DECLARE @KenmerkenToAdd NVARCHAR(MAX) = N'
{
    "Item 4": false,
    "Item 5": false
}
';

SET @FirstJSON = JSON_MODIFY(
                               @FirstJSON,
                               ' $.kenmerken',
                               JSON_QUERY(@KenmerkenToAdd)
                            );

SELECT @FirstJSON;

Darei:

{
"message id": "B673A8E4-3652-4544-A02D-BA9726BD71ED",
"volgnummer": 61000233530024,
"debug": null,
"kenmerken": {
   "Item 4": false,
   "Item 5": false
   }
}

Onde eu gostaria de ter:

{
    "message id": "B673A8E4-3652-4544-A02D-BA9726BD71ED",
    "volgnummer": 61000233530024,
    "debug": null,
    "kenmerken": {
       "Item 1": 1,
       "Item 2": 1,
       "Item 3": 1,
       "Item 4": false,
       "Item 5": false
       }
    }