SQL Server Suspect: Banco de dados no estado SUSPECT

­­­­

Uma das piores situações que um Administrador de Banco de Dados pode encarar é ouvir reclamações de todos os usuários do sistema relatando que não conseguem acessar o banco de dados ou que a aplicação apresenta erros de acesso no database. Após uma breve verificação desta situação, o DBA descobre que um dos bancos de dados da produção está inacessível e entrou em estado SUSPECT.

Para exemplificarmos como trabalhar nessa situação, usaremos dois casos práticos. O primeiro será sobre um arquivo de log corrompido e como colocar o banco ONLINE sem utilizar o recurso de restore de backup, imaginando que não existe esse recurso disponível.

Com o outro caso, trabalharemos com a hipótese do arquivo de log ter sido apagado acidentalmente enquanto o serviço do SQL Server estava inativo ou até mesmo no caso do arquivo de log estar corrompido de maneira irrecuperável, sendo que será necessária uma ação sem contar com esse arquivo.

Para realizar esses exemplos e orientar na teorização, a versão do SQL Server utilizada aqui deve ser a 2005 ou superior.

No SQL Server, temos “estados de banco de dados” que são representações de como o banco de dados se encontra para execuções de processo. Os estados definem se o banco está apto para se trabalhar nele ou se existe algum problema que precisa de ação direta do DBA. Esses estados são apresentados a seguir:

· ONLINE: O banco de dados está disponível para acesso. Aqui podemos acessar e gravar informações;

· OFFLINE: O banco de dados está indisponível. O serviço do SQL Server não coloca o banco de dados nesse estado automaticamente. É um estado que somente o administrador do banco de dados o coloca via comando ALTER DATABASE [database] OFFLINE;

· RESTORING: O banco de dados está indisponível. Um ou mais arquivos do grupo de arquivos que compõe o banco de dados está sendo restaurado por uma ação de restore;

· RECOVERING: O banco de dados está sendo recuperado. Ele ficará disponível assim que a recuperação estiver completa. Caso não consiga recuperar (colocar o banco de dados em ONLINE), o mesmo entra em estado SUSPECT e fica inacessível. O estado “RECOVERING” acontece toda vez que o serviço do SQL Server é iniciado para testar se todos os objetos e seus datafiles estão íntegros;

· RECOVERY_PENDING: O banco de dados está com algum erro na recuperação e uma ação adicional é exigida do usuário para resolver o erro e permitir que o processo de recuperação seja concluído. O banco fica inacessível enquanto esse erro não for sanado;

· SUSPECT: Alguns dos arquivos do grupo do banco de dados estão corrompidos. Na inicialização do SQL Server, este verifica se os arquivos estão íntegros.

Se ele encontra algum problema nesses arquivos, ele coloca o banco de dados no estado “SUSPECT”. Esse estado necessita da ação direta do Administrador de Banco de Dados e é o estado que trabalharemos nesse artigo;

· EMERGENCY: Nesse estado o banco fica em modo de usuário único e marcado como READ_ONLY, além do arquivo de log de gravação do banco ficar desabilitado. Nesse estado é que trabalharemos para solucionar o estado do banco de dados SUSPECT e para tornar ele ONLINE.

O banco de dados no estado “ONLINE” está acessível e pronto para ser conectado, sendo que toda a gravação dos dados (como update, insert ou delete) passa pelo arquivo de log e em seguida passa para o arquivo de datafile.

Nesse artigo trabalharemos com bancos de dados no estado SUSPECT. O estado SUSPECT significa que existe uma inconsistência transacional e/ou estrutural.

Esse é o resultado de um processo de recuperação com falha (típico quando ocorre corrupção nas páginas de dados) ou o serviço do SQL Server inicializou, mas falhou no RECOVERING do banco de dados (típico quando ocorre erro no log do banco de dados ou também corrupção em páginas de dados).

Por causa dessa tentativa de col ...