1) O failover é automático e realizado em menos de 3 segundos – isso significa que se o servidor principal cair, o servidor espelho passará a atender as requisições dos clientes em até 3 segundos. Logicamente que esse tempo está diretamente relacionado às condições da sua rede e do seu hardware.
2) Não é necessário hardwares especializados – Você pode configurar o database mirroring utilizando qualquer hardware padrão do mercado e também não é necessário storage de discos externo.
3) Ele é auto monitorável – na sessão de database mirroring existe um parceiro conhecido como witness server, ele é responsável por monitorar o mirror e fornecer o failover automático no caso de problemas na base de dados principal.
4) A alta disponibilidade é realizada no nível de database.
5) O redirecionamento dos clientes é automático e transparente.
6) Não possui um limite de distância entre os nós que compõem o mirror.

Bom, é claro que o database mirroring também possui algumas limitações como:
 
1) Suporte a full-text limitado – você pode espelhar um database configurado para full-text da mesma forma que os demais, o problema é que após o início do mirroring os subseqüentes backups de log não conterão as possíveis alterações realizadas nos catálogos do full-text. Para mais informações sobre essa limitação e como resolvê-la, consulte o tópico “Database Mirroring and Full-Text Catalogs” no Books Online do SQL Server 2005/2008.
2) A aplicação precisa ser escrita de forma a dar suporte a database mirroring – normalmente é uma simples alteração na string de conexão. Para mais informações consulte o tópico “Connecting Clients to a Mirrored Database” no Books Online do SQL Server 2005/2008.
3) Enquanto a sessão de database mirroring estiver ativa não é permitida a realização de backup/restore da base espelho.
4) Enquanto a sessão de database mirroring estiver ativa, a base espelho não estará disponível para as aplicações. Isso porque a base ficará em status de recovering.

Falando basicamente, o database mirroring envolve duas cópias de um mesmo banco de dados que reside em diferentes servidores ou instâncias do SQL Server 2005/2008. Um ponto importante a ser observado é que durante a sessão de database mirroring, apenas uma cópia do banco de dados ficará disponível para as aplicações, esta é conhecida como “principal database”. Na prática, o espelhamento envolve aplicar o log de cada transação (INSERT, UPDATE, DELETE) realizada no principal database na outra cópia do banco de dados, conhecida como “mirror database”.

Embora o processo possa parecer semelhante ao já conhecido Log Shipping, a grande diferença é que enquanto o log shipping realiza as atualizações em bloco de transações, através de um backup/restore do log de transação do database, no database mirroring as transações são atualizadas de modo instantâneo, sem necessitar de um backup/restore do log de transação do database.
 
O principal e o mirror databases devem residir em servidores ou instâncias diferentes e trabalham como parceiros em uma sessão conhecida como “database mirroring session”. O parceiro que armazena o principal database é conhecido como “principal server” e o parceiro que armazenada o mirror database é conhecido como “mirror server”.

A configuração mais simples de database mirroring envolve apenas duas instâncias do SQL Server – o principal e o mirror server. No entanto, caso você deseje configurar o database mirroring para suportar failover automático, então uma terceira instância será necessária. Essa instância é conhecida como “witness server”.

A figura abaixo mostra como ficaria uma sessão de database mirroring com dois servidores e uma sessão envolvendo também um witness server.

Modos de Operação

Uma sessão de database mirroring pode ser configurada para operar em três diferentes modos de operação: High Availability, High Protection ou High Performance.

O modo de operação deve ser selecionado de acordo com o nível de segurança desejado para as transações (transaction safety) e pode trabalhar em modo de transferência síncrono ou assíncrono.  O modo exato dependerá da configuração do transaction safety e se a sessão possuirá ou não um witness server.

A tabela abaixo resume as possíveis configurações para o modo de operação:

Modo operação	Transaction Safety	Modo Transferência	Requer Witness	Failover
High Availability	FULL	Síncrono	Sim	Automático ou Manual
High Protection	FULL	Síncrono	Não	Manual
High Performance	OFF	Assíncrono	Não	Forçado

High Availability

Como podemos observar na figura acima, o modo de operação high availability (alta disponibilidade) requer que o transaction safety seja definido como FULL. Este também é o único modo que oferece failover automático e consequentemente requer a presença de um witness server. O propósito do witness server é simplesmente monitorar o status da sessão e fornecer a capacidade de failover automático.

Em casos de indisponibilidade do principal server, ocorrerá um processo conhecido como “role switching”. Nesse momento o mirror server assume o papel de principal server e disponibilizará sua base como principal database. Quando o principal server original voltar a ficar disponível, este assumirá o papel de mirror server e seu database se tornará o novo mirror database.

O modo high availability opera no modo de transferência síncrono, isso garante que as transações sempre serão efetivadas em ambos os parceiros antes de enviar um retorno ao cliente. Quando operando em modo síncrono o principal server deverá aguardar uma resposta do mirror server dizendo que a transação foi efetivada com sucesso no mirror database e isso pode fazer com que a performance do principal server seja afetada pela capacidade do mirror server. No geral, esse modo de operação deve ser usado quando se possui um bom link de comunicação entre os parceiros.

Você deve estar se perguntando: Mas o que acontece se eu perder a comunicação entre o principal e o mirror server? Nesse caso, se o principal server estiver se comunicando normalmente com o witness server, ele continuará tratando as requisições dos clientes sem aguardar por um retorno (acknowledgement) do mirror server. Durante esse período o principal server armazenará as transações em uma fila e as enviará ao mirror server assim que o mesmo estiver disponível. O problema é que se o tempo de indisponibilidade do mirror server for muito longo, essa fila pode estourar e alguns dados podem ser perdidos.

Por outro lado, se o principal server perder a comunicação também com o witness server, ele deixará de responder os clientes. Isso porque ele não terá como confirmar se continua sendo o principal server ou não.

High Protection

O modo de operação high protection também requer que o transaction safety seja definido como FULL. Ele garante que não haverá perda de dados, mas como não exige a presença de um witness server, nos casos de indisponibilidade do principal server o failover deverá ser executado de forma manual.

Em high protection mode, se ocorrer problemas de comunicação entre o principal e mirror server, o principal server deixará de responder os clientes. Isso porque ele não terá como confirmar se continua sendo o principal server ou não.

High Performance

Esse é o mais rápido dos modos de operação, pois trabalha em modo assíncrono. Ou seja, a transação é efetivada no principal server e um retorno é dado ao cliente mesmo sem esperar por uma resposta do mirror server dizendo se a transação foi efetivada com sucesso no mirror database ou não.  Ele não requer a presença de um witness server e o único tipo de failover permitido é o "forçado".

O failover forçado faz uma recuperação imediata do mirror database podendo envolver perda de dados nos casos onde o mirror server ainda não tiver recebido o log de transação do principal server.

Em high performance mode, se ocorrer problemas de comunicação entre o principal e o mirror server, o principal server continuará tratando as requisições dos clientes e enfileirará as transações para posterior envio ao mirror server.

Pré-requisitos

Antes de iniciar a configuração do database mirroring alguns pontos importantes devem ser observados:

1. Certifique-se que os dois nós do mirror (principal e mirror server) estejam com a mesma edição do SQL Server 2005. As edições suportadas são Standard Edition ou Enterprise Edition.
2. Se o failover automático é um requisito para sua solução de mirroring, você deverá configurar uma terceira máquina ou instância do SQL Server 2005 como um witness server. O witness pode ser executado em qualquer estação que suporte o SQL Server 2005 Enterprise, Standard, Workgroup ou Express Edition.
3. Certifique-se que existe comunicação entre os servidores ou instâncias envolvidas na configuração.
4. Se os serviços do SQL Server nos diferentes servidores ou instâncias estão sendo iniciados com diferentes contas de usuários de domínio ou ainda, os servidores estão fora de um domínio, será preciso criar no database master de cada instância um login para a conta de usuário que inicia o SQL Server das outras instâncias. O ideal é que ambas as instâncias sejam iniciadas com uma mesma conta de usuário de domínio. Para mais informações, consulte o link How to: Allow Database Mirroring Network Access Using Windows Authentication (Transact-SQL) no Books Online do SQL Server 2005.
5. O principal database deve ter seu recovery model configurado como FULL.
6. O mirror database deve ser iniciado a partir de um restore do principal database com a opção WITH NORECOVERY.
7. O mirror database deve ter o mesmo nome que o principal database.
8. Certifique-se que existe logins no mirror server para todos os usuários utilizados no principal database.
9. Todas as instâncias do SQL Server 2005 (inclusive o Witness) devem estar atualizar com o Service Pack 1 ou mais recente

Nota: É importante lembrar que por default a versão RTM do SQL Server 2005 (build 9.0.1399) não oferece suporte ao database mirroring. Isso significa que embora ele possa ser habilitado através da ativação do trace flag 1400, oficialmente a Microsoft só oferece suporte a database mirroring a partir do SQL Server 2005 SP1 ou superior. A recomendação é que database mirroring não seja configurado em ambientes de produção que não possuam o SQL Server 2005 SP1 ou superior.

Configurando o Database Mirroring

Nota: Esta configuração foi executada no SQL Server 2005, mas a funcionaldade de Database Mirroring também está disponível no SQL Server 2008.

Agora que você já sabe como funciona o database mirroring, vamos ao que realmente interessa, a configuração passo-a-passo. Para este artigo estarei utilizando como exemplo a base de dados Pubs.

Em um ambiente de produção, o ideal é termos as instâncias do SQL Server 2005 instaladas em máquinas diferentes, podendo o witness server ser configurado em qualquer estação com Windows XP SP2 e SQL Server Express Edition. Se você quiser instalar a instância do witness server em um dos servidores principais, a sugestão é que este seja instalado no servidor que alocará a instância do mirror server.

Para configurar o database mirroring no SQL Server 2005, siga os passos descritos abaixo:

1. No Object Explorer, selecione o principal server, expanda databases e clique com o botão direito sobre o database que será espelhado (principal database). Selecione properties e na página Options, altere seu recovery model para Full.

Se preferir, execute o script abaixo no Query Editor do SQL Server Management Studio.

ALTER DATABASE Pubs SET RECOVERY FULL

2. Faça um backup full e um backup de log do principal database. Se preferir, execute o script abaixo no Query Editor.

Nota: O ideal é que o principal database fique bloqueado até a conclusão da configuração. Isso evitará alterações no log de transação após a realização dos backups.

--  Rodar no Principal Server
BACKUP DATABASE Pubs TO DISK='C:/Backup/Pubs_BKP.BAK' WITH INIT
GO
BACKUP LOG Pubs TO DISK='C:/Backup/Pubs_TRL.BAK' WITH INIT

Nota: Durante todo este artigo estarei utilizando a barra (/) para a separação do diretório.

3. Copie os backups para o mirror server e restaure o backup full no mirror server utilizando a opção WITH NORECOVERY.

--Rodar no Mirror Server
RESTORE DATABASE Pubs  FROM DISK='C:/Backup/Pubs_BKP.BAK' WITH NORECOVERY

A recomendação é que quando possível o caminho no mirror server seja idêntico ao caminho do principal server (incluindo o nome das letras dos discos). Se o caminho for diferente, use a opção MOVE durante o restore informando o caminho onde os arquivos de dados e log deverão ser armazenados.

--Rodar no Mirror Server
RESTORE DATABASE Pubs FROM DISK='C:/Backup/Pubs_BKP.BAK' WITH REPLACE,NORECOVERY,
MOVE 'Pubs_Data' TO 'G:/Dados/Pubs_Data.mdf',
MOVE 'Pubs_Log' TO 'G:/Dados/Pubs_Log.ldf'

Feito isso, o mirror database ficará em status de “Restoring”, indicando que o database está pronto para receber as transações do principal database.

4. No principal server, expanda Databases e selecione o principal database. Clique com o botão direito do mouse sobre o mesmo e seleciona All TasksMirror....

5. Clique sobre o botão Configure Security....
6. Na janela Configure Database Mirroring Security Wizard, informe se você quer configurar a segurança de forma a incluir um witness server e clique em Next.

Nota: Lembre-se que para utilizar failover automático a configuração de um witness server é obrigatória.

7. Na janela Choose Server to Configure, selecione os servidores onde as configurações de segurança deverão ser salvas. Se estiver utilizando um witness server, marque as três opções e clique em Next.
8. Na janela Principal Server Instance, especifique as informações para o endpoint do principal server. Um endpoint é um objeto SQL Server que permite ao SQL Server se comunicar através da rede. Quando configurando database mirroring, uma instância requer seu próprio e dedicado database mirroring endpoint. Ele é usado exclusivamente para receber comunicação de database mirroring dos demais parceiros que compõem o mirror (o mirror e witness server).

Nota: Se o principal, mirror e witness servers são instâncias SQL Server em um mesmo servidor físico, os endpoints para cada uma das instâncias devem utilizar número de portas diferentes (exemplo 5022, 5023 e 5024). Se estiver utilizando diferentes servidores para cada uma das instâncias, a recomendação é utilizar a porta default 5022.

Especifique também se os dados enviados através do endpoint deverão ou não ser criptografados.

9. Na janela Mirror Server Instance, selecione o servidor que será o mirror server. Ao selecionar o servidor será apresentada a janela Connect to Server, a qual permite configurar uma conexão com o servidor. Se o mirror server e o principal server estiverem no mesmo domínio do Windows, a recomendação é que se utilize Windows Authentication, se estiverem em domínios diferentes, utilize SQL Authentication e entre com um login e senha do SQL Server (Por exemplo o login sa).

10. Na janela Witness Server Instance, selecione o servidor que será o witness server. Esta configuração somente será necessária se optar por configurar o failover automático.

11. Ao clicar em Finish será apresentado um sumário das configurações.
12. Clique em Finish para concluir o processo de configuração.
13. A janela Configuring Endpoint apresenta o status final da configuração. Se nenhum problema tiver ocorrido, você deverá ter o status de sucesso para a configuração dos endpoints das três instâncias. Clique em close.
14. Ao clicar em Close, a mensagem abaixo será apresentada indicando que o database mirroring foi configurado com sucesso.

15. Dê volta à janela principal temos algo como a janela abaixo. Clique em Start Mirroring para iniciar a sessão de database mirroring.

Nota: Antes de clicar em Start Mirroring a recomendação é executar um backup de transação do principal database e restaurá-lo no mirror database para sincronizar os dados do log. Caso ao clicar em Start Mirroring seja apresentada a mensagem de erro 1478, restaure o backup de transação realizado no passo 3.

Configurando o Database Mirroring via Transact-SQL

Para aqueles que preferem utilizar a linguagem Transact-SQL, também é possível configurar o database mirroring utilizando T-SQL.

Após certificar-se de que todos os requisitos foram satisfeitos, incluindo a ativação do trace flag 1400 para a versão do SQL Server 2005 sem o SP1 (build 9.0.1399), siga os passos abaixo para configurar o database mirroring via T-SQL.

1. Na guia Registered Servers do SQL Server Management Studio, clique com o botão direito sobre o principal server (servidor que possui o database a ser espelhado) e selecione Connect|New Query. Altere o recovery model do principal database para FULL.

--  Rodar no Principal Server
ALTER DATABASE Pubs SET RECOVERY FULL

2. Faça um backup Full e um backup de log do principal database.

--  Rodar no Principal Server
BACKUP DATABASE Pubs TO DISK='C:/Backup/Pubs_BKP.BAK' WITH INIT
GO
BACKUP LOG Pubs TO DISK='C:/Backup/Pubs_TRL.BAK' WITH INIT

3. Copie os backups para o mirror server e restaure o backup full no mirror server utilizando a opção WITH NORECOVERY.

--Rodar no Mirror Server
RESTORE DATABASE Pubs FROM DISK='C:/Backup/Pubs_BKP.BAK' WITH REPLACE,NORECOVERY

Se o caminho (incluindo o nome das letras dos discos) no mirror server for diferente do caminho do principal server, utilize a opção MOVE durante o restore.
 
--Rodar no Mirror Server
RESTORE DATABASE Pubs FROM DISK='C:/Backup/Pubs_BKP.BAK' WITH REPLACE,NORECOVERY,
MOVE 'Pubs_Data' TO 'G:/Dados/Pubs_Data.mdf',
MOVE 'Pubs_Log' TO 'G:/Dados/Pubs_Log.ldf'

4. Crie os endpoints no principal server, mirror server e witness server. Lembrando que a criação de um endpoint no witness server somente é necessária se pretende configurar o database mirroring como High Availability.

--  Rodar no Principal Server
IF EXISTS (SELECT name FROM sys.database_mirroring_endpoints WHERE name='endpoint_mirroring')
  DROP ENDPOINT endpoint_mirroring
GO
CREATE ENDPOINT endpoint_mirroring
    STATE = STARTED
    AS TCP ( LISTENER_PORT = 5022 )
    FOR DATABASE_MIRRORING (ROLE=PARTNER);
GO

--Rodar no Mirror Server
IF EXISTS (SELECT name FROM sys.database_mirroring_endpoints WHERE name='endpoint_mirroring')
  DROP ENDPOINT endpoint_mirroring
GO
CREATE ENDPOINT endpoint_mirroring
    STATE = STARTED
    AS TCP ( LISTENER_PORT = 5022 )
    FOR DATABASE_MIRRORING (ROLE=PARTNER);
GO

--Rodar no Witness Server
IF EXISTS (SELECT name FROM sys.database_mirroring_endpoints WHERE name='endpoint_mirroring')
  DROP ENDPOINT endpoint_mirroring
GO
CREATE ENDPOINT endpoint_mirroring
    STATE = STARTED
    AS TCP ( LISTENER_PORT = 5022 )
    FOR DATABASE_MIRRORING (ROLE=WITNESS);
GO

Depois de preparado o mirror database e criado os endpoints em cada um dos servidores ou instâncias do SQL Server 2005, podemos então iniciar a criação de uma sessão de database morroring.

Para iniciar uma sessão de database mirroring, siga os passos descritos abaixo:

1. Certifique-se de que os endpoints foram criados e iniciados com sucesso em cada um dos servidores ou instâncias. Para isso, utilize o seguinte T-SQL script.

SELECT role_desc, state_desc FROM sys.database_mirroring_endpoints

2. Restaure o backup de log do principal database sobre o mirror database. Esse procedimento é necessário para sincronizar o log de transação do principal database com o do mirror database.

-- Rodar no Mirror Server
RESTORE LOG Pubs FROM
DISK='C:/Backup/Pubs_TRL.BAK' WITH NORECOVERY

3. Configure o principal server como um parceiro do mirror server. Conecte-se ao query editor no mirror server e execute:

-- Rodar no Mirror Server
USE master
GO
ALTER DATABASE Pubs
SET PARTNER = 'TCP://SERVER01.contoso.com:5022'

Neste exemplo, SERVER01 é o nome físico do meu principal server e contoso.com é o nome do meu domínio. Se preferir você pode usar também o endereço IP do servidor.

4. Configure o mirror server como um parceiro do principal server, para isso, conecte-se ao query editor no principal server e execute:

-- Rodar no Principal Server
USE master
GO
ALTER DATABASE Pubs
SET PARTNER = 'TCP://SERVER02.contoso.com:5022'

5. Opcionalmente, se configurar um witness server para a sessão de database mirroring, conecte-se ao query editor no principal server e execute o script abaixo:

--- Rodar no Principal Server
Use master
GO
ALTER DATABASE Pubs
SET WITNESS = 'TCP://VPC.contoso.com:5022'

Testando a Funcionalidade do Database Mirroring

Concluída a configuração e inicialização da sessão de database mirroring, se tudo deu certo o database mirroring já deve estar funcionando. A figura abaixo mostra o status do principal e mirror database após a configuração.

Experimente fazer algumas alterações em seu principal database (por exemplo, criando uma tabela e inserindo registros sobre a mesma) e depois verifique se estas foram espelhadas no mirror database. No entanto, lembre-se que o mirror database não fica disponível para leitura.

Para utilizar o mirror database é preciso executar 2 passos:

1. Quebrar o mirroring

Para quebrar o mirroring, podemos utilizar a janela de propriedades do principal database e na página Mirroring clicar sobre o botão Stop Mirroring, ou ainda executar o script abaixo no query editor de um dos partners da sessão:

--Executar no Principal ou Mirror Server
--Para desfazer o Mirror
ALTER DATABASE Pubs SET PARTNER OFF

Caso tenha configurado o mirroring para suportar alta disponibilidade, basta clicar sobre o botão Failover, na janela de propriedades do principal database e o failover será realizado automaticamente.

2. Remover o status de Restoring do mirror database

Após quebrar o mirroring, o mirror database se manterá no status de Restoring. Para utilizá-lo é preciso antes deixá-lo em seu status normal para utilização realizando o recovering do database. Para fazer o recovering do mirror database, execute o script abaixo no query editor do mirror server.

-- Rodar no Mirror Server
RESTORE DATABASE Pubs WITH RECOVERY

Pronto, com isso o mirror database estará disponível para utilização e deverá conter as alterações realizadas no principal database.

Erros mais Comuns

Dois erros muito comuns durante a configuração de uma sessão de database mirroring são os erros 1418 e 1478.

Msg 1418, Level 16, State 1, Line 1
The server network address "TCP://SERVER02.conto.com:5022" can not be reached or does not exist. Check the network address name and reissue the command.

Msg 1478, Level 16, State 0, Line 1
The mirror database, "Pubs", has insufficient transaction log data to preserve the log backup chain of the principal database.  This may happen if a log backup from the principal database has not been taken or has not been restored on the mirror database.

Ambos os erros costumam ocorrer no mesmo ponto: no momento da configuração dos Partners da sessão (passos 3, 4 ou 5 quando configurando via script, ou ao clicar sobre o botão Start Mirroring quando configurando via tela gráfica).

O erro 1418 indica problemas de conectividade entre os nós, normalmente problemas de resolução dos nomes das máquinas. Para corrigí-lo, certifique-se de que os nomes das máquinas estão corretos ou então tente configurar os partners utilizando o endereço IP.

ALTER DATABASE Pubs
SET PARTNER = 'TCP://192.168.0.12:5022'

Nota: Lembre-se também de informar o mesmo número de porta utilizado na criação do endpoint do respectivo partner.

O erro 1478 indica uma falta de sincronismo entre o log de transação do principal e o mirror database. Para corrigi-lo, efetue um backup de transação no principal database e restaure-o no mirror database utilizando a opção WITH NORECOVERY.

RESTORE LOG Pubs FROM
DISK='C:/Backup/Pubs_TRL.BAK' WITH NORECOVERY

Após a restauração do bakup de transação, reinicie a configuração dos Partners em ambos os servidores da sessão.

Bom pessoal, é isso aí. Qualquer dúvida ou problema na configura do database mirroring, post uma mensagem em nosso fórum.

Caso desejem saber mais sobre database mirroring, incluindo a parte conceitual sobre seu funcionamento, uma excelente fonte de documentação é o Whitepaper Database Mirroring in SQL Server 2005 (http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx) ou ainda o próprio Books Online do SQL Server 2005.

Dois Webcasts também muito interessantes sobre database mirroring são: Implementing Database Mirroring in SQL Server 2005 (Part 1 of 2) e Implementing Database Mirroring in SQL Server 2005 (Part 2 of 2)

Um abraço a todos
Nilton Pinheiro

Nilton,

 Excelente artigo, sanou todas as duvidas.
 Parabéns e obrigado.

Wendel Meireles