ss pad sql database mirroring

1

Procedimento de Configuração

Database Mirroring

SQL Server

2

Sumário

1. Histórico do Documento 3

2. Introdução 4

3. Requisitos Mínimos 4

4. Modos de operação do Database Mirroring 5

5. Configurando o Database Mirroring 6

5.1 Configurando as instâncias para conexões de saída usando um Certificado de Segurança 6 5.2 Configurando as instâncias para conexões de entrada usando um Certificado de Segurança 8

6. Configurando a sessão de Database Mirroring para um Database 9

6.1 Inicialização do database 9 6.2 Configurando os parceiros da sessão de Database Mirroring 10 6.3 Objetos Adicionais 11 6.4 Monitorando o Database Mirroring 11

7. FailOver Manual 13

7.1 Diagrama Simplificado do Procedimento 13 7.2 Alternativas para FailOver Manual 14

7.2.1 Forçando o Serviço com possível perda de informações 14 7.2.2 Utilizando um Backup do Transaction Log para evitar a perda de informações 15

8. FailBack Manual 16

8.1 Alternativas para o FailBack Manual 16 8.1.1 Recriando a sessão do Database Mirroring 16 8.1.2 Restabelecendo a sessão do Database Mirroring após forçar o serviço 18

3

1. Histórico do Documento

Data Histórico

22/10/2011 Criação do documento

4

2. Introdução

Este documento descreve a configuração do Database Mirroring entre 2 instâncias SQL Server em servidores distintos. Estes servidores devem

preferencialmente estar no mesmo domínio. No entanto, para tornar a aplicação deste documento mais abrangente, o procedimento de

configuração aqui descrito foi criado de forma que também poderá ser utilizado para a configuração do Database Mirroring entre servidores que

encontram-se em domínios diferentes, sem relação de confiança entre eles, ou servidores que sequer pertencem a um domínio.

A complexidade técnica envolvida na implementação deste processo não é discutida em detalhes neste documento. São apresentados os passos

necessários para concluí-lo com sucesso, bem como uma breve explicação de alguns termos e conceitos.

O procedimento de configuração descrito neste documento será realizado utilizando somente comandos Transact-SQL. Não será abordada a

configuração através de interfaces gráficas.

A comunicação entre as 2 instâncias pode ocorrer através de um link compartilhado com outros processos. Aliado ao fato de que os servidores

podem estar em domínios diferentes, ou não pertencerem a nenhum domínio, isto constitui um risco para a segurança das informações. Portanto,

este documento contempla também os passos necessários para garantir a encriptação dos dados transferidos entre os servidores.

3. Requisitos Mínimos

O Database Mirroring funciona entre servidores 32-Bit e 64-Bit, sem restrições. Em todas as sessões de Database Mirroring, só podem haver 2

instâncias SQL Server envolvidas, uma no servidor principal e outra no servidor mirror. Ele é suportado a partir do SQL Server 2005 Service Pack

1 para as edições Standard e Enterprise. As 2 instâncias devem usar a mesma edição.

Os dois servidores devem possuir a mesma estrutura de diretórios onde são armazenados os datafiles (MDF) e logfiles (LDF), inclusive em

relação as letras dos drives. Em uma situação onde um novo datafile ou logfile é criado no database no servidor principal, esta operação será

repetida no database no servidor mirror. Se no mirror não houver a mesma estrutura de diretórios e letras dos drives, esta operação irá falhar e o

database perderá o sincronismo, fazendo com que a sessão de Database Mirroring tenha de ser reconfigurada.

É recomendado que o tráfego das sessões de Database Mirroring entre o servidor principal e o servidor mirror ocorram através de uma interface

de rede dedicada em cada servidor, conectadas por um cabo crossover. Em ambientes virtuais ou quando há teaming entre interfaces de rede,

isto não é possível, mas é recomendado que nestes casos seja utilizada uma VLAN diferente da que é utilizada pelos aplicativos e usuários na

conexão às instâncias.

5

4. Modos de operação do Database Mirroring

O Database Mirroring pode operar em 2 modos: síncrono e assíncrono.

Há também a possibilidade do uso de um terceiro servidor no processo, chamado Witness. Este servidor é utilizado somente em conjunto com o

modo síncrono, para failover automático. Este cenário não será abordado neste documento.

O modo assíncrono (high-performance mode) é suportado apenas na edição Enterprise. Neste modo, o COMMIT das transações ocorre no

servidor principal e então são transferidas para o servidor mirror. Por este motivo, oferece maior desempenho no servidor principal, mas há o

risco de ocorrer atraso no sincronismo e perda de informações no processo de failover. Este modo é recomendado especialmente quando o link

entre os servidores não oferece desempenho satisfatório.

O modo síncrono (high-protection mode) é suportado nas edições Standard e Enterprise. Neste modo, o COMMIT das transações ocorre sempre

nos 2 servidores. Isto pode adicionar latência nas transações, diminuindo o desempenho no servidor principal. No entanto, o sincronismo em

tempo real é garantido entre o database no servidor principal e o database no servidor mirror. Este modo é recomenado especialmente quando

há um link direto entre os servidores, por interfaces de rede dedicadas ou em uma VLAN diferente da que é utilizada pelos aplicativos e usuários

na conexão às instâncias.

6

5. Configurando o Database Mirroring

O Database Mirroring deve ser configurado em cada instância, antes que uma sessão de Database Mirroring possa ser configurada para os

databases. Para garantir a segurança das informações no tráfego através de links compartilhados, é importante que seja utilizado um certificado

de segurança para autenticação e transferência de dados através dos End Points, especialmente se os servidores não estiverem no mesmo

domínio ou não estiverem em nenhum domínio. Este procedimento é descrito a seguir.

5.1 Configurando as instâncias para conexões de saída usando um Certificado de Segurança

Execute o seguinte procedimento no servidor principal:

Abra o SQL Server Management Studio.

Conecte-se utilizando um login com privilégios de SysAdmin.

Clique em New Query.

No database master, crie uma MASTER KEY, informando uma senha forte no parâmetro PASSWORD:

Use Master;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'senhaForte';

Execute um Backup da MASTER KEY (especifique o caminho do arquivo). informando uma senha forte no parâmetro PASSWORD. Por

questões de segurança, esta senha não deve ser a mesma utilizada na criação da MASTER KEY: Use Master;

BACKUP MASTER KEY TO FILE = 'C:\Mirroring_Principal_Master_Key.key' ENCRYPTION BY PASSWORD =

'senhaForte';

Crie um certificado que será utilizado no End Point do Database Mirroring: Use Master;

CREATE CERTIFICATE Mirroring_Principal WITH SUBJECT = 'Mirroring Principal Certificate';

Crie um End Point para o Database Mirroring, utilizando o certificado. Certifique-se de que a porta 5022 está liberada no Firewall para entrada e saída no protocolo TCP. Se preferir, utilize outra porta: CREATE ENDPOINT Mirroring

STATE = STARTED

AS TCP (

LISTENER_PORT = 5022

, LISTENER_IP = ALL

)

FOR DATABASE_MIRRORING (

AUTHENTICATION = CERTIFICATE Mirroring_Principal

, ENCRYPTION = REQUIRED ALGORITHM AES

, ROLE = ALL);

Execute um Backup do certificado (especifique o caminho do arquivo): BACKUP CERTIFICATE Mirroring_Principal TO FILE = 'C:\Mirroring_Principal_Certificate.cer';

Copie, de forma segura, o Backup do certificado para o servidor mirror.

Mantenha a senha da MASTER KEY, o Backup da MASTER KEY e sua senha, e o Backup do certificado em um local seguro, pois eles serão

necessários caso seja necessário realizar uma reconfiguração no futuro.

7

Em seguida, execute o seguinte procedimento no servidor mirror:




No database master, crie uma MASTER KEY, informando uma senha forte no parâmetro PASSWORD:

Use Master;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'senhaForte';

Execute um Backup da MASTER KEY (especifique o caminho do arquivo). informando uma senha forte no parâmetro PASSWORD. Por

questões de segurança, esta senha não deve ser a mesma utilizada na criação da MASTER KEY: Use Master;

BACKUP MASTER KEY TO FILE = 'C:\Mirroring_Mirror_Master_Key.key' ENCRYPTION BY PASSWORD =

'senhaForte';

Crie um certificado que será utilizado no End Point do Database Mirroring: Use Master;

CREATE CERTIFICATE Mirroring_Mirror WITH SUBJECT = 'Mirroring Mirror Certificate';

Crie um End Point para o Database Mirroring, utilizando o certificado. Certifique-se de que a porta 5022 está liberada no Firewall para entrada e saída no protocolo TCP. Se preferir, utilize outra porta: CREATE ENDPOINT Mirroring

STATE = STARTED

AS TCP (

LISTENER_PORT = 5022

, LISTENER_IP = ALL

)

FOR DATABASE_MIRRORING (

AUTHENTICATION = CERTIFICATE Mirroring_Mirror

, ENCRYPTION = REQUIRED ALGORITHM AES

, ROLE = ALL);

Execute um Backup do certificado (especifique o caminho do arquivo): BACKUP CERTIFICATE Mirroring_Mirror TO FILE = 'C:\Mirroring_Mirror_Certificate.cer';

Copie, de forma segura, o Backup do certificado para o servidor principal.

Mantenha a senha da MASTER KEY, o Backup da MASTER KEY e sua senha, e o Backup do certificado em um local seguro, pois eles serão

necessários caso seja necessário realizar uma reconfiguração no futuro.

8

5.2 Configurando as instâncias para conexões de entrada usando um Certificado de Segurança





Crie um login que será utilizado para o servidor mirror conectar-se, informando uma senha forte no parâmetro PASSWORD :

USE master;

CREATE LOGIN mirroring_mirror WITH PASSWORD = 'senhaForte';

Crie um usuário para este login: USE master;

CREATE USER mirroring_mirror_user FOR LOGIN mirroring_mirror;

Associe o certificado criado no servidor mirror com o usuário (especifique o caminho do arquivo): CREATE CERTIFICATE Mirroring_Mirror_Certificate

AUTHORIZATION mirroring_mirror_user

FROM FILE = 'C:\Mirroring_Mirror_Certificate.cer'

Conceda a permissão CONNECT no login, para o Endpoint do servidor mirror: GRANT CONNECT ON ENDPOINT::Mirroring TO mirroring_mirror;

Em seguida, execute o seguinte procedimento no servidor mirror:




Crie um login que será utilizado para o servidor principal conectar-se, informando uma senha forte no parâmetro PASSWORD :

USE master;

CREATE LOGIN mirroring_principal WITH PASSWORD = 'senhaForte';

Crie um usuário para este login: USE master;

CREATE USER mirroring_principal_user FOR LOGIN mirroring_principal;

Associe o certificado criado no servidor principal com o usuário (especifique o caminho do arquivo): CREATE CERTIFICATE Mirroring_Principal_Certificate

AUTHORIZATION mirroring_principal_user

FROM FILE = 'C:\Mirroring_Principal_Certificate.cer'

Conceda a permissão CONNECT no login, para o Endpoint do servidor mirror: GRANT CONNECT ON ENDPOINT::Mirroring TO mirroring_principal;

9

6. Configurando a sessão de Database Mirroring para um Database

6.1 Inicialização do database

Cada sessão de Database Mirroring é configurada individualmente, para cada database. Antes de iniciar a sessão do Database Mirroring entre as

2 instâncias, o database deverá ser inicializado na instância do servidor mirror com o Backup Full mais atual. Também será necessário um

Backup do Transaction Log, que deve ser executado após o Backup Full. Este procedimento é descrito a seguir.





Configure o database para utilizar Full Recovery Model: ALTER DATABASE databaseName SET RECOVERY FULL

Execute um Backup Full do database (especifique o caminho do arquivo): BACKUP DATABASE databaseName to disk = 'c:\databaseName.bak' WITH FORMAT

Execute um Backup do Transaction Log do database (especifique o mesmo nome de arquivo do Backup Full): BACKUP LOG databaseName TO DISK = 'c:\databaseName.bak' WITH NOINIT

Copie o arquivo databaseName.bak para um disco local do servidor mirror, da forma que oferecer a maior rapidez.

Verifique o nome lógico (coluna name) e físico (coluna filename) de cada um dos arquivos do database, e copie estes nomes: USE databaseName;

exec sp_helpfile;

Transações serão acumuladas no Transaction Log do database no servidor principal enquanto a cópia é realizada, e estas transações só

começarão a ser enviadas ao servidor mirror quando a sessão do Database Mirroring for iniciada para o database. Quanto mais tempo o

processo demorar para ser concluído, mais transações irão se acumular no servidor principal, e mais tempo levará a sincronização entre os

servidores quando a sessão do Database Mirroring for iniciada.

Concluída a cópia, execute o seguinte procedimento no servidor mirror:




Restaure o Backup Full com a opção NORECOVERY. Especifique o caminho de cada arquivo MDF e LDF anotados anteriormente, que

devem ser idênticos aos do servidor principal. Caso o database possua mais de dois arquivos, você deve incluir uma opção MOVE no

comando abaixo para cada arquivo adicional. O database deve possuir exatamente o mesmo nome utilizado no servidor principal: RESTORE DATABASE databaseName

FROM DISK = 'c:\databaseName.bak' WITH FILE = 1, NORECOVERY,

MOVE 'nome_logico_do_mdf' TO 'c:\databaseName.mdf',

MOVE 'nome_logico_do_ldf' TO 'c:\databaseName_log.ldf'

Restaure o Backup do Transaction Log com a opção NORECOVERY (especifique o mesmo nome de arquivo do Backup Full):

RESTORE LOG databaseName FROM DISK = 'c:\databaseName.bak' WITH FILE = 2, NORECOVERY

10

6.2 Configurando os parceiros da sessão de Database Mirroring

Após a inicialização do database, o próximo passo é iniciar a sessão de Database Mirroring entre o database no servidor principal e o database

de mesmo nome no servidor mirror. Este procedimento é também chamado de Configuração dos Parceiros da Sessão.

Execute o seguinte procedimento no servidor mirror:




Configure o database no servidor principal como um parceiro do database no servidor mirror informando o nome do database, o FQDN

ou IP estático do servidor principal em <principal_address> e em <port>, o número da porta utilizada na criação do End Point no

servidor principal: ALTER DATABASE databaseName SET PARTNER = 'TCP://<principal_address>:<port>';

Em seguida, execute o seguinte procedimento no servidor principal:




Configure o database no servidor mirror como um parceiro do database no servidor principal informando o nome do database, o FQDN

ou IP estático do servidor mirror em <mirror-address> e em <port>, o número da porta utilizada na criação do End Point no

servidor mirror: ALTER DATABASE databaseName SET PARTNER = 'TCP://<mirror_address>:<port>';

Na edição Standard, o modo de execução é síncrono e selecionado automaticamente. Se você estiver usando a edição Enterprise, configure a sessão de Database Mirroring para executar no modo desejado. Você pode escolher entre os modos síncrono (SAFETY

FULL) ou assíncrono (SAFETY OFF), dependendo dos seus requisitos:

ALTER DATABASE databaseName SET PARTNER SAFETY FULL;

A sessão do Database Mirroring para o database será iniciada, e começará a sincronização do database no servidor principal com o database no

servidor mirror.

Após a configuração da sessão, é importante que o Backup do Transaction Log seja configurado para executar regularmente no database no

servidor principal, pois o Database Mirroring não irá expurgar automaticamente do Transaction Log as transações já transferidas ao servidor

mirror, havendo o risco do arquivo crescer indefinidamente, até que seja tomado todo o espaço disponível em disco.

11

6.3 Objetos Adicionais

Cada sessão de Database Mirroring é configurada individualmente, para cada database. Objetos externos ao database não são sincronizados

entre as instâncias. Portanto, a sessão não contempla a sincronização dos seguintes objetos, que deverão ser transferidos e sincronizados

manualmente entre as instâncias:

Logins

SQL Agent Jobs, Alerts e Operators

SQL Server Integration Services Packages

Support databases (outros databases utilizados como apoio ao database em mirror)

Linked Servers

Backup Devices

Maintenance Plans

Configurações do Database Mail

Configurações do Distributed Transaction Coordinator

Entre outros...

6.4 Monitorando o Database Mirroring

O monitoramento do processo pode ser feito através do SQL Server Management Studio. Siga o seguinte procedimento no servidor principal:


Clique com o botão direito do mouse no database em questão.

Selecione Tasks > Launch Database Mirroring Monitor.

Clique em Register Mirrored Database.

Informe a instância do SQL Server, e conecte-se a ela clicando no botão Connect.

Serão mostrados todos os databases que possuem sessão de Database Mirroring nesta instância. Selecione o database que será

registrado no Monitor, e clique em OK.

O Monitor mostra diversas informações de status sobre o database, como a transação mais antiga ainda não transferida, sincronismo entre o

servidor principal e mirror, entre outras. Através do Monitor, é possível acompanhar o processo, e saber se há algum problema na transferência

de dados entre os servidores.

Outro método, mais simplificado, de verificar o status do Database Mirroring para o database:


Clique com o botão direito do mouse no database em questão.

Selecione Tasks > Mirror.

Observe o campo Status.

São estes os tipos de estados possíveis:

SYNCHRONIZING: Transações do Transaction Log estão sendo enviadas para o servidor mirror, que está aplicando estas modificações

no database.

SYNCHRONIZED: Quando o servidor mirror recebe as transações mais atuais do servidor principal, e aplica estas modificações no

12

database. Este estado permanece enquanto há esta condição de sincronismo na comunicação e envio constante de transações do

Transaction Log do servidor principal para o mirror, e enquanto as modificações estão sendo aplicadas no database. Note que, em High-

Performance Mode, a transferência de dados é assíncrona, e portanto o servidor principal não espera que as modificações sejam

aplicadas no servidor mirror para então aplicá-la no servidor principal. Por isso este modo é mais recomendado quando a comunicação

entre os servidores ocorre por um link compartilhado com outros processos. No entando, pode haver perda de informações caso o

servidor principal fique indisponível, mesmo que no momento da falha, o estado seja SYNCHRONIZED.

SUSPENDED: Quando a sessão de Mirroring foi pausada pelo administrador, ou quando o database em mirror não está disponível no

servidor mirror. Neste caso, transações não estão sendo enviadas do servidor principal para o servidor mirror.

DISCONNECTED: O servidor principal perdeu a comunicação com o servidor mirror.

Se o estado permanece em SYNCHRONIZING constantemente, há uma contenção no servidor principal, no servidor mirror, ou no link entre eles.

Muitas transações estão sendo executadas no servidor principal, ou o servidor mirror está recebendo estas transações, mas está demorando

demais para aplicá-las no database. Outra possibilidade é uma contenção no link de comunicação entre os servidores, e as transações demoram

a ser enviadas.

Alguns contadores estão disponíveis para monitoramento do Database Mirroring, e são expostos pelo SQL Server ao sistema operacional para

serem monitorados por ferramentas, através de comandos WMI, ou mesmo através do Performance Monitor do Windows. Estes mesmos

contadores estão disponíveis para a configuração de alertas no SQL Server Agent, para envio de notificações por email a um operador quando

ocorrerem situações de atraso no sincronismo entre os databases.

13

7. FailOver Manual

7.1 Diagrama Simplificado do Procedimento

Procedimento para FailOver Manual do database

Se

rvid

or

Mirro

r(s

em

pe

rda

de

in

form

açõ

es)

Ap

lica

tivo

sS

erv

ido

r M

irro

r(p

ossív

el p

erd

a d

e in

form

açõ

es)

Se

rvid

or

Prin

cip

al

Sim Sim

Copie o Backup do

Transaction Log para

o disco local do

Servidor Mirror

Independente do

database estar

onLine ou não, tente

efetuar o Backup do

Transaction Log

Conseguiu

efetuar o Backup

do Transaction

Log?

Instância está

disponível?

Servidor Mirror

torna-se o

Servidor Principal

Force o

Serviço na

sessão de

Database

Mirroring

Não

Reconfigure os

aplicativos para

acesso ao database

no Servidor Mirror,

agora no papel de

Servidor Principal

Remova a sessão de

Database Mirroring

Restaure o Backup do

Transaction Log com

a opção WITH

RECOVERY

Reconfigure os

aplicativos para

acesso ao database

no Servidor Mirror.

Não há uma sessão

de Database Mirroring

Não

14

7.2 Alternativas para FailOver Manual

As alternativas aqui apresentadas para FailOver manual, consideram sempre um cenário de indisponibilidade no servidor principal, seja total ou

apenas do database. Neste cenário, há sempre o risco de perda de informações. Isto será abordado a seguir.

7.2.1 Forçando o Serviço com possível perda de informações

Caso o servidor principal esteja totalmente indisponível, sendo impossível até mesmo iniciar o serviço da instância SQL Server, não haverá outra

alternativa senão Forçar o Serviço no servidor mirror. Forçar o Serviço significa forçar o FailOver para o servidor mirror, transferindo a ele o papel

de servidor principal, assim como a responsabilidade de servir o acesso ao database para as aplicações.

Neste processo, informações podem ser perdidas, especialmente se a sessão do Database Mirroring estiver funcionando em High-Performance

Mode (assíncrono), pois não há garantias de que todas as transações mais recentes foram enviadas pelo servidor principal ao servidor mirror,

antes da falha ocorrer. São transações que podem ou não existir, dependendo da frequência em que o database é atualizado. O envio destas

transações pelo servidor principal ocorre tão logo são incluídas no Transaction Log. Elas permanecem em uma fila, que é rapidamente

gerenciada pelo SQL Server no sentido de enviá-las o mais rápido possível para o servidor mirror. Se há um problema de lentidão no link de

comunicação entre os servidores, ou contenção no servidor principal, é possível que algumas transações recentes não tenham sido enviadas

antes da ocorrência da falha. Logo, estas transações são perdidas se o serviço for forçado.

No entanto, a vantagem deste procedimento é que o SQL Server automaticamente transfere o papel de servidor principal para o servidor mirror, e

torna o database disponível imediatamente para acesso pelos aplicativos. A sessão de Database Mirroring para o database não é removida, ela é

apenas suspensa, o que facilitará o FailBack mais tarde.

Se as consequências detalhadas acima são aceitáveis, efetue o seguinte procedimento:



Forçe o Serviço: ALTER DATABASE databaseName SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

O servidor mirror imediatamente efetuará a transição para servidor principal, e a sessão de Database Mirroring será suspensa. O database estará

disponível imediatamente para acesso pelos aplicativos.

15

7.2.2 Utilizando um Backup do Transaction Log para evitar a perda de informações

A outra alternativa consiste em efetuar um Backup do Transaction Log do database, no servidor principal. Não é um Backup comum do

Transaction Log, e sim um Backup que tenta recuperar as transações contidas no Transaction Log, mesmo que o database esteja indisponível.

Execute este procedimento apenas se as consequências de Forçar o Serviço forem inaceitáveis.

Obviamente, este procedimento só poderá ser realizado se o servidor principal estiver disponível, e o serviço da instância SQL Server estiver

iniciado. O procedimento considera que o database está indisponível, e não é possível recuperá-lo. No entanto, o logfile do database está

disponível em seu local original.

Se este procedimento for executado com sucesso, há a garantia de que todas as transações concluídas no database no servidor principal até o

momento antes da falha serão transferidas para o database no servidor mirror.





Efetue o Backup do Transaction Log (especifique o caminho do arquivo): BACKUP LOG databaseName TO DISK = 'C:\databaseName_TransactionLog_Tail.trn' WITH

CONTINUE_AFTER_ERROR, NO_TRUNCATE

Se ocorrerem erros na execução deste comando, o log file do database está danificado, e as transações não podem ser recuperadas.

Não há outra alternativa, senão executar o procedimento para Forçar o Serviço.

Se o comando executar com sucesso, copie o Backup do Transaction Log para o servidor mirror.

Se o Backup do Transaction Log foi executado com sucesso e copiado para o servidor mirror, execute o seguinte procedimento no servidor

mirror:




Remova a sessão de Database Mirroring para o database: ALTER DATABASE databaseName SET PARTNER OFF

Restaure o Backup do Transaction Log e torne o database acessível para os aplicativos (especifique o caminho do arquivo): RESTORE LOG databaseName FROM DISK = 'C:\databaseName_TransactionLog_Tail.trn' WITH RECOVERY

O servidor mirror está agora servindo o acesso ao database, mas como um database exposto, ou seja, sem uma sessão de Database Mirroring

configurada. Se o servidor principal original se tornar novamente disponível, assim como o database neste servidor, haverão 2 cópias disponíveis

do database, uma em cada servidor. É importante que os aplicativos não tenham acesso ao database no servidor principal original.

16

8. FailBack Manual

O FailBack Manual ocorrerá apenas quando o servidor principal original estiver novamente disponível. O procedimento a ser aplicado depende da

forma como ocorreu a indisponibilidade neste servidor, e qual procedimento foi adotado para o FailOver Manual.

8.1 Alternativas para o FailBack Manual

8.1.1 Recriando a sessão do Database Mirroring

Independente do procedimento de FailOver Manual que foi executado, se a sessão de Database Mirroring foi removida para o database – tanto

devido ao procedimento executado ou devido a reinstalação da instância do SQL Server no servidor principal – será necessário reconfigurar a

sessão.

Se a instância do SQL Server não foi reinstalada no servidor principal, toda a configuração do Database Mirroring está intacta. Portanto, devem

ser seguidos apenas os procedimentos descritos no item “Configurando a sessão de Database Mirroring para um Database”, invertendo os

papéis dos servidores, pois neste caso o servidor mirror irá atuar no papel de servidor principal, já que é este servidor que está atuamente

servindo o acesso ao database.

Por outro lado, se a instância do SQL Server foi reinstalada no servidor principal, devem ser seguidos todos os seguintes procedimentos:

No item “Configurando o Database Mirroring”, apenas os procedimentos para configuração do servidor principal, pois é necessário

configurar novamente o Database Mirroring neste servidor.

O Backup do novo certificado criado no servidor principal deverá ser copiado para o servidor mirror. Neste servidor, elimine o certificado

de segurança atual: USE master;

DROP CERTIFICATE Mirroring_Principal_Certificate;

Associe o novo certificado com o usuário mirroring_principal_user (especifique o caminho do arquivo):

USE master;

CREATE CERTIFICATE Mirroring_Principal_Certificate

AUTHORIZATION mirroring_principal_user

FROM FILE = 'C:\Mirroring_Principal_Certificate.cer'

Execute todos os procedimentos descritos no item “Configurando a sessão de Database Mirroring para um Database”, invertendo os

papéis dos servidores, pois neste momento o servidor mirror está servindo o acesso ao database e portanto irá atuar no papel de

servidor principal.

Após a execução destes procedimentos, a sessão de Database Mirroring será estabelecida para o database, e os papéis dos servidores podem

ser invertidos, forçando o serviço, conforme o procedimento descrito no item “Forçando o Serviço com possível perda de informações”. No

entanto, este trabalho deve ser efetuado em uma parada programada, onde sejam impedidas modificações no database, para evitar possibilidade

de perda de informações decorrente do procedimento.

17

Como a sessão de Database Mirroring para o database será automaticamente suspensa pelo SQL Server ao forçar o serviço, execute o seguinte

procedimento em qualquer um dos 2 servidores para restabelecê-la:




Restabeleça a sessão de Database Mirroring: ALTER DATABASE databaseName SET PARTNER RESUME

O database no servidor mirror entrará no estado SYNCHRONIZING. Dependendo do número de transações executadas durante o período em

que a sessão estava suspensa, este estado pode permanecer durante algum tempo, até que todas as transações sejam enviadas pelo servidor

principal ao servidor mirror, e sejam aplicadas no database no servidor mirror. Após este período, o estado mudará para SYNCHRONIZED.

18

8.1.2 Restabelecendo a sessão do Database Mirroring após forçar o serviço

Se o servidor principal estiver novamente disponível, a instância do SQL Server não foi reinstalada, suas configurações não foram perdidas, e o

database estiver intacto, o SQL Server automaticamente identifica que o serviço foi forçado e inverte o papel dos servidores. Portanto, o servidor

mirror assumirá automaticamente o papel de servidor principal.

A sessão de Database Mirroring para o database é suspensa automaticamente. Neste momento, você deve tomar uma das seguintes decisões:

Restabelecer a sessão de Database Mirroring para o database, passando a transferir as transações que foram acumuladas enquanto a

sessão estava suspensa, e descartando quaisquer transações armazenadas no Transaction Log que não haviam sido enviadas para o

servidor mirror até o momento da falha.

Remover a sessão do Database Mirroring configurada, para tornar o database On-Line no servidor principal original, e trabalhar em

conjunto com o DBA no sentido de tentar recuperar estas transações a partir do Transaction Log. Esta tarefa pode consumir um tempo

considerável e só deve ser realizada se a perda destas transações for inaceitável.

Nenhuma destas decisões afeta a disponibilidade do database no servidor que está atualmente servindo o acesso ao database.

Se decidir por restabelecer a sessão de Database Mirroring para o database, execute o seguinte procedimento em qualquer um dos 2 servidores:




Restabeleça a sessão de Database Mirroring: ALTER DATABASE databaseName SET PARTNER RESUME

O database no servidor mirror entrará no estado SYNCHRONIZING. Dependendo do número de transações acumuladas durante o período em

que a sessão estava suspensa, este estado pode permanecer durante algum tempo, até que todas as transações sejam enviadas pelo servidor

principal ao servidor mirror, e sejam aplicadas no database no servidor mirror. Após este período, o estado mudará para SYNCHRONIZED.

Os papéis dos servidores podem ser invertidos novamente, forçando o serviço, conforme o procedimento descrito no item “Forçando o Serviço

com possível perda de informações”. No entanto, este trabalho deve ser efetuado em uma parada programada, onde sejam impedidas

modificações no database, para evitar possibilidade de perda de informações decorrente do procedimento. Como a sessão de Database Mirroring

para o database será automaticamente suspensa pelo SQL Server ao forçar o serviço, repita o procedimento aqui descrito para restabelecer a

sessão.

ss pad sql database mirroring

Documents