Database Mirroring \u2013 Operation Mode High Performance \u2013 Parte 2<\/a><\/p>\n Novamente, com o loop de insert rodando no servidor A (Principal), para esse teste, eu parei o servi\u00e7o do SQL Server do servidor A:<\/p>\n Contudo, dessa vez o pessoal da infraestrutura n\u00e3o conseguiu resolver o problema do Servidor A. Logo, eu tive que acabar com o mirror para que o Log da database do servidor B n\u00e3o ficasse crescendo sem parar.<\/p>\n Para acabar com o mirror, executei o comando: alter database mirror1 set partner off<\/p>\n Logo ap\u00f3s, rodando a query abaixo, \u00e9 poss\u00edvel ver que o mirror n\u00e3o existe mais: Mesmo com o mirror n\u00e3o existindo mais, a base do servidor B continua com o status restoring:<\/p>\n Para deix\u00e1-la online, deve-se rodar o comando: restore database mirror1 with recovery<\/p>\n Entretanto, ao execut\u00e1-lo, recebi o seguinte erro:<\/p>\n Msg 5094, Level 16, State 2, Line 1 Isso aconteceu porque eu tinha um snapshot na database do servidor B que era o mirror.<\/p>\n Esse snapshot deve ser exclu\u00eddo com o comando abaixo: Onde Mirror1_Snapshot \u00e9 o nome da database snapshot que eu criei. Posteriormente farei um post sobre database snapshot no database mirroring.<\/p>\n Executando o comando \u201crestore database mirror1 with recovery<\/em>\u201d novamente, a database ficou online.<\/p>\n Algum tempo depois a galera da Infraestrutura abriu um chamado no fornecedor de Hardware e conseguiram voltar o servidor A. Ao fazer isso, a database desse servidor tamb\u00e9m ficou online automaticamente. Isso pode gerar um problema grave, pois imagina se existirem muitas aplica\u00e7\u00f5es e servi\u00e7os apontando para o servidor A. Quando o servidor A morre e o servidor B passa a receber as aplica\u00e7\u00f5es e servi\u00e7os, ele se torna o servidor com dados mais atualizados. Agora, imagina que voc\u00ea esqueceu de redirecionar alguma aplica\u00e7\u00e3o ou servi\u00e7o do servidor A para o B, quando o servidor A fica dispon\u00edvel, suas aplica\u00e7\u00f5es e servi\u00e7os podem ficar manipulando dados no servidor A e B. Isso vai gerar um GRANDE problema dependendo do tamanho do seu ambiente. Ent\u00e3o, deve-se ter um cuidado especial com essa situa\u00e7\u00e3o e mapear TODAS as aplica\u00e7\u00f5es e servi\u00e7os que utilizam uma database presente em um Database Mirroring.<\/p>\n Uma solu\u00e7\u00e3o para isso seria um redirecionamento de DNS. As aplica\u00e7\u00f5es utilizariam um ALIAS chamado DBProducao e esse ALIAS apontaria para um servidor f\u00edsico chamado ServerA com IP 192.0.0.1. Caso aconte\u00e7a algum problema com esse servidor, o database mirror far\u00e1 um failover para o serverB com IP 192.0.0.2. Assim, basta voc\u00ea realizar o redirecionamento de DNS do Alias DBProducao para que ele responda pelo IP 192.0.0.2. Com isso, n\u00e3o existe o risco de nenhuma aplica\u00e7\u00e3o ou servi\u00e7o gravar dados em um local indevido.<\/p>\n Continuando o teste, agora vamos verificar como ficou a sincroniza\u00e7\u00e3o dos dados entre os dois servidores com a volta do servidor A.<\/p>\n O servidor B (ambiente5\\inst1) que era o mirror, possui dados at\u00e9 o Cod e data abaixo: Ap\u00f3s o servidor A (que era o Principal) ficar online, executei a query abaixo para selecionar os dados que existiam no servidor A, mas ainda n\u00e3o haviam sido espelhados para o servidor B:<\/p>\n select * from mirror1..Teste where cod >= 32610 order by data desc<\/p>\n Comparando o resultado cheguei \u00e0 conclus\u00e3o:<\/p>\n Perdi dados de 2012-01-05 15:25:12<\/strong>.710 at\u00e9 2012-01-05 15:25:22<\/strong>.747, ou seja, 10 segundos.<\/p>\n Isso porque meu ambiente estava fazendo apenas um insert em uma tabela. Agora imagina em um ambiente grande onde a quantidade de dados atualizados \u00e9 alta. A perda de dados seria consider\u00e1vel. Contudo, ela ainda pode ser menor do que se voc\u00ea tivesse apenas uma rotina de backup e perdesse os arquivos de log de alguma database. Nesse caso, voc\u00ea n\u00e3o conseguiria salvar o Tail Log e s\u00f3 teria os backups do log j\u00e1 realizados. Como esse job deve rodar a cada 5 minutos, por exemplo, a perda de dados pode ser muito maior do que em um mirror com High Performance.<\/p>\n Artigos relacionados:<\/p>\n S\u00e9rie de Posts sobre Database Mirroring<\/a><\/p>\n Database Mirroring \u2013 Como alterar o Operation Mode<\/a><\/p>\n Database Mirroring \u2013 Operation Mode High Performance \u2013 Parte 1<\/a><\/p>\n![\"\"](\"https:\/\/www.fabriciolima.net\/blog\/wp-content\/uploads\/2012\/03\/DBMirror1.png\" "\\"DBMirror1\\"")
<\/a><\/p>\n
\nSELECT db.name, mirroring_state_desc, mirroring_safety_level_desc,mirroring_witness_state_desc
\nFROM sys.database_mirroring m
\nJOIN sys.databases db ON db.database_id = m.database_id
\nwhere name = ‘Mirror1’<\/p>\n![\"\"](\"https:\/\/www.fabriciolima.net\/blog\/wp-content\/uploads\/2012\/03\/DBMirror2.png\" "\\"DBMirror2\\"")
<\/a><\/p>\n![\"\"](\"https:\/\/www.fabriciolima.net\/blog\/wp-content\/uploads\/2012\/03\/DBMirror3.png\" "\\"DBMirror3\\"")
<\/a><\/p>\n
\nThe operation cannot be performed on a database with database snapshots or active DBCC replicas.
\nMsg 3013, Level 16, State 1, Line 1
\nRESTORE DATABASE is terminating abnormally.<\/p>\n
\ndrop database mirror1_snapshot<\/p>\n
\nCod: 32610\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Data: 2012-01-05 15:25:12.710<\/p>\n