SQL Server

Atingir a alta disponibilidade do SQL Server

Zach Nichter

Visão geral:

• Espelhamento
• Instantâneos de banco de dados
• Envio de log
• Agrupamento
• Replicação

Faça download do código deste artigo: NichterHA2007_03.exe (151KB)

Alta disponibilidade é um conceito que todos os administradores de banco de dados devem entender. Refere-se à prontidão e acessibilidade de um sistema. Às vezes, alta disponibilidade indica um tempo de resposta de segundos enquanto outras situações exigem tempos de respostas em

frações de segundo. Uma vez fiz consultoria em uma empresa onde os servidores da Web exigiam que as consultas do SQL tivessem tempos de resposta de ida e volta em milissegundos; se a resposta ultrapassasse o limite, o sistema do banco de dados era considerado com falha e o servidor da Web deveria ser reconectado no próximo servidor de banco de dados disponível.

Com a exigência de aplicativos cada vez mais rápidos feita pelos usuários, saber como atingir a alta disponibilidade e tempos de resposta rápidos o ajudará a planejar seus aplicativos dependentes de dados de forma adequada.

Felizmente, o SQL Server™ 2005 tem várias opções para melhorar a disponibilidade, incluindo a replicação, o agrupamento, o espelhamento do banco de dados, os instantâneos de bancos de dados e o envio de logs do banco de dados. Irei analisar esses recursos e fornecer algumas informações para que você possa decidir quais são os recursos certos para o seu ambiente. Vamos começar com a Figura 1, que descreve as opções de disponibilidade do SQL Server 2005.

Figure 1 Opções de alta disponibilidade

Definição de alta disponibilidade

Um de seus primeiros objetivos ao planejar um aplicativo de alta disponibilidade é definir o que isso significa em seu ambiente específico. Para algumas organizações, alta disponibilidade indica que deve haver um hardware redundante igual ao hardware de produção, o que requer que os dados e o hardware tenham duração e disponibilidade de 99,995% ou mais. Outras organizações podem exigir que apenas os dados propriamente ditos tenham alta disponibilidade, sem tanta preocupação com o desempenho do nível de produção caso um failover seja necessário. Definir a alta disponibilidade é importante para determinar a solução correta para sua situação.

Também é necessário identificar os tipos de interrupções que podem ocorrer e indicar como isso afeta seus SLAs (Contratos de nível de serviço). As interrupções que podem afetar a disponibilidade incluem o desempenho planejado, não planejado e degradado.

Uma interrupção planejada normalmente é uma janela de manutenção programada sobre a qual os usuários dos sistemas são informados com antecedência. Uma interrupção não planejada geralmente resulta de uma falha de hardware ou software que torna os dados inacessíveis. A degradação do desempenho também pode provocar interrupções e normalmente é medida no tempo de resposta do usuário final, que em geral faz um acordo com antecedência com os negócios e a organização de TI através de algum tipo de SLA.

Além de identificar possíveis fontes de interrupção, também é necessário determinar o nível de atividade dos dados e ser estes devem estar sempre online ou podem ficar quase na linha ou offline ocasionalmente. Decida também se a opção de disponibilidade estará no mesmo local geográfico ou em um local remoto. Os limites do orçamento provavelmente influenciarão em sua decisão final. Agora, vamos analisar cada opção de disponibilidade.

Espelhamento do banco de dados

Antes de mergulharmos no espelhamento do banco de dados, vamos definir a terminologia.

Principal é o servidor de produção principal que hospeda o banco de dados que envia os logs de transação continuamente para o servidor de espelhamento e o banco de dados.

Espelhamento é o servidor secundário que hospeda a cópia de backup do banco de dados. A cópia de espelhamento é sincronizada de modo consistente com o banco de dados principal.

Função indica a finalidade do servidor específico, se este atua como principal ou espelhamento.

Testemunha é a instância que monitora os servidores principal e de espelhamento à medida que realizam suas obrigações e pode iniciar um failover automático.

Parceiro pode ser o servidor principal ou o de espelhamento.

Em um ambiente típico, será feito um backup do banco de dados principal na instância principal e o backup será restaurado na instância de espelhamento (consulte a Figura 2). Após o banco de dados ser restaurado, o espelhamento deve ser configurado no servidor principal com a janela de propriedades do banco de dados principais no SQL Server Management Studio (SMSS) ou com os scripts T-SQL.

Figure 2** Database mirroring architecture **(Clique na imagem para aumentar a exibição)

Após a configuração do espelhamento e o estabelecimento da sessão de espelhamento, os bancos de dados principal e espelhado serão sincronizados. O banco de dados principal enviará os logs de transação dos eventos ocorridos desde que o último backup foi aplicado no espelhamento. O espelhamento receberá o log e tentará aplicá-lo o mais rápido possível. Se estiver usando o SQL Server 2005 Enterprise Edition, esse processo terá vários threads; caso contrário, será uma operação de um único thread. Assim que os logs são aplicados no espelhamento, os bancos de dados são considerados sincronizados e permanecerão sincronizados até a sessão espelhada ser rompida.

Conforme os clientes executam novas transações, o servidor principal executa as transações no banco de dados principal e, ao fazer isso, envia os registros de log de transação do banco de dados principal para o log de retrabalho ou consultas de log do banco de dados espelhado, onde são selecionados e aplicados no banco de dados espelhado. Após a transação ser aplicada e confirmada no banco de dados de espelhamento, uma resposta é enviada ao principal anunciando que a transação foi confirmada no espelhamento. O principal não confirmará nenhuma transação nova que pode vir ao sistema até que o espelhamento reconheça o recebimento.

Em caso de falha, o espelhamento pode iniciar uma falha automática e a testemunha suporta processo determinando se o banco de dados principal está disponível. Quando a falha ocorre, o problema sobre o conteúdo do parceiro de espelhamento deve ser resolvido antes de se tornar novamente o parceiro principal. Após solucionar os problemas no parceiro de espelhamento, a volta ao servidor-parceiro de espelhamento é iniciada e os bancos de dados são sincronizados novamente. Após a sincronização, a sessão de espelhamento pode ser reiniciada.

Esse modo de espelhamento específico é um modo de alta segurança que fornece operações transacionais síncronas ativando a segurança transacional, mas um servidor-testemunha não é necessário já que não aproveita o failover automático; todos os failovers são iniciados manualmente. Há outro tipo de modo de espelhamento que fornece operações transacionais síncronas, o modo de alta disponibilidade. Esse modo requer não só a ativação da segurança transacional, mas também uma testemunha usada para failovers automáticas em caso de falha.

O terceiro e último modo disponível de espelhamento é o de alto desempenho. Esse modo requer a desativação da segurança transacional, permitindo o suporte operacional assíncrono que, por usa vez, permite a confirmação das transações no parceiro principal sem precisar aguardar a gravação do registro da transação no espelhamento. O modo de alto desempenho não requer um servidor-testemunha da configuração.

Observe que o espelhamento requer a mesma edição do SQL Server no principal e no espelhamento, mas não no testemunha, que pode ser o SQL Server Express Edition. Além disso, é importante que o banco de dados principal esteja no modo de recuperação total.

O ADO.NET 2.0 é integrado no SQL Server 2005 e inclui a capacidade de oferecer suporte ao espelhamento do banco de dados e fornecer um failover transparente para o aplicativo no ambiente espelhado. Isso permite que o aplicativo ADO.NET realize o failover automaticamente sem nenhuma codificação ou configuração adicional caso não seja possível estabelecer uma conexão com o banco de dados principal. A configuração é tão fácil quanto especificar um usuário comum entre os dois ambientes e o parceiro de failover na cadeia de conexão. O exemplo a seguir mostra uma seqüência de conexão do ADO.NET identificando o parceiro de failover para o ambiente do banco de dados espelhado:

"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
 Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"

O espelhamento do banco de dados é uma boa opção para sua empresa dependendo dos requisitos de aplicativos e de dados, mas você deve considerar algumas coisas para obter o desempenho ideal. Por exemplo, qual é a taxa de transação do sistema ou o volume de alteração de dados? Ao considerar o espelhamento do banco de dados, é fundamental determinar se a largura de banda e a velocidade da rede são suficientes para manipular o volume de dados e a taxa de processamento da transação. Além disso, considere a saturação do link. Isso é importante especialmente se o espelhamento estiver em um local geográfico diferente. O monitoramento prévio do sistema é fundamental para determinar se há algum limite ambiental que pode impedir a operação eficaz do espelhamento.

O espelhamento do banco de dados pode ser uma boa opção especialmente se estiver tentando manter os custos baixos. De fato, a arquitetura do espelhamento do banco de dados não requer nenhum disco compartilhado e nenhum recurso avançado ou especializado para executar o ambiente. E, diferente do agrupamento, o espelhamento do banco de dados não requer que os dois parceiros tenham o mesmo hardware. Além disso, é muito simples implementar o espelhamento usando o assistente de configuração encontrado na guia de espelhamento da janela de propriedades do banco de dados (consulte a Figura 3). Também recomendo a leitura do white paper “Práticas recomendadas do espelhamento do banco de dados e considerações sobre desempenho” em go.microsoft.com/fwlink/?LinkId=80897 para obter informações mais úteis.

Figure 3** Mirroring setup wizard **(Clique na imagem para aumentar a exibição)

Instantâneos de bancos de dados

Os instantâneos de bancos de dados são uma nova tecnologia oferecida no SQL Server 2005 Enterprise Edition, mas não são considerados opções de alta disponibilidade. Esses instantâneos devem ser usados como uma opção viável de recuperação ou criação de relatórios quando usados com outras tecnologias. Um instantâneo é simplesmente uma exibição somente leitura de um banco de dados em um momento específico.

O instantâneo é criado com um comando CREATE DATABASE como esse:

CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME = 
    'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO

Quando o instantâneo do banco de dados é criado, usa um ou vários arquivos chamados de arquivos esparsos em vez dos arquivos de dados como um banco de dados típico faria. Esses arquivos esparsos são basicamente locais de hospedagem virtual que, a princípio, não consomem nenhum dado. São usados para preservar dados apenas se os dados forem alterados ou excluídos do banco de dados de origem. Os dados são gravados nos arquivos esparsos, uma página de dados por vez, e o instantâneo do banco de dados real exibe apenas os dados que foram alterados desde que o instantâneo foi criado. O resto dos dados vem das páginas de dados do banco de dados de origem.

Os arquivos de instantâneo do banco de dados têm o tamanho do banco de dados quando o instantâneo foi criado. O tamanho alocado não informa quantos dados realmente estão preservados. Para obter essa informação, execute uma instrução T-SQL como essa:

SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
    2030'), 1);
GO

Devido à maneira de armazenamento dos dados nos arquivos esparsos e no banco de dado de origem, quando um instantâneo do banco de dados é acessado, as páginas de dados dos arquivos do banco de dados original e as páginas dos arquivos esparsos do instantâneo são recuperadas. Os instantâneos podem residir apenas no servidor com o banco de dados de origem do qual o instantâneo foi criado devido à necessidade de compartilhar páginas de dados. Como essa arquitetura não ajuda a E/S no banco de dados de origem, os instantâneos não são uma opção válida de criação de relatórios a ser usada visto que não representam o verdadeiro estado do banco de dados.

Considere um cenário no qual o espelhamento no banco de dados é usado com instantâneos. Isso permite que os dados de relatório, o espelhamento e os bancos de dados do instantâneo sejam separados fisicamente do banco de dados principal. O instantâneo do banco de dados é programado com o SQL Server Agent e um script personalizado para fornecer instantâneos atualizados em intervalos regulares. O script de exemplo da Figura 4 mostra o procedimento armazenado usado para realizar isso. Esse script foi desenvolvido para ser usado dentro de um trabalho para gerenciar a criação e a eliminação de instantâneos de um banco de dados específico em seu ambiente. Isso possibilitaria uma solução aceitável de criação de relatórios porque os dados de relatório seriam isolados dos dados de produção.

Figure 4 Procedimento armazenado para a programação de instantâneos

use msdb;
GO
set nocount on
GO

CREATE PROCEDURE usp_snaprefresh 
     @database    sysname = NULL    --name of the database to snapshot
    ,@keepsnap    int        = 24   --# of hours to keep a snapshot 
                                    --after it was created 
                                    --use a value of '0' to keep all
                                    --existing snapshots
    ,@fileloc    sysname            --location for snapshot
        = 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'    
AS

DECLARE 
     @dt            datetime        ,@cnt          int
    ,@databaseid    int             ,@snap         sysname
    ,@sql           nvarchar(1000)  ,@yy           varchar(4)
    ,@mm            varchar(2)      ,@dd           varchar(2)
    ,@h             varchar(2)      ,@m            varchar(2)
    ,@lname         sysname         ,@pname        sysname
    ,@file          sysname         ,@pos1         int
    ,@pos2          int

-- initialize variables
SELECT 
     @dt = getdate()
    ,@cnt = 0, @pos1 = 0, @pos2 = 0
    ,@databaseid = db_id(@database)

-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
    RAISERROR ('Missing database name. Rerun the procedure specifying a
       valid database name.',16,1)
    RETURN (0) 
END

--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
    -- determine if other snapshots exist for this server older than @
    -- keepsnap value hrs
    SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum], 
        name INTO #t1 
    FROM master.sys.databases 
    WHERE source_database_id = @databaseid
        AND create_date < dateadd(hh,-(@keepsnap),getdate())

    IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
    BEGIN
        WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
        BEGIN
            SELECT @snap = name FROM #t1 WHERE RowNum = @cnt

            PRINT 'Dropping snapshot ''' + @snap + ''''

            SET @sql = 'DROP DATABASE ' + @snap

            EXEC(@sql)
            SELECT @cnt = @cnt + 1
        END
    END
END

-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
   month(@dt))
    ,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
         datepart(hh,@dt)) 
    ,@m = convert(varchar(2), datepart(mi,@dt))

-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m

-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files 
WHERE file_id = 1'

EXEC(@sql)

--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1

-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
    SET @fileloc = @fileloc + '\'
END

-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database

EXEC(@sql)

-- cleanup
DROP TABLE tempdb..t1;
GO

No entanto, tenha em mente que os instantâneos de bancos de dados são considerados temporários porque não é possível fazer um backup desses instantâneos e eles não podem existir sem o banco de dados de origem. Se o arquivo esparso não tiver espaço, o instantâneo será considerado corrompido e deve ser eliminado.

Além disso, com os instantâneos do banco de dados, o desempenho do sistema pode ser degradado durante as operações de modificação de dados no banco de dados de origem porque as páginas de dados estão sendo gravadas no arquivo esparso de cada instantâneo dos arquivos de dados do banco de dados de origem. Isso, por sua vez, multiplica o número de gravações pelo número de instantâneos que um banco de dados tem.

As permissões de leitura são definidas pelo banco de dados de origem no ponto do instantâneo e não podem ser alteradas. O instantâneo deve residir na mesma instância do banco de dados de origem devido ao compartilhamento das páginas de dados e ao mesmo cache de buffer.

Avalie a possibilidade de usar os instantâneos como uma solução de criação de relatórios apenas se o espelhamento também estiver sendo usado; caso contrário, não haverá nenhum ganho de desempenho para o seu ambiente. Os instantâneos de bancos de dados são possivelmente a maneira mais rápida de preservar dados antes que uma operação questionável seja executada no sistema. Um banco de dados pode regressar ao estado do instantâneo ou os dados podem ser excluídos do instantâneo para substituir os dados no banco de origem.

É necessário determinar um padrão de nomeação para os bancos de dados do instantâneo. O padrão que eu uso é originaldatabasename_date_time.snp. Esse padrão especifica primeiramente o banco de dados de origem e, em seguida, o dia e a hora (no formato 24 horas) em que o instantâneo foi criado.

Envio de log

O envio de log é uma opção de alta disponibilidade limitada que utiliza o backup e a recuperação para estabelecer uma solução bem barata. O envio de log aproveita os backups de logs de transação em um intervalo programado para manter um banco de dados secundário atualizado.

O envio de log no SQL Server 2005 usa assistentes para percorrer o processo de configuração, programação, inicialização e monitoramento (consulte a Figura 5). O processo é simples e pode ser concluído em alguns minutos.

Figure 5** Log shipping setup wizard **(Clique na imagem para aumentar a exibição)

Após a identificação do banco de dados primário, uma programação é criada e a idade do arquivo determinada para os arquivos de backup. Em seguida, é necessário estabelecer os compartilhamentos de arquivo para os arquivos de backup. Após a configuração dos compartilhamentos, o local do arquivo do banco de dados secundário deve ser estabelecido e o banco de dados deve ser inicializado concluindo a restauração do banco de dados primário. Finalmente, as programações devem ser definidas para as cópias do arquivo de backup e os backups de logs de transação devem ser restaurados, junto com os alertas ou atrasos necessários para cada etapa.

Quando a configuração está concluída, o envio de log faz o backup do log de transação de um banco de dados em um intervalo programado, em um local de rede compartilhado. Após os arquivos serem enviados para o compartilhamento, o backup é ativado no banco de dados secundário em uma programação definida.

O envio de log funciona bem em muitas situações devido a sua simplicidade. É uma boa opção de alta disponibilidade que é barata e pode manipular um sistema de altas transações. O banco de dados secundário empregado no envio de log pode ser usado no modo somente leitura, o que é útil para um banco de dados de criação de relatórios. O envio de log requer uma sobrecarga mínima, mas precisa de uma diretriz de alertas para a manipulação de falhas.

Algumas coisas devem ser consideradas se você estiver pensando em usar o envio de log em seu ambiente, são elas: a configuração e o gerenciamento simples e o fato de poucos ou nenhum recurso especializado serem necessários. O envio de log não é uma solução de alta disponibilidade em tempo real; no entanto, é possível combiná-lo com o espelhamento do banco de dados para essa finalidade. É limitado por programações e operações, como backups, cópias de arquivos e restaurações. Também requer o failover manual. Por esses motivos, o envio de log fornece uma solução simples para o ambiente que não é tão sensível aos requisitos de tempo.

Agrupamento do SQL Server

O agrupamento do servidor funciona no nível do sistema operacional e envolve hardwares duplicados, bem como recursos do disco compartilhado para o acesso do cluster. O agrupamento talvez seja a opção menos intrusiva para os usuários finais, mas provavelmente também é a mais cara. Requer pelo menos a quantia de hardware necessária para executar uma instância não agrupada.

O tópico de agrupamento é bastante discutido e, em vez de explorar todos os detalhes aqui, farei uma breve visão geral. O agrupamento requer dois ou mais servidores e ambos devem ser instalados com a mesma versão do Windows® 2000, edições Advanced ou Datacenter ou do Windows Server® 2003, edições Enterprise ou Datacenter. Também requer a instalação do Microsoft® Cluster Services (MSCS), que trata da propriedade do recursos compartilhados entre os servidores e gerencia endereços IP, discos compartilhados e nomes de rede. O agrupamento também requer um recurso de disco compartilhado, normalmente na forma de uma SAN (Rede de área de armazenamento) ou do armazenamento SCSI conectado.

Uma instância do SQL Server também é considerada um recurso e as edições Standard e Enterprise do SQL Server 2005 podem ser instaladas em uma configuração em cluster. Consulte o artigo “Feature Comparison Chart for SQL Server 2005”, em microsoft.com/sql/prodinfo/features/compare-features.mspx, para obter uma lista dos recursos suportados pelas duas edições do SQL Server 2005.

Após o estabelecimento dos recursos no cluster, o nó secundário e do cluster mantém uma comunicação regular com o nó primário do cluster através de uma pulsação estabelecida em uma rede privada entre os dois nós do cluster. A pulsação é um ponto de verificação de intervalo criado para determinar se o primário falhou.

Caso o primário falhe, os recursos serão movidos para o nó secundário, mas o estado do servidor lógico será mantido. Isso permite que os clientes continuem funcionando com apenas uma pausa na interação. O processo inteiro de failover pode ocorrer entre 5 ou 30 segundos ou mais em alguns casos, dependendo do hardware, do software e dos componentes de rede envolvidos no cluster.

O agrupamento pode ser uma tecnologia cara e complexa que requer recursos especializados para resolver falhas do sistema; no entanto, fornece o failover mais uniforme para os usuários finais de qualquer opção de failover automático. Cada aplicativo é diferente e alguns talvez não reconheçam ou sejam compatíveis com cluster, o que requer a reconexão do aplicativo em ambientes desfavoráveis.

Replicação

A replicação do SQL Server 2005 também pode ser usada em arquiteturas de alta disponibilidade. Há quatro tipos de replicação: de instantâneos, transacional, ponto a ponto e mesclagem. Na realidade, ponto a ponto é apenas uma forma de replicação transacional que não irei discutir aqui.

Com a replicação, é possível que um local secundário e o banco de dados de alta disponibilidade em que cada bit é tão funcional quanto no banco de dados primário. Isso pode ser realizado com a replicação de mesclagem, que toma as transações dos bancos de dados primário e secundário e as mesclas e altera entre si. Como você pode imaginar, um procedimento de resolução de conflitos é necessário nessa configuração.

A replicação transacional é muito similar ao design lógico do espelhamento do banco de dados. As transações aplicadas no banco de dados primário são enviadas para o banco de dados secundário a fim de assegurar que o ambiente permaneça consistente. Assim que chegam, as transações são aplicadas no banco de dados secundário, que aguarda a aplicação da próxima transação no sistema.

A replicação de instantâneos é muito similar ao envio de log, pois ambos são executados em intervalos programados e atualizam o banco de dados secundário em alterações de massa em vez de aplicar cada transação nos dois sistemas assim que são confirmadas. As duas tecnologias são utilizadas da mesma maneira em muitos aspectos.

A replicação requer um conhecimento especializado, o que é uma grande preocupação para os ambientes que não contam com um administrador de banco de dados dedicado. A replicação pode ser um pouco complexa na solução de problemas e não requer um design mais envolvido se não for usado como uma opção de alta disponibilidade.

A replicação pode preencher adequadamente todos os requisitos de uma solução de alta disponibilidade. Essa tecnologia faz o que o espelhamento do banco de dados pode fazer no nível do registro usando a replicação transacional, mas sem a opção de failover automático. Supondo que você tenha recursos suficientes e um pouco de criatividade, criar scripts de uma solução para um failover automático não deve ser impossível.

Diferente do espelhamento do banco de dados, os bancos de dados de origem e de destino são totalmente acessíveis para os aplicativos cliente. A replicação fornece a mesma funcionalidade do envio de log com o uso da replicação de instantâneos.

No entanto, é preciso levar em conta que a tecnologia de replicação é uma batalha comprovada e bem documentada. Usar a replicação para uma solução de alta disponibilidade tem alguns problemas e o desempenho pode ser uma preocupação, mas apenas tanto quanto o espelhamento do banco de dados. Qualquer solução de alta disponibilidade projetada com replicação provavelmente terá uma arquitetura mais complicada de gerenciar; não necessariamente mais avançada, mas definitivamente mais envolvida. Além disso, um dos maiores obstáculos a considerar é o fato de que se a estrutura de tabelas do banco de dados for alterada ou se desejar adicionar uma tabela para ser replicada, é necessário quebrar e redefinir a publicação para finalizar as alterações nos dois bancos de dados.

Conclusão

Agora, você pôde ver como a criação de uma solução de alta disponibilidade para seu ambiente requer um toque de criatividade. Cada tecnologia de alta disponibilidade do SQL Server 2005 tem suas vantagens e desvantagens e leva a situações diferentes.

O envio de log, a replicação de instantâneos e até mesmo o espelhamento do banco de dados no modo de alto desempenho seriam bons quando separassem geograficamente um banco de dados primário da Web dos ambientes do banco de dados secundário (especialmente se os dados secundários não tiverem que ser disponibilizados em tempo real).

Se, por outro lado, o banco de dados secundário exigir dados em tempo real, a replicação transacional ou o espelhamento do banco de dados pode levar a carga se as taxas de transação do servidor primeiro forem baixas e o link entre os dois locais do ambiente for rápido e não saturado.

Considere também seu nível de conforto com estas tecnologias. Se você já tiver experiência com algumas tecnologias, provavelmente não haverá problemas. Se você for um gerente com nenhum administrador de banco de dados dedicado, tente esclarecer as tecnologias mais complexas como a replicação, na qual existe muita movimentação de partes e a resolução de problemas pode ser complexa. Avalie a possibilidade de contratar um consultor experiente de SQL Server para ajudá-lo a projetar, implementar e possivelmente treinar sua equipe para gerenciar uma nova solução de alta disponibilidade adequada para seu ambiente.

Se a alta disponibilidade em sua organização requer apenas a disponibilidade dos dados, uma alta porcentagem de tempo e de inatividade dos dados é um fator grave e o agrupamento pode ser a solução.

A conclusão de tudo isso é que o SQL Server 2005 tem fornecido várias opções novas para a implementação de alta disponibilidade, feitas sob medida para atender diferentes tipos de ambiente. Uma única opção de disponibilidade pode satisfazer suas necessidades ou você pode aproveitar uma combinação de tecnologias. Como você sabe, existem várias opções disponíveis.

Zach Nichter é um profissional de SQL Server com mais de 10 anos de experiência. Ele tem assumido várias funções de suporte do SQL Server, incluindo administrador de banco de dados, chefe de equipe, gerente e consultor. Atualmente, Zach trabalha na Levi Strauss & Co. como o arquiteto do banco de dados, enfocando o desempenho, o monitoramento, a arquitetura e outras iniciativas estratégicas do SQL Server.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..