{"id":3022,"date":"2014-06-16T08:37:14","date_gmt":"2014-06-16T10:37:14","guid":{"rendered":"http:\/\/fabriciolima.net\/blog\/?p=3022"},"modified":"2018-07-18T18:18:44","modified_gmt":"2018-07-18T21:18:44","slug":"cliente-diz-tenho-backups-e-meu-banco-esta-seguro-sera","status":"publish","type":"post","link":"https:\/\/fabriciolima.net\/blog\/2014\/06\/16\/cliente-diz-tenho-backups-e-meu-banco-esta-seguro-sera\/","title":{"rendered":"Cliente diz: “Tenho Backups e meu banco est\u00e1 seguro”. Ser\u00e1???"},"content":{"rendered":"

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

Resultado: Perda de dados para a empresa.<\/strong><\/span><\/p>\n

Imagina se isso acontece com o banco de dados da sua empresa e com a tabela mais importante que existe?<\/strong><\/p>\n

Outro caso real e mais grave \u00e9 contado pelo Paul Randal<\/a>\u00a0(cara que escreveu o CHECKDB). Um Banco dos EUA teve um problema de corrup\u00e7\u00e3o em um \u00edndice nonclustered. A princ\u00edpio essa \u00e9 uma corrup\u00e7\u00e3o simples de resolver, mas o DBA tomou uma s\u00e9rie de a\u00e7\u00f5es erradas que aumentou ainda mais o problema. Chamaram o Paul Randal e ap\u00f3s an\u00e1lise do ambiente ele pediu os backups para recuperar a base. O Banco tinha um backup FULL de 4 meses atr\u00e1s e backups do Log at\u00e9 o dia do problema, tudo em fita.\u00a0Milagrosamente, todos os backups foram restaurados com sucesso, mas o banco ficou parado por 2 dias para concluir essa opera\u00e7\u00e3o. Os clientes que n\u00e3o conseguiram tirar extratos ou sacar seu dinheiro por dois dias mudaram de banco e logo em seguida o banco quebrou.<\/p>\n

Resultado: Empresa falida e com uma contribui\u00e7\u00e3o significativa do DBA. Para verem o poder que esse profissional tem em m\u00e3os e muitas vezes isso n\u00e3o \u00e9 valorizado at\u00e9 que um desastre como esse aconte\u00e7a.<\/span><\/strong><\/p>\n

Mas o que pode ser feito para evitar ou amenizar esses problemas de corrup\u00e7\u00e3o?<\/p>\n