Recuperando Banco de Dados Corrompidos no SQL Server 2005 utilizando Comandos DBCC

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

O artigo tem como objetivo apresentar algumas das funções utilizadas para detectar e corrigir possíveis problemas de corrupção do banco de dados SQL Server 2005.

Esse artigo faz parte da revista SQL Magazine edição 62. Clique aqui para ler todos os artigos desta edição

imagem_pdf.jpg

SQL Server

Recuperando Banco de Dados Corrompidos no SQL Server 2005 utilizando Comandos DBCC

 

Imagine que você é um administrador de banco de dados SQL Server 2005 onde os dados da sua empresa devem estar disponíveis 24 horas por dia, 7 dias por semana. O que fazer quando o banco de dados apresenta problemas de corrupção de arquivos ou de dados? Como proceder para colocar no ar as informações de seu cliente de maneira rápida com a mínima de perda de dados?

Para isso, é importante conhecer os principais recursos que o SQL Server 2005 disponibiliza para auxiliar você na tarefa de administração e correção de problemas com banco de dados.

O presente artigo tem como objetivo apresentar algumas das funções utilizadas para detectar e corrigir possíveis problemas de corrupção do banco de dados SQL Server 2005, através da simulação de um problema de corrupção do arquivo do banco de dados.

 

Possíveis Estados e Corrompimento de um Banco de Dados no SQL Server 2005

Antes de iniciarmos o nosso estudo de caso, é importante conhecer os principais estados que um banco de dados SQL Server 2005 pode assumir, pois através do seu estado é possível identificar se o banco está ou não corrompido. Sendo assim, os principais estados que um banco SQL Server 2005 pode assumir são:

·         ONLINE: O banco de dados está disponível para acesso. O grupo principal de arquivos está online.

·         OFFLINE: O banco de dados não está disponível. Um banco torna-se off-line por ação explícita do usuário, e permanece assim até que o usuário o torne online novamente. Por exemplo, podemos tornar um banco no estado off-line para mover os arquivos para um novo disco, para em seguida torná-lo online novamente.                

·         RESTORING: O banco de dados fica nesse estado em duas situações: (1) um ou mais arquivos primários estão sendo restaurados ou (2) um ou mais arquivos secundários estão sendo restaurados. Nesse estado o banco de dados ficará off-line, o que significa que ele está indisponível até o termino da restauração.

·         RECOVERING: O banco de dados está sendo recuperado. O processo de recuperação é um estado momentâneo, e o banco de dados automaticamente se tornará online se a recuperação for bem sucedida. Caso contrário, o banco pode se tornar suspeito. Nesse estado, o banco de dados está indisponível para acesso até a conclusão da recuperação.

·         RECOVERING PENDING: Quando se detecta um erro de recursos relacionados ao uso do SQL Server (exemplo: problemas com hardware ou serviços do sistema operacional que o SQL Server 2005 necessite para a execução correta de seus serviços) durante a recuperação. O banco de dados não está danificado, mas arquivos podem estar faltando ou limitações de recursos de sistemas pode estar impedindo que ele seja iniciado. Nesse estado, o banco de dados está indisponível e medidas adicionais pelo usuário são necessárias para resolver o erro e tornar o banco de dados online novamente.

·         SUSPECT: Pelo menos um dos grupos primários de arquivos está marcado como suspeito e esses grupos podem estar danificados. O banco de dados não pode ser recuperado durante a inicialização do SQL Server. Nesse estado, o banco de dados está indisponível e medidas adicionais pelo usuário são necessárias para resolver o problema.

·         EMERGENCY: O estado de emergência é definido pelo usuário do banco de dados. O banco está em modo de usuário único e pode ser reparado ou restaurado. Neste estado, o banco é marcado como READ_ONLY (somente leitura), o log está desabilitado e o acesso está limitado aos membros da função de servidor SYSADMIN. Este modo é utilizado principalmente para fins de resolução de problemas. Por exemplo, um banco de dados marcado como suspeito pode ser definido para o estado de emergência. Isto permite que administrador do sistema faça leitura no banco de dados.    

 

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?