Tenho um Banco de Dados SQL corrompido que é inacessível por qualquer meio. Ele está a ponto de comandos simples, como USE MyDatabase, não executarem.
O erro que recebo é: O SQL Server detectou um erro de E/S baseado em consistência lógica: pageid incorreto (esperado 1:371; real 0:0). Ocorreu durante uma leitura de página (1:371) no ID 5 do banco de dados no deslocamento 0x000000002e6000 no arquivo.
O banco de dados chegou a essa situação porque este é um arquivo .MDF corrompido salvo de um HD morto que não está mais acessível. Então, o .MDF contém os dados mais recentes que o usuário quer. Sim, o usuário conseguiu recuperar alguns backups completos, mas eles são muito antigos.
Então o que eu tenho é: um bom e antigo backup completo no arquivo .BAK, um arquivo .MDF corrompido e atualizado e um arquivo .LDF, que está em estado desconhecido, pois não sei como verificá-lo.
Este banco de dados só poderia ser anexado fazendo a 'solução alternativa' de restaurá-lo do antigo arquivo de backup completo .BAK, definindo-o OFFLINE, substituindo o arquivo .MDF com sucesso pelo corrompido. No entanto, o banco de dados sempre fica preso no modo EMERGENCY ou SUSPECT, e não pode prosseguir além disso. Não consigo nem usar CHECKDB, pois qualquer comando ALTER DATABASE resultará no erro descrito.
Eu já tentei exportar os DADOS dele usando o comando bcp e manualmente do SSMS Task, mas também falhou. Eu também usei algumas versões de teste gratuitas de renomados softwares de reparo .MDF, e ele realmente conseguiu capturar bons dados, no entanto, o usuário ainda está cético em usá-los.
Eu também tentei seguir as instruções descritas aqui , mas sem sucesso, pois não consigo fazer o banco de dados ficar em single-user, apenas no MODO DE EMERGÊNCIA. Eu também tentei iniciar o servidor via SQLcmd e prosseguir a partir disso, mas também falhou.
Ainda há algo que possa ser feito? Posso consertar o estado atual dessas páginas com falha via HEX, mesmo que elas desapareçam depois? Alguma outra fonte de exportação que eu possa tentar? Tentei de tudo para restaurar com sucesso?
ATUALIZAÇÃO: Como não tinha mais opção, fiz algo que não é amplamente recomendado : restaurei o backup bom para criar um arquivo .MDF bom. Abri o arquivo .MDF bom com o editor HEX e copiei os endereços de página defeituosos, depois os escrevi no arquivo .MDF ruim. Foi o meu dia, pois por uma sorte incrível , consegui colocar o banco de dados ONLINE e executar comandos alter, que mesmo com alguns erros, colocaram o banco de dados em uma posição onde eu poderia executar checkdb e depois disso, eu poderia executar algumas consultas em tabelas-chave, recuperando alguns dados importantes!!! Os dados, é claro, tinham muitos buracos, e foi realmente doloroso selecionar os setores bons. Essa experiência ruim se transformou em uma boa. Não postarei isso como uma solução, pois esta é realmente confusa. Obrigado a todos que me ajudaram aqui e no stackoverflow.
Não particularmente, a menos que esses dados valham o suficiente para pagar alguém especializado em recuperação de SQL Server para ver se eles podem fazer melhor. Dadas as informações, no entanto, uma varredura offline dos arquivos provavelmente vai lhe dar o que você pode obter e você já fez isso.
Você pode copiar a página para que ela passe na soma de verificação e outras verificações de consistência interna, mas se o mecanismo estiver esperando que isso faça parte de, digamos, uma tabela de sistema base e tentar acessá-la como tal, ele pode passar em todas as verificações de consistência física que quiser, mas o mecanismo provavelmente ainda terá AV ou algum outro problema interno, já que os dados presentes não são os esperados. Os bancos de dados não entram em suspect apenas por um único índice não pertencente ao sistema ter um problema.