Corrigindo Erro de Suspect Database

Posted on outubro 22, 2012

3


 

Introdução

Uma das causas de um banco de dados entrar em ‘Suspect’ é que, algum dos arquivos do banco de dados não estarem disponíveis durante a inicialização do serviço do SQL Server. Com isso, podemos ter ou problemas de corrupção em alguma parte dentro dos arquivos ou também se o banco de dados for movido para outro diretório e durante a inicialização e o SQL Server não conseguir mapear o arquivo. Se realmente ocorrer esses problemas descritos acima o banco de dados será marcado como SUSPECT.

Colocando o Banco em Suspect

Iremos realizar a criação de uma banco de dados e realizar a corrupção de um dos arquivos para entender melhor como o SQL Server se comporta durante esse procedimento.

CREATE DATABASE DatabaseSuspect

 

USE DatabaseSuspect

go

 

CREATE TABLE Dados

(

    ID INT IDENTITY(1,500),

    Nome VARCHAR(100)

)

 

INSERT INTO Dados (Nome)

VALUES (‘Luan Moreno Medeiros Maciel’)

go 10

 

INSERT INTO Dados (Nome)

VALUES (‘Antônio de Pádua’)

go 10

 

INSERT INTO Dados (Nome)

VALUES (‘Auguimar Júnior’)

go 100

 

INSERT INTO Dados (Nome)

VALUES (‘Ribamar Martins’)

go 100

 

INSERT INTO Dados (Nome)

VALUES (‘Watson Odilon’)

go 100

 

BEGIN TRAN

 

INSERT INTO Dados (Nome)

VALUES (‘SQLServerIOProblem’)

go 100

 

CHECKPOINT

 

SHUTDOWN WITH NOWAIT

Durante uma transação explícita que realizamos logo acima, iremos executar o comando SHUTDOWN WITH NOWAIT, porém antes disso executamos o comando CHECKPOINT, para garantir que essa transação seja escrita em disco. Executando esse comando nós simulamos um problema repentino de desligamento da instância do banco de dados. Nesse momento iremos simular uma falha de I/O abrindo o HEX EDITOR 

 

image

(Figura 1 – Alterando a 2ª fila para 0 e assim simulando um problema de I/O / Corrupção.)

 

 

image

(Figura 2 – Reiniciando a Instância.)

 

USE DatabaseSuspect

go

Msg 945, Level 14, State 2, Line 1
Database ‘DatabaseSuspect’ cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.

 

Como primeiro aspecto devemos colocar o banco de dados em Modo EMERGENCY e depois colocar o banco de dados em SINGLE_USER garantindo assim somente um acesso.

 

ALTER DATABASE DatabaseSuspect

SET EMERGENCY

USE DatabaseSuspect

go

 

sp_dboption ‘DatabaseSuspect’, ‘dbo Use Only’, false

 

ALTER DATABASE DatabaseSuspect

SET SINGLE_USER

 

Agora iremos rodar o DBCC CheckDB e assim verficar a integridade do banco de dados, tentando reparar sem perda de dados.

 

DBCC CHECKDB (‘DatabaseSuspect’,REPAIR_ALLOW_DATA_LOSS)

go

 

Msg 5120, Level 16, State 101, Line 1
Unable to open the physical file "C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\DatabaseSuspect_log.LDF". Operating system error 32: "32(failed to retrieve text for this error. Reason: 15105)".
File activation failure. The physical file name "C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\DatabaseSuspect_log.LDF" may be incorrect.
The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.
Failed to restart the current database. The current database is switched to master.
Msg 5123, Level 16, State 1, Line 1
CREATE FILE encountered operating system error 32(failed to retrieve text for this error. Reason: 15105) while attempting to open or create the physical file ‘C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\DatabaseSuspect_log.LDF’.
Msg 5024, Level 16, State 2, Line 1
No entry found for the primary log file in sysfiles1.  Could not rebuild the log.
Msg 5028, Level 16, State 2, Line 1
The system could not activate enough of the database to rebuild the log.
DBCC results for ‘DatabaseSuspect’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘DatabaseSuspect’.
Msg 7909, Level 20, State 1, Line 1
The emergency-mode repair failed.You must restore from backup.

 

O SQL Server tenta realizar um rebuild do log porém com o erro gerado do DBCC CheckDB ele força o log a ser reconstruído tentado aproveitá-lo o máximo possível realizando um FULL Repair.

 

sp_dboption ‘DatabaseSuspect’, ‘dbo Use Only’, false

 

ALTER DATABASE DatabaseSuspect

SET MULTI_USER

Com isso voltamos o banco de dados em modo MULTI_USER e realizando um SELECTe  vemos que nesse caso os registros foram recuperados.

SELECT  COUNT(*)AS Quantidade

FROM Dados

WHERE Nome = ‘SQLServerIOProblem’

 

image

(Figura 3 – Quantidade de registros inseridos 100.)