Fala Pessoal,

Neste post continuarei com o teste do Operation Mode High Safety Without Automatic Failover. Caso ainda não tenham visto os posts anteriores, sugiro que os leia antes de continuar:

Database Mirroring – Operation Mode High Safety Without Failover – Parte 1

Database Mirroring – Operation Mode High Safety Without Failover – Parte 2

O Objetivo deste teste é parar o servidor Principal, acabar com o Mirror, subir o servidor Principal e verificar se houve alguma perda de dados.

Iniciei o loop de Insert sem waitfor delay:
while 1=1
begin
if exists (select null
from sys.databases
where name = ‘MIRROR1’ and state_desc = ‘ONLINE’)
insert into mirror1..Teste(texto)
select @@servername
end

Caso um problema aconteça com o seu servidor A (principal) o mirror fica conforme abaixo:

Nesse momento, como nesse operation mode não temos um failover automático, o mirror fica nesse status até que o servidor A volte ou você faça um failover manual.

Conforme mostrei no post anterior:

Database Mirroring – Error: The Command Failed Because The Database Mirror Is Busy

Não é possível fazer um failover manual nessa situação.

Caso você não possa esperar o servidor A voltar, a única solução é parar o mirror conforme os scripts:

ALTER DATABASE mirror1 SET PARTNER OFF
GO
RESTORE DATABASE mirror1 WITH RECOVERY

Executando os comandos acima, a database mirror1 já fica disponível no servidor B.

Ao subir novamente o servidor A, a database mirror1 desse servidor também fica disponível.

Nesse momento, deve-se ter certeza que as aplicações e serviços estão apontando para apenas um servidor.

Para verificar se houve perda de dados com a quebra do mirror, executei a seguinte query nos dois servidores para pegar o último registro que foi inserido no servidor A com o texto ‘ambiente5’ e comparar com o último registro com essa informação que foi sincronizado com o servidor B:

select top 1 Cod, Data, Texto
from mirror1..Teste
where Texto = ‘ambiente5’
order by data desc

Resultado no servidor A (Ambiente5):

300.866    2012-01-31 14:00:37.250    Ambiente5

Resultado servidor B (Ambiente5\inst1):

300.866    2012-01-31 14:00:37.250    Ambiente5

Ou seja, o último registro inserido no servidor A foi transferido para o servidor B. Não tive perda de dados.

Conforme era esperado, como meu mirror estava sincronizado e no modo High Safety, não tive perda de dados, entretanto, tivemos que acabar com o mirror. Caso o tamanho da database seja muito grande, a reconstrução de um database mirror pode demorar horas. Se não for possível esperar todo esse tempo para um ambiente crítico, deve-se utilizar o operation mode High Safety With Automatic Failover.

Artigos relacionados:

Série de Posts sobre Database Mirroring

Database Mirroring – Como alterar o Operation Mode

Database Mirroring – Operation Mode High Performance – Parte 1

Database Mirroring – Operation Mode High Performance – Parte 2

Database Mirroring – Operation Mode High Performance – Parte 3

Database Mirroring – Operation Mode High Safety Without Failover – Parte 1

Database Mirroring – Operation Mode High Safety Without Failover – Parte 2

Database Mirroring – Error: The Command Failed Because The Database Mirror Is Busy

Até o próximo post.

Gostou desse Post?

Cadastre seu e-mail para receber novos Posts e curta minha Página no Facebook para receber Dicas de Leituras e Eventos sobre SQL Server.

Abraços,

Fabrício Lima

MCITP – Database Administrator

Consultor e Instrutor SQL Server

Trabalha com SQL Server desde 2006