Olá, meu nome é Kirk. Sou engenheiro-chefe sênior trabalhando com a equipe de GSE. Este vídeo é dedicado à análise da ferramenta de banco de dados TSQL do Microsoft SQL Server, DBCC CHECKDB. Discutiremos por que e quando DBCC CHECKDB deve ser executado, juntamente com as opções de comando que determinam o nível de verificação de banco de dados e tempo de execução envolvidos.
Antes de começarmos a demonstração, quero esclarecer alguns pontos. DBCC CHECKDB é uma ferramenta TSQL que analisa a integridade lógica e física de todos os objetos em um determinado banco de dados SQL Server. Temos algumas opções de reparo que também estão disponíveis, e temos algo chamado "TABLOCK" como uma opção que envolve o uso ou não de um snapshot do banco de dados. Vamos analisar a opção "ESTIMATEONLY", por que gostaríamos de usá-la, e isso é relativo ao uso de "TEMPDB" durante um processo CHECKDB.
Além disso, veremos "PHYSICAL_ONLY", por que queremos usar essa opção e quando. E também veremos como podemos controlar o número de processadores envolvidos no processo CHECKDB com algo chamado "MAXDOP". Neste ponto, vamos analisar alguns dos exemplos do que veríamos quando executamos DBCC CHECKDB. Então, o primeiro comando em si literalmente verificará tudo o que é possível para DBCC CHECKDB olhar dentro de um determinado banco de dados.
Aqui estão os resultados. A linha de retorno que mais nos interessa quando executamos isso é o número de "erros de alocação" e "erros de consistência" encontrados no banco de dados. Então, eu tenho um banco de dados "AdventureWorks2019" saudável, então tudo está voltando sem erros. Ele também é um banco de dados pequeno, por isso é processado bem rápido. Se tivermos um banco de dados muito maior, um banco de dados, por exemplo, 100 vezes o tamanho deste, isso levará muito mais tempo para ser executado.
E, muitas pessoas se perguntam com que frequência devemos tentar executar DBCC CHECKDB, e geralmente os mestres SQL lhe dirão, você quer tentar executá-lo o mais rápido possível. Se houver alguma inconsistência ou qualquer tipo de dano de software no banco de dados, você quer descobrir isso o mais rápido possível e lidar com isso. A próxima opção que analisaremos é a chamada "COM PHYSICAL_ONLY".
É o mesmo comando, exceto, neste caso, é literalmente apenas verificar a entidade física ou a estrutura do próprio banco de dados. Normalmente, ele é executado muito mais rápido do que uma verificação completa, e é por isso que gostaríamos de executá-lo em ambientes de produção onde temos limitações em nossos tempos de manutenção. Também temos outra opção chamada "WITH TABLOCK", então uma coisa que precisamos entender sobre DBCC CHECKDB, uma das primeiras coisas que ele faz é criar um arquivo instantâneo que está contido no banco de dados "TEMPDB", e há momentos em que podemos não ser capazes de usar "TEMPDB" para algo assim com um processo CHECKDB.
Então, o que quer que designemos como "WITH TABLOCK", estamos dizendo ao DBCC CHECKDB para não criar um arquivo de snapshot, portanto, ele não ocupará esse espaço em "TEMPDB" e, geralmente, será executado mais rapidamente como resultado disso. Outra opção que podemos executar é "WITH ESTIMATEONLY". Esse comando específico nos informará quanto espaço esperaríamos ter usado em nosso banco de dados "TEMPDB" ao executar o CHECKDB.
E aqui está um exemplo do resultado disso, ele volta em kilobytes, ou seja, cerca de 230 megabytes. Outra opção que temos é a "WITH MAXDOP". Agora, qualquer que seja o DBCC CHECKDB executado, ele tenta usar quantos processadores precisar para executar em paralelo. Ele deseja executar vários threads para tentar executar o mais rápido possível. Portanto, pode haver limitações quanto ao número de processadores que gostaríamos de permitir que fossem executados neste processo, então podemos limitar isso com a declaração "WITH MAXDOP".
Neste caso, estou dizendo ao SQL para usar apenas um processador para nossa execução do CHECKDB. E, quando fazemos isso, são menos processadores dedicados a isso, mas, geralmente, levará mais tempo para executar seu DBCC CHECKDB. Agora, vamos dar uma olhada nas opções de reparo. Existem várias opções de reparo. A mais drástica é a "REPAIR_ALLOW_DATA_LOSS". Você literalmente pode perder dados sempre que usarmos essa opção para tentar reparar um banco de dados que está voltando com erros. Ou você pode usar a opção "REPAIR_REBUILD".
REPAIR_REBUILD é considerada uma opção de reparo flexível, e o que queremos dizer com isso é que ela garante que não perderemos dados disponíveis no banco de dados quando executarmos isso. Então, da maneira como esse comando é apresentado, usaremos o contexto do banco de dados "Master". Sempre que fizermos algo assim, devemos colocar o banco de dados no modo "SINGLE_USER" para permitir uma operação de reparo. Neste caso, vamos executá-lo.
Agora, temos a opção aqui de "ESTIMATEONLY", e mais uma vez, o "ESTIMATEONLY" vai nos dizer quanto espaço vamos abrir mão em "TEMPDB" para fazer isso. Nosso arquivo de snapshot vai ocupar cerca de 230 megabytes, com base em nosso retorno aqui. Depois de fazer um reparo, recomendamos colocá-lo novamente no modo "MULTI_USER". Agora, com "ESTIMATEONLY", não executamos o reparo, apenas fazemos a estimativa. Vamos analisar a execução do comando com o "REPAIR_REBUILD".
Mais uma vez, vamos "Execute" e vamos colocá-lo novamente em "MULTI_USER". Mais uma vez, no contexto do banco de dados "Master", vamos colocá-lo no modo "SINGLE_USER". Neste caso, vamos executar uma operação de reparo. Esta é a operação de reparo leve. E o que você verá é muito do que veríamos em uma verificação regular do banco de dados e, é claro, mais uma vez, queremos verificar se há erros relatados. Neste caso, mais uma vez, não há nenhum.
Tenho um bom banco de dados. E a última parte dessa operação é colocá-lo de volta no modo "MULTI_USER". O comando de reparo "REPAIR_ALLOW_DATA_LOSS" é exatamente como o "REPAIR_REBUILD", exceto que estamos usando o "REPAIR_ALLOW_DATA_LOSS". Normalmente, executamos isso quando tentamos executar o "REPAIR_REBUILD" e o "REPAIR_REBUILD" retorna e nos informa que não foi possível concluir o reparo do banco de dados.
Então, nosso último recurso sem um bom backup, e sim, devemos usar um bom backup antes de sermos forçados a fazer um "REPAIR_ALLOW_DATA_LOSS". Se não houver backup, esta é a nossa única opção para colocar o banco de dados on-line novamente e disponível. Isso conclui nossa demonstração de discussão sobre DBCC CHECKDB, considerando quando usar CHECKDB e algumas das opções de comando mais comuns disponíveis. Espero que este vídeo tenha ajudado você a entender o valor de usar DBCC CHECKDB ao tentar manter uma instalação de banco de dados SQL Server consistente e estável.
Agradecemos a você por assistir.
