Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a:
SQL Server
O SQL Server pode estar envolvido em operações de backup e restauração via VSS (Serviço de Cópias de Sombra de Volume) por meio de seu serviço dedicado SQL Writer. Para obter mais informações, consulte Aplicativos para backup do SQL Server – VSS (Serviço de Cópias de Sombra de Volume) e SQL Writer.
O serviço relataria erros de execução para logs de eventos de aplicativos do Windows com um evento Source (ou ProviderName no contexto do PowerShell ou XML) de valor SQLWRITER, como você pode ver no exemplo mais adiante neste artigo. Antes do SQL Server 2019 (15.x), não havia nenhum log de atividades dedicado, o que tornava desafiadoras as investigações contra o SQL Server como participante de operações do VSS.
Este artigo descreve o novo log introduzido no SQL Server 2019 (15.x) para oferecer melhor visibilidade sobre as operações do SQLWriter. Essa funcionalidade também foi disponibilizada no SQL Server 2016 (13.x) Service Pack 3 e no SQL Server 2017 (14.x) Atualização Cumulativa (CU) 27.
Visão geral
As principais características do registro em log do SQLWriter no SQL Server 2019 (15.x) são:
- Ele fica ativado por padrão
- É de todo o sistema (rastreará a atividade do SQL Writer em relação a todas as instâncias do SQL Server em execução no servidor)
- Ele é baseado em texto
- Seu diretório de trabalho é
C:\Program Files\Microsoft SQL Server\90\Shared - Dentro desse diretório:
- O registro ocorre no arquivo
SqlWriterLogger.txt - Esse arquivo é renomeado para
SqlWriterLogger1.txtao atingir um tamanho máximo (por padrão, 1 MB), com o registro em log continuando noSqlWriterLogger.txtprincipal. - Existe apenas um arquivo de rollover, portanto o segundo rollover sobrescreveria o
SqlWriterLogger1.txtexistente. - Os parâmetros são gerenciados pelo arquivo
SqlWriterConfig.ini
- O registro ocorre no arquivo
Como o SQL Writer é um componente compartilhado do SQL Server, há apenas uma instância dele em um sistema, e sua versão principal será a mesma da versão principal mais alta entre todas as instâncias instaladas do SQL Server. Por exemplo, se instâncias do SQL Server 2016 (13.x) SP2 e do SQL Server 2019 (15.x) forem instaladas no mesmo sistema, o binário do Gravador do SQL será fornecido pelo SQL Server 2019 (15.x) e fará a manutenção de todas as instâncias em execução de todas as versões principais (embora o diretório base permaneça abaixo de \90). As instâncias e versões locais se beneficiarão do novo rastreamento do SQL Server 2019 (15.x) descrito aqui. Isso também implica que apenas as atualizações cumulativas do SQL Server 2019 (15.x) atualizarão os binários do SQL Writer nesta situação.
Observação
Os parágrafos a seguir descrevem a situação começando com o SQL Server 2019 (15.x) CU 4. As versões anteriores do SQL Server 2019 (15.x) não terão a mesma quantidade de informações no arquivo de log nas configurações padrão.
Operações básicas
Você pode se beneficiar do novo registro sem nenhuma alteração manual. É possível abrir ou obter uma cópia do arquivo de log principal SqlWriterLogger.txt em C:\Program Files\Microsoft SQL Server\90\Shared\. O arquivo refletirá todos os eventos de VSS que chegam ao SQL Writer, que seriam principalmente:
-
OnIdentifyeventos, conforme acionados pelo comandovssadmin list writers - Eventos de backup
- Eventos de restauração
Ou seja, mesmo que essas operações ocorram com êxito, o arquivo de log registrará as entradas detalhadas. Você pode confirmar que as operações de VSS estão em andamento e estão interagindo com êxito com o SQL Writer. É uma melhoria que oferece uma maneira fácil e integrada de estabelecer esses detalhes no nível da instância do SQL Server.
Além disso, os eventos de inicialização do serviço SQLWriter também serão registrados e informarão os parâmetros de registro em log ativos.
Obviamente, se houver uma falha de operação do VSS que envolva o SQL Server, o SqlWriterLogger se tornará um lugar importante para verificar se há informações.
Observação
Essa nova infraestrutura de log complementa a existente para relatórios de erros do SQL Server, mas não a substitui. Portanto, em caso de erro, o log de eventos de aplicativo do Windows Application Event Log continua sendo o primeiro lugar a verificar (filtrando pelas Origens, como "SQLWRITER" e "VSS").
SqlWriterLogger.txt fornece informações adicionais para esse conjunto inicial.
Revisão de registros de log típicos
As exportações a seguir foram feitas na configuração padrão.
Início do serviço
[01/11/2021 02:54:59, TID 61f8] ****************************************************************
[01/11/2021 02:54:59, TID 61f8] ** SQLWRITER TRACING STARTED - ProcessId: 0x4124
[01/11/2021 02:54:59, TID 61f8] ** Service is not running as WIDWriter.
[01/11/2021 02:54:59, TID 61f8] ** SQL Writer version is 15.0.4073.23
[01/11/2021 02:54:59, TID 61f8] ** MODERN LOGGER V2 ENABLED ON C:\Program Files\Microsoft SQL Server\90\Shared\SqlWriterLogger.txt
[01/11/2021 02:54:59, TID 61f8] ** With TraceLevel = DEFAULT, TraceFileSizeMb = 1, ForceFlush = False
[01/11/2021 02:54:59, TID 61f8] ** Recording events in Server Local Time. UTC OFFSET: -8:00
[01/11/2021 02:54:59, TID 61f8] ****************************************************************
O registro acima será observado a cada inicialização do serviço SQL Writer (ele pode até mesmo ser registrado duas vezes por inicialização do serviço).
Em ordem de exibição, podemos ver as seguintes informações:
- Um carimbo de data/hora (data + hora) no horário local do servidor e o ThreadId que originou a entrada, para cada linha.
- A ProcessId do processo SQLWriter que está sendo iniciado.
- O fato de que o serviço foi iniciado no modo 'normal' ('não estar em execução como WIDWriter') ou no modo do Banco de Dados Interno do Windows.
- A versão dos binários do SQL Writer.
- Todos os parâmetros definidos pelo arquivo
SqlWriterConfig.ini:- O caminho de destino do arquivo de log ativo
- O nível de detalhes do rastreamento, que neste exemplo é DEFAULT
- O tamanho máximo do arquivo antes que ocorra a rotação, que neste exemplo é de 1 MB
- A opção de forçar o ForceFlush a cada atualização do arquivo de log, em vez de usar uma abordagem mais relaxada/com buffer, que é false por padrão.
- Um lembrete de que o registro em log é a hora local junto com a diferença UTC dessa hora local.
Evento 'OnIdentify' do VSS
[01/12/2021 08:23:40, TID 464c] Entering SQL Writer OnIdentify.
[01/12/2021 08:23:40, TID 464c] Service: MSSQLSERVER Server: GF19. Version=15
[01/12/2021 08:23:40, TID 464c] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/12/2021 08:23:40, TID 464c] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/12/2021 08:23:40, TID 464c] Skip User Instances Enumeration
OnIdentify é uma operação comum do VSS. Ela é disparada pelo comando vssadmin list writers. A maioria dos solicitantes do VSS iniciaria qualquer operação de backup ou restauração do VSS com um evento OnIdentify.
Antes, somente o rastreamento com o profilador ativo permitia ao DBA detectar esse evento. Com o novo recurso de registro em log, cada evento levará à entrada acima.
Em ordem de exibição, veja que as seguintes informações são registradas:
- Uma menção explícita ao evento
OnIdentifyVSS. - Uma lista de todas as instâncias ativas (em execução) do SQL Server, juntamente com o nome da instância, a versão principal e a Edição.
- A indicação de que não tentamos listar as "Instâncias de Usuário" – um recurso específico do SQL Server também conhecido como LocalDB e normalmente não envolvido em servidores de banco de dados empresariais.
Backup do VSS no modo de componente concluído com êxito
[01/11/2021 02:30:19, TID 32c8] Entering SQL Writer Initialize.
[01/11/2021 02:33:33, TID 232c] Entering SQL Writer OnIdentify.
[01/11/2021 02:33:33, TID 232c] Service: MSSQLSERVER Server: GF19. Version=15
[01/11/2021 02:33:33, TID 232c] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/11/2021 02:33:33, TID 232c] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/11/2021 02:33:33, TID 232c] Skip User Instances Enumeration
[01/11/2021 02:33:37, TID 232c] Entering SQL Writer OnPrepareBackup.
[01/11/2021 02:33:37, TID 232c] ****************************************************************
[01/11/2021 02:33:37, TID 232c] ** VSS SQL BACKUP BEGIN - ID: 232c
[01/11/2021 02:33:37, TID 232c] ****************************************************************
[01/11/2021 02:33:37, TID 232c] Component based backup selected.
[01/11/2021 02:33:37, TID 232c] Database count from metadata is 1
[01/11/2021 02:33:37, TID 232c] Database db_on_G on instance GF19 found in metadata
[01/11/2021 02:33:37, TID 232c] Backup type is VSS_BT_COPY
[01/11/2021 02:33:38, TID 232c] Entering SQL Writer OnPrepareSnapshot.
[01/11/2021 02:33:38, TID 232c] Service: MSSQLSERVER Server: GF19. Version=15
[01/11/2021 02:33:38, TID 232c] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/11/2021 02:33:38, TID 232c] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/11/2021 02:33:38, TID 232c] Skip User Instances Enumeration
[01/11/2021 02:33:38, TID 232c] Entering SQL Writer OnFreeze.
[01/11/2021 02:33:38, TID 232c] Entering SQL Writer OnThaw.
[01/11/2021 02:33:38, TID 232c] Entering SQL Writer OnPostSnapshot.
[01/11/2021 02:33:38, TID 232c] Entering SQL Writer OnIdentify.
[01/11/2021 02:33:38, TID 232c] Service: MSSQLSERVER Server: GF19. Version=15
[01/11/2021 02:33:38, TID 232c] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/11/2021 02:33:38, TID 232c] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/11/2021 02:33:38, TID 232c] Skip User Instances Enumeration
[01/11/2021 02:33:40, TID 232c] Entering SQL Writer OnBackupComplete.
Esse evento leva a um conjunto mais considerável de entradas. Em ordem de exibição, podemos ver as seguintes informações:
- Uma seção
OnIdentifycompleta, que, como já indicado, geralmente leva a um backup. - Menção de cada fase principal do backup VSS, com o padrão "Entrando no SQL Writer xxxx".
- O primeiro aqui é
Entering SQL Writer OnPrepareBackup.
- O primeiro aqui é
- Uma entrada evidente que indica o início de um backup do SQL do VSS
- (O ID é o ThreadId que está registrando em log essa tentativa de backup no SQLWriter)
- A API de backup do VSS selecionada pelo solicitante do VSS: "componente" ou "não componente / volume"
- O número de bancos de dados incluídos na lista de componentes enviada pelo solicitante VSS, neste caso, um único DB (1).
- Uma confirmação de que cada nome de banco de dados fornecido pelo solicitante (aqui, 'db_on_G') foi ou não encontrado na instância do SQL Server à qual foi associado pelo solicitante do VSS (aqui, a instância padrão 'GF19').
- O tipo de backup do VSS solicitado. Geralmente
VSS_BT_FULLouVSS_BT_COPY. Confira a enumeração VSS_BACKUP_TYPE. - Outra
OnIdentifyseção - Mais entradas identificando as fases principais do backup do VSS (
OnFreeze,OnThaw,OnPostSnapshot) - Uma seção
OnIdentifyfinal. - Um relatório final da fase VSS, que, pelo nome, o torna um "evento de encerramento" útil:
OnBackupComplete.
Essas entradas dão detalhes sobre as operações do VSS que antes eram difíceis de estabelecer rapidamente e exigiam um rastreamento avançado para serem realizadas. Um bom exemplo é o modo "Componente" ou "Não componente" de qualquer solicitação de backup do VSS. Com o SQL Writer do SQL Server 2019 (15.x), elas são registradas por padrão a cada solicitação de VSS e ficam facilmente acessíveis.
Situação de falha: banco de dados interrompido
Para ilustrar a afirmação anterior de que o registro do SQL Writer complementa a arquitetura do Log de Eventos, vamos analisar as entradas associadas a uma situação de falha bem conhecida: um banco de dados corrompido. Esse cenário pode ocorrer quando um backup do VSS tenta criar um conjunto de volumes de instantâneo que inclua somente um conjunto parcial de arquivos de um determinado banco de dados. O SQL Writer irá bloqueá-lo conforme as convenções do VSS.
Este trecho corresponde ao conteúdo de SqlWriterLogger.txt para a operação:
[01/11/2021 02:57:00, TID 5a88] Entering SQL Writer OnIdentify.
[01/11/2021 02:57:00, TID 5a88] Service: MSSQLSERVER Server: GF19. Version=15
[01/11/2021 02:57:00, TID 5a88] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/11/2021 02:57:00, TID 5a88] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/11/2021 02:57:00, TID 5a88] Skip User Instances Enumeration
[01/11/2021 02:57:02, TID 5a88] Entering SQL Writer OnPrepareBackup.
[01/11/2021 02:57:02, TID 5a88] ****************************************************************
[01/11/2021 02:57:02, TID 5a88] ** VSS SQL BACKUP BEGIN - ID: 5a88
[01/11/2021 02:57:02, TID 5a88] ****************************************************************
[01/11/2021 02:57:02, TID 5a88] Volume based (= NonComponent) backup selected.
[01/11/2021 02:57:02, TID 5a88] Backup type is VSS_BT_FULL
[01/11/2021 02:57:03, TID 5a88] Entering SQL Writer OnPrepareSnapshot.
[01/11/2021 02:57:03, TID 5a88] Service: MSSQLSERVER Server: GF19. Version=15
[01/11/2021 02:57:03, TID 5a88] Instance MSSQL15.MSSQLSERVER Edition: Developer Edition
[01/11/2021 02:57:03, TID 5a88] Instance MSSQL15.NAMED1 Edition: Enterprise Edition: Core-based Licensing
[01/11/2021 02:57:03, TID 5a88] Skip User Instances Enumeration
[01/11/2021 02:57:03, TID 5a88] HRESULT EXCEPTION CAUGHT: hr: 0x80780002
[01/11/2021 02:57:03, TID 5a88] Entering SQL Writer OnAbort.
Em SqlWriterLogger.txt, vemos que ocorreu uma falha, no entanto, o único detalhe que temos sobre a falha é o 0x80780002 HResult. Esse valor é difícil de interpretar sem as referências de código de erro. Mas ele identifica a situação de banco de dados interrompido.
Exibir log de eventos
Agora, vamos verificar o conteúdo dos Logs de Eventos do Aplicativo do Windows:
Log Name: Application
Source: SQLWRITER
Date: 1/11/2021 02:57:03 AM
Event ID: 24579
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: GF19
Description:
Sqllib error: Database db_on_G_and_H of SQL Server instance GF19 is stored on multiple volumes, only some of which are being shadowed.
O evento fornece uma mensagem formatada amigável e completa explicando a situação.
A estrutura VSS do sistema operacional também relatará o problema em Logs de Eventos, usando sua nomenclatura (o VSS gerencia "componentes", que são "bancos de dados" no contexto do SQL Server).
Log Name: Application
Source: VSS
Date: 1/11/2021 02:57:03 AM
Event ID: 8229
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: GF19
Description:
A VSS writer has rejected an event with error 0x800423f0, The shadow-copy set only
contains only a subset of the volumes needed to correctly backup the selected
components of the writer.
Changes that the writer made to the writer components while handling the event will
not be available to the requester.
Check the event log for related events from the application hosting the VSS writer.
Operation:
PrepareForSnapshot Event
Context:
Execution Context: Writer
Writer Class Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
Writer Name: SqlServerWriter
Writer Instance Name: Microsoft SQL Server 2019:SQLWriter
Writer Instance ID: {a16fed29-e555-4cc5-8938-c89201f31f7e}
Command Line: "C:\Program Files\Microsoft SQL Server\90\Shared\sqlwriter.exe"
Process ID: 22628
O Log de Eventos é uma fonte melhor de informações sobre o erro. No entanto, o conteúdo do SqlWriterLogger fornece detalhes sobre a solicitação de backup (um VSS_BT_FULL, uma solicitação de backup VSS sem componente que falhou durante a fase OnPrepareSnapshot do SQL Writer). Qualquer investigação de erros do VSS envolvendo o SQL Server, portanto, deve coletar e examinar ambas as fontes.
Modificar os parâmetros de log do SQL Writer
O log do SQL Writer pode ser configurado editando o arquivo de texto SqlWriterConfig.ini. O próprio arquivo contém uma descrição embutida rápida dos parâmetros disponíveis, que examinaremos abaixo.
Observação
O arquivo .ini está em uma pasta protegida pelo Windows (Arquivos de Programas). Como tal, requer privilégios elevados de administrador para edição. Clicar duas vezes no Explorer abre o Bloco de Notas sem elevação: ele permitirá que o usuário leia o conteúdo, mas as tentativas de salvar qualquer alteração falharão. Inicie o Bloco de Notas como administrador e, em seguida, abra SqlWriterConfig.ini, ou use um editor de texto que possa solicitar elevação de privilégio, conforme necessário, ao salvar o arquivo.
Duplicando aqui os comentários do arquivo SqlWriterConfig.ini:
| Parâmetro | Opções | Descrição |
|---|---|---|
| EnableLogging | - TRUE (padrão) - FALSO |
Permite que o usuário desative todo o novo recurso de registro, no caso improvável de isso ser necessário. |
| TraceFile | C:\Program Files\Microsoft SQL Server\90\Shared\SqlWriterLog.txt |
Permite que o usuário altere o caminho e o nome do arquivo de rastreamento. Não é recomendável alterá-lo, pois o local padrão, amplamente conhecido, facilita ir diretamente ao local correto em qualquer SQL Server. |
| TraceLevel | - DEFAULT (padrão) -MÍNIMO -VERBOSE |
O nível de detalhamento dos logs. Mais informações estão em detalhes de TraceLevel. |
| TraceFileSizeMb | 1 MB (padrão) | O tamanho máximo do arquivo antes da rotação. O arquivo .txt usa a codificação UTF-8 e consome 2 bytes por caractere. É válido aumentar esse valor, por exemplo, em caso de atividade intensa do VSS, retenção de registros de log por longos períodos ou se valores TraceLevel não padrão estiverem habilitados por longos períodos. O valor padrão de 1 MB deve fornecer histórico suficiente para a maioria das situações. |
| ForceFlush | - VERDADE - FALSE (padrão) |
Configurar esta opção como TRUE só seria útil nas raras circunstâncias em que o serviço SQL Writer travasse antes que tivesse a chance de gravar suas últimas entradas de log; caso contrário, mantenha o valor padrão. |
Aplique as alterações
Qualquer alteração nas configurações requer o reinício do serviço SQL Writer para que seja ativada.
Dica
Reiniciar o SQL Writer é extremamente rápido e pode ser feito a qualquer momento, pois o SQL Writer não retém nenhuma informação de estado nem realiza qualquer atividade entre chamadas do VSS. A única precaução é evitar uma reinicialização enquanto uma operação do VSS (backup, restauração) está ocorrendo.
O SQL Writer informará os parâmetros ativos em seu arquivo de log ao ser (re)iniciado, como pode ser visto no trecho de exemplo Service Start.
Detalhes de TraceLevel
O arquivo SqlWriterConfig.ini lista os seguintes níveis:
| Nível | Detalhe |
|---|---|
DEFAULT |
Os parâmetros de verbosidade padrão devem ser adequados para a maioria das necessidades: consulte a seção Revisão de entradas de log típicas para observar o que já é gerado por padrão. Além dos erros, as chamadas do VSS bem-sucedidas, juntamente com os metadados do VSS, serão registradas por padrão. |
MINIMAL |
Esse nível manterá a formatação do modo DEFAULT e seus eventos. Ele também vai gerar saídas em muitos pontos importantes do código. O mais notável é que ele registrará em log todos os arquivos e as iterações do banco de dados comuns na lógica do SQLWriter. Ele pode aumentar consideravelmente o número de entradas registradas para cada operação do VSS (incluindo o evento trivial OnIdentify), especialmente em instâncias que hospedam um grande número de bancos de dados: cada arquivo físico de cada banco de dados pode ser registrado mais de uma vez durante um backup do VSS. Esse nível só ajuda a fornecer uma ideia mais precisa da posição lógica do SQL Writer no momento da falha. Também é conveniente para fins de exploração. Não é útil mantê-lo ativo além das investigações momentâneas, pois o nível de detalhes reduzirá consideravelmente a profundidade do histórico do tamanho padrão do arquivo de 1 MB. Aumentar o valor TraceFileSizeMb pode ser importante. |
VERBOSE |
Atualmente este nível relata os mesmos eventos que MINIMAL, mas prefixa cada entrada com objetos de código-fonte e descritores de métodos. Ele torna a saída mais larga (maior do que no modo Mínimo) e menos legível. As informações adicionadas não seriam úteis fora das interações com os Serviços de Suporte da Microsoft. O mesmo comentário que MINIMAL seria aplicado: manter esse nível ativo por muito tempo reduzirá consideravelmente a profundidade do histórico do tamanho padrão do arquivo de 1 MB e aumentar o valor TraceFileSizeMb poderá ser importante. |
Os níveis MINIMAL e VERBOSE não fornecem detalhes adicionais de erro em caso de falha, apenas detalhes adicionais de progresso para cada operação de baixo nível relacionada às atividades do SQL Writer.