Para isso, trabalharemos em dois exemplos práticos: um com o banco de dados com o log corrompido e o outro sem o log de dados (típico quando o arquivo foi totalmente perdido por alguma falha de hardware ou software). Com essa prática, saberemos como reagir quando o banco estiver 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 colocar o database no ar sem sucesso, o SQL Server não pode garantir a consistência dos dados e marca o mesmo como SUSPECT. Além disso, o banco de dados se encontrará como se estivesse offline (inacessível), sendo que a única ação possível nesse database é passar para o estado “EMERGENCY” (somente leitura).
Razões para corromper um banco de dados
A maioria dos problemas de I/O ocorre por falhas de subsistemas como, por exemplo, falha em algum momento no sistema operacional ou drivers do storage com problemas de firmware.
Nesses casos, na hora da gravação dos dados da memória RAM (ou do arquivo de SWAP) para o disco, pode ocorrer uma falha onde uma página, um cabeçalho ou até mesmo o arquivo inteiro do banco de dados pode se corromper.
Até mesmo uma falha de energia brusca no momento de gravação também pode corromper o banco de dados.
Quando baixamos o serviço do SQL Server de forma brusca (com o comando SHUTDOWN WITH NOWAIT), o serviço do SQL Server pode gravar uma informação incompleta no storage e também pode causar corrupção, pois não espera a efetiva gravação dos dados em disco.
Outro detalhe importante que pode corromper o banco de dados é deixar a opção AUTO CLOSE com o valor true.
Isto faz com que, assim que a última sessão encerrar dentro do banco de dados, os arquivos físicos que compõem o banco de dados (*.mdf e *. ldf) fiquem livres para outros serviços do sistema operacional utilizar.
Com a opção AUTO CLOSE configurada como true, realizar uma compactação de arquivos do Windows ou até mover um ou todos os datafiles do banco de dados se torna totalmente possível. Até mesmo a própria verificação do antivírus pode travar a utilização dos datafiles no SQL Server e não deixar o database ONLINE.
Por isso é importante criar uma regra no aplicativo do antivírus para não verificar a pasta de datafiles do SQL Server. Isso evita que o antivírus tente acessar esses arquivos em qualquer circunstância e também libera qualquer concorrência entre o serviço do SQL Server e o antivírus.
Outra situação que pode acabar corrompendo
um datafile do database é deixar a opção “Page
Verify” em NONE ou TORN_PAGE_DETECTION. A opção NONE não utiliza a verificação da
gravação do dado no disco e a outra opção (TORN_PAGE_DETECTION)
já é defasada nas versões SQL Server 2005 ou maior (pois uti ...
