Fala Pessoal,<\/p>\n
Gostaria de fazer deste post como se fosse uma thread de um f\u00f3rum com uma discus\u00e3o sobre alta disponibilidade no SQL Server.<\/p>\n
S\u00e1bado, dia 13\/08 eu tive um problema em uma database que deixa qualquer DBA com o cora\u00e7\u00e3o disparado(DBA n\u00e3o pode ter problema card\u00edaco!!!). Uma database de 110GB que \u00e9 muito utilizada ficou com o status Suspect<\/strong>. No meu caso n\u00e3o foi t\u00e3o grave pois o problema ocorreu em uma database de um servidor D-1 que recebe restore di\u00e1rio do servidor de produ\u00e7\u00e3o.<\/p>\n A database ficou Suspect durante a cria\u00e7\u00e3o de um \u00edndice muito grande que \u00e9 criado diariamente nesse servidor D-1.<\/p>\n A primeira coisa que fiz para tentar deixar a database online novamente foi seguir os passos desse meu outro artigo, onde j\u00e1 havia recuperado uma database em modo Suspect: Casos do Dia a Dia: Database em modo Suspect<\/a>.<\/p>\n Ent\u00e3o, executei os comandos: ALTER DATABASE XXXXXX SET ONLINE<\/strong><\/p>\n Entretanto, ao tentar deixar a database ONLINE, ela entrou em modo SUSPECT novamente e o erro abaixo foi gerado:<\/p>\n Msg 926, Level 14, State 1, Line 1 Fiz um select na tabela Msdb.dbo.Suspect_Pages<\/strong> e encontrei 2 p\u00e1ginas com problema. As duas possu\u00edam na coluna Event_Type o valor 1 que significa:<\/p>\n 1 = An 823 error that causes a suspect page (such as a disk error) or an 824 error other than a bad checksum or a torn page (such as a bad page ID).<\/span><\/p>\n Novamente deixei a database em modo de emergencia para fazer alguns select na database:<\/p>\n ALTER DATABASE XXXXXX SET EMERGENCY<\/strong><\/p>\n ALTER DATABASE XXXXXX SET SINGLE_USER WITH ROLLBACK IMMEDIATE<\/strong><\/p>\n Em seguida, eu tentei rodar o comando abaixo para verificar qual seria o objeto que estava com problema, mas o DBCC PAGE retornava um erro e n\u00e3o me mostrava a informa\u00e7\u00e3o dos objetos:<\/p>\n DBCC TRACEON ( 3604 ) Nesse momento, tentei rodar o comando DBCC CHECKDB nessa database, mas o mesmo tamb\u00e9m n\u00e3o funcionou retornando o seguinte erro com 5 segundos de execu\u00e7\u00e3o:<\/p>\n Msg 8921, Level 16, State 1, Line 2. Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.<\/span><\/p>\n Pela mensagem de erro, como a letra do TempDB estava com 30 GB de espa\u00e7o dispon\u00edvel, acredito que uma tabela de sistema dessa database estava inconsistente.<\/p>\n Como eu n\u00e3o iria voltar um Backup Full pois j\u00e1 estava quase na hora da atualiza\u00e7\u00e3o di\u00e1ria dessa database(o que foi executado com sucesso), fui tentar uma \u00faltima op\u00e7\u00e3o para recuperar a database mesmo com uma poss\u00edvel perda de dados:<\/p>\n DBCC CHECKDB (NOME_DATABASE, REPAIR_ALLOW_DATA_LOSS) <\/strong><\/p>\n Todavia, esse comando tamb\u00e9m me retornava um erro:<\/p>\n Msg 8921, Level 16, State 1, Line 2. Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors. No log do SQL foi registrada a seguinte informa\u00e7\u00e3o: <\/span><\/p>\n DBCC CHECKDB(XXXXXXX) WITH no_infomsgs executed by LOGIN found 78 errors and repaired 0 errors.<\/span><\/p>\n Ou seja, n\u00e3o foi poss\u00edvel corrigir o problema dessa database. Eu apenas consegui deixar a database dispon\u00edvel para uso novamente executando:<\/p>\n ALTER DATABASE XXXXXX SET MULTI_USER<\/strong><\/p>\n Alguns jobs que acessam essa database at\u00e9 executaram com sucesso, mas eu n\u00e3o consegui criar o \u00edndice que gerou o problema de corrup\u00e7\u00e3o e acredito outras procedimentos falhariam ao acessar os dados corrompidos.<\/p>\n Eu n\u00e3o consegui encontrar outra solu\u00e7\u00e3o que n\u00e3o fosse voltar o restore completo dessa database, o que demoraria mais de 1 hora e causaria um grande transtorno se fosse em produ\u00e7\u00e3o.<\/p>\n Se eu tivesse toda uma solu\u00e7\u00e3o de cluster do SQL Server, n\u00e3o adiantaria nada nesse caso pois ela garante a disponibilidade do Hardware do servidor.<\/p>\n Minha replica\u00e7\u00e3o de dados entre 2 Storages tamb\u00e9m n\u00e3o resolveria pois os dados iriam corrompidos de um Storage para o outro.<\/p>\n Conforme j\u00e1 tinha verificado na tabela Suspect_Pages, ele me indicou que o erro gerado era de n\u00famero 823 ou 824: Na solu\u00e7\u00e3o de Database Mirroring do SQL Serve 2008, temos uma \u00f3tima funcionalidade de corre\u00e7\u00e3o de p\u00e1ginas corrompidas, conforme podemos ver nesse artigo do Paul Randal:SQL Server 2008: Automatic Page Repair with Database Mirroring Nesse artigo podemos ver os n\u00fameros dos erros que a solu\u00e7\u00e3o de Automatic Page Repair soluciona:<\/p>\n “The feature works for pages that have 824 errors, 823 errors where the OS returns a CRC error while reading the page (to prevent resource issues triggering a page repair), and pages that have 829 errors (where the page is marked as restore pending).” <\/span><\/p>\n Logo, se eu tivesse um Database Mirroring configurado ele resolveria esse meu problema de corrup\u00e7\u00e3o de forma transparente.<\/p>\n Contudo, a solu\u00e7\u00e3o de Database Mirroring tamb\u00e9m tem alguns problemas:<\/p>\n N\u00f3s que trabalhamos como DBA Full Time de uma empresa, vamos sempre dormir preocupados pois a qualquer momento pode acontecer um problema em que sua solu\u00e7\u00e3o de alta disponibilidade n\u00e3o consiga tratar 100% dos poss\u00edveis problemas e voc\u00ea precise voltar um backup completo da base, o que dependendo do tamanho da database, causaria um alto tempo de parada (perda de $$) e muitas explica\u00e7\u00f5es teriam que ser dadas a diretoria.<\/p>\n Algu\u00e9m tentaria fazer algo diferente para resolver esse problema espec\u00edfico de corrup\u00e7\u00e3o?<\/p>\n Qual solu\u00e7\u00e3o de High Availability e Desaster Recovery voc\u00ea utilizaria para deixar seu BD (>500 GB de dados) preparado para problemas de hardware e de Corrup\u00e7\u00e3o e com um Failover Autom\u00e1tico? N\u00e3o importando o valor do investimento($$) necess\u00e1rio.<\/p>\n Conto com a opini\u00e3o da comunidade SQL Server.<\/p>\n Gostou dessa dica?<\/b><\/p>\n Cadastre seu e-mail para receber novos Posts e curta minha P\u00e1gina no Facebook<\/a> para receber Dicas de Leituras e Eventos sobre SQL Server.<\/p>\n
\nALTER DATABASE XXXXXX SET EMERGENCY<\/strong> — Foi alterada com sucesso<\/p>\n
\nDatabase NOMEDATABASE cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.Msg 5069, Level 16, State 1, Line 1. ALTER DATABASE statement failed. Msg 824, Level 24, State 2, Line 1
\nSQL Server detected a logical consistency-based I\/O error: incorrect pageid (expected 1:1175999; actual 1:12045999). It occurred during a read of page (1:11751999) in database ID 99 at offset 0x0000166a370000 in file ‘X:\\XXXXXX.mdf’.
\nThis is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). <\/span><\/p>\n
\nDBCC PAGE ( XXXXXX, 1 , 1175999 , 3 )<\/strong>
\nou
\nDBCC PAGE ( XXXXXX, 1 , 1175999 , 1 )<\/strong><\/p>\n
\nCHECKDB found 78 allocation errors and 0 consistency errors not associated with any single object.
\nCHECKDB found 78 allocation errors and 0 consistency errors in database ‘XXXXXX’.<\/span><\/span><\/p>\n
\nEventType = 1 :An 823 error that causes a suspect page (such as a disk error) or an 824 error other than a bad checksum or a torn page (such as a bad page ID).<\/span><\/p>\n
\n<\/a><\/p>\n\n