Use a ferramenta Sqldumper.exe para gerar um arquivo de despejo no SQL Server
Este artigo fornece diretrizes gerais para a ferramenta Sqldumper.exe incluída com SQL Server. Essa ferramenta é usada para gerar diferentes tipos de arquivos de despejo.
Versão original do produto: SQL Server 2019, SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005
Número de KB original: 917825
Resumo
A ferramenta Sqldumper.exe está incluída no Microsoft SQL Server. Ele gera arquivos de despejo de memória de SQL Server e processos relacionados para depuração. Este artigo descreve como usar Sqldumper.exe para gerar um arquivo de despejo para tarefas de relatório de erro ou depuração do Watson.
O artigo também descreve dois outros métodos para gerar arquivos de despejo:
- O script do PowerShell anexado automatiza SQLDumper.exe opções de linha de comando.
- O comando DBCC STACKDUMP Transact-SQL (T-SQL) pode ser usado para gerar um arquivo de despejo no SQL Server.
Como executar Sqldumper.exe manualmente
Execute a ferramenta Sqldumper.exe no contexto da pasta em que SQL Server originalmente instalou a ferramenta.
Por padrão, o caminho de instalação do Sqldumper.exe é <SQLServerInstall Drive>:\Program Files\Microsoft SQL Server\90\Shared\SQLDumper.exe. Observe que <SQLServerInstall Drive> é um espaço reservado para a unidade na qual você instalou SQL Server.
Para gerar um arquivo de despejo usando a ferramenta Sqldumper.exe, siga estas etapas:
Abra <a pasta SQLServerInstall Drive>:\Program Files\Microsoft SQL Server\<number>\Shared.
Neste caminho de pasta, <o número> é um espaço reservado para um dos seguintes:
- 150 para SQL Server 2019
- 140 para SQL Server 2017
- 130 para SQL Server 2016
- 120 para SQL Server 2014
- 110 para SQL Server 2012
- 100 para SQL Server 2008
- 90 para SQL Server 2005
Verifique se o arquivo Dbghelp.dll está nesta pasta.
Selecione Iniciar>Execução, digite cmd e selecione OK.
No prompt de comando, digite o seguinte comando e pressione Enter:
cd <SQLServerInstall Drive>:\Program Files\Microsoft SQL Server\<number>\SharedObservação
Neste caminho de pasta, <o número> é o mesmo espaço reservado que muda com a versão SQL Server, conforme descrito anteriormente.
Para gerar um tipo específico de arquivo de despejo, digite o comando correspondente no prompt de comando e pressione Enter:
Arquivo de despejo completo:
Sqldumper.exe <ProcessID> 0 0x01100Arquivo de despejo de mini-despejo:
Sqldumper.exe <ProcessID> 0 0x0120Arquivo de mini-despejo que inclui memória referenciada indiretamente (essa é a opção recomendada e também é usada por SQL Server por padrão quando gera arquivos de despejo de memória automaticamente):
Sqldumper.exe <ProcessID> 0 0x0128Arquivo de despejo filtrado:
Sqldumper.exe <ProcessID> 0 0x8100
Observação
<ProcessID> é um espaço reservado para o identificador de processo do aplicativo Windows para o qual você deseja gerar um arquivo de despejo.
Se Sqldumper.exe for executado com êxito, a ferramenta gerará um arquivo de despejo na pasta na qual a ferramenta está instalada.
O arquivo de despejo que Sqldumper.exe gera tem um padrão de nome de arquivo que se assemelha a SQLDmpr<xxxx.mdmp>.
Nesse padrão, <xxxx> é um número crescente que é determinado com base em outros arquivos que têm um nome de arquivo semelhante na mesma pasta. Se você já tiver arquivos na pasta que têm nomes de arquivo no padrão especificado, talvez seja necessário comparar a data e a hora em que o arquivo foi criado para identificar o arquivo desejado.
Como obter um identificador de processo de aplicativo do Microsoft Windows
Para gerar um arquivo de despejo usando a ferramenta Sqldumper.exe, você deve ter o identificador de processo do aplicativo Windows para o qual deseja gerar um arquivo de despejo. Veja como obter o identificador de processo:
- Pressione Ctrl+Alt+Delete e selecione Gerenciador de Tarefas.
- Na caixa de diálogo Gerenciador de Tarefas do Windows , selecione a guia Processos .
- No menu Exibir , selecione Selecionar Colunas.
- Na caixa de diálogo Selecionar Colunas , selecione a caixa de seleção PID (Identificador de Processo) e selecione OK.
- Observe o identificador de processo do aplicativo Windows para o qual você deseja gerar um arquivo de despejo. Para o aplicativo SQL Server, observe o identificador de processo do processo deSqlservr.exe.
- Fechar Gerenciador de Tarefas.
Como alternativa, use o arquivo de log de erro SQL Server para obter o identificador de processo do aplicativo SQL Server que está em execução no computador. Parte do arquivo de log de erros SQL Server se assemelha ao seguinte exemplo:
2021-09-15 11:50:32.690 Server Microsoft SQL Server 2019 (RTM-CU12) (KB5004524) - 15.0.4153.1 (X64)
Jul 19 2021 15:37:34
Copyright (C) 2019 Microsoft Corporation
Enterprise Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 19043: ) (Hypervisor)
2021-09-15 11:50:32.690 Server UTC adjustment: -5:00
2021-09-15 11:50:32.690 Server (c) Microsoft Corporation.
2021-09-15 11:50:32.690 Server All rights reserved.
2021-09-15 11:50:32.690 Server Server process ID is 7028.
O número que aparece depois Server process ID é o identificador de processo do processo deSqlservr.exe .
Caminho de saída para arquivos de despejo de memória
SQLDumper.exe existe principalmente para gerar arquivos de despejo de memória para o processo de SQL Server em cenários em que um despejo de memória é necessário para resolve problemas específicos (como exceções, afirmações, agendadores não produtivos). Nesses casos, SQL Server invoca o SQLDumper.exe para gerar um arquivo de despejo de memória de seu processo. Por padrão, o arquivo de despejo de memória é armazenado no diretório MSSQL\LOG\ da instância do SQL.
Como alterar o caminho padrão
Se, por exemplo, o tamanho do arquivo de despejo for muito grande, você poderá modificar o caminho fazendo o seguinte:
- Abra SQL Server Configuration Manager.
- Em serviços de SQL Server, localize a instância SQL Server que está sob investigação.
- Clique com o botão direito do mouse nessa entrada, selecione Propriedades e vá para a guia Avançado .
- Altere esse Diretório de Despejo para o caminho desejado e selecione OK.
- Reinicie SQL Server (quando possível) para que a nova configuração entre em vigor.
Quando a ferramenta Sqldumper.exe é usada manualmente para gerar um arquivo de despejo para qualquer aplicativo Windows, o arquivo de despejo pode ser tão grande quanto a memória que o aplicativo Windows está usando atualmente. Verifique se há espaço em disco suficiente disponível na unidade para a qual Sqldumper.exe está escrevendo o arquivo de despejo.
Especificar uma pasta de saída personalizada no comando
Você pode especificar o diretório em que deseja que a ferramenta Sqldumper.exe escreva o arquivo de despejo. O diretório já deve existir antes de executar Sqldumper.exe. Caso contrário, Sqldumper.exe falhará. Não use um caminho UNC como local para o arquivo de despejo. Veja a seguir um exemplo de como especificar o local do arquivo de despejo do arquivo de mini-despejo:
Selecione Iniciar>Execução, digite cmd e selecione OK.
No prompt de comando, digite o seguinte comando e pressione Enter:
cd <SQLServerInstall Drive>:\Program Files\Microsoft SQL Server\<number>\SharedNo prompt de comando, digite o seguinte comando e pressione Enter:
Sqldumper.exe ProcessID 0 0x0128 0 <MdumpPath>Observação
<O MdumpPath> é um espaço reservado para o diretório em que você deseja que a ferramenta Sqldumper.exe escreva o arquivo de despejo. Por padrão, o arquivo é gravado na pasta atual.
Se você especificar um arquivo de despejo completo ou um arquivo de despejo filtrado a ser gerado, Sqldumper.exe poderá levar vários minutos para gerar o arquivo de despejo. O tempo gasto depende das seguintes variáveis:
- A quantidade de memória que Sqlservr.exe está usando no momento.
- A velocidade da unidade para a qual a ferramenta está gravando o arquivo de despejo.
Durante esse tempo, a ferramenta Sqldumper.exe não processará comandos. Você notará que o servidor parou de responder. Além disso, pode ocorrer um failover de cluster.
Requisitos de permissão
Para executar Sqldumper.exe, você deve entrar no Windows usando um dos seguintes métodos:
- Use uma conta que é membro do grupo de administradores no computador.
- Use a mesma conta de usuário na qual o serviço SQL Server está em execução.
Para que a ferramenta Sqldumper.exe funcione com êxito por meio da Área de Trabalho Remota ou por meio dos Serviços de Terminal, você deve iniciar a Área de Trabalho Remota ou os Serviços de Terminal no modo de console. Por exemplo, para iniciar a Área de Trabalho Remota no modo de console, selecione Iniciar>Execução, digite mstsc/console e selecione OK. Se o servidor de destino executar o Windows 2000, a opção /console será ignorada silenciosamente. Você pode se conectar ao servidor por meio da Área de Trabalho Remota, mas não usará a sessão do console.
Se você notar que nenhum arquivo de despejo foi gerado na pasta atual depois de executar Sqldumper.exe, examine as informações que a ferramenta gerou na linha de comando para tentar determinar a possível causa da falha. Essas informações também estão registradas no arquivo Sqldumper_errorlog.log no diretório atual. A seguir estão duas possíveis mensagens de erro e suas causas:
| Mensagem | Motivo |
|---|---|
| "0x57 com falha do OpenProcess – O parâmetro está incorreto" | Uma ID de Processo inválida foi passada para o utilitário Sqldumper.exe. |
| "Valor inválido para id de thread – <erro de parâmetro> inválido" | Um parâmetro inválido foi passado para o utilitário Sqldumper.exe. |
Se uma mensagem de erro que se assemelha a uma das seguintes for gerada, você poderá ignorar com segurança esta mensagem:
- "Tipo de retorno de chamada desconhecido durante o minidump 6"
- "Tipo de retorno de chamada desconhecido durante o minidump 7"
Impacto da geração de despejo
Quando um arquivo de despejo de um processo de modo de usuário é solicitado (como é discutido neste artigo, em oposição aos Despejos do Kernel do Sistema Operacional, que estão fora do nosso escopo), o processo de destino (aqui SQLServer.exe) é congelado pela duração necessária para serializar o conteúdo de despejo para seu destino de arquivo.
Frozen significa que o processo não será capaz de executar nenhuma solicitação de usuário ou qualquer operação interna, incluindo qualquer mecanismo de Pesquisa de Recursos, como a implementação de IsAlive e Looks Alive do Windows Clustering (consulte a seção Despejos de memória em failovers de cluster para obter detalhes sobre como lidar com essa situação). Qualquer tempo limite que dependa do tempo de relógio de parede também pode ser violado por causa do congelamento.
Como pode ser derivado da instrução anterior, a duração do congelamento é, portanto, o fator crítico aqui e é impulsionado pelo seguinte:
- O tipo de despejo selecionado.
- O tamanho do processo de SQL Server na memória, que no caso de uma única instância ativa executando parâmetros padrão é geralmente próximo ao total de RAM física do servidor.
- O desempenho do disco usado como destino para o despejo.
Além disso, o tamanho do arquivo de despejo no disco deve ser planejado, especialmente se vários despejos forem uma possibilidade e se tipos de despejo grandes e não padrão forem selecionados. Verifique se você revisa os tipos de despejo para saber o que esperar. Por padrão, alguns métodos de despejo criarão o despejo na pasta \Log da SQL Server Instância, que, em configuração simples padrão, também seria o disco do sistema e o disco de log data+para SQL Server. Levar esse disco à saturação terá um impacto severo na disponibilidade do SQL Server e/ou do sistema.
Gerenciar o impacto em sistemas clusterizados
O processo é suspenso temporariamente durante a geração de despejo. Isso pode afetar a disponibilidade do serviço SQL Server e disparar o failover de recursos em contextos de Always On (instância de cluster de failover e grupo de disponibilidade). A geração de despejo de processos diferentes afeta os recursos de forma diferente. Leia cuidadosamente as seções Impacto da geração de despejo e de tipos de despejo .
Ao capturar um despejo de SQL Server em uma instância clusterada de failover ou em uma instância de AG (grupo de disponibilidade) de SQL Server, o SQL Server clusterizado ou AG poderá falhar em outro nó se o despejo demorar muito para ser concluído. Isso pode ser especialmente problemático em sistemas que usam quantidades muito grandes de RAM ou se você estiver gerando um despejo de memória filtrado ou completo. Para evitar o failover, use as seguintes configurações antes de capturar o arquivo de despejo. A alteração pode ser revertida após a tomada de um arquivo de despejo:
- Para instância clusterada de failover (FCI):
- Clique com o botão direito do mouse em SQL Server recurso no Administrador de Cluster, selecione Se o recurso falhar, não reinicie na guia Políticas.
- Na guia Propriedades , aumente o Tempo limite do HealthCheck. Por exemplo, defina o valor da propriedade como 180 segundos ou superior. Se esse tempo limite for atingido, a política Se o recurso falhar, a reinicialização não será ignorada e o recurso será reiniciado de qualquer maneira.
- Na guia Propriedades , altere o valor FailureConditionLevel para zero.
- Para AG, aplique todas as seguintes configurações:
- Aumente o tempo limite da sessão, por exemplo, 120 segundos para todas as réplicas. Em SQL Server Management Studio (SSMS), clique com o botão direito do mouse no réplica a ser configurado e selecione Propriedades. Altere o campo tempo limite da sessão (segundos) para 120 segundos. Para obter mais informações, consulte Alterar o período de Session-Timeout para uma réplica de disponibilidade (SQL Server).
- Altere o failover automático de todas as réplicas para failover manual. No SSMS, clique com o botão direito do mouse em réplica, selecione Propriedades e altere o failover automático de todas as réplicas para failover manual na guia Propriedades. Para obter mais informações, consulte Alterar o modo de failover de uma réplica de disponibilidade (SQL Server).
- Aumente o LeaseTimeout para 60.000 ms (60 segundos) e altere HealthCheckTimeout para 90.000 ms (90 segundos). No Administrador de Cluster, clique com o botão direito do mouse no recurso AG, selecione Propriedades e, em seguida, alterne para a guia Propriedades para modificar ambas as configurações. Para obter mais informações, consulte Configurar configurações de propriedade HealthCheckTimeout.
Melhorias no produto para reduzir o impacto no SQL Server
Quatro melhorias importantes foram adicionadas a versões recentes de SQL Server para reduzir o tamanho do arquivo de despejo e/ou tempo para gerar o despejo de memória:
- Mecanismo de filtragem de bitmap
- Eliminação de despejos repetidos no mesmo problema
- Saída reduzida no log de erros
- Compactação paralela de despejos de memória
Mecanismo de filtragem de bitmap
SQL Server aloca um bitmap que mantém o controle das páginas de memória a serem excluídas de um despejo filtrado. Sqldumper.exe lê o bitmap e filtra páginas sem a necessidade de ler outros metadados do gerenciador de memória. Você verá as seguintes mensagens no log de erros SQL Server quando o bitmap estiver habilitado ou desabilitado, respectivamente:
Page exclusion bitmap is enabled. e Page exclusion bitmap is disabled.
SQL Server 2016
Começando com SQL Server 2016 SP2 CU13, a filtragem de bitmap está habilitada por padrão.
SQL Server 2017
- Isso não está disponível no RTM por meio do CU15.
- Em SQL Server CU16 de 2017, você pode habilitar a filtragem de bitmap por meio de T8089 e desabilitar o T8089.
- Começando com SQL Server CU20 2017, a filtragem de bitmap está habilitada por padrão. O sinalizador de rastreamento T8089 não será mais aplicado e será ignorado se ativado. A filtragem de bitmap pode ser desabilitada por meio do T8095.
SQL Server 2019
Isso está habilitado por padrão em SQL Server RTM 2019. Ele pode ser desabilitado por meio do T8095.
Eliminação de despejos repetidos no mesmo problema
Despejos de memória repetidos no mesmo problema são eliminados. Usando uma assinatura de pilha, o mecanismo SQL mantém o controle se uma exceção já ocorreu e não produzirá um novo despejo de memória se já houver uma. Isso se aplica a violações de acesso, estouro de pilha, declarações e exceções de corrupção de índice. Isso reduz significativamente a quantidade de espaço em disco usada por despejos de memória e não congela o processo temporariamente para gerar um despejo. Isso foi adicionado no SQL Server 2019.
Saída reduzida no log de erros
O conteúdo gerado no log de erros SQL Server de um único despejo de memória pode não só ser avassalador, mas também pode retardar o processo de geração de um despejo de memória devido ao tempo necessário para serializar todas essas informações em um formato de texto no log de erros. No SQL Server 2019, o conteúdo armazenado no log de erros após a geração de despejo foi muito reduzido e pode ser assim:
DateTimespidS pid **Dump thread - spid = 0, EC = 0x0000015C7169BF40
DateTimespidS pid *
DateTimespidS pid *User initiated stack dump. This is not a server exception dump.
DateTimespidS pid *
DateTimespidS pid Stack Signature for the dump is 0x00000000788399E5
DateTimespidS pid External dump process return code 0x20000001.
External dump process returned no errors.
Anteriormente SQL Server imprimiria informações para cada sessão ou thread quando um despejo manual foi disparado pelo usuário, por exemplo.
Compactação paralela de despejos de memória
Para gerar despejos mais rapidamente e torná-los menores em tamanho, um recurso de despejo de memória compactada foi introduzido no CU8 2022 SQL Server e SQL Server CU23 de 2019. Quando ativado, Sqldumper.exe cria vários threads para ler a memória de um processo simultaneamente, compacta-a e salva-a no arquivo de despejo. Essa compactação paralela de vários threads reduz o tamanho do arquivo e acelera o processo de despejo quando usado com despejos completos e filtrados.
Você pode ativar o sinalizador de rastreamento 2610 para habilitar o despejo de memória compactada:
DBCC TRACEON (2610,-1)
GO
DBCC STACKDUMP with FILTERED_DUMP
GO
DBCC TRACEOFF (2610,-1)
Como alternativa, você pode adicionar -T2610 como um parâmetro de inicialização à sua instância SQL Server para que ela sempre crie despejos de memória compactados.
Se você executar manualmente Sqldumper.exe, poderá usar o -zdmp parâmetro para capturar um despejo de memória compactada. Por exemplo:
Sqldumper.exe <ProcessID> 0 0x8100 0 d:\temp -zdmp
Você também pode limitar quantos núcleos Sqldumper.exe podem usar para criar o despejo compactado usando o -cpu:X parâmetro, em que X é o número de CPUs. Esse parâmetro só está disponível quando você executa manualmente Sqldumper.exe na linha de comando:
Sqldumper.exe <ProcessID> 0 0x8100 0 d:\temp -zdmp -cpu:8
Fatores que impedem ou atrasam a criação de despejos de memória
Os fatores a seguir são conhecidos por causar atrasos ou impedir a criação de despejos de memória.
- O caminho de E/S em que os despejos de memória são gravados tem um desempenho ruim. Nesses casos, investigar e resolve desempenho de E/S do disco é a próxima etapa lógica.
- Um antivírus ou outro software de monitoramento está interferindo no SQLDumper.exe. Em alguns casos, a função ReadProcessMemory de desvio de software de terceiros. Isso pode aumentar drasticamente a duração do despejo. Para resolve a maioria desses problemas, desabilite o software de interferência ou adicione SQLDumper.exe a uma lista de exclusão.
Tipos de despejo
Os métodos a seguir podem ser usados para gerar três tipos diferentes de despejos: mini despejos, despejos completos e despejos filtrados.
Mini despejos com memória referenciada
Esse tipo de despejo de memória é um instantâneo de todos os threads ativos do processo ("pilhas de thread"), juntamente com um extrato limitado da memória referenciada pelas pilhas de thread e algum outro processo de chave ou dados de thread. Eles normalmente são alguns megabytes em tamanho, e são rápidos para gerar (de menos de um segundo para alguns segundos). Sistemas de servidor ainda maiores (com centenas de CPU indiretamente impulsionando um grande número de threads em SQL Server processo) raramente excedem de 20 a 30 MB: o tamanho de um mini despejo não cresce com o tamanho de SQL Server processo. Esse tipo de despejo é o tipo padrão usado por SQL Server ao gerar despejos de memória automaticamente em exceções, problemas de agendador, problemas de trava, corrupção de banco de dados, afirma.
Observação
SQL Server, como parte de sua instrumentação interna, gerará "mini despejos de diagnóstico" automatizados em algumas situações específicas. Essa operação é, portanto, considerada segura o suficiente para que SQL Server possa acioná-la automaticamente quando necessário.
Despejos completos
Um despejo de memória completo é uma cópia completa do espaço do processo de destino ativo. Isso incluiria, portanto, todo o estado do thread, toda a memória alocada por processo e todos os módulos carregados. Os despejos completos terão, portanto, um tamanho, que é aproximadamente o mesmo de SQL Server processo, que por sua vez pode ser quase tão grande quanto a RAM total do sistema. Em servidores grandes dedicados a uma única instância de SQL Server, isso pode significar um arquivo, que é várias centenas de gigabytes ou mais. Desnecessariamente para dizer, esse arquivo levará muito tempo para ser gerado e, portanto, induzirá o congelamento prolongado. O desempenho do disco para o destino do arquivo do despejo influenciará significativamente o tempo de congelamento. Esse tipo de despejo raramente é usado para SQL Server atualmente, conforme descrito na explicação a seguir.
Despejos filtrados
À medida que o tamanho da RAM de servidores típicos que executam SQL Server aumenta constantemente, os despejos completos tornam-se mais difícéis. Portanto, os despejos filtrados são implementados. Um despejo filtrado é um subconjunto de um despejo completo, em que grandes áreas de SQL Server memória são excluídas na hora e não gravadas em disco. Normalmente, a memória excluída não traz nenhum valor adicionado à solução de problemas. Exemplos são páginas de dados/índice e alguns caches internos, como páginas de dados do Hekaton e memória do Pool de Logs. Esse despejo filtrado resulta em um arquivo menor do que um despejo completo, mas o despejo ainda mantém quase toda a sua utilidade. Despejos filtrados substituíram despejos completos como a opção preferencial em uma grande maioria das situações em que mini despejos não são suficientes. A diminuição de tamanho pode variar em comparação com um despejo completo, mas ainda é um arquivo bastante grande, que geralmente é de 30 a 60 % de SQL Server tamanho do processo. Portanto, é melhor planejar para um tamanho possível tão grande quanto um despejo completo como uma opção pior, o que deixa uma boa margem de segurança. Um despejo filtrado pode não ser necessariamente mais rápido de gerar do que um despejo completo em todos os casos: é uma questão de saber se os ganhos relacionados ao número de E/S evitado excedem o tempo necessário para implementar a lógica do filtro (a velocidade do disco e a velocidade da CPU/RAM influenciarão isso).
Você pode usar a consulta a seguir para obter uma estimativa aproximada do tamanho do despejo filtrado. Embora a expectativa seja que a maioria dos dados ou páginas de índice sejam excluídos do despejo, os que estão exclusivamente presos e modificados não serão omitidos.
SELECT SUM(pages_kb)
FROM sys.dm_os_memory_clerks
WHERE type != 'MEMORYCLERK_SQLBUFFERPOOL'
Como você pode usar Sqldumper.exe para gerar um arquivo de despejo sob demanda para qualquer aplicativo Microsoft Windows, você pode considerar usar a opção de despejo filtrado. No entanto, um arquivo de despejo filtrado só é aplicável e significativo no contexto de SQL Server. Você ainda pode gerar um mini-despejo, um arquivo de despejo completo ou aplicativos não SQL Server com êxito.
O processo SQL Server chama a ferramenta Sqldumper.exe internamente para gerar um arquivo de despejo quando o processo tiver exceções. SQL Server passa parâmetros para Sqldumper.exe. Você pode usar sinalizadores de rastreamento para alterar os parâmetros que SQL Server passa para a ferramenta por padrão quando ocorre uma exceção ou declaração. Esses sinalizadores de rastreamento estão no intervalo de 2540 a 2559. Você pode usar um desses sinalizadores de rastreamento para alterar o tipo de despejo padrão SQLDumper.exe gerar (o padrão é um mini-despejo com memória referenciada). Por exemplo:
- Sinalizador de rastreamento 2551: produz um despejo de memória filtrado.
- Sinalizador de rastreamento 2544: produz um despejo de memória completo.
- Sinalizador de rastreamento 8026: SQL Server limpará um gatilho de despejo depois de gerar o despejo uma vez.
Se dois ou mais sinalizadores de rastreamento estiverem ativos, a opção que indica o maior despejo de memória será honrada. Por exemplo, se os sinalizadores de rastreamento 2551 e 2544 forem usados, SQL Server criará um despejo de memória completo.
Gerar um despejo de memória em failovers de cluster
Em cenários de failover de cluster, a DLL do recurso SQL Server pode obter um arquivo de despejo antes que o failover ocorra para ajudar na solução de problemas. Quando a DLL do recurso SQL Server determina que um recurso SQL Server falhou, a DLL do recurso SQL Server usa o utilitário Sqldumper.exe para obter um arquivo de despejo do processo de SQL Server. Para garantir que a ferramenta Sqldumper.exe gere com êxito o arquivo de despejo, você deve definir as três propriedades a seguir como pré-requisitos:
SqlDumperDumpTimeOutUm tempo limite especificado pelo usuário. A DLL do recurso aguarda a conclusão do arquivo de despejo antes que a DLL do recurso pare o serviço SQL Server.
SqlDumperDumpPathO local em que a ferramenta Sqldumper.exe gera o arquivo de despejo.
SqlDumperDumpFlagsSinalizadores que Sqldumper.exe usa.
Se uma das propriedades não estiver definida, Sqldumper.exe não poderá gerar o arquivo de despejo. Uma mensagem de aviso será registrada no log de eventos e no log de cluster sempre que o recurso for colocado online.
Configuração de cluster para SQLDumper em versões SQL Server 2012 e posteriores
Você pode usar o ALTER SERVER CONFIGURATION comando (T-SQL) para modificar essas propriedades. Por exemplo:
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY SqlDumperDumpTimeOut = 0;
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY SqlDumperDumpPath = 'C:\temp\';
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY SqlDumperDumpFlags = 296;
Como alternativa, você pode usar scripts do PowerShell. Por exemplo, para uma instância nomeada SQL2017AG:
Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Set-ClusterParameter -Name "SqlDumperDumpPath" -Value "C:\temp"
Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Set-ClusterParameter -Name "SqlDumperDumpFlags" -Value 296
Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Set-ClusterParameter -Name "SqlDumperDumpTimeOut" -Value 0
Para validar as configurações que foram aplicadas, você pode executar este comando do PowerShell:
Get-ClusterResource -Name "SQL Server (SQL2017AG)" | Get-ClusterParameter
Configuração de cluster para SQLDumper em SQL Server 2008/2008 R2 ou Windows 2012 e versões anteriores
Para definir as propriedades do utilitário Sqldumper.exe para failover de cluster usando o comando de recurso de cluster , siga estas etapas:
- Selecione Iniciar>Execução, digite cmd e selecione OK.
- Para cada propriedade, digite o comando correspondente no prompt de comando e pressione Enter:
A propriedade
SqlDumperDumpFlagsPara definir a
SqlDumperDumpFlagspropriedade para um tipo específico de arquivo de despejo, digite o comando correspondente no prompt de comando e pressione Enter:Todos os arquivos de despejo completo do thread
Instância padrão
cluster resource "SQL Server" /priv SqlDumperDumpFlags = 0x01100Instância nomeada
cluster resource "SQL Server (INSTANCE1)" /priv SqlDumperDumpFlags = 0x01100
Todos os arquivos de mini-despejo de thread
Instância padrão
cluster resource "SQL Server" /priv SqlDumperDumpFlags = 0x0120Instância nomeada
cluster resource "SQL Server (INSTANCE1)" /priv SqlDumperDumpFlags = 0x0120
Filtrado todo o arquivo de despejo de thread
Instância padrão
cluster resource "SQL Server" /priv SqlDumperDumpFlags = 0x8100Instância nomeada
cluster resource "SQL Server (INSTANCE1)" /priv SqlDumperDumpFlags = 0x8100
A propriedade
SqlDumperDumpPathcluster resource "SQL Server" /priv SqlDumperDumpPath = <DirectoryPath>Observação
<DirectoryPath> é um espaço reservado para o diretório no qual o arquivo de despejo será gerado e deve ser especificado entre aspas (" ").
A propriedade
SqlDumperDumpTimeOutcluster resource "SQL Server" /priv SqlDumperDumpTimeOut = <Timeout>Observação
<O tempo limite> é um espaço reservado para o tempo limite em milissegundos (ms).
O tempo que a ferramenta leva para gerar um arquivo de despejo de um processo de SQL Server depende da configuração do computador. Para um computador que tem muitas memórias, o tempo pode ser significativo. Para obter uma estimativa do tempo que o processo leva, use a ferramenta Sqldumper.exe para gerar manualmente um arquivo de despejo. Os valores válidos para a SqlDumperDumpTimeOut propriedade são de 10.000 ms a MAXDWORD. MAXDWORD representa o valor mais alto no intervalo do tipo de dados DWORD (4294967295).
Para verificar se as configurações foram habilitadas, você pode executar o seguinte comando:
cluster resource "SQL Server" /priv
Remover propriedades Sqldumper.exe para failover de cluster
Para remover as propriedades da ferramenta Sqldumper.exe para failover de cluster, siga estas etapas:
- Selecione Iniciar>Execução, digite cmd e selecione OK.
- Para uma propriedade específica, digite o comando correspondente no prompt de comando e pressione Enter:
A propriedade
SqlDumperDumpFlagsInstância padrão
cluster resource "SQL Server" /priv:SqlDumperDumpFlags /usedefaultInstância nomeada
cluster resource "SQL Server (INSTANCE1)" /priv:SqlDumperDumpFlags /usedefault
A propriedade
SqlDumperDumpPathInstância padrão
cluster resource "SQL Server" /priv:SqlDumperDumpPath /usedefaultInstância nomeada
cluster resource "SQL Server (INSTANCE1)" /priv:SqlDumperDumpPath /usedefault
A propriedade
SqlDumperDumpTimeOutInstância padrão
cluster resource "SQL Server" /priv:SqlDumperDumpTimeOut /usedefaultInstância nomeada
cluster resource "SQL Server (INSTANCE1)" /priv:SqlDumperDumpTimeOut /usedefault
Como usar o DBCC STACKDUMP
O DBCC STACKDUMP comando pode ajudá-lo a criar um despejo de memória no diretório LOG da instalação da instância SQL Server. O comando criará por padrão um minidump com todos os threads, que tem tamanho limitado e é adequado para refletir o estado do processo de SQL Server. Execute o seguinte comando em um cliente SQL Server:
DBCC STACKDUMP
Para obter a funcionalidade estendida do DBCC STACKDUMP em SQL Server 2019, consulte Funcionalidade estendida do DBCC STACKDUMP introduzida no SQL Server 2019.
Para habilitar esse método para criar um despejo filtrado, ative os sinalizadores de rastreamento 2551 usando o seguinte comando:
DBCC TRACEON(2551, -1)
GO
DBCC STACKDUMP
Para criar um despejo completo, use o sinalizador de rastreamento 2544.
Depois de obter o arquivo de despejo, você deve desabilitar o sinalizador de rastreamento usando o comando DBCC TRACEOFF (<TraceNumber>, -1); para evitar atualizar inadvertidamente todas as SQL Server minidumps de autognóstico para despejos maiores. No comando, <TraceNumber> é o sinalizador de rastreamento que você habilitou anteriormente como 2551 ou 2544. Por exemplo:
DBCC TRACEOFF(2551, -1)
Caso não tenha certeza de qual sinalizador de rastreamento permanece ativo, execute o seguinte comando:
DBCC TRACESTATUS(-1)
Um conjunto de resultados vazio indica que nenhum sinalizador de rastreamento está ativo. Por outro lado, se 2551 ainda estiver ativo, você verá:
| TraceFlag | Status | Global | Sessão |
|---|---|---|---|
| 2551 | 1 | 1 | 0 |
Observação
O traceflag habilitado por DBCC TRACEON é redefinido (removido) após uma reinicialização do serviço.
Funcionalidade do STACKDUMP do DBCC estendida introduzida no SQL Server 2019
Começando com SQL Server CU2 2019, o DBCC STACKDUMP comando foi estendido para dar suporte à geração de despejos de diferentes tipos: mini, filtrado e despejos completos. Esse comando elimina a necessidade de usar sinalizadores de rastreamento. Ele também permite limitar a saída de texto no outro arquivo de texto que é gerado com o despejo de memória. Isso pode fornecer ganho de desempenho visível no tempo que leva SQLDumper.exe para gerar um despejo de memória.
DBCC STACKDUMP WITH MINI_DUMP | FILTERED_DUMP | FULL_DUMP [, TEXT_DUMP = LIMITED | DETAILED]
A TEXT_DUMP = LIMITED é a opção padrão. Se você quiser receber uma saída detalhada no arquivo SQLDump000X.txt , poderá usar TEXT_DUMP = DETAILED.
Para gerar um despejo filtrado com saída limitada no arquivo .txt , execute o seguinte comando:
DBCC STACKDUMP WITH FILTERED_DUMP , TEXT_DUMP = LIMITED
Como usar um script do PowerShell para gerar um arquivo de despejo com SQLDumper
Salve o código a seguir como um arquivo PS1, por exemplo ,SQLDumpHelper.ps1:
Detalhes do código
$isInt = $false $isIntValDcnt = $false $isIntValDelay = $false $SqlPidInt = 0 $NumFoler = "" $OneThruFour = "" $SqlDumpTypeSelection = "" $SSASDumpTypeSelection = "" $SSISDumpTypeSelection = "" $SQLNumfolder = 0 $SQLDumperDir = "" $OutputFolder = "" $DumpType = "0x0120" $ValidPid $SharedFolderFound = $false $YesNo = "" $ProductNumber = "" $ProductStr = "" Write-Host "" Write-Host "`******************************************************************" Write-Host "This script helps you generate one or more SQL Server memory dumps" Write-Host "It presents you with choices on:` -target SQL Server process (if more than one) -type of memory dump -count and time interval (if multiple memory dumps) You can interrupt this script using CTRL+C" Write-Host "***********************************************************************" # check for administrator rights # debugging tools like SQLDumper.exe require Admin privileges to generate a memory dump if (-not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) { Write-Warning "Administrator rights are required to generate a memory dump!`nPlease re-run this script as an Administrator!" return } # what product would you like to generate a memory dump while ($true) { Write-Host "Which product would you like to generate a memory dump of?" -ForegroundColor Yellow Write-Host "1) SQL Server" Write-Host "2) SSAS (Analysis Services)" Write-Host "3) SSIS (Integration Services)" Write-Host "4) SSRS (Reporting Services)" Write-Host "5) SQL Server Agent" Write-Host "" $ProductNumber = Read-Host "Enter 1-5>" if ($ProductNumber -in 1,2,3,4,5) { break } Write-Host "`nPlease enter a valid number from list above!`n" Start-Sleep -Milliseconds 300 } if ($ProductNumber -eq "1") { $SqlTaskList = Tasklist /SVC /FI "imagename eq sqlservr*" /FO CSV | ConvertFrom-Csv $ProductStr = "SQL Server" } elseif ($ProductNumber -eq "2") { $SqlTaskList = Tasklist /SVC /FI "imagename eq msmdsrv*" /FO CSV | ConvertFrom-Csv $ProductStr = "SSAS (Analysis Services)" } elseif ($ProductNumber -eq "3") { $SqlTaskList = Tasklist /SVC /FI "imagename eq msdtssrvr*" /FO CSV | ConvertFrom-Csv $ProductStr = "SSIS (Integration Services)" } elseif ($ProductNumber -eq "4") { $SqlTaskList = Tasklist /SVC /FI "imagename eq reportingservicesservice*" /FO CSV | ConvertFrom-Csv $ProductStr = "SSRS (Reporting Services)" } elseif ($ProductNumber -eq "5") { $SqlTaskList = Tasklist /SVC /FI "imagename eq sqlagent*" /FO CSV | ConvertFrom-Csv $ProductStr = "SQL Server Agent" } if ($SqlTaskList.Count -eq 0) { Write-Host "There are currently no running instances of $ProductStr. Exiting..." -ForegroundColor Green break } # if multiple SQL Server instances, get the user to input PID for desired SQL Server if ($SqlTaskList.Count -gt 1) { Write-Host "More than one $ProductStr instance found." $SqlTaskList | Select-Object PID, "Image name", Services | Out-Host # check input and make sure it is a valid integer while ($true) { Write-Host "Please enter the PID for the desired SQL service from list above" -ForegroundColor Yellow $SqlPidStr = Read-Host ">" if( $SqlPidStr -in $SqlTaskList.PID) { $SqlPidInt = [int]$SqlPidStr break } } Write-Host "Using PID=$SqlPidInt for generating a $ProductStr memory dump" -ForegroundColor Green Write-Host "" } else # if only one SQL Server/SSAS on the box, go here { $SqlTaskList | Select-Object PID, "Image name", Services | Out-Host $SqlPidInt = [convert]::ToInt32($SqlTaskList.PID) Write-Host "Using PID=", $SqlPidInt, " for generating a $ProductStr memory dump" -ForegroundColor Green Write-Host "" } # dump type if ($ProductNumber -eq "1") # SQL Server memory dump { # ask what type of SQL Server memory dump while($true) { Write-Host "Which type of memory dump would you like to generate?" -ForegroundColor Yellow Write-Host "1) Mini-dump" Write-Host "2) Mini-dump with referenced memory " -NoNewLine; Write-Host "(Recommended)" Write-Host "3) Filtered dump " -NoNewline; Write-Host "(Not Recommended)" -ForegroundColor Red Write-Host "4) Full dump " -NoNewline; Write-Host "(Do Not Use on Production systems!)" -ForegroundColor Red Write-Host "" $SqlDumpTypeSelection = Read-Host "Enter 1-4>" if ($SqlDumpTypeSelection -in 1,2,3,4) { break } Write-Host "`nPlease enter a valid type of memory dump!`n" Start-Sleep -Milliseconds 300 } Write-Host "" switch ($SqlDumpTypeSelection) { "1" { $DumpType="0x0120"; break } "2" { $DumpType="0x0128"; break } "3" { $DumpType="0x8100"; break } "4" { $DumpType="0x01100"; break } default { "0x0120"; break } } } elseif ($ProductNumber -eq "2") # SSAS dump { # ask what type of SSAS memory dump while($true) { Write-Host "Which type of memory dump would you like to generate?" -ForegroundColor Yellow Write-Host "1) Mini-dump" Write-Host "2) Full dump " -NoNewline; Write-Host "(Do Not Use on Production systems!)" -ForegroundColor Red Write-Host "" $SSASDumpTypeSelection = Read-Host "Enter 1-2>" if ($SSASDumpTypeSelection -in 1,2) { break } Write-Host "`nPlease enter a valid type of memory dump!`n" Start-Sleep -Milliseconds 300 } Write-Host "" switch ($SSASDumpTypeSelection) { "1" {$DumpType="0x0";break} "2" {$DumpType="0x34";break} default {"0x0120"; break} } } elseif ($ProductNumber -in 3,4,5) # SSIS/SSRS/SQL Agent dump { # ask what type of SSIS memory dump while($true) { Write-Host "Which type of memory dump would you like to generate?" -ForegroundColor Yellow Write-Host "1) Mini-dump" Write-Host "2) Full dump" Write-Host "" $SSISDumpTypeSelection = Read-Host "Enter 1-2>" if ($SSISDumpTypeSelection -in 1,2) { break } Write-Host "`nPlease enter a valid type of memory dump!`n" Start-Sleep -Milliseconds 300 } Write-Host "" switch ($SSISDumpTypeSelection) { "1" { $DumpType="0x0"; break } "2" { $DumpType="0x34"; break } default { "0x0120"; break } } } # Sqldumper.exe PID 0 0x0128 0 c:\temp # output folder while($OutputFolder -eq "" -or !(Test-Path -Path $OutputFolder)) { Write-Host "" Write-Host "Where would your like the memory dump stored (output folder)?" -ForegroundColor Yellow $OutputFolder = Read-Host "Enter an output folder with no quotes (e.g. C:\MyTempFolder or C:\My Folder)" if ($OutputFolder -eq "" -or !(Test-Path -Path $OutputFolder)) { Write-Host "'" $OutputFolder "' is not a valid folder. Please, enter a valid folder location" -ForegroundColor Yellow } } # strip the last character of the Output folder if it is a backslash "\". Else Sqldumper.exe will fail if ($OutputFolder.Substring($OutputFolder.Length-1) -eq "\") { $OutputFolder = $OutputFolder.Substring(0, $OutputFolder.Length-1) Write-Host "Stripped the last '\' from output folder name. Now folder name is $OutputFolder" } # find the highest version of SQLDumper.exe on the machine $NumFolder = dir "C:\Program Files\Microsoft SQL Server\1*" | Select-Object @{name = "DirNameInt"; expression={[int]($_.Name)}}, Name, Mode | Where-Object Mode -Match "da*" | Sort-Object DirNameInt -Descending for( $j=0; $j -lt $NumFolder.Count; $j++) { $SQLNumfolder = $NumFolder.DirNameInt[$j] # start with the highest value from sorted folder names - latest version of dumper $SQLDumperDir = "C:\Program Files\Microsoft SQL Server\" + $SQLNumfolder.ToString() + "\Shared\" $TestPathDumperDir = $SQLDumperDir + "sqldumper.exe" if (Test-Path -Path $SQLDumperDir) { break } } # build the SQLDumper.exe command e.g. (Sqldumper.exe 1096 0 0x0128 0 c:\temp\) $cmd = "$([char]34)"+$SQLDumperDir + "sqldumper.exe$([char]34)" $arglist = $SqlPidInt.ToString() + " 0 " +$DumpType +" 0 $([char]34)" + $OutputFolder + "$([char]34)" Write-Host "Command for dump generation: ", $cmd, $arglist -ForegroundColor Green # do-we-want-multiple-dumps section Write-Host "" Write-Host "This utility can generate multiple memory dumps, at a certain interval" Write-Host "Would you like to collect multiple memory dumps (2 or more)?" -ForegroundColor Yellow # validate Y/N input while ($true) { $YesNo = Read-Host "Enter Y or N>" if ($YesNo -in "y","n") { break } Write-Host "Not a valid 'Y' or 'N' response" } # get input on how many dumps and at what interval if ($YesNo -eq "y") { [int]$DumpCountInt=0 while (1 -ge $DumpCountInt) { Write-Host "How many dumps would you like to generate for this $ProductStr ?" -ForegroundColor Yellow $DumpCountStr = Read-Host ">" if ([int]::TryParse($DumpCountStr, [ref]$DumpCountInt) -and $DumpCountInt -gt 1) { break } Write-Host "Please enter a number greater than one." -ForegroundColor Red } [int]$DelayIntervalInt=0 while ($true) { Write-Host "How frequently (in seconds) would you like to generate the memory dumps?" -ForegroundColor Yellow $DelayIntervalStr = Read-Host ">" if ([int]::TryParse($DelayIntervalStr, [ref]$DelayIntervalInt) -and $DelayIntervalInt -gt 0) { break } Write-Host "Please enter a number greater than zero." -ForegroundColor Red } Write-Host "Generating $DumpCountInt memory dumps at a $DelayIntervalStr-second interval" -ForegroundColor Green # loop to generate multiple dumps $cntr = 0 while ($true) { Start-Process -FilePath $cmd -Wait -Verb runAs -ArgumentList $arglist $cntr++ Write-Host "Generated $cntr memory dump(s)." -ForegroundColor Green if ($cntr -ge $DumpCountInt) { break } Start-Sleep -S $DelayIntervalInt } # print what files exist in the output folder Write-Host "" Write-Host "Here are all the memory dumps in the output folder '$OutputFolder'" -ForegroundColor Green $MemoryDumps = $OutputFolder + "\SQLDmpr*" Get-ChildItem -Path $MemoryDumps Write-Host "" Write-Host "Process complete" } else # produce just a single dump { Start-Process -FilePath $cmd -Wait -Verb runAs -ArgumentList $arglist # print what files exist in the output folder Write-Host "" Write-Host "Here are all the memory dumps in the output folder '$OutputFolder'" -ForegroundColor Green $MemoryDumps = $OutputFolder + "\SQLDmpr*" Get-ChildItem -Path $MemoryDumps Write-Host "" Write-Host "Process complete" } Write-Host "For errors and completion status, review SQLDUMPER_ERRORLOG.log created by SQLDumper.exe in the output folder '$OutputFolder'.`nOr if SQLDumper.exe failed, look in the folder from which you are running this script."Execute-o no Prompt de Comando como administrador usando o seguinte comando:
Powershell.exe -File SQLDumpHelper.ps1Ou execute-o de Windows PowerShell console e execute como administrador usando o seguinte comando:
.\SQLDumpHelper.ps1
Observação
Se você nunca tiver executado scripts do PowerShell em seu sistema, poderá receber a seguinte mensagem de erro:
"O arquivo ...SQLDumpHelper.ps1 não pode ser carregado porque a execução de scripts está desabilitada neste sistema."
Para habilitar a capacidade de executar os comandos, siga estas etapas:
Inicie Windows PowerShell console usando a opção Executar como Administrador. Somente membros do grupo de administradores no computador podem alterar a política de execução.
Habilite a execução de scripts não assinados pelo seguinte comando:
Set-ExecutionPolicy RemoteSignedObservação
Isso permitirá que você execute scripts não assinados que você cria em seu computador local e scripts assinados pela Internet.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários