Espelhamento de banco de dados assncrono (Modo de alto desempenho)Observao O espelhamento de banco de dados assncrono suportado somente pelo SQL Server 2005 Enterprise Edition Service Pack 1 (SP1) e verses posteriores. Quando a segurana de transao est definida como OFF, a sesso de espelhamento de banco de dados opera de maneira assncrona. A operao assncrona d suporte apenas a um modo de operao modo de alto desempenho. Esse modo aumenta desempenho s custas de alta disponibilidade. O modo de alto desempenho usa apenas o servidor principal e o servidor espelho. Problemas no servidor espelho nunca causam impacto no servidor principal. Com a perda do servidor principal, o banco de dados espelho fica marcado como DESCONECTADO, mas est disponvel em espera passiva. O modo de alto desempenho oferece suporte apenas a uma forma de troca de funo: servio forado (com possvel perda de dados), que usa o servidor espelho como um servidor em espera passiva. O servio forado uma das possveis respostas falha do servidor principal. Como a perda de dados possvel, devem ser consideradas outras alternativas antes de forar servio ao espelho. Para obter mais informaes, consulte "Respondendo falha do principal", mais adiante neste tpico. A figura a seguir mostra a configurao de uma sesso que usa modo de alto desempenho.

No modo de alto desempenho, assim que o servidor principal envia o log para uma transao para o servidor espelho, o servidor principal envia uma confirmao para o cliente, sem esperar uma confirmao do servidor espelho. As transaes so confirmadas sem esperar que o servidor espelho grave o log no disco. A operao assncrona permite a execuo do servidor principal com latncia de transao mnima. O servidor espelho tenta acompanhar os registros de log enviados pelo servidor principal. Mas, o banco de dados espelho pode ficar um pouco atrasado em relao ao banco de dados principal, embora normalmente a lacuna entre os bancos de dados seja pequena. Entretanto, a lacuna pode ser significativa se o servidor principal estiver com grande carga de trabalho ou se o sistema do servidor espelho estiver sobrecarregado. Quando o modo de alto desempenho apropriado? O modo de alto desempenho pode ser til em um cenrio de recuperao de desastre no qual os servidores principal e espelho esto separados por uma distncia significativa e onde voc no deseja que erros pequenos causem impacto ao servidor principal. Observao O envio de logs pode ser um suplemento ao espelhamento de banco de dados e uma alternativa favorvel ao espelhamento de banco de dados assncrono. Para obter informaes sobre as vantagens do envio de logs, consulteViso geral das solues de alta disponibilidade. Para obter informaes sobre como usar o envio de logs com espelhamento de banco de dados, consulte Espelhamento de banco de dados e envio de logs. O impacto de uma testemunha no modo de alto desempenho Se voc usar a Transact-SQL para configurar o modo de alto desempenho, sempre que a propriedade SAFETY for definida como OFF, altamente recomendvel que a propriedade WITNESS tambm seja definida como OFF. Uma testemunha pode coexistir com modo de alto desempenho, mas a testemunha no fornece nenhum benefcio e representa um risco. Se a testemunha estiver desconectada da sesso quando qualquer parceiro abaixar, o banco de dados ficar indisponvel. Isso ocorre por que mesmo com o modo de alto desempenho no exigindo testemunhas, se uma delas definida, a sesso exige um quorum que consista em duas ou mais instncias do servidor. Se a sesso no tem quorum, no pode servir o banco de dados. Quando uma testemunha definida em modo de alto desempenho, a aplicao de quorum significa que:

Se o servidor espelho for perdido, o servidor principal deve ser conectado testemunha. Caso contrrio, o servidor principal deixa seu banco de dados offline at que a testemunha ou o servidor espelho se rena novamente sesso.

Se o servidor principal for perdido, forar o servio para o servidor espelho exige que o servidor espelho esteja conectado testemunha.

Observao Para obter mais informaes sobre os tipos de quoruns, consulte Quorum: como uma testemunha afeta a disponibilidade do banco de dados. Respondendo falha no principal Quando o principal falhar, o proprietrio do banco de dados tem vrias escolhas, como se segue:

Deixar o banco de dados indisponvel at que o principal fique disponvel novamente. Se o banco de dados principal e seu log de transaes estiverem intactos, essa escolha preserva todas as transaes confirmadas s custas da disponibilidade.

Interrompa a sesso de espelhamento de banco de dados, atualize manualmente o banco de dados e, ento, inicie uma nova sesso de espelhamento de banco de dados. Se o banco de dados principal estiver perdido mas o servidor principal ainda estiver sendo executado, tente imediatamente fazer o backup da parte final do log no banco de dados principal. Se o backup da parte final do log for bem-sucedido, a remoo do espelhamento pode ser a melhor alternativa. Aps a remoo do espelhamento, possvel restaurar o log no banco de dados espelho anterior, que preserva todos os dados.

Observao Se o backup da parte final do log falhar e voc no puder esperar pela recuperao do servidor principal, considere forar o servio, que tem a vantagem de manter o estado da sesso.

Servio forado (com possvel perda de dados) no servidor espelho. O servio forado estritamente um mtodo de recuperao de desastres e deve ser usado com moderao. Forar um servio possvel somente se o servidor principal no estiver conectado, a sesso for assncrona (a segurana de transao estiver definida como OFF) e quando a sesso no tiver qualquer testemunha (a propriedade WITNESS estiver definida como OFF) ou a testemunha estiver conectada ao servidor espelho (ou seja, quando houver quorum). Forar um servio leva o servidor espelho a assumir a funo de principal e a disponibilizar sua cpia do banco de dados aos clientes. Quando o servio forado, quaisquer logs de transao que o principal ainda no tiver enviado ao servidor espelho sero perdidos. Assim, deve-se limitar o servio forado a situaes onde a possvel perda de dados aceitvel e a disponibilidade imediata do banco de dados crtica. Para obter informaes sobre o funcionamento do servio forado e sobre as prticas recomendadas, consulte Servio forado (com possvel perda de dados).

Espelhamento de banco de dados sncrono (modo de alta segurana)Quando a segurana de transao definida como FULL, a sesso de espelhamento de banco de dados executada no modo de segurana alta e opera de forma sncrona depois de uma fase de sincronizao inicial. Este tpico descreve os detalhes das sesses de espelhamento de banco de dados configuradas para operao sncrona. Esse tpico supe que voc esteja familiarizado com os conceitos fundamentais das operaes de espelhamento de banco de dados. Para obter mais informaes, consulte Sesses de espelhamento de banco de dados . Para realizar a operao sncrona de uma sesso, o servidor espelho deve sincronizar o banco de dados espelho com o banco de dados principal. Quando a sesso iniciada, o servidor principal comea a enviar seu log ativo ao servidor espelho. O servidor espelho grava todos os registros de log de entrada no disco o mais rpido possvel. Assim que todos os registros de log recebidos so gravados no disco, os bancos de dados so sincronizados. Contanto que os parceiros permaneam em comunicao, os bancos de dados permanecem sincronizados. Observao Para monitorar alteraes de estado em uma sesso de espelhamento de banco de dados, use a classe de evento Database Mirroring State Change. Para obter mais informaes, consulte Classe de evento Database Mirroring State Change. Depois de concluda a sincronizao, toda transao confirmada no banco de dados principal tambm confirmada no servidor espelho, garantindo a proteo dos dados. Isso feito esperando a confirmao de uma transao no banco de dados principal, at o servidor principal receber uma mensagem do servidor espelho declarando que intensificou o log da transao no disco. Observe que a espera por essa mensagem aumenta a latncia da transao. O tempo necessrio para a sincronizao depende essencialmente do atraso do banco de dados espelho em relao ao banco de dados principal no incio da sesso (medido inicialmente pelo nmero de registros de log recebido do servidor principal), da carga de trabalho no banco de dados principal e da velocidade do sistema espelho. Depois que uma sesso sincronizada, o log intensificado que ainda precisar ser refeito no banco de dados espelho continuar na fila de restaurao. Para obter mais informaes, consulte Sesses de espelhamento de banco de dados . Assim que o banco de dados espelho for sincronizado, o estado de ambas as cpias do banco de dados ser alterado para SYNCHRONIZED. A operao sncrona mantida da seguinte maneira: 1. Durante o recebimento de uma transao de um cliente, o servidor principal grava o log da transao no log de transaes. 2. O servidor principal grava a transao no banco de dados e, simultaneamente, envia o registro de log ao servidor espelho. O servidor principal espera uma confirmao do servidor espelho antes de confirmar qualquer uma das operaes a seguir ao cliente: uma reverso ou uma confirmao de transao. 3. 4. O servidor espelho intensifica o log do disco e retorna uma confirmao ao servidor principal. Durante o recebimento da confirmao do servidor espelho, o servidor principal envia uma mensagem de confirmao ao cliente. O modo de segurana alta protege seus dados exigindo a sincronizao dos dados entre dois locais. Todas as transaes confirmadas esto garantidas para serem gravadas no disco do servidor espelho. Modo de segurana alta sem failover automtico A figura a seguir mostra a configurao do modo de segurana alta sem failover automtico. A configurao consiste apenas nos dois parceiros.

Quando os parceiros esto conectados e o banco de dados j est sincronizado, h suporte para failover manual. Se a instncia de servidor espelho diminuir, a instncia de servidor principal no ser afetada e as execues sero expostas (ou seja, sem espelhamento dos dados). Se o servidor principal estiver perdido, o espelho ser suspenso, mas o servio poder ser forado para o servidor espelho (com possvel perda de dados). Para obter mais informaes, consulte Servio forado (com possvel perda de dados). Modo de segurana alta com failover automtico O failover automtico fornece alta disponibilidade, assegurando que o banco de dados ainda funcione depois da perda de um servidor. O failover automtico exige que a sesso tenha uma terceira instncia de servidor, a testemunha que, idealmente, reside em um terceiro computador. A figura a seguir mostra a configurao da sesso do modo de segurana alta que oferece suporte a failover automtico.

Ao contrrio dos dois parceiros, a testemunha no atende o banco de dados. A testemunha simplesmente oferece suporte a failover automtico verificando se o servidor principal est funcionando. O servidor espelho apenas iniciar o failover automtico se o espelho e a testemunha permanecerem conectados um ao outro depois de serem desconectados do servidor principal. Quando uma testemunha definida, a sesso exige quorum uma relao entre pelo menos duas instncias de servidor que permite disponibilizar o banco de dados. Para obter mais informaes, consulte Quorum: como uma testemunha afeta a disponibilidade do banco de dados e Failover automtico. Para obter mais informaes, consulte Testemunha de espelhamento de banco de dados. O failover automtico exige as seguintes condies:

O banco de dados j esteja sincronizado. A falha ocorra quando todas as trs instncias de servidor estejam conectadas, e a testemunha e o servidor espelho permaneam conectados.

A perda de um parceiro tem o seguinte efeito:

Se o servidor principal ficar indisponvel nas condies anteriores, acontecer o failover automtico. O servidor espelho alternado para a funo principal e oferece seu banco de dados como banco de dados principal.

Se o servidor principal ficar indisponvel quando essas condies no forem atendidas, ser possvel forar o servio (com possvel perda de dados). Para obter mais informaes, consulte Servio forado (com possvel perda de dados).

Se apenas o servidor espelho ficar indisponvel, o principal e a testemunha continuaro funcionando.

Se a sesso perder a testemunha, o quorum exigir ambos os parceiros. Se qualquer parceiro perder quorum, ambos os parceiros perdero quorum e o banco de dados ficar indisponvel at que o quorum seja restabelecido. Esse requisito de quorum garante que na ausncia de uma testemunha o banco de dados nunca ser executado exposto, ou seja, sem ser espelhado. Observao

Se voc espera que a testemunha permanea desconectada por um tempo significativo, recomendamos que voc remova a testemunha da sesso at ela ficar disponvel.

Testemunha de espelhamento de banco de dadosPara oferecer suporte a failover automtico, a sesso de espelhamento de banco de dados deve ser configurada em modo de alta segurana e tambm deve possuir uma terceira instncia de servidor, conhecida como testemunha. A testemunha uma instncia opcional do SQL Server que permite ao servidor espelho, em uma sesso de modo de alta segurana, reconhecer se um failover automtico deve ser iniciado. Ao contrrio dos dois parceiros, a testemunha no serve o banco de dados. O suporte ao failover automtico a nica funo da testemunha. Observao No modo de alto desempenho, a testemunha pode prejudicar a disponibilidade. Se uma testemunha for configurada para uma sesso de espelhamento de banco de dados, o servidor principal dever ser conectado a pelo menos uma das outras instncias de servidor, o servidor espelho ou a testemunha, ou ambos. Caso contrrio, o banco de dados ficar indisponvel e ser impossvel forar o servio (com possvel perda de dados). Portanto, para o modo de alto desempenho, altamente recomendvel que voc sempre mantenha a testemunha definida como OFF. Para obter informaes sobre o impacto de uma testemunha no modo de alto desempenho, consulte Espelhamento de banco de dados assncrono (Modo de alto desempenho) A ilustrao a seguir mostra uma sesso de modo de alta segurana com uma testemunha.

Usando uma testemunha em vrias sesses Uma instncia de servidor especfica pode agir como uma testemunha em sesses de espelhamento de banco de dados, cada uma para um banco de dados diferente. As sesses diferentes podem ser com parceiros diferentes. A ilustrao a seguir mostra uma instncia de servidor que uma testemunha em duas sesses de espelhamento de banco de dados com parceiros diferentes.

Uma instncia de servidor nico tambm pode funcionar ao mesmo tempo como uma testemunha em algumas sesses e um parceiro em outras sesses. Porm, na prtica, uma instncia de servidor normalmente funciona como uma testemunha ou um parceiro. Isso porque os parceiros exigem computadores sofisticados com hardware suficiente para oferecer suporte a um banco de dados de produo, ao passo que a testemunha pode ser executada em qualquer sistema Windows disponvel que oferea suporte ao SQL Server 2008. Recomendaes de software e hardware A localizao da testemunha em um computador separado dos parceiros altamente recomendvel. S h suporte para os parceiros de espelhamento de banco de dados no SQL Server 2005 Standard e verses posteriores e no SQL Server 2005 Enterprise Edition e verses posteriores. Por outro lado, tambm h suporte para testemunhas no SQL Server 2005 Workgroup e verses posteriores e no SQL Server 2005 Express Edition e verses posteriores. Uma testemunha pode ser executada em qualquer sistema de computador confivel que fornea suporte a quaisquer edies do SQL Server. Porm, recomendvel que toda instncia de servidor usada como testemunha atenda configurao mnima exigida para a verso Standard do SQL Server que est sendo executada. Para obter mais informaes sobre esses requisitos, consulte Requisitos de hardware e software para a instalao do SQL Server 2008 R2. Funo da testemunha no failover automtico Ao longo de uma sesso de espelhamento de banco de dados, todas as instncias de servidor monitoram seus status de conexo. Se os parceiros forem desconectados uns dos outros, confiaro na testemunha para assegurar que apenas um deles esteja atendendo ao banco de dados atualmente. Se um servidor espelho sincronizado perder sua conexo com o servidor principal, mas continuar conectado testemunha, o servidor espelho entrar em contato com a testemunha para determinar se a testemunha perdeu sua conexo com o servidor principal:

Se o servidor principal ainda estiver conectado testemunha, no acontecer o failover automtico. Em vez disso, o servidor principal continuar atendendo ao banco de dados enquanto estiver acumulando registros de log para enviar ao servidor espelho quando os parceiros forem reconectados.

Se a testemunha tambm estiver desconectada do servidor principal, o servidor espelho saber que o banco de dados principal ficou indisponvel. Nesse caso, o servidor espelho iniciar imediatamente um failover automtico.

Se o servidor espelho estiver desconectado da testemunha e tambm do servidor principal, no ser possvel o failover automtico, independentemente do estado do servidor principal.

O requisito de que pelo menos duas das instncias de servidor estejam conectadas conhecido como quorum. O quorum assegura que o banco de dados s possa ser atendido por um parceiro de cada vez. Para obter informaes sobre o funcionamento do quorum e seu impacto em uma sesso, consulte Quorum: como uma testemunha afeta a disponibilidade do banco de dados.

Espelhamento de banco de dados e envio de logsUm determinado banco de dados pode ser espelhado ou ter o log enviado; ou ter os dois processos realizados simultaneamente. Para escolher o mtodo a ser usado, considere o seguinte:

Voc precisa de quantos servidores de destino? Se voc precisar de um nico banco de dados de destino, o espelhamento de banco de dados ser a soluo indicada. Se voc precisar de mais de um banco de dados de destino, dever usar o envio de logs, sozinho ou com o espelhamento de banco de dados. A combinao dos dois mtodos traz os benefcios de um espelhamento de banco de dados com o suporte de vrios destinos fornecido pelo envio de logs.

Caso precise adiar a restaurao do log no banco de dados de destino (geralmente, para se proteger contra erros lgicos), use o envio de logs, sozinho ou com o espelhamento de banco de dados.

Este tpico aborda as consideraes sobre como combinar o envio de logs com o espelhamento de banco de dados. Observao Para introdues nessas tecnologias, consulte Viso geral do espelhamento de banco de dados e Viso geral do envio de log. Combinando o envio de logs e o espelhamento de banco de dados O banco de dados principal em uma sesso de espelhamento tambm pode agir como o banco de dados primrio em uma configurao de envio de logs, ou vice-versa; uma vez que o compartilhamento de backup do envio de logs est intacto. A sesso de espelhamento de banco de dados executada em qualquer modo operacional, sncrono (com a segurana de transao definida como FULL) ou assncrono (com a segurana de transao definida como OFF). Observao Para usar o espelhamento de banco de dados em um banco de dados, ser sempre necessrio o modelo de recuperao completa. Geralmente, ao combinar o envio de logs e o espelhamento de banco de dados, a sesso de espelhamento estabelecida antes do envio de logs, embora isso no seja um exigncia. O banco de dados principal atual configurado como envio de logs primrio (o banco de dados principal/primrio), junto com um ou mais bancos de dados secundrios remotos. Alm disso, o banco de dados espelho deve ser configurado como envio de logs primrio (o banco de dados espelho/primrio). Os bancos de dados secundrios de envio de logs devem ocupar instncias de servidor diferentes do servidor principal/primrio ou servidor espelho/primrio. Observao As configuraes de diferenciao de maisculas e minsculas dos servidores envolvidos no envio de logs devem corresponder. Durante uma sesso de envio de logs, os trabalhos de backup no banco de dados primrio criam backups de log em uma pasta de backup. Nessa pasta, os backups so copiados por trabalhos de cpia dos servidores secundrios. Para obterem xito, os trabalhos de backup e de cpia devem ter acesso pasta de backup de envio de logs. Para maximizar a disponibilidade do servidor primrio, recomendamos que a pasta de backup seja estabelecida em um local de backup compartilhado em um computador host separado. Assegure de que todos os servidores de envio de logs, inclusive o servidor espelho/primrio, possam acessar o local de backup compartilhado (conhecido como um compartilhamento de backup). Para permitir que o envio de logs continue depois que houver falha no espelhamento de banco de dados, voc tambm dever configurar o servidor espelho como um servidor primrio, usando a mesma configurao utilizada para o primrio, no banco de dados principal. O banco de dados espelho est no estado de restaurao, o que impede que os trabalhos de backup faam o backup do log no banco de dados espelho. Isso assegura que o banco de dados espelho/primrio no interfira no banco de dados principal/primrio cujos backups de log esto sendo copiados atualmente por servidores secundrios. Para evitar alertas falsos, depois que o trabalho de backup executado no banco de dados

espelho/primrio, ele emite uma mensagem para a tabela log_shipping_monitor_history_detail e o trabalho de agente retorna um status de xito. O banco de dados espelho/primrio est inativo na sesso de envio de logs. Porm, se houver falha no espelhamento, o banco de dados espelho anterior ficar online como o banco de dados principal. Nessa altura, aquele banco de dados tambm fica ativo como o banco de dados primrio de envio de logs. Os trabalhos de backup de envio de logs que no puderam enviar previamente o log de envio naquele banco de dados, comeam a enviar o log. Reciprocamente, um failover faz com que o banco de dados principal/primrio anterior se torne o novo banco de dados espelho/primrio e entre em estado de restaurao, e os trabalhos de backup naquele banco de dados interrompam o backup de log. Observao No caso de um failover automtico, a alterao para a funo espelho acontece quando o banco de dados principal/primrio anterior volta sesso de espelhamento. Para executar em modo de segurana alta com failover automtico a sesso de espelhamento est configurada com uma instncia de servidor adicional conhecida como testemunha. Se o banco de dados principal estiver perdido por qualquer motivo, depois que o banco de dados for sincronizado e se o servidor espelho e a testemunha ainda conseguirem se comunicar, haver um failover automtico. Um failover automtico faz com que o servidor espelho assuma a funo principal e coloque seu banco de dados online como o banco de dados principal. Para obter mais informaes, consulte Failover automtico. Se o local de backup de envio de logs estiver acessvel ao novo servidor principal/primrio, seus trabalhos de backup comearo a enviar backups de log quele local. O modo sncrono do espelhamento de banco de dados garante que a cadeia de logs no seja afetada por um failover de espelhamento, e que somente o log vlido seja restaurado. Os servidores secundrios continuam copiando backups de log sem saber que uma instncia de servidor diferente se tornou o servidor primrio. Ao usar um monitor de envio de logs local, torna-se desnecessria qualquer considerao especial para acomodar esse cenrio. Para obter informaes sobre como usar uma instncia de monitoramento remoto com esse cenrio, consulte "O Impacto do espelhamento de banco de dados em uma instncia de monitoramento remoto", mais adiante neste tpico. Failover do banco de dados principal para o banco de dados espelho A figura a seguir mostra como o envio de logs e o espelhamento de banco dados trabalham juntos quando o espelhamento est sendo executado em modo de alta segurana com failover automtico. Inicialmente, o Server_A o servidor principal do espelhamento e o servidor primrio do envio de logs. O Server_B o servidor espelho, mas tambm est configurado como um servidor primrio, s que inativo no momento. O Server_C e o Server_D so servidores de envio de logs secundrios. Para maximizar a disponibilidade da sesso de envio de logs, o local de backup fica em um diretrio de compartilhamento em um computador host separado.

Depois de um failover de espelhamento, o nome do servidor primrio definido no servidor secundrio permanece inalterado. . O impacto do espelhamento de banco de dados em uma instncia de monitoramento remoto Quando o envio de logs usado com uma instncia de monitoramento remoto, a combinao da sesso de envio de logs e de espelhamento de banco de dados afeta as informaes nas tabelas de monitor. As informaes sobre o primrio formam uma combinao de um configurado no principal/primrio e o monitor configurado em cada secundrio. Para continuar monitorando da maneira mais uniforme possvel, ao usar um monitor remoto, recomendamos que voc especifique o nome primrio original ao configurar o primrio no secundrio. Essa abordagem tambm facilita a alterao da configurao de envio de logs do Microsoft SQL Server Agent. Para obter mais informaes sobre monitoramento, consulte Monitorando envio de logs . Configurando um espelhamento e um envio de logs em conjunto Para configurar um espelhamento de banco de dados junto com um envio de logs, siga as seguintes etapas: 1. Restaure os backups do banco de dados principal/primrio com NORECOVERY em outra instncia de servidor a ser usada posteriormente como banco de dados espelho do espelhamento de banco de dados para o banco de dados principal/primrio. Para obter mais informaes, consulte Preparando um banco de dados espelho para espelhamento. 2. Configure um espelhamento de banco de dados. Para obter mais informaes, consulte Como configurar uma sesso de espelhamento de banco de dados (SQL Server Management Studio) ou Configurando espelhamento de banco de dados.

3.

Restaure os backups do banco de dados principal/primrio para outras instncias do servidor a serem usadas posteriormente como bancos de dados secundrios de envio de logs para o banco de dados primrio. Para obter mais informaes, consulte Implantao do envio de logs.

4.

Configure um envio de logs no banco de dados principal como o banco de dados primrio para um ou mais bancos de dados secundrios. Voc deveria configurar um nico compartilhamento como parte como diretrio de backup (um compartilhamento de backup). Isso garante que depois da troca de funes entre os servidores principal e espelho, os trabalhos de backup continuam gravando no mesmo diretrio que antes. Uma prtica recomendada garantir que esse compartilhamento esteja localizado em um servidor fsico diferente dos servidores que hospedam os bancos de dados envolvidos no espelhamento e no envio de logs. Para obter mais informaes, consulte Como habilitar o envio de logs (SQL Server Management Studio).

5.

Execute o failover manualmente do principal para o espelho. Para executar um failover manual:

6.

Como realizar failover manualmente de uma sesso de espelhamento de banco de dados (SQL Server Management Studio) Como executar failover manualmente em uma sesso de espelhamento de banco de dados (Transact-SQL)

Configure um envio de logs no principal novo (antigo espelho) como sendo o banco de dados primrio.

Importante No execute nenhuma configurao de um secundrio. 7. 8. necessrio usar o mesmo compartilhamento de backup usado na etapa 4. A interface Envio do Log de Transaes no SQL Server Management Studio oferece suporte apenas a um banco de dados primrio por configurao de envio de logs. Portanto, necessrio usar os procedimentos armazenados para configurar o novo principal como primrio. Para obter mais informaes, consulte Como habilitar o envio de logs (Transact-SQL). 9. Execute outro failover manual para failback da entidade original.

Replicao e espelhamento do banco de dadosO espelhamento do banco de dados pode ser usado junto com a replicao para proporcionar disponibilidade ao banco de dados de publicao. O espelhamento do banco de dados compreende duas cpias de um nico banco de dados que geralmente reside em computadores diferentes. Em determinado momento, apenas uma cpia do banco de dados est atualmente disponvel aos clientes. Essa cpia conhecida como o banco de dados principal. As atualizaes realizadas pelos clientes no banco de dados principal so aplicadas outra cpia do banco de dados, conhecida como banco de dados espelho. O espelhamento envolve a aplicao do log de transaes de cada insero, atualizao ou excluso efetuada no banco de dados principal, para o banco de dados espelho. O failover de replicao para um espelho tem o suporte apenas para os bancos de dados de publicao, no tem o suporte do banco de dados de distribuio nem dos bancos de dados de assinatura. Para obter informaes sobre como recuperar um banco de dados de distribuio ou banco de dados de assinatura, sem precisar reconfigurar a replicao, consulte Fazendo backup e restaurando bancos de dados replicados.

Observao Aps um failover, o espelho se torna o principal. Nesse tpico, "principal" e "espelho" sempre se referem ao principal original e ao espelho. Exigncias e consideraes no uso de replicao com espelhamento do banco de dados Esteja atento quanto s exigncias e s consideraes a seguir, quando for usar a replicao com o espelhamento do banco de dados:

O principal e o espelho devem compartilhar um Distribuidor. Recomendamos que esse seja um Distribuidor remoto que oferea tolerncia maior a falhas, caso o Publicador tenha um failover no programado.

O Publicador e o Distribuidor devem ser o MicrosoftSQL Server 2005 ou uma verso posterior. Os Assinantes podem ter qualquer verso, mas as assinaturas pull de replicao de mesclagem de uma verso anterior ao SQL Server 2005 no oferece suporte ao failover; neste caso, o agente executa no Assinante e as verses anteriores do agente no consideram o espelho. A replicao desses Assinantes retomada se ocorrer um failback de banco de dados do espelho para o principal.

A replicao d suporte ao espelhamento do banco de dados de publicao para a replicao de mesclagem e para a replicao de transao com Assinantes somente leitura ou Assinantes de atualizao em fila. No h suporte para Assinantes de atualizao imediata, Publicadores Oracle, Publicadores em uma topologia ponto a ponto e republicao.

Os metadados e os objetos que existem fora do banco de dados no so copiados para o espelho, inclusive logons, trabalhos, servidores vinculados, etc. Se precisar dos metadados e dos objetos no espelho, ser preciso copi-los manualmente. Para obter mais informaes, consulte Administrando logons e trabalhos depois de troca de funes.

Configurando a replicao do espelhamento do banco de dados A configurao da replicao e do espelhamento do banco de dados compreende cinco etapas. Cada etapa est descrita com mais detalhes na prxima seo. 1. 2. 3. 4. 5. Configurar o Publicador. Configurar o espelhamento do banco de dados Configurar o espelho para usar o mesmo Distribuidor como principal. Configurar os agentes de replicao para failover. Adicionar o principal e o espelho ao Replication Monitor.

As Etapas 1 e 2 podem ser realizadas tambm em ordem oposta.

Para configurar o espelhamento de banco de dados para um banco de dados de publicao1. Configure o Publicador: a. Recomendamos o uso de um Distribuidor remoto. Para obter mais informaes sobre como configurar a distribuio, consulte Configurando a distribuio. b. Voc pode habilitar um banco de dados para instantneos e publicaes transacionais e/ou publicaes de mesclagem. Para bancos de dados espelhados com mais de um tipo de publicao, voc dever habilitar os dois tipos de banco de dados no mesmo n, usando sp_replicationdboption. Por exemplo, voc pode executar as chamadas do procedimento armazenado a seguir, no principal:

Copiar Cdigo

exec sp_replicationdboption @dbname='', @optname='publish', @value=true exec sp_replicationdboption @dbname='', @optname='mergepublish', @value=truePara obter mais informaes sobre como criar publicaes, consulte Publicando dados e objetos de banco de dados. 2. Configure o espelhamento do banco de dados Para obter mais informaes, consulte Como configurar uma sesso de espelhamento de banco de dados (SQL Server Management Studio) e Configurando espelhamento de banco de dados. 3. Configure a distribuio para o espelho. Especifique o nome do espelho como Publicador e especifique o mesmo Distribuidor e a pasta de instantneos usada pelo principal. Por exemplo, caso esteja configurando a replicao com procedimentos armazenados, execute sp_adddistpublisher no Distribuidor e, em seguida, execute sp_adddistributor no espelho. Para sp_adddistpublisher:

4.

Defina o valor do parmetro @publisher para o nome de rede do espelho. Defina o valor do parmetro @working_directory para a pasta de instantneos usada pelo principal.

Especifique o nome de espelho para o parmetro de agente -PublisherFailoverPartner. Esse parmetro de agente exigido pelos seguintes agentes para identificar o espelho, aps o failover:

Snapshot Agent (para todas as publicaes) Log Reader Agent (para todas as publicaes transacionais) Queue Reader Agent (para publicaes transacionais que do suporte s assinaturas de atualizao em fila). Merge Agent (para assinaturas de mesclagem) Ouvinte de replicao SQL Server (replisapi.dll: para assinaturas de mesclagem sincronizadas usando a sincronizao da Web) SQL Merge ActiveX Control (para assinaturas de mesclagem sincronizadas com o controle)

O Distribution Agent e o Distribution ActiveX Control no tm esse parmetro porque no se conectam ao Publicador. As alteraes de parmetro de agente entraro em vigor na prxima vez em que o agente for iniciado. Se o agente for executado continuamente, ser preciso interromper e reiniciar o agente. Os parmetros de agente podem ser especificados em perfis de agente e no prompt de comando. Para obter mais informaes, consulte:

Como trabalhar com perfis do Replication Agent (SQL Server Management Studio)

Como exibir e modificar parmetros do prompt de comando de agentes de replicao (SQL Server Management Studio) Como trabalhar com perfis do Replication Agent (Programao Transact-SQL de replicao) Conceitos dos executveis do Replication Agent

Recomendamos adicionar o -PublisherFailoverPartner a um perfil de agente e especificar o nome de espelho no perfil. Por exemplo, se voc estiver configurando uma replicao com procedimentos armazenados:

Copiar Cdigo

-- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles. -- Select the profile id of the profile that needs to be updated from the result set. -- In the agent_type column returned by sp_help_agent_profile: -- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent. exec sp_help_agent_profile -- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1). -- Execute sp_add_agent_parameter in the context of the distribution database. exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'' -- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6). -- Execute sp_add_agent_parameter in the context of the distribution database. exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N''5. Adicione o principal e o espelho ao Replication Monitor. Para obter mais informaes, consulte Como adicionar e remover Publicadores do Replication Monitor (Replication Monitor). Mantendo um banco de dados espelhado Manter um banco de dados de publicao espelhado praticamente o mesmo que manter um banco de dados no espelhado, com as consideraes a seguir:

A administrao e o monitoramento devem ocorrer no servidor ativo. No SQL Server Management Studio, as publicaes aparecem sob a pasta Publicaes Locais, somente para o servidor ativo. Por exemplo, se um failover for realizado no espelho, as publicaes sero

exibidas no espelho; mas no, no principal. Se ocorrer um failover de banco de dados no espelho, talvez seja necessrio atualizar manualmente o Management Studio e o Replication Monitor, para que a alterao seja refletida.

O Replication Monitor exibe os ns do Publicador na rvore de objetos para ambos, o principal e o espelho. Se o principal for o servidor ativo, as informaes da publicao s sero exibidas sob o n principal, no Replication Monitor. Se o espelho for o servidor ativo:

Se ocorrer um erro em um agente, esse erro ser indicado somente no n principal, no no n espelho. Se o principal estiver indisponvel, os ns principal e espelho exibem listas de publicaes idnticas. O monitoramento deve ser realizado nas publicaes sob o n espelho. Ao usar os procedimentos armazenados ou RMO (Replication Management Objects) para gerenciar a replicao no espelho, nos casos em que voc especifica o nome do Publicador, especifique o nome da instncia na qual o banco de dados foi habilitado para a replicao. Para determinar o nome apropriado, use a funo publishingservername. Quando um banco de dados de publicao espelhado, os metadados de replicao armazenados no banco de dados espelhado so idnticos aos metadados armazenados no banco de dados principal. Portanto, para os bancos de dados de publicao habilitados para replicao no principal, o nome da instncia do Publicador armazenado nas tabelas do sistema no espelho ser o nome do principal, no do espelho. Isso afetar a configurao e a manuteno da replicao, em caso de failover do banco de dados de publicao no espelho. Por exemplo, se voc configurar a replicao com procedimentos armazenados no espelho, aps o failover; e deseja adicionar uma assinatura pull a um banco de dados de publicao habilitado no principal, especifique o nome do principal, em vez do nome do espelho para o parmetro @publisher de sp_addpullsubscription ou sp_addmergepullsubscription. Ao habilitar um banco de dados de publicao no espelho, aps o failover para o espelho, o nome da instncia do Publicador, armazenado nas tabelas do sistema, ser o nome do espelho; neste caso, voc usar o nome do espelho para o parmetro @publisher.

Observao Em alguns casos, como o sp_addpublication, o parmetro @publisher tem suporte apenas para os Publicadores no-SQL Server; nesses casos, no relevante para o espelhamento do banco de dados SQL Server.

Para sincronizar uma assinatura no Management Studio, aps o failover: sincronize as assinaturas pull do Assinante e sincronize as assinaturas push do Publicador ativo.

Comportamento da replicao se o espelhamento for removido Considere as questes a seguir, em caso de remoo do espelhamento do banco de dados de um banco de dados publicado:

Se o banco de dados de publicao no principal no estiver mais espelhado, a replicao continuar a funcionar sem alterao no principal original. Se ocorrer um failover de banco de dados de publicao do principal para o espelho, e a relao de espelhamento for subseqentemente desabilitada ou removida, os agentes de replicao no funcionaro com o espelho. Se o principal estiver permanentemente perdido, desabilite e, em seguida, reconfigure a replicao com o espelho especificado como Publicador.

Se o espelhamento do banco de dados for completamente removido, o banco de dados espelho estar em um estado de recuperao e dever ser restaurado para tornar-se funcional. O comportamento do banco de dados recuperado com relao replicao depende da especificao da opo KEEP_REPLICATION. Essa opo fora a operao de restaurao para preservar as configuraes da replicao, quando for restaurar um banco de dados publicado em um servidor que no seja naquele em que o backup foi criado. Use a opo KEEP_REPLICATION somente quando o outro banco de dados de publicao estiver indisponvel. A opo no ter suporte se o outro banco de dados de publicao continuar intacto e replicando. Para obter mais informaes sobre a opo KEEP_REPLICATION, consulte RESTORE (Transact-SQL).

Comportamento do Log Reader Agent A tabela a seguir descreve o comportamento do Log Reader Agent nos vrios modos operacionais do espelhamento do banco de dados. Para obter mais informaes sobre os modos de operao, consulte Configuraes Transact-SQL e modos de operao de espelhamento de banco de dados. Modo de operao Modo de segurana alta com failover automtico Modo de alto desempenho

Comportamento do Log Reader Agent se o espelho estiver indisponvel Se o espelho estiver indisponvel, o Log Reader Agent propagar os comandos no banco de dados de distribuio. O principal no pode realizar o failover no espelho, at que este esteja on-line novamente e tenha todas as transaes do principal. Se o espelho estiver indisponvel, o banco de dados principal estar em execuo exposto (isto , sem espelho). Porm, o Log Reader Agent s replica as transaes que esto intensificadas no espelho. Caso o servio seja forado e o servidor espelho assumir a funo do principal, o Log Reader Agent funcionar no espelho e iniciar a seleo de novas transaes. Para obter mais informaes, consulte Servio forado (com possvel perda de dados). Fique ciente de que a latncia de replicao aumentar, se o espelho ficar atrs do principal. Todas as transaes confirmadas tm a garantia de serem intensificadas em disco, no servidor espelho. O Log Reader Agent s replica as transaes que esto intensificadas no espelho. Se o espelho estiver indisponvel, o principal probe qualquer atividade adicional no banco de dados; portanto, o Log Reader Agent no ter nenhuma transao a ser replicada.

Modo de segurana alta sem failover automtico

Viso geral do espelhamento de banco de dadosO espelhamento de banco de dados uma soluo de software usada, essencialmente, para aumentar a disponibilidade do banco de dados. O espelhamento implementado em uma base por banco de dados e s funciona com bancos de dados que usem o modelo de recuperao completa. Os modelos de recuperao simples e bulk-logged no oferecem suporte ao espelhamento de banco de dados. Por isso, todas as operaes em massa so sempre totalmente registradas. O espelhamento de banco de dados funciona com qualquer nvel de compatibilidade de banco de dados com suporte. Observao No possvel fazer um espelhamento dos bancos de dados mestre, msdb, tempdb ou modelo. O espelhamento de banco de dados mantm duas cpias de um nico banco de dados que devem estar localizadas em instncias do servidor diferentes do Mecanismo de banco de dados do SQL Server. Geralmente, essas instncias do servidor esto em localidades diferentes dos computadores. Uma instncia do servidor atua como banco de dados para clientes (servidor principal). A outra instncia funciona como servidor em espera ativa ou passiva (servidor espelho), dependendo da configurao e do estado da sesso de espelhamento. Quando uma sesso de espelhamento de banco de dados sincronizada, o espelhamento de banco de dados fornece um servidor em espera ativa que oferece suporte rpido a failover , sem que haja perda de dados de transaes confirmadas. Quando a sesso no sincronizada, o servidor espelho fica, normalmente, disponvel como servidor em espera passiva (com possvel perda de dados).

Benefcios do espelhamento de banco de dados O espelhamento de banco de dados uma estratgia simples que oferece os seguintes benefcios:

Aumenta a proteo dos dados. O espelhamento de banco de dados fornece completa ou quase completa redundncia de dados, dependendo se o modo operacional de alta segurana ou de alto desempenho. Para obter mais informaes, consulte "Modos de operao", mais adiante neste tpico. Um parceiro de espelhamento de banco de dados executado no SQL Server 2008 Enterprise ou em verses posteriores tenta resolver automaticamente determinados tipos de erros que impedem a leitura de uma pgina de dados. O parceiro que no est habilitado para ler uma pgina solicita uma cpia atualizada de outro parceiro. Se essa solicitao tiver xito, a pgina ilegvel ser substituda pela cpia. Isso geralmente resolve o erro. Para obter mais informaes, consulte Reparo automtico de pgina durante uma sesso de espelhamento de banco de dados.

Aumenta a disponibilidade de um banco de dados. No caso de desastre, no modo de segurana alta com failover automtico, o failover coloca rapidamente online a cpia do banco de dados em espera (sem perda de dados). Nos outros modos de operao, o administrador do banco de dados tem a possibilidade de forar o servio (com possvel perda de dados) para a cpia do banco de dados em espera. Para obter mais informaes, consulte "Troca de funo mais adiante neste tpico.

Aumenta a disponibilidade do banco de dados de produo durante as atualizaes. Para minimizar o tempo de inatividade de um banco de dados espelhado, atualize de forma seqencial as instncias do SQL Server que participam da sesso de espelhamento de banco de dados. Isso ocasionar o tempo de inatividade de um nico failover. Essa forma de atualizao conhecida como atualizao sem interrupo. Para obter mais informaes, consulte Como instalar um service pack em um sistema com tempo de inatividade mnimo para bancos de dados espelhados.

Como funciona o espelhamento de banco de dados Os servidores principal e espelho comunicam e cooperam entre si como parceiros na sesso de espelhamento de banco de dados. Os dois parceiros executam funes complementares na sesso: a funo principal e a funo de espelho. Em um dado momento, um parceiro executa a funo principal e o outro parceiro executa a funo espelho. Cada parceiro descrito como proprietrio de sua funo atual. O parceiro que possui a funo principal conhecido como servidor principal, e a sua cpia do banco de dados o banco de dados principal atual. O parceiro que possui a funo espelho conhecido como servidor espelho, e a sua cpia de banco de dados o banco de dados espelho atual. Quando o espelhamento de banco de dados implantado em um ambiente de produo, o banco de dados principal o banco de dados de produo. O espelhamento de banco de dados compreende refazer cada operao de insero, atualizao e excluso, que ocorre no banco de dados principal, no banco de dados espelho o mais rpido possvel. Para refazer a operao, envie um fluxo de registros de log de transaes ativo para o servidor espelho, que aplica os registros de log ao banco de dados espelho, na seqncia, com a maior rapidez possvel. Ao contrrio da replicao, que trabalha no nvel lgico, o espelhamento de banco de dados trabalha no nvel do registro de log fsico. A partir do SQL Server 2008, o servidor principal compacta o fluxo de registros do log de transaes antes de envi-lo ao servidor espelho. Essa compactao do log ocorre em todas as sesses de espelhamento. Modos de operao Uma sesso de espelhamento de banco de dados executa com operao sncrona ou assncrona. No modo operacional assncrono, as transaes so confirmadas sem esperar que o servidor espelho grave o log no disco, o que maximiza o desempenho. Na operao sncrona, a transao confirmada em ambos os parceiros, mas custa da latncia de transao aumentada. H dois modos operacionais de espelhamento. Um deles, o modo de segurana alta que oferece suporte operao sncrona. No modo de segurana alta, quando uma sesso iniciada, o servidor espelho sincroniza rapidamente o banco de dados espelho com banco de dados principal. Assim que os bancos

de dados so sincronizados, a transao confirmada em ambos os parceiros, a custa do aumento de latncia da transao. O segundo modo de operao, o modo de alto desempenho, executado assincronamente. O servidor espelho tenta preservar os registros de log enviados pelo servidor principal. O banco de dados espelho pode ficar um pouco defasado em relao ao banco de dados principal. Entretanto, normalmente a defasagem entre os bancos de dados pequena. Porm, a defasagem pode tornar-se significante se o servidor principal estiver com grande carga de trabalho ou se o sistema do servidor espelho estiver sobrecarregado. No modo de alto desempenho, assim que o servidor principal envia um registro de log para o servidor espelho, o servidor principal envia uma confirmao para o cliente. O servidor principal no aguarda uma confirmao do servidor espelho. Isso significa que as transaes so confirmadas sem esperar que o servidor espelho grave o log no disco. Essa operao assncrona habilita o servidor principal para executar com latncia de transao mnima e com grande chance de que alguns dados sejam perdidos. Todas as sesses de espelhamento de banco de dados oferecem suporte somente a um servidor principal e a um servidor espelho. Essa configurao mostrada na ilustrao a seguir.

O modo de segurana alta com failover automtico requer a instncia de um terceiro servidor, conhecido como testemunha. Ao contrrio dos dois parceiros, a testemunha no atende ao banco de dados. A testemunha oferece suporte a failover automtico, verificando se o servidor principal est instalado e funcionando. O servidor espelho apenas iniciar o failover automtico se o espelho e a testemunha permanecerem conectados um ao outro depois de serem desconectados do servidor principal. A ilustrao a seguir mostra uma configurao com testemunha.

Para obter mais informaes, consulte "Troca de funo mais adiante neste tpico. Observao O estabelecimento de uma sesso de espelhamento nova requer que todas as instncias de servidor envolvidas estejam sendo executadas na mesma verso do SQL Server. Entretanto, ao atualizar

para o SQL Server 2008, poder haver variao nas verses das instncias envolvidas. Para obter mais informaes, consulte Como minimizar o tempo de inatividade de bancos de dados espelhados durante a atualizao de instncias do servidor. Segurana de transao e modos de operao O que vai determinar se um modo de operao assncrono ou sncrono a configurao de segurana da transao. Caso somente o SQL Server Management Studio seja usado para configurar o espelhamento de banco de dados, as definies de segurana da transao sero configuradas automaticamente quando o modo de operao for selecionado. Se o Transact-SQL for usado para configurar o espelhamento de banco de dados, ser necessrio saber como definir a segurana de transao. A segurana de transao controlada pela propriedade SAFETY da instruo ALTER DATABASE. Em um banco de dados que est sendo espelhado, SAFETY FULL ou OFF.

Se a opo SAFETY for definida como FULL, a operao de espelhamento de banco de dados ser sncrona, depois da fase de sincronizao inicial. Se a testemunha for definida no modo de segurana alta, a sesso oferecer suporte ao failover automtico.

Se a opo SAFETY for definida como OFF, a operao de espelhamento de banco de dados ser assncrona. A sesso executada em modo de alto desempenho e a opo WITNESS tambm deve ser OFF.

Para obter mais informaes, consulte Configuraes Transact-SQL e modos de operao de espelhamento de banco de dados. Troca de funo No contexto da sesso de espelhamento de banco de dados, as funes principal e espelho podem ser, normalmente, alternadas em um processo conhecido como troca de funo. A troca de funo envolve a transferncia da funo principal ao servidor espelho. Na troca de funo, o servidor espelho funciona como parceiro de failover do servidor principal. Quando ocorre a troca de funo, o servidor espelho assume a funo principal e coloca online a sua cpia do banco de dados, como banco de dados principal novo. O servidor principal anterior, se disponvel, assume a funo de espelho e seu banco de dados se torna o novo banco de dados espelho. Potencialmente, as funes podem ser alternadas de forma repetida. Estas so as trs formas de troca de funo existentes.

Failover automtico Requer modo de segurana alta e a presena do servidor espelho e de uma testemunha. O banco de dados j deve estar sincronizado e a testemunha deve estar conectada ao servidor espelho. A funo da testemunha verificar se um determinado servidor parceiro est instalado e funcionando. Se o servidor espelho perder a conexo com o servidor principal, mas a testemunha ainda estiver conectada, o servidor espelho no iniciar o failover. Para obter mais informaes, consulte Testemunha de espelhamento de banco de dados.

Failover manual Requer modo de segurana alta. Os parceiros devem estar conectados entre si e o banco de dados j deve estar sincronizado.

Servio forado (com possvel perda de dados) Nos modos de alto desempenho e de segurana alta sem failover automtico, possvel forar o servio se o servidor principal falhar e o servidor espelho estiver disponvel.

Importante O modo de alto desempenho destina-se a executar sem uma testemunha. Porm, se existir uma testemunha, forar o servio requer que a testemunha esteja conectada ao servidor espelho.

Em qualquer cenrio de troca de funo, assim que o novo banco de dados principal estiver online, para recuperar rapidamente os aplicativos cliente, reconecte-os ao banco de dados. SQL Server 2008 R2 Enterprise (64 bits) x64 A tabela a seguir mostra os requisitos do sistema do SQL Server 2008 R2 Enterprise (64 bits) x64: Componente Processador Requisito Tipo de processador: Mnimo: AMD Opteron, AMD Athlon 64, Intel Xeon com suporte Intel EM64T, Intel Pentium IV com suporte EM64T Velocidade do processador: Mnimo: 1,4 GHz

Sistema operacional

Recomendvel: 2,0 GHz ou mais rpido Server 2003 SP2 64 bits x64 Datacenter Server 2003 SP2 64 bits x64 Enterprise Server 2003 SP2 64 bits x64 Standard Server 2003 R2 SP2 64 bits x64 Datacenter Server 2003 R2 SP2 64 bits x64 Enterprise Server 2003 R2 SP2 64 bits x64 Standard Server 2008 SP2 64 bits x64 Datacenter Server 2008 SP2 64 bits x64 Datacenter sem Hyper-V Server 2008 SP2 64 bits x64 Enterprise, Server 2008 SP2 64 bits x64 Enterprise sem Hyper-V Server 2008 SP2 64 bits x64 Standard Server 2008 SP2 64 bits x64 Standard sem Hyper-V Server 2008 SP2 64 bits x64 Web 2008 R2 64 bits x64 Datacenter 2008 R2 64 bits x64 Enterprise 2008 R2 64 bits x64 Standard 2008 R2 64 bits x64 Web Server 2008 R2 x64 para Windows Essential Server Solutions

Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows Windows

Memria

RAM: Mnimo: 1 GB Recomendvel: 4 GB ou mais 2 TB (O SQL Server Enterprise Edition d suporte a um mximo de 2 TB de RAM ou o mximo do sistema operacional, sendo considerado o menor valor).

A comunico entre os dois servidores (principal e espelho) ser provida atravs de dois links conectados um appliance firewall/load balancer que por sua vez far o balano de carga para dois servidores web respondendo pela camada de apresentao da aplicao. Cada servidor web far acesso a um servidor de aplicaes, cabendo aplicao do servidor web comutar o acesso ao outro servidor de aplicaes em caso de ausncia de resposta do seu servidor primrio. Ambos servidores de aplicaes estaro acessando um nico gerenciador de banco de dados por questes de integridade. O gerenciador de banco de dados ser replicado em um servidor secundrio, formando um cluster de alta disponibilidade, o qual assumir as transaes em caso de failover do servidor primrio, de forma transparente para a aplicao.