DBCC CHECKFILEGROUP (Transact-SQL)
Aplica-se a: SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure
Verifica a alocação e a integridade estrutural de todas as tabelas e exibições indexadas no grupo de arquivos especificado do banco de dados atual.
Convenções de sintaxe de Transact-SQL
Sintaxe
DBCC CHECKFILEGROUP
[
[ ( { filegroup_name | filegroup_id | 0 }
[ , NOINDEX ]
) ]
[ WITH
{
[ ALL_ERRORMSGS | NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
[ , PHYSICAL_ONLY ]
[ , MAXDOP = number_of_processors ]
}
]
]
Argumentos
filegroup_name
O nome do grupo de arquivos no banco de dados atual para o qual verificar a alocação da tabela e a integridade estrutural. Se não for especificado, ou se 0 for especificado, o padrão será o grupo de arquivos primário. Os nomes de grupos de arquivos precisam estar em conformidade com as regras para identificadores.
O filegroup_name não pode ser um grupo de arquivos FILESTREAM.
filegroup_id
O número de ID (identificação) do grupo de arquivos no banco de dados atual para o qual verificar a alocação da tabela e a integridade estrutural.
NOINDEX
Especifica que não deve-se executar verificações intensivas de índices não clusterizados para tabelas de usuário. Isto reduz o tempo de execução geral. NOINDEX
não afeta as tabelas do sistema porque DBCC CHECKFILEGROUP
sempre verifica todos os índices dessas.
ALL_ERRORMSGS
Exibe um número ilimitado de erros por objeto. Todas as mensagens de erro são exibidas por padrão. Especificar ou omitir esta opção não têm nenhum efeito.
NO_INFOMSGS
Suprime todas as mensagens informativas.
TABLOCK
Faz com que DBCC CHECKFILEGROUP
obtenha bloqueios em vez de usar um instantâneo de banco de dados interno.
ESTIMATE ONLY
Exibe a quantidade estimada de espaço tempdb
necessária para executar DBCC CHECKFILEGROUP
com todas as outras opções especificadas.
PHYSICAL_ONLY
Limita a verificação à integridade da estrutura física da página, dos cabeçalhos de registros e da estrutura física de árvores B. Criada para fornecer uma pequena verificação de sobrecarga da consistência física do grupo de arquivos, essa verificação também pode detectar páginas fragmentadas e falhas comuns de hardware que podem comprometer os dados. Uma execução completa de DBCC CHECKFILEGROUP
pode demorar consideravelmente mais do que nas versões anteriores. Esse comportamento ocorre devido às seguintes razões:
- As verificações lógicas são mais abrangentes.
- Algumas das estruturas subjacentes a serem verificadas são mais complexas.
- Foram introduzidas muitas verificações novas para incluir os novos recursos.
Observação
A documentação usa o termo árvore B geralmente em referência a índices. Em índices de rowstore, o Database Engine implementa uma árvore B+. Isso não se aplica a índices columnstore ou índice em tabelas com otimização de memória. Para obter mais informações, confira o Guia de arquitetura e design do índice do SQL Server e SQL do Azure.
Isso significa que usar a opção PHYSICAL_ONLY
pode causar um runtime muito menor para DBCC CHECKFILEGROUP
em grandes grupos de arquivos e, portanto, é recomendado para uso frequente em sistemas de produção. Também é recomendado realizar uma execução completa periódica de DBCC CHECKFILEGROUP
. A frequência dessas execuções depende de fatores específicos aos negócios e ambientes de produção individuais. PHYSICAL_ONLY
sempre implica NO_INFOMSGS
e não é permitido com nenhuma das opções de reparo.
Observação
Especificar PHYSICAL_ONLY
faz com que DBCC CHECKFILEGROUP
ignore todas as verificações de dados FILESTREAM.
MAXDOP
Aplica-se a: SQL Server 2014 Service Pack 2 e versões posteriores
Substitui a opção de configuração max degree of parallelism de sp_configure
da instrução. MAXDOP
pode exceder o valor configurado com sp_configure
. Se MAXDOP
exceder o valor configurado com o Resource Governor, o Mecanismo de Banco de Dados usará o valor MAXDOP
do Resource Governor descrito em ALTER WORKLOAD GROUP (Transact-SQL). Todas as regras semânticas usadas com a opção de configuração de grau máximo de paralelismo são aplicáveis ao usar a dica de consulta MAXDOP
. Para obter mais informações, veja Configurar a opção max degree of parallelism de configuração de servidor.
Cuidado
Se MAXDOP
for definido como zero, o servidor escolherá o grau máximo de paralelismo.
Comentários
DBCC CHECKFILEGROUP
e DBCC CHECKDB
são comandos DBCC semelhantes. A principal diferença é que DBCC CHECKFILEGROUP
é limitado ao único grupo de arquivos especificado e às tabelas necessárias.
DBCC CHECKFILEGROUP
executa os seguintes comandos:
- DBCC CHECKALLOC do grupo de arquivos.
- DBCC CHECKTABLE de cada tabela e exibição indexada no grupo de arquivos.
Não é necessário executar DBCC CHECKALLOC
ou DBCC CHECKTABLE
separadamente de DBCC CHECKFILEGROUP
.
Instantâneo de banco de dados interno
DBCC CHECKFILEGROUP
usa um instantâneo de banco de dados interno para fornecer a consistência transacional necessária a fim de executar essas verificações. Para saber mais, confira Exibir o tamanho do arquivo esparso de um instantâneo de banco de dados (Transact-SQL) e a seção Uso de instantâneo de banco de dados interno do DBCC em DBCC (Transact-SQL).
Se não for possível criar um instantâneo ou a opção TABLOCK
for especificada, o DBCC CHECKFILEGROUP
obterá bloqueios a fim de adquirir a consistência necessária. Nesse caso, um bloqueio de banco de dados exclusivo é necessário para executar as verificações de alocação, e bloqueios de tabela compartilhados são necessários para executar as verificações de tabela. TABLOCK
faz com que DBCC CHECKFILEGROUP
seja executado mais rapidamente em um banco de dados sob alta carga, mas diminui a simultaneidade disponível nele enquanto DBCC CHECKFILEGROUP
está em execução.
Observação
A execução de DBCC CHECKFILEGROUP
em tempdb
não realiza nenhuma verificação de alocação e deve adquirir bloqueios de tabela compartilhada para a execução de verificações de tabela. Isso ocorre porque, por motivos de desempenho, os instantâneos de banco de dados não estão disponíveis em tempdb
. Isso significa que não é possível obter a consistência transacional exigida.
Verificar objetos em paralelo
Por padrão, DBCC CHECKFILEGROUP
executa a verificação paralela de objetos. O grau de paralelismo é automaticamente determinado pelo processador de consulta. O grau de máximo de paralelismo é configurado da mesma forma que as consultas paralelas. Para restringir o número máximo de processadores disponíveis para a verificação do DBCC, use sp_configure. Para obter mais informações, veja Configurar a opção max degree of parallelism de configuração de servidor.
A verificação paralela pode ser desabilitada usando o sinalizador de rastreamento 2528. Para obter mais informações, confira Sinalizadores de rastreamento (Transact-SQL).
Índices não clusterizados em grupos de arquivos separados
Se um índice não clusterizado no grupo de arquivos especificado estiver associado a uma tabela em outro grupo de arquivos, não será verificado porque a tabela base não está disponível para validação.
Se uma tabela no grupo de arquivos especificado tiver um índice não clusterizado em outro grupo de arquivos, o índice não clusterizado não será verificado devido ao seguinte:
- A estrutura da tabela base não depende da estrutura de um índice não clusterizado. Os índices não clusterizados não precisam ser examinados a fim de validar a tabela base.
- O comando
DBCC CHECKFILEGROUP
valida objetos somente no grupo de arquivos especificado.
Um índice clusterizado e uma tabela não podem estar em grupos de arquivos diferentes. Portanto, as considerações anteriores se aplicam somente a índices não clusterizados.
Tabelas particionadas em grupos de arquivos separados
Quando uma tabela particionada existe em diversos grupos de arquivos, DBCC CHECKFILEGROUP
verifica os conjuntos de linhas de partição existentes no grupo de arquivos especificado e ignora os conjuntos de linhas nos outros grupos de arquivos. A mensagem informativa 2594 indica as partições que não foram verificadas. Índices não clusterizados não residentes no grupo de arquivos especificado não são verificados.
Entender as mensagens de erro do DBCC
Após a conclusão do comando DBCC CHECKFILEGROUP
, uma mensagem é gravada no log de erros do SQL Server. Se o comando DBCC for executado com êxito, a mensagem indicará uma conclusão bem-sucedida e a quantidade de tempo até a conclusão do comando. Se o comando DBCC parar antes de concluir a verificação devido a um erro, a mensagem indicará que o comando foi finalizado, um valor de estado e a duração da execução do comando. A tabela a seguir lista e descreve os valores de estado que podem ser incluídos na mensagem.
Estado | Descrição |
---|---|
0 | O número do erro 8930 foi gerado. Isso indica um dano de metadados que provocou a finalização do comando DBCC. |
1 | O erro número 8967 foi gerado. Ocorreu um erro interno de DBCC. |
2 | Ocorreu uma falha durante o reparo do banco de dados em modo de emergência. |
3 | Isso indica um dano de metadados que provocou a finalização do comando DBCC. |
4 | Uma declaração ou violação de acesso foi detectada. |
5 | Ocorreu um erro desconhecido que finalizou o comando DBCC. |
Relatório de erros
Um mini-arquivo de despejo (SQLDUMP<nnnn>.txt
) é criado no diretório LOG
do SQL Server sempre que DBCC CHECKFILEGROUP
detecta um erro de corrupção. Quando a coleta de dados Uso de Recursos e os recursos de Relatório de Erros recursos estão habilitados para a instância do SQL Server, o arquivo é encaminhado automaticamente ao Microsoft. Os dados coletados são usados para aprimorar a funcionalidade do SQL Server.
O arquivo de despejo contém os resultados do comando DBCC CHECKFILEGROUP
e a saída do diagnóstico adicional. O arquivo tem DACLs (listas de controle de acesso discricionário) restritas. O acesso é limitado à conta de serviço do SQL Server e aos membros da função sysadmin. Por padrão, a função sysadmin contém todos os membros do grupo BUILTIN\Administradores do Windows e do grupo do administrador local. O comando do DBCC não falhará se o processo de coleta de dados falhar.
Resolver erros
Se algum erro for relatado por DBCC CHECKFILEGROUP
, restaure o banco de dados com base no backup do banco de dados. As opções de reparo não podem ser especificadas para DBCC CHECKFILEGROUP
.
Se não houver nenhum backup, a execução de DBCC CHECKDB
com uma opção de reparo especificada corrigirá os erros relatados. A opção de reparo a ser usada será especificada no fim da lista se erros forem relatados. A correção de erros usando a opção REPAIR_ALLOW_DATA_LOSS pode exigir que algumas páginas e, portanto, dados, sejam excluídos.
Conjuntos de resultados
DBCC CHECKFILEGROUP
retorna o seguinte conjunto de resultados (os valores podem variar):
- Exceto quando
ESTIMATEONLY
ouNO_INFOMSGS
estiver especificado. - No caso do banco de dados atual, se nenhum banco de dados está especificado e se alguma opção (exceto
NOINDEX
) está ou não especificada.
DBCC results for 'master'.
DBCC results for 'sys.sysrowsetcolumns'.
There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.
DBCC results for 'sys.sysrowsets'.
There are 97 rows in 1 pages for object 'sys.sysrowsets'.
DBCC results for 'sysallocunits'.
There are 195 rows in 3 pages for object 'sysallocunits'.
There are 2340 rows in 16 pages for object 'spt_values'.
DBCC results for 'MSreplication_options'.
There are 2 rows in 1 pages for object 'MSreplication_options'.
CHECKFILEGROUP found 0 allocation errors and 0 consistency errors in database 'master'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Se NO_INFOMSGS
estiver especificado, DBCC CHECKFILEGROUP
retornará o seguinte:
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Se ESTIMATEONLY
estiver especificado, DBCC CHECKFILEGROUP
retornará o seguinte (os valores podem variar):
Estimated TEMPDB space needed for CHECKALLOC (KB)
-------------------------------------------------
15
(1 row(s) affected)
Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
207
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Permissões
Exige associação à função de servidor fixa sysadmin ou à função de banco de dados fixa db_owner .
Exemplos
a. Verificar o grupo de arquivos PRIMARY no banco de dados
O exemplo a seguir verifica o grupo de arquivos primário do banco de dados atual.
DBCC CHECKFILEGROUP;
GO
B. Verificar o grupo de arquivos PRIMARY de AdventureWorks sem índices não clusterizados
O exemplo a seguir verifica o grupo de arquivos primário do banco de dados AdventureWorks2022
(excluindo os índices não clusterizados) especificando o número de identificação do grupo de arquivos primário e NOINDEX
.
USE AdventureWorks2022;
GO
DBCC CHECKFILEGROUP (1, NOINDEX);
GO
C. Verificar o grupo de arquivos PRIMARY com opções
O exemplo a seguir verifica o grupo de arquivos primário do banco de dados master
e especifica a opção ESTIMATEONLY
.
USE master;
GO
DBCC CHECKFILEGROUP (1)
WITH ESTIMATEONLY;