Ol\u00e1 Pessoal,<\/p>\n
O objetivo desse post \u00e9 fazer um alerta a todos voc\u00eas que s\u00e3o respons\u00e1veis por um banco de dados SQL Server, seja voc\u00ea um desenvolvedor, um analista de banco de dados, um coordenador ou gerente de TI.<\/p>\n
J\u00e1 atendi muitos clientes na minha Consultoria SQL Server<\/a> que contrataram um pacote de Tuning comigo, mas n\u00e3o quiseram contratar o pacote de reestrutura\u00e7\u00e3o das rotinas de backups e alertas, pois ele j\u00e1 tinha um backup rodando no banco de dados ou tinha um servidor na nuvem onde existe uma garantia de alta disponibilidade do servidor virtual ou por outros motivos.<\/p>\n Acontece que mesmo com uma excelente rotina de backups voc\u00ea pode perder dados no SQL Server.<\/span> Isso n\u00e3o \u00e9 um problema exclusivo do SQL Server, dados tamb\u00e9m podem se corromper nos outros SGBDs do mercado (Oracle, DB2 e etc).<\/p>\n Em um exemplo real, um cliente me ligou pedindo ajuda depois que sua base estava corrompida. Ao fazer uma an\u00e1lise do n\u00edvel de corrup\u00e7\u00e3o desse cliente, n\u00e3o seria poss\u00edvel recuperar essa base, pois p\u00e1ginas de estruturas internas da \u00fanica tabela existente na base estavam corrompidas. Nem o comando CHECKDB com\u00a0REPAIR_ALLOW_DATA_LOSS era poss\u00edvel ser executado nessa base dado o n\u00edvel de corrup\u00e7\u00e3o. Solicitei os backups ao cliente e ele disse que tinha apenas um backup feito na semana anterior, mas que j\u00e1 tinha restaurado e o backup tamb\u00e9m j\u00e1 estava com a base corrompida.<\/em><\/p>\n Nesse caso, o backup era executado com sucesso, mas a base possu\u00eda p\u00e1ginas corrompidas.\u00a0<\/strong><\/span>A \u00fanica solu\u00e7\u00e3o poss\u00edvel foi realizar um SELECT nos dados que ainda estavam sendo retornados e inserir esses dados em uma nova Base\/Tabela.<\/p>\n