Cenário:
Vamos criar um database em seguida vamos simular um erro de Log corruption, e vamos realizar alguns procedimentos para torná-lo operacional novamente.
Passo a passo (Reprodução):
1 – Criar um database de nome Teste no servidor SQL Server:
CREATE DATABASE Teste
ON (NAME=’Teste_Data’, FILENAME=’D:TempTeste_Data.MDF’)
LOG ON (NAME=’Teste_Log’, FILENAME=’D:TempTeste_Log.LDF’)
2 – Pare o serviço do SQL Server.
3 – Renomeie o arquivo de Log.
4 – Inicie o serviço do SQL Server.
5 – Verifique o status do database pelo Enterprise Manager, provavelmente estará em Suspect.
6 – Faça um detach no database:
EXEC sp_detach_db ‘Teste’
7 – Localize os arquivos de dados (.mdf) e log (.ldf) e renomei-os para um nome qualquer.
8 – Crie um novo database com o mesmo nome do banco corrompido, conforme passo 1.
Nota: Na medida do possível é recomendado que os arquivos deste novo banco tenham o mesmo tamanho que os arquivos do banco corrompido.
9 – Pare o serviço do SQL Server.
10 – Localize os arquivos de dados (.mdf) e log (.ldf) do banco recém criado e renomeie os arquivos para o nome dos arquivos originais (banco corrompido).
11 – Inicie o serviço do SQL Server.
12 – Verifique o status do database pelo Enterprise Manager, provavelmente estará em Suspect.
13 – Vamos tentar “zerar” o status do database para o modo operacional.
EXEC sp_resetstatus ‘Teste’
Nota: Neste passo verificamos que o comando acima retorna que nada foi alterado.
14 – Vamos novamente tentar colocar o database operacional, utilizando um comando DBCC não documentado.
DBCC DBRECOVER (Teste, ignoreerrors)
Server: Msg 5173, Level 16, State 1, Line 1
Cannot associate files with different databases.
Log file ‘d:TempTeste_Log.LDF’ does not match the primary file. It may be from a different database or the log may have been rebuilt previously.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
A mensagem acima indica que o arquivo de Log encontrado não é correspondente ao Primary Data File.
15 – Sendo assim, vamos fazer um “rebuild” no arquivo de Log para que nosso database torne-se operacional.
EXEC sp_configure ‘allow updates’, 1
RECONFIGURE WITH OVERRIDE
GO
BEGIN TRANSACTION
UPDATE sysdatabases SET status = 32768 WHERE name=’Teste’
COMMIT TRANSACTION
GO
EXEC sp_configure ‘allow updates’, 1
RECONFIGURE WITH OVERRIDE
GO
15.1 – Vamos novamente verificar o status do nosso database no Enterprise Manager.
Agora ele deve apresentar-se em “Emergency Mode“, neste status conseguimos realizar um “rebuild” no Log, para isso vamos utilizar um outro comando DBCC não documentado:
USE master
GO
DBCC REBUILD_LOG(‘Teste’,’D:TempTeste_Log_new.LDF’)
A seguinte mensagem deverá ser exibida:
Warning: The log for database ‘Teste’ has been rebuilt. Transactional consistency has been lost. DBCC CHECKDB should be run to validate physical consistency. Database options will have to be reset, and extra log files may need to be deleted.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
16 – Após os procedimentos do passo 15, vamos corrigir as inconsistências que por ventura possam ter ocorrido nesse “rebuild“.
DBCC CHECKDB(‘Teste’)
Caso ao final dessa checagem sejam encontradas inconsistências, execute:
EXEC sp_dboption ‘dbo use only’, false
GO
EXEC sp_dboption ‘single user’, true
GO
DBCC CHECKDB(‘Teste’, REPAIR_FAST)
Se mesmo após o REPAIR_FAST continuar encontrando inconsistências execute:
DBCC CHECKDB(‘Teste’, REPAIR_ALLOW_DATA_LOSS)
Nota: Este procedimento deve ser executado em último caso, pois como o próprio nome diz, existe a possibilidade de perda de dados.
Ao final dessa checagem verifique novamente se existem inconsistências executando o comando DBCC CHECKDB do passo 16.
17 – Caso não existam mais inconsistências, devemos colocar nosso banco operacional novamente, sendo assim execute:
EXEC sp_dboption ‘single user’, false
Pronto, a partir deste ponto o database deverá ficar operacional novamente. Lembre-se de realizar um backup full 🙂
Grande abraço e até a próxima!
Rodrigo Fernandes (RFernandes)