Database Mirroring

Aprenda a configurar o mais novo recurso de

alta disponibilidade do SQL Server 2005

atabase Mirroring com certeza uma das

mais esperadas e teis features disponveis
no SQL Server 2005. Oficialmente disponvel a partir do SQL Server 2005 Service Pack
1 (SP1), o database mirroring uma soluo
de software que permite aumentar a disponibilidade de um
banco de dados. Na prtica, ele permite que voc tenha uma
cpia idntica do seu banco de dados de produo em um outro servidor. Neste artigo estaremos descrevendo os requisitos
necessrios e o passo-a-passo completo de como configurar
o database mirroring para aumentar a disponibilidade de um
banco de dados no SQL Server 2005.

Database Mirroring x Failover Clustering

NILTON PINHEIRO
(niltonpinheiro@msn.com)
formado em Anlise de Sistemas
e
ps-graduado
em
Redes
Corporativas. Possui 7 anos de
experincia com SQL Server, dos
quais a 5 trabalha como DBA
em uma conceituada instituio
financeira em So Paulo. Como um Beta Tester
Microsoft, participou ativamente da fase Beta do SQL
Server 2005 e trabalha com o SQL Server 2005 desde
seu Beta1. Possui as certificaes MCDBA e MCSE,
MVP (Microsoft Most Valuable Professionals) em SQL
Server e fundador do site www.mcdbabrasil.com.br.

Ao contrrio do failover clustering (veja revista SQL Magazine

edio 25 e Nota 1), o qual fornece soluo de alta disponibilidade para servidores de banco de dados de grandes ambientes,
o database mirroring foi desenvolvido tendo em mente fornecer
soluo de alta disponibilidade para bancos de dados de pequenas
e mdias empresas. Sua grande vantagem est no fato de no exigir discos ou servidores especializados, podendo ser configurado
em qualquer servidor padro de mercado, o que torna a soluo
barata e acessvel a qualquer empresa de pequeno e mdio porte.
Nota 1. Failover Clustering
O failover cluster uma soluo de alta disponibilidade que
fornece funcionalidade de failover automtico no apenas
para um banco de dados, mas para o servidor inteiro. O
failover clustering configurado com dois ou mais servidores
trabalhando como parceiros e o failover automtico garante que
na falha de um dos parceiros, o outro assumir seus recursos
garantindo assim a disponibilidade dos recursos ou sistema.
Por exigir hardwares certificados e storage de discos externo,
uma soluo cara e por isso implementada apenas por grandes
empresas ou ambientes.

8 SQL Magazine - Database Mirroring

SQL38.indb 8

11.12.06 14:12:33

S QL S ERV ER 2005

A diferena mais importante entre database mirroring e failover clustering est no nvel de proteo oferecido pelas duas
tecnologias. Enquanto o database mirroring oferece proteo
no nvel de banco de dados, o failover clustering oferece proteo no nvel de servidor. Por outro lado, no database mirroring, o servidor principal e o servidor espelho (servidor que
mantm uma cpia do banco de dados configurado para o
mirroring) so servidores ou instncias SQL Server separadas
e com nomes distintos, enquanto que no failover clustering a
instncia do SQL Server recebe um nome e endereo IP virtual
que se mantm o mesmo, independente do servidor ou n que
hospeda a instncia.
Dada essa distino, se o objetivo manter a disponibilidade
banco a banco, o database mirroring a escolha mais adequada. Por outro lado, se o objetivo manter a disponibilidade
de todo o servidor, o failover clustering a opo ideal. Uma
comparao entre as principais features do failover clustering e
database mirroring pode ser vista na Tabela 1.

sejam aplicadas no banco de dados de um outro servidor. Embora o processo possa parecer semelhante, a grande diferena
que enquanto o log shipping realiza as atualizaes em bloco
de transaes, atravs de um backup/restore do log de transao do banco de dados, no database mirroring as transaes
so atualizadas de modo instantneo, sem necessitar de um backup/restore do log de transao do banco de dados.
Utilizado por muitas empresas como uma soluo de alta
disponibilidade, no log shipping, se o servidor principal falhar,
um backup de log do banco de dados dever ser executado e
recuperado no banco de dados do outro servidor, conhecido
como standby server. Este processo manual, o que pode gerar uma indisponibilidade de vrios minutos. Com o database
mirroring, uma vez que as transaes so aplicadas no outro
servidor de forma instantnea, se o servidor principal falhar,
nenhum backup de log precisar ser executado, garantindo
uma disponibilidade quase que imediata.
Uma comparao entre as principais features do log shipping
e database mirroring pode ser vista na Tabela 2.

Database Mirroring x Log Shipping

Como funciona o database mirroring

O database mirroring tambm est bem prximo do log shipping (ver Nota 2), uma vez que ambos utilizam um processo
de transferncia de log de transao para garantir que as transaes efetuadas no banco de dados de um servidor principal
Feature disponvel

O database mirroring envolve duas cpias de um mesmo banco de dados que reside em diferentes servidores ou instncias do
SQL Server 2005. Um ponto importante a ser observado que

Database Mirroring

Failover Clustering

Deteco de falha

Sim

Sim

Failover automtico

Sim

Sim

Redirecionamento Transparente dos clientes

Sim, automtico

Sim, reconecta para o mesmo IP.

Perda de trabalho zero

Sim

Sim

Percepo do downtime

Menos que 3 segundos

30 segundos + tempo de recovery do database

Necessita de hardware Especial

No

Sim, servidores e storage devem ser certificados

para cluster.

Limite de distncia entre os ns

Ilimitado

160 quilmetros

Complexidade de configurao

Baixa

Alta

Acesso ao servidor standby

Possvel, mas com impacto na performance No possvel

Nvel de proteo

Banco de dados

Servidor

Tabela 1. Comparativo entre Failover Clustering e Database Mirroring.

Feature disponvel

Database Mirroring

Log Shipping

Deteco de falha

Sim

Sim

Failover automtico

Sim

No

Redirecionamento Transparente dos clientes

Sim, automtico

No

Perda de trabalho zero

Sim

No

Percepo do downtime

Menos que 3 segundos

Minutos

Necessita de hardware especial

No

No

Limite de distncia entre os ns

Ilimitado

Ilimitado

Complexidade de configurao

Baixa

Baixa

Acesso ao servidor standby

Possvel, mas com impacto na performance

No possvel

Nvel de proteo

Banco de dados

Banco de dados

Tabela 2. Comparativo entre Log Shipping e Database Mirroring.

Edio 38 - SQL Magazine

SQL38.indb 9

11.12.06 14:12:34

durante a sesso de database mirroring, apenas uma cpia do

banco de dados ficar disponvel para as aplicaes, esta cpia
conhecida como principal database. Na prtica, o processo envolve aplicar os registros do log de transao para cada transao
(INSERT, UPDATE, DELETE) realizada no principal database na
outra cpia do banco de dados, conhecida como mirror database.

O principal e o mirror database devem residir em diferentes servidores ou instncias, e trabalham como parceiros em uma sesso 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 configurao mais simples de database mirroring envolve apenas duas instncias do SQL Server o principal
e o mirror server. No entanto, caso voc deseje configurar
o database mirroring para suportar failover automtico,
ento uma terceira instncia ser necessria. Essa instncia conhecida como witness server. O witness server
responsvel por monitorar o principal server e o mirror
server, e fornecer o failover automtico nos casos de problemas com principal database.
A Figura 1 apresenta como ficaria uma sesso de database mirroring com dois servidores e um witness server.
Na Figura 1 podemos destacar:
Principal Database: como o prprio nome diz, este o
banco de dados principal. O banco de dados que est configurado para database mirroring.
Mirror Database: este banco de dados a cpia do principal database. O banco de dados espelho.
Principal Server: o principal server o servidor que armazena o principal database. ele quem aceita as conexes dos
clientes e permite atualizaes para o principal database.

Mirror Server: o mirror server o servidor standby ou servidor espelho. ele quem armazena a cpia do principal database. Os clientes no podem acess-lo diretamente.
Witness Server: o propsito do witness server monitorar
o principal e o mirror server para garantir que em um dado
momento apenas um dos servidores seja o principal server, e
fornecer o suporte ao failover automtico nos casos de problemas com o principal server ou principal database. O failover
automtico o recurso que permitir que se o principal server
cair por qualquer motivo, o mirror server assumir o trabalho
executado pelo principal server, deixando de ser o mirror server e assumindo o novo papel de principal server. Se voc no
pretender utilizar o recurso de failover automtico, o witness
server no necessrio.
Apesar das documentaes relacionadas ao database mirroring utilizarem a nomenclatura acima, para facilitar o entendimento pelo leitor, a partir deste ponto estarei me referindo
ao principal server com servidor principal e ao mirror server
como servidor espelho. Da mesma forma, estarei me referindo
ao principal database como DB principal e ao mirror database
como DB espelho.

Modos de operao
Uma sesso de database mirroring pode ser configurada para
operar em trs diferentes modos de operao: High Availability, High Protection ou High Performance. Ao longo desta seo
iremos conhecer um pouco sobre cada modo de operao.
O modo de operao deve ser selecionado de acordo com o nvel de segurana desejado para as transaes (transaction safety) e
pode trabalhar em modo de transferncia sncrono ou assncrono.
O modo exato depender da configurao do transaction safety e
se a sesso possuir ou no um witness server. A Tabela 3 resume
as possveis configuraes para o modo de operao.

Nota 2. Log Shipping

O Log Shipping um recurso disponvel no SQL Server que
atravs de um processo automtico envia o log de transao
do banco de dados de um servidor principal para um outro
servidor. Backups de log so executados periodicamente no
banco de dados do servidor principal e copiados para o outro
servidor onde so restaurados sequencialmente, mantendo a
sincronizao entre o banco de dados de destino e origem a
mais prxima possvel.

Figura 1. Sesso de Database Mirroring.

Modo operao

Transaction Safety

Modo Transferncia

Requer Witness

Failover

High Availability

Full

Sncrono

Sim

Automtico ou Manual

High Protection

Full

Sncrono

No

Manual

High Performance

Off

Assncrono

No

Forado

Tabela 3. Configuraes para o modo de operao de uma sesso de database mirroring.

10 SQL Magazine - Database Mirroring

SQL38.indb 10

11.12.06 14:12:35

S QL S ERV ER 2005

High Availability
Como podemos observar na Tabela 3, o modo de operao
high availability (alta disponibilidade) requer que o transaction
safety seja definido como FULL. Este tambm o nico modo
que oferece failover automtico e conseqentemente requer a
presena de um witness server.

Em casos de indisponibilidade do servidor principal,

ocorrer um processo conhecido como role switching.
Neste momento, o servidor espelho assume o papel de servidor principal e disponibilizar seu banco de dados como
sendo o novo DB principal. Quando o servidor principal
original voltar a ficar disponvel, este assumir o papel de
servidor espelho e seu banco de dados se tornar o novo
DB espelho.
O modo high availability opera no modo de transferncia sncrono. Isso garante que as transaes sempre
sero efetivadas em ambos os parceiros antes de enviar
um retorno ao cliente. Quando operando em modo sncrono, o servidor principal dever aguardar uma resposta
do servidor espelho dizendo que a transao foi efetivada
com sucesso no DB espelho, e isso pode fazer com que a
performance do servidor principal seja afetada pela capacidade do servidor espelho. No geral, esse modo de ope-

rao deve ser usado quando se possui um bom link de

comunicao entre os parceiros.
Voc deve estar se perguntando: mas o que acontece
se eu perder a comunicao entre o servidor principal e o
servidor espelho? Nesse caso, se o servidor principal estiver se comunicando normalmente com o witness server,
ele continuar tratando as requisies dos clientes sem
aguardar por um retorno (acknowledgement) do servidor espelho. Durante esse perodo, o servidor principal
armazenar as transaes em uma fila e as enviar ao
servidor espelho assim que o mesmo estiver disponvel.
O problema que se o tempo de indisponibilidade do
servidor espelho for muito longo, essa fila pode estourar e
alguns dados podem ser perdidos.
Por outro lado, se o servidor principal perder a comunicao tambm com o witness server, ele deixar de responder os clientes. Isso porque ele no ter como confirmar se continua sendo o servidor principal ou no.

High Protection
O modo de operao high protection tambm requer que o
transaction safety seja definido como FULL. Ele garante que
no haver perda de dados, mas como no exige a presena de

Edio 38 - SQL Magazine

SQL38.indb 11

11
11.12.06 14:12:36

um witness server, nos casos de indisponibilidade do servidor

principal, o failover dever ser executado de forma manual.
No modo high protection, se ocorrer problemas de comunicao entre o servidor principal e o servidor espelho, o servidor principal deixar de responder aos clientes. Isso porque ele no ter
como confirmar se continua sendo o servidor principal ou no.

High Performance
Este o mais rpido dos modos de operao, pois trabalha
em modo assncrono. Ou seja, a transao efetivada no servidor principal e um retorno dado ao cliente mesmo sem esperar por uma resposta do servidor espelho informando se a
transao foi efetivada com sucesso no DB espelho ou no. Ele
no requer a presena de um witness server e o nico tipo de
failover permitido o forado. O failover forado requer a
execuo manual do comando:
ALTER DATABASE <banco> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

O failover forado faz uma recuperao imediata do

DB espelho podendo envolver perda de dados nos casos
onde o servidor espelho ainda no tiver recebido o log
de transao do servidor principal.
No modo high performance, se ocorrer problemas de comunicao entre o servidor principal e o
servidor espelho, o servidor principal continuar
tratando as requisies dos clientes e enfileirar
as transaes para posterior envio ao servidor
espelho.

Requisitos necessrios
Antes de iniciar a configurao do database mirroring, alguns pontos importantes devem ser observados:
1. Certifique-se que o servidor principal e o servidor espelho estejam com
a mesma edio do SQL Server
2005. As edies suportadas para
database mirroring so as edies
Standard ou Enterprise Edition;
2. As instncias do SQL Server 2005 devem estar com
o Service Pack 1 (SP1) ou
superior;
3. Se o failover automtico um requisito necessrio para sua soluo de
mirroring, voc dever
configurar uma terceira mquina ou instncia do SQL Server 2005
SP1 como um witness
server. O witness pode
ser configurado em
qualquer estao de trabalho com Windows XP

SP2 e as edies Enterprise, Standard, Workgroup ou Express

Edition do SQL Server 2005;
4. Certifique-se que existe comunicao entre os servidores
ou instncias envolvidas na configurao;
5. Se os servios do SQL Server nos diferentes servidores
ou instncias esto sendo iniciados com diferentes contas de
usurios de domnio, ou esto fora de um domnio, ser necessrio criar no banco de dados master de cada instncia um login para a conta de usurio que inicia o servio do SQL Server
das outras instncias. O ideal que ambas as instncias sejam
iniciadas com uma mesma conta de usurio de domnio. Para
mais informaes, consulte o link How to: Allow Database
Mirroring Network Access Using Windows Authentication
(Transact-SQL), no Books Online do SQL Server 2005;
6. O DB principal deve estar com a propriedade recovery
model configurada como FULL. Isso porque os registros de
log resultantes do modelo simple ou bulk-logged no podem
ser enviados para o DB espelho;
7. O DB espelho deve ser iniciado a partir de um restore do
DB principal com a opo WITH NORECOVERY;
8. O DB espelho deve ter o mesmo nome que o DB principal;
9. Certifique-se da existncia de logins no servidor espelho
para todos os usurios utilizados no DB principal;
10. No possvel configurar o database mirroring em bancos de dados de sistemas (master, model, msdb e tempdb).

Configurando o database mirroring

Agora que voc j sabe como funciona o database mirroring,
vamos ver passo-a-passo como configur-lo. Para este artigo,
estarei utilizando como DB principal o banco de dados AdventureWorks do prprio SQL Server 2005. Como o objetivo
configurar o database mirroring com o modo de operao
de alta disponibilidade (High Avaliability), tambm estou utilizando trs instncias do SQL Server 2005 SP1 configuradas
da seguinte forma:
SERVER01: servidor com Windows Server 2003 SP1 e
instncia nomeada do SQL Server 2005 SP1 respondendo pelo
nome de Princ. Este ser o Servidor principal.
SERVER02: servidor com Windows Server 2003 SP1 e
instncia nomeada do SQL Server 2005 SP1 respondendo pelo
nome de Mirror. Este ser o Servidor espelho.
VPC: mquina virtual com Windows XP Professional
SP2 e instncia nomeada do SQL Server 2005 Express Edition SP1 respondendo pelo nome de SQLEXPRESS. Este
ser o Witness Server.
Embora para um ambiente de laboratrio seja possvel instalar as trs instncias de SQL Server em uma mesma mquina,
para um ambiente de produo o recomendado estar com as
instncias do SQL Server 2005 instaladas em mquinas diferentes. Se voc precisar instalar a instncia do witness server em
um dos servidores principais, a recomendao que este seja instalado no servidor que alocar a instncia do servidor espelho.
Para configurar o database mirroring no SQL Server 2005,
siga os passos descritos abaixo.

12 SQL Magazine - Database Mirroring

SQL38.indb 12

11.12.06 14:12:37

S QL S ERV ER 2005

Passo 1

O primeiro passo na configurao do database mirroring

garantir que o banco de dados a ser espelhado (o DB principal)
est com a opo Recovery model definida como FULL. Para
isso, na ferramenta SQL Server Management Studio, em Object
Explorer (Menu View Object Explorer), selecione o servidor principal, expanda Databases e clique com o boto direito
do mouse sobre o banco de dados AdvantureWorks. Selecione
Properties e na pgina Options, altere a opo Recovery model para Full. Um exemplo pode ser visto na Figura 2.
Passo 2

Faa um backup full e em seguida um backup de log do DB

principal. Para fazer os backups, clique com o boto direito do
mouse sobre o banco de dados AdventureWorks e selecione a
opo Tasks > Back Up....

Na janela de backup, em Source, certifique-se de que a

opo Backup type esteja definida como Full. ela quem
nos garante que o backup que estamos executando realmente um backup Full, ou seja, um backup completo
incluindo estrutura e dados. Em Destination, clique sobre
o boto Remove para remover o caminho default. Em seguida clique sobre o boto Add... e informe o caminho
C:\AdventureWorks_BKP.BAK. Com isso estamos informando ao SQL Server para fazer um Backup Full do
banco de dados AdventureWorks no arquivo AdventureWorks_BKP.BAK que ser armazenado no disco C:\.
Clique sobre o boto OK para realizar o backup full. Um
exemplo pode ser visto na Figura 3.
Aps a concluso do Backup Full, volte na janela de backup do banco de dados AdventureWorks. Em Source, na
opo Backup type selecione agora a opo Transaction
Log e clique em OK para realizar o backup de transao.
Observe que executei o backup Full e o backup de

Figura 2. Definindo o Recovery model como Full.

transao em um mesmo arquivo. Isso alm de facilitar a

cpia do arquivo para o servidor espelho, facilitar tambm o processo de restore uma vez que teremos
ambos os backups em um mesmo arquivo.
Passo 3

Aps realizar os backups do DB principal, copie o arquivo AdventureWorks_

BKP.BAK para o disco C:\ do servidor
espelho e restaure o backup full no
servidor espelho utilizando a opo
WITH NORECOVERY. Para restaurar
o backup Full, no servidor espelho:
Clique com o boto direito sobre Databases e selecione Restore
Database....
Na janela de restore, em Destination
for restore, no campo To database informe
o nome para o banco de dados. Lembre-se que
um dos requisitos do database mirroring que o
DB espelho deve ter o mesmo nome que o DB principal.
Para o nosso exemplo, defina o nome do DB espelho como
AdventureWorks.
Em Source for restore, selecione From device e clique
sobre o boto para informar o caminho do arquivo de backup.
Na janela Specify Backup, clique sobre o boto Add...
e localize no disco C:\ o arquivo AdventureWorks_BKP.BAK.
Clique em Ok e novamente em OK.

Na janela Restore Database, em Select the backup

set to restore, selecione as opes para o backup full e
de log conforme a Figura 4. Isso nos permite restaura o
backup full e de transao em um nico passo.
Ainda na janela Restore Database, selecione a pgina Options e em Recovery state selecione a segunda opo (RES-

Figura 3. Configurando o backup como FULL.

Edio 38 - SQL Magazine

SQL38.indb 13

13
11.12.06 14:12:38

TORE WITH NORECOVEY). Aqui vale uma observao: a

recomendao que quando possvel, o caminho para os arquivos de dados e log (incluindo o nome das letras dos discos) no servidor espelho seja idntico ao caminho do servidor
principal. Caso deseje armazenar os arquivos de dados e log
do DB espelho em uma localizao diferente, em Restore the
database file as, altere o caminho para a coluna Restore as. A
Figura 5 mostra como ficou nossa configurao para o banco
de dados AdventureWorks.
Clique em OK e aguarde at a concluso do processo de
restore.

es do DB principal. A Figura 6 mostra como fica o status do

DB espelho aps a concluso do processo de restore.
Passo 4

No servidor principal, expanda Databases e selecione

o DB principal (AdventureWorks). Clique com o boto
direito do mouse sobre o mesmo e seleciona All Tasks
> Mirror.... Voc ver a janela de propriedades, como a
apresentada na Figura 7.
Passo 5

Clique sobre o boto Configure Security... (ver Figura 7).

Feito isso, o DB espelho ficar em status de Restoring, indicando que o banco de dados est pronto para receber as transa-

Passo 6

Na janela Configure Database Mirroring Security Wizard, clique em Next, informe se voc quer configurar a
segurana de forma a incluir um witness server e clique
em Next. Lembre-se que para utilizar o failover automtico, a configurao de um witness server obrigatria.
Para nosso exemplo selecione Yes.
Passo 7

Na janela Choose Server to Configure, selecione os

servidores onde as configuraes de segurana devero
ser salvas. Se estiver utilizando um witness server, marque as opes como as da Figura 8 e clique em Next.
Passo 8

Figura 4. Selecionando os backups a serem restaurados.

Figura 5. Alterando a locallizao para os arquivos de dados e log.

Na janela Principal Server Instance, especifique as informaes para o endpoint do servidor principal, como o exemplo
apresentado na Figura 9 e clique em Next.
Um endpoint um objeto SQL Server que permite ao SQL
Server se comunicar atravs da rede. Quando configurando o
database mirroring, uma instncia requer seu prprio e dedicado
database mirroring endpoint. Ele usado exclusivamente para receber comunicao de database mirroring dos demais parceiros

Figura 6. Status do DB espelho aps a concluso do restore.

14 SQL Magazine - Database Mirroring

SQL38.indb 14

11.12.06 14:12:39

S QL S ERV ER 2005

que compem o mirror (o servidor espelho e o witness server).

Se o servidor principal, o espelho e o witness so instncias SQL Server em um mesmo servidor fsico, os endpoints para cada uma das instncias devem utilizar nmero de portas diferentes (exemplo 5022, 5023 e 5024). Se
estiver utilizando diferentes servidores para cada uma das
instncias, a recomendao utilizar a porta default 5022.
Especifique tambm se os dados enviados atravs do endpoint devero ou no ser criptografados (ver Figura 9).
Passo 9

Passo 11

Na janela Service Accounts, informe as contas de usurios que iniciam o servio do SQL Server nas respectivas
instncias. Caso voc utilize a mesma conta de usurio de
domnio para iniciar o servio em ambas as mquinas,
simplesmente clique em Next para prosseguir.
Passo 12

Ao clicar em Finish, ser apresentado um sumrio das

configuraes. Clique em Finish para concluir o processo
de configurao.

Na janela Mirror Server Instance, selecione o servidor que ser o servidor espelho clicando sobre o boto
Connect. Ao selecionar o servidor, ser apresentada a janela Connect to Server, a qual permite configurar uma
conexo com o servidor. Se o servidor espelho e o servidor
principal estiverem no mesmo domnio do Windows, a
recomendao que se utilize a opo Windows Authentication. Se estiverem em domnios diferentes, utilize
SQL Authentication e entre com o login e senha de um
usurio que seja administrador do SQL Server. A Figura
10 apresenta a janela de configurao do endpoint para o
servidor espelho.
Passo 10

Na janela Witness Server Instance, selecione o servidor que ser o witness server clicando sobre o boto
Connect. Esta configurao somente ser necessria se
optarmos por configurar o failover automtico. A Figura
11 apresenta a janela de configurao do endpoint para
o witness server.

Figura 8. Selecionado os servidores para configurao.

Figura 7. Pgina de configurao do database mirroring.

Figura 9. Configurao do endpoint para o servidor principal.

Edio 38 - SQL Magazine

SQL38.indb 15

15
11.12.06 14:12:40

Figura 10. Configurao do endpoint para o servidor espelho.

Figura 11. Configurao do endpoint para o witness server.

Passo 13

A janela Configuring Endpoints mostra o status final da

configurao. Se nenhum problema tiver ocorrido, voc dever
ter o status de sucesso para a configurao dos endpoints das
trs instncias. Em seguida clique em close.
Ao clicar em Close, ser apresentada uma mensagem indicando que o database mirroring foi configurado com sucesso.
Clique em OK.
Passo 14

Da volta janela principal, temos uma tela semelhante Figura 12. Clique em Start Mirroring para iniciar a sesso de
database mirroring (ler Nota 1).

Testando a funcionalidade do database mirroring

Concluda a configurao e inicializao da sesso de database mirroring, se tudo deu certo o database mirroring j deve
estar funcionando. A Figura 13 mostra o status do DB principal e DB espelho aps a inicializao da sesso.
Experimente fazer algumas alteraes em seu DB principal
(por exemplo, criando uma tabela e inserindo registros sobre
a mesma) e depois verifique se estas foram espelhadas no DB

Figura 12. Janela principal do database mirroring.

Nota 1. Start Mirroring

Antes de clicar em Start Mirroring a recomendao executar
um backup de transao do DB principal e restaur-lo no DB
espelho para sincronizar os dados do log. Caso ao clicar em
Start Mirroring seja apresentada a mensagem de erro 1478
(veja o significado deste erro na continuidade do artigo na
seo Erros mais comuns), re-execute o passo 3, restaurando
apenas o backup de transao.
Figura 13. Status do DB principal e DB espelho aps a inicializao.

16 SQL Magazine - Database Mirroring

SQL38.indb 16

11.12.06 14:12:40

S QL S ERV ER 2005

espelho. No entanto, lembre-se que o DB espelho no fica disponvel para leitura. Para utilizar o DB espelho preciso quebrar a
sesso de mirroring ou ativar o failover manualmente.

Quebrar o mirroring
Para quebrar o mirroring, podemos utilizar a janela de propriedades do DB principal e na pgina Mirroring clicar sobre o
boto Stop Mirroring ou ainda executar o script da Listagem
1 no query editor de um dos parceiros da sesso. A Figura 14
apresenta a janela principal do database mirroring com o boto
que permite parar a sesso de mirroring (Stop Mirroing).
Listagem 1. Script Transact-SQL para quebrar uma sesso de mirroring.
--Executar no servidor principal ou servidor espelho
--Para desfazer o Mirror
ALTER DATABASE AdventureWorks SET PARTNER OFF

Aps quebrar o mirroring, o DB espelho se manter no status de Restoring. Para utiliz-lo, preciso antes deix-lo em seu
status normal de utilizao, realizando o recovering do banco
de dados. Para fazer o recovering do DB espelho, execute o
script da Listagem 2 no query editor do servidor espelho.
Listagem 2. Script Transact-SQL para executar o recover do DB espelho.
-- Rodar no Servidor espelho
RESTORE DATABASE AdventureWorks WITH RECOVERY

Ativar o Failover
O processo de failover o processo que far com que os servidores troquem de papis, ou seja, o servidor principal passe a
ser o servidor espelho e o servidor espelho passe a ser o novo servidor principal. Quando estamos utilizando um witness server
e ocorre algum problema no servidor principal, este processo
de troca de papis realizado de forma automtica e tudo
controlado pelo witness server. No entanto, tambm possvel
executar o failover de forma manual. Isso muito til quando
precisamos, por exemplo, realizar alguma manuteno no servidor que detm o papel de servidor principal.
Para forar o failover manual, no servidor principal, clique
com o boto direito do mouse sobre o DB principal, selecione
Tasks > Mirror... e clique sobre o boto Failover (ver boto
Failover na Figura 14).
Ao clicar sobre o boto Failover, ser apresentada a mensagem da Figura 15 informando da troca de papis entre os
servidores. Clique em Yes para confirmar a troca de papis dos
servidores.
Pronto! Com a troca de papis o servidor principal original
passa a ser o servidor espelho, bem como o DB espelho original
passa a ser o novo DB principal. Com isso, podemos consultar
o novo DB principal para verificar se as operaes realizadas no
antigo DB principal foram espelhadas com sucesso para o novo
DB principal (antigo DB espelho).

Edio 38 - SQL Magazine

SQL38.indb 17

17
11.12.06 14:12:42

Erros mais comuns

Dois erros muito comuns durante a configurao de uma sesso de database mirroring so os erros 1418 e 1478. Vamos comentar sobre cada um desses erros. Ambos os erros costumam
ocorrer no mesmo ponto: no momento da configurao dos
parceiros da sesso ao clicar sobre o boto Start Mirroring.

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.

Figura 14. Janela principal do database mirroring.

O erro 1418 indica problemas de conectividade entre os

ns, normalmente problemas de resoluo dos nomes das
mquinas. Para corrigi-lo, certifique-se de que os nomes das
mquinas esto corretos ou ento, na janela de configurao
do database mirroring do Passo 14 (Figura 12), configure o
servidor principal e o servidor espelho utilizando o endereo
IP ao invs do nome dos servidores. A Figura 16 mostra como
isso pode ser feito.

Msg 1478, Level 16, State 0, Line 1

The mirror database, AdventureWorks, 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.

Figura 15. Mensagem informando sobre a troca de papis entre o

servidor principal e o servidor espelho.

O erro 1478 indica uma falta de sincronismo entre o log de

transao do DB principal e o DB espelho. Para corrigi-lo, efetue um backup do log de transao no DB principal e restaureo no DB espelho utilizando a opo WITH NORECOVERY.
Aps a restaurao do backup de transao, reinicie a configurao dos endpoints em ambos os servidores da sesso, refazendo os passos de 4 a 14.

Concluses
Como vimos, o database mirroring na verdade bastante
simples de ser configurado, alm de ser uma excelente opo
para quem precisa manter a alta disponibilidade de um banco
de dados e no possui recursos financeiros para a implantao
de um ambiente mais robusto, como o Cluster Server.
Vale lembrar que por padro, uma sesso de database mirroring executada em modo sncrono, com a opo transaction
safety definida como FULL. Isso garante o funcionamento do
failover automtico. Para configurar uma sesso para executar
em modo assncrono (Modo de Operao High Performance
[Alta Performance]), defina o transaction safety como OFF.
Para mais informaes, consulte os tpicos Database Mirroring Sessions e How to: Change Transaction Safety in a Database Mirroring Session (Transact-SQL) no Books Online do
SQL Server 2005.
Figura 16. Substituindo o nome dos servidores por seus respectivos
endereos IP.

Um abrao a todos e at a prxima.

18 SQL Magazine - Database Mirroring

SQL38.indb 18

11.12.06 14:12:46

Uma das
es
maiores pont
a por
t
i
e
F
.
o
d
n
u
m
do

.
s
o
r
i
e
l
i
s
a
Br

encerrar
blicao decidimos
pu
de
os
an
s
tr
azine no Brasil.
Aps
marca MSDN Mag
da
o
us
o
35
o

i
Magazine,
na ed
ora se chama .NET
ag
ne
ira!
i
az
ag
M
N
D
A MS
ser 100% brasile
de
o
lh
gu
or
o
m
te
e
uma publicao qu
qualidade,
sta ganhou mais
vi
re
a
a
n
da
u
m
Com a
e.
ais nacionalidad
mais contedo, m

.NET Magazine

senvolvedor
A revista do de
iro.
o de ser brasile
que tem orgulh

19
J nas bancas!

Edio 38 - SQL Magazine

SQL38.indb 19

11.12.06 14:13:01