Exportar (0) Imprimir
Expandir Tudo
Este tópico ainda não foi avaliado como - Avalie este tópico

Continuidade dos negócios no Banco de dados SQL do Windows Azure

Este artigo descreve os recursos de continuidade de negócios fornecidos pelo Banco de dados SQL do Windows Azure. Ele também inclui informações sobre a tolerância a falhas interna que dá suporte à alta disponibilidade dos aplicativos do SQL Database

Os problemas de continuidade dos negócios podem estar incluídos em uma das seguintes categorias principais:

  • Falha de servidores ou dispositivos individuais ou de conectividade na rede

  • Corrupção, modificação indesejada ou exclusão de dados

  • Perda generalizada de instalações de data center

O propósito de criar backups de bancos de dados é permitir a recuperação da perda de dados causada por tais problemas. Fazer backup e restaurar dados no Banco de dados SQL do Windows Azure são processos diferentes dos que ocorrem em um SQL Server local e devem funcionar com os recursos e as ferramentas disponíveis. Para obter uma visão geral sobre as opções de backup e restauração fornecidas pelo Banco de dados SQL do Windows Azure, consulte Backup e restauração do banco de dados SQL do Windows Azure. As seções a seguir explicam como o Banco de dados SQL do Windows Azure trata essas categorias para ajudar a proporcionar continuidade dos negócios:

Os serviços do SQL Database no Windows Azure fornecem recursos internos de tolerância a falhas. Para ajudar a proteger seu banco de dados das exclusões ou modificações indesejadas ou contra falhas generalizadas de instalações do data center, exige o desenvolvimento de uma estratégia de continuidade de negócios. Esses recursos e essas estratégias são descritas nas seções abaixo.

Como ajudar a proteger seu banco de dados contra falhas de servidores e dispositivos individuais

Ao armazenar seus dados no Banco de dados SQL do Windows Azure, você está aproveitando as vantagens de muitos recursos de tolerância a falhas e infraestrutura segura que, de outra forma, precisaria projetar, adquirir, implementar e gerenciar. Esta seção aborda o que o Banco de dados SQL do Windows Azure faz para você sem despesas adicionais.

Redundância da infraestrutura

O Banco de dados SQL do Windows Azure reduz as interrupções causadas por falhas de dispositivos individuais, como unidades de disco rígido, adaptadores de interface de rede ou até servidores inteiros. Para melhorar a durabilidade dos dados e a tolerância a falhas, são mantidas várias cópias de todos os dados em diferentes nós físicos localizados em subsistemas físicos totalmente independentes, como racks de servidores e roteadores de rede. A qualquer hora, o Banco de dados SQL do Windows Azure mantém três réplicas dos dados em execução – uma réplica primária e duas réplicas secundárias. O Banco de dados SQL do Windows Azure usa um esquema de confirmação baseado em quorum, onde os dados são gravados na réplica primária e em uma réplica secundária antes que a transação seja considerada confirmada. Se o hardware falhar na réplica primária, o Banco de dados SQL do Windows Azure detectará a falha e fará o failover para a réplica secundária. No caso de uma perda física da réplica, o Banco de dados SQL do Windows Azure cria uma nova réplica automaticamente. Portanto, existem pelo menos duas cópias físicas transacionalmente consistentes dos dados no data center. O diagrama a seguir ilustra como o Banco de dados SQL do Windows Azure mantém três réplicas nos racks de servidores físicos no data center.

Racks de servidores físicos em um data center

Além das réplicas redundantes, o Banco de dados SQL do Windows Azure mantém cópias internas dos seus dados dos últimos 14 dias para todos os seus bancos de dados do data center. Essas cópias oferecem uma proteção contra falhas de hardware e do sistema simultâneas ou catastróficas, mas não estão disponíveis aos clientes. Recomendamos que você implemente suas próprias soluções de backup e restauração conforme é descrito nas seções a seguir.

Observações importantes

  • O objetivo é que as falhas no data center não resultem em perda de dados, mas elas resultarão em desconexões temporárias e falhas de transações.

  • Seu aplicativo deve ser resistente às desconexões temporárias. Recomendamos que você implemente a lógica de repetição em seu aplicativo para evitar perdas de conexão. Para obter mais informações sobre como solucionar os erros de perda de conexão, consulte o artigo Gerenciamento de conexões no SQL Database no TechNet Wiki.

  • No momento, não fornecemos um SLA para o RPO (objetivo de ponto de recuperação) e o RTO (objetivo de tempo de recuperação) normais. Para obter mais informações sobre Contratos de Nível de Serviço do Windows Azure, consulte Contratos de Nível de Serviço.

Como ajudar a proteger seu banco de dados contra exclusões ou modificações indesejadas

Usuários ou aplicativos podem fazer alterações indesejadas nos dados. Isso pode exigir uma operação de reversão. Por exemplo, um usuário poderia modificar alguns dados do cliente errado. A capacidade de restaurar dados de aplicativos no caso de corrupção ou de uma modificação ou exclusão indesejada é um requisito fundamental para aplicativos de software. Recomendamos que você implemente os métodos a seguir a fim de implementar backups para instâncias do Banco de dados SQL do Windows Azure.

As cópias de banco de dados podem ser usadas como uma opção de backup e restauração para ajudar a proteger seu banco de dados conforme descrito nas seções abaixo:

noteObservação
Para obter uma visão geral sobre as opções de backup e restauração fornecidas pelo Banco de dados SQL do Windows Azure, consulte Backup e restauração do banco de dados SQL do Windows Azure.

Cópias de bancos de dados

Para criar uma cópia separada do seu Banco de dados SQL do Windows Azure, execute um comando Transact-SQL para criar uma cópia do banco de dados periodicamente e, em seguida, gerenciar essas cópias. Execute a instrução Transact-SQL CREATE DATABASE com a cláusula AS COPY OF para criar uma cópia independente do seu banco de dados no Banco de dados SQL do Windows Azure. Observe que uma operação de cópia pode demorar muito tempo, às vezes horas, dependendo da carga de trabalho no data center, da quantidade de carga de trabalho em execução no banco de dados original sendo copiado e do tamanho do banco de dados original sendo copiado.

O exemplo de código a seguir demonstra como executar uma cópia de banco de dados usando a instrução Transact-SQLCREATE DATABASE (Banco de Dados SQL do Windows Azure).

CREATE DATABASE destination_database_name AS COPY OF [source_server_name].source_database_name

Você pode criar uma cópia do seu banco de dados em outro servidor do Banco de dados SQL do Windows Azure, mas o servidor deve estar no mesmo data center. Uma operação de cópia pode ser demorada, mas a cópia final do seu banco de dados de destino estará transacionalmente consistente com o banco de dados original quando o processo de cópia for concluído. Por exemplo, se você iniciar um processo de cópia às 14:00 na notação de 24 horas, o Banco de dados SQL do Windows Azure imediatamente criará a nova cópia com base no backup do sistema feito mais próximo das 14:00. Observe que isso não seria mais do que 5 minutos antes das 14:00. O Banco de dados SQL do Windows Azure replicará as transações confirmadas no banco de dados de origem para o banco de dados de destino até que o banco de dados de destino alcance o banco de dados de origem. Uma vez que o banco de dados de destino esteja em dia, a operação de cópia é considerada concluída e o link de replicação entre a origem e o destino é desfeito, deixando o novo banco de dados de destino isolado de quaisquer alterações futuras no banco de dados de origem. Neste ponto, o novo banco de dados de destino se torna acessível. Como exemplo, vamos supor que o processo de cópia de banco de dados leve várias horas para ser concluído. O processo de cópia de banco de dados espelhará o banco de dados de origem no momento em que a operação de cópia for concluída. Portanto, ao pensar na restauração como um mecanismo de recuperação de qualquer erro do usuário em um momento determinado, você deve saber que, se o erro do usuário ocorrer enquanto a operação estiver em andamento, o erro também será replicado no banco de dados de destino.

Além de permitir um processo de recuperação mais simples, como a manutenção da cadeia de conexão original, a cópia do banco de dados para um servidor diferente não oferece a você nenhuma proteção adicional contra desastres. O servidor do Banco de dados SQL do Windows Azure é um servidor lógico e, embora o banco de dados de origem e o de destino possam estar agrupados no mesmo servidor lógico, os dois bancos de dados não estão necessariamente localizados fisicamente no mesmo computador. Além disso, quando você considera as duas réplicas secundárias para os bancos de dados de origem e destino, a probabilidade de colocalização física das 6 cópias diferentes se torna remota. Em resumo, a cópia para um servidor lógico separado não oferece a você nenhuma proteção mais forte.

Depois que a cópia de banco de dados começar, você poderá consultar as exibições sys.databases (Banco de Dados SQL do Windows Azure) e sys.dm_database_copies (Banco de Dados SQL do Windows Azure) no banco de dados master do servidor de destino para recuperar mais informações sobre o andamento da cópia.

SELECT [databases].[name], [copies].* 
FROM sys.dm_database_copies copies 
JOIN sys.databases databases 
ON copies.database_id = databases.database_id

A frequência na qual você escolhe copiar seu banco de dados pode variar e depende das necessidades comerciais. Para a recuperação de erros de usuários ou aplicativos, recomendamos que você crie uma cópia diariamente e mantenha duas ou três cópias em execução na base do revezamento removendo a cópia mais antiga todos os dias após uma nova cópia completa.

Observe que, embora a nossa recomendação seja fazer cópias diárias, você poderá copiar seu banco de dados com mais frequência. Recomendamos que você execute uma operação de cópia de banco de dados, no máximo, uma vez por hora, já que cada processo de cópia pode terminar em horários diferentes, mas cada um é transacionalmente consistente com o banco de dados de origem no momento em que a cópia é concluída. Se você iniciar duas cópias de banco de dados com um intervalo de 5 minutos, ambas poderão terminar quase ao mesmo tempo. Isso cria uma cópia de banco de dados idêntica e você seria cobrado pela mesma cópia (ou semelhante) dos dados duas vezes.

Para obter mais informações sobre a cópia de bancos de dados, consulte Copiando bancos de dados no Banco de dados SQL do Windows Azure.

Restauração de cópia de banco de dados

Você pode implementar a restauração do seu banco de dados e a respectiva cópia no mesmo servidor renomeando-os. Por exemplo, considere um banco de dados denominado “Database1”e uma cópia “Database1_copy_02_01_2012”. O script Transact-SQL a seguir demonstra como trocar os nomes dos bancos de dados no mesmo servidor quando um banco de dados de origem e sua cópia são chamados “Database1” e “Database1_copy_02_01_2012”, respectivamente. Após a execução bem-sucedida do script, o tráfego do banco de dados é direcionado para a cópia, e não para o banco de dados original.

ALTER DATABASE Database1 
MODIFY NAME = Database1_OLD
GO
WAITFOR DELAY '00:00:30'
GO
ALTER DATABASE Database1_copy_02_01_2012
MODIFY NAME = Database1
GO

Enquanto o serviço executa o processo de renomeação, as conexões existentes com o banco de dados original são canceladas. Portanto, é importante verificar se o seu aplicativo é resistente a perdas de conexão com o Banco de dados SQL do Windows Azure e será capaz de restabelecer a conexão quando tal evento ocorrer. O script Transact-SQL inclui a instrução WAITFOR DELAY entre as duas instruções ALTER. Isso ajuda a garantir que as novas conexões estabelecidas durante o período de recuperação não sejam feitas acidentalmente com o banco de dados antigo antes de a renomeação ser concluída. Se você precisar copiar seu banco de dados em um servidor do Banco de dados SQL do Windows Azure diferente, a renomeação não funcionará. Nesses casos, modifique seu aplicativo para que aponte para a cópia do banco de dados no servidor separado.

Observações importantes

  • As cópias de banco de dados podem ser demoradas e variáveis em termos de duração.

  • Sua fatura incluirá cobranças para cada cópia de banco de dados. Mas você é cobrado pela nova cópia do banco de dados somente depois que o processo de cópia é concluído com êxito. Cada cópia de banco de dados é cobrada à mesma taxa que o banco de dados de origem.

  • Você é responsável por gerenciar as cópias e removê-las quando apropriado.

  • O uso do banco de dados é calculado diariamente. Portanto, se a sua cópia do banco de dados estiver ativa somente por um dia, você será cobrado uma taxa pro rata referente a um dia do banco de dados de cópia.

  • A restauração em um servidor lógico diferente requer modificações em cadeias de conexão.

  • A restauração em um servidor lógico diferente não garante uma melhor proteção contra perda de dados e melhor desempenho do sistema.

  • Enquanto um processo de cópia está em andamento, todas as alterações no banco de dados original são replicadas na cópia. Portanto, decidir qual cópia do banco de dados restaurar é uma questão importante.

  • A versão de novembro de 2011 do Banco de dados SQL apresentou o Federações no Banco de dados SQL do Windows Azure (antigo SQL Azure). No momento, você não pode copiar um banco de dados que contém federações usando a operação de cópia de banco de dados. Por outro lado, a criação de uma federação falhará se uma operação de cópia estiver ativa no banco de dados. A cópia de banco de dados também não pode ser executada em membros da federação.

  • O RTO deve ser igual ao “tempo para reconhecer o erro + tempo para renomear o banco de dados + intervalo de tempo entre as duas instruções ALTER.

Como ajudar a proteger seu banco de dados contra falhas generalizadas de instalações de data center

Para ajudar a proteger contra qualquer perda de data center no caso de um desastre, você precisa criar um armazenamento externo de backups de bancos de dados fora do data center em que seu aplicativo de banco de dados está implantado. Para fazer isso, recomendamos que você use a cópia de banco de dados descrita na seção anterior e o SQL Database Import/Export Service. A cópia de banco de dados mantém a consistência transacional durante a exportação. O SQL Database Import/Export Service copia as definições de objeto do seu banco de dados do Banco de dados SQL do Windows Azure de origem em um arquivo de exportação lógico (BACPAC) e, em seguida, copia em massa os dados das tabelas de usuários no BACPAC). Você deve determinar o destino específico do BACPAC e o procedimento de recuperação específico com base no contrato de nível de serviço do aplicativo e outros requisitos de negócios.

Para obter uma visão geral sobre as opções de backup e restauração fornecidas pelo Banco de dados SQL do Windows Azure, consulte Backup e restauração do banco de dados SQL do Windows Azure. Para obter mais informações sobre como usar o serviço SQL Database Import/Export, consulte os exemplos de DAC SQL e o artigo sobre importação/exportação de DAC como um serviço. Para obter mais informações sobre como usar o Portal de Gerenciamento do Windows Azure para importar/exportar o banco de dados no Banco de dados SQL do Windows Azure, consulte Como importar e exportar um banco de dados (Banco de dados SQL do Windows Azure).

Para ajudar a proteger seus dados contra a perda de um data center, você pode implementar os seguintes métodos:

  • Exportar o arquivo BACPAC para um blob usando a conta de armazenamento em um data center diferente.

  • Exportar o arquivo BACPAC para um blob usando a conta de armazenamento no mesmo data center e basear-se na replicação geográfica do Armazenamento do Windows Azure para copiar o arquivo BACPAC em um data center separado.

  • Importar o arquivo BACPAC para seu SQL Server local.

As seções a seguir descrevem como usar esses métodos e também as vantagens e desvantagens de cada um.

Exportar o arquivo BACPAC para um blob usando a conta de armazenamento em um data center diferente

Com esse método, você precisa criar uma conta de armazenamento em um data center na mesma região, mas separado do data center de sua conta do Banco de dados SQL do Windows Azure. Por exemplo, se o seu aplicativo e o banco de dados são executados no data center Norte da Europa, recomendamos que você mantenha uma cópia do banco de dados ou do BACPAC em outro data center na mesma região, como Europa Ocidental. Para obter mais proteção, você também pode manter uma cópia do banco de dados ou do BACPAC em outro data center em uma região diferente, por exemplo, Centro-Sul dos EUA.

Uma vez que a operação de exportação de arquivo esteja concluída, você poderá usar imediatamente a operação de importação para recriar o banco de dados e os dados em outro servidor do Banco de dados SQL do Windows Azure no mesmo ou em outro data center. Em seguida, você poderá excluir os Blobs do Windows Azure usados para reduzir os custos. A importação para o Banco de dados SQL do Windows Azure no data center de destino valida a operação e reduz a duração geral da recuperação. Nesse caso, você não será cobrado pelo banco de dados. Como alternativa, você pode adiar a operação de importação até que o failover de fato seja concluído. Nesse caso, a Microsoft o cobrará pelo armazenamento de Blob. Observe que você ainda precisaria fazer importações periódicas para o banco de dados em cada data center de backup para validar a operação e testar o procedimento de recuperação de desastre. Lembre-se de que você também será cobrado pelo custo de banda larga da cópia do BACPAC em um ou mais data centers.

O diagrama a seguir ilustra uma proteção de dados avançada. O diagrama demonstra a realização de uma cópia de banco de dados no data center A e, em seguida, a exportação dele para o Armazenamento do Windows Azure no data center B. Depois o diagrama mostra a importação do BACPAC para recriar o banco de dados no data center B e a cópia do BACPAC no data center C. Finalmente, ele mostra a importação do BACPAC para recriar o banco de dados no data center C.

Exportar o arquivo BACPAC em outro data center

Se o data center A falhar, o RPO, ou potencial perda de dados do seu aplicativo, será determinado pela frequência com que você realiza a exportação. Por exemplo, se você exporta dados uma vez por dia, sua perda de dados será de 24 horas de dados. O RTO do próprio banco de dados será mínimo se você fizer uma importação imediata do banco de dados. Se você adiar a importação, o RTO será determinado pelo tamanho do BACPAC e o tempo da importação para o novo banco de dados.

Exportar o arquivo BACPAC para um blob usando a conta de armazenamento no mesmo data center

Com esse método, você precisa ter uma conta de armazenamento no mesmo data center em que tem sua conta do Banco de dados SQL. Essa solução de recuperação se baseia na replicação geográfica de objetos de armazenamento do Windows Azure, como blobs e tabelas do Windows Azure, em outro data center na mesma região, sem custos adicionais. Por exemplo, se sua conta de armazenamento estiver no data center Norte da Europa, seus objetos de armazenamento do Windows Azure serão automaticamente replicados no segundo data center na mesma região, como Europa Ocidental.

Com esse método, você não tem a opção de importar imediatamente o BACPAC para o novo banco de dados no segundo data center. Isso ocorre porque a decisão de fazer o failover é tomada pelo Windows Azure. Portanto, o BACPAC replicado geograficamente pode ficar acessível somente depois que o Windows Azure executa a operação de failover. Você será cobrado pelo uso da conta de armazenamento do Windows Azure, mas não haverá cobrança pela banda larga, pois a cópia do BACPAC é feita no mesmo data center e o custo da replicação geográfica está incluído no custo de armazenamento. É importante observar que o serviço de importação/exportação produz o BACPAC usando Blobs de Blocos, que ajudam a preservar sua integridade replicando o BACPAC inteiro.

O diagrama a seguir ilustra a cópia de um banco de dados no data center A e a exportação dele para o armazenamento do Windows Azure no mesmo data center. Em seguida, o diagrama mostra que o Windows Azure realiza a replicação geográfica de objetos de armazenamento do Windows Azure do data center A para o data center B automaticamente. Finalmente, o diagrama ilustra a importação do BACPAC para recriar o banco de dados no data center B.

Exportar o arquivo BACPAC no mesmo data center

Com esse método, o RPO normal deverá ser igual ao “intervalo de tempo de arquivamento x 2”. Se ocorrer uma falha logo após a criação do arquivo, os dados do Blob poderão ser perdidos. Nesse caso, somente o arquivo anterior estará disponível. O RTO normal deverá ser igual a “24 horas + tempo de importação”. Embora a segunda opção possa ser mais demorada do que a primeira, ela oferece redução nos custos de armazenamento.

WarningAviso
Blobs e Tables do Windows Azure são replicados geograficamente entre dois data centers centenas de quilômetros distantes um do outro no mesmo continente, para oferecer durabilidade adicional dos dados no caso de um desastre de grandes proporções, sem custos adicionais. Para obter mais informações, consulte a postagem de blog Introdução à replicação geográfica para Armazenamento do Windows Azure. Com essa primeira versão de replicação geográfica, não fornecemos um SLA referente ao tempo necessário para replicar geograficamente os dados de modo assíncrono, embora as transações sejam normalmente replicadas geograficamente dentro de alguns minutos após sua confirmação na localização primária, e o tempo estimado para que os dados estejam acessíveis aos clientes após um desastre é 24 horas.

Importar o arquivo BACPAC para um SQL Server local

Além disso, você também pode baixar o BACPAC de sua conta de armazenamento para um computador cliente local e depois importar o arquivo para uma instância local do SQL Server 2012, SQL Server 2008 R2, SQL Server 2008 ou SQL Server 2005 usando a funcionalidade de Importação/Exportação oferecida pelo SQL Server Management Studio no SQL Server 2012. A importação do arquivo para uma instância local do SQL Server ajuda a garantir que você mantenha uma cópia local de seus dados sem precisar de uma conexão com a internet ou da disponibilidade de data centers do Windows Azure. Para importar um arquivo de armazenamento para uma instância local do SQL Server, baixe o produto SQL Server 2012 aqui e instale as Ferramentas de Gerenciamento. Para obter mais informações, consulte Instalar o SQL Server 2012 nos Manuais Online do SQL Server. Depois de instalar as Ferramentas de Gerenciamento do Microsoft SQL Server 2012, baixe o arquivo de exportação de sua conta de armazenamento para seu cliente local. Quando o download estiver concluído, conecte-se ao banco de dados de destino usando o SQL Server Management Studio. No Pesquisador de Objetos, clique com o botão direito do mouse no servidor, selecione Importar Aplicativo da Camada de Dados e siga as etapas para importar o arquivo de exportação.

Observações importantes

  • Essas opções exigem uma conta de Armazenamento do Windows Azure.

  • Seu aplicativo deve gerenciar eventos de failover.

  • Sua fatura incluirá cobranças para cada cópia de banco de dados.

  • Sua fatura incluirá cobranças por arquivamentos offline armazenados em sua conta de Armazenamento do Windows Azure.

  • Você é responsável por gerenciar as cópias de banco de dados e removê-las quando apropriado.

  • Você poderá precisar de uma instância local do SQL Server.

  • Após o failover, você poderá perder alguns dados.

  • A versão de novembro de 2011 do Banco de dados SQL apresentou o Federações no Banco de dados SQL do Windows Azure (antigo SQL Azure). Para implementar uma estratégia de recuperação para seus dados federados, escreva seus próprios scripts de exportação personalizados usando o bulk copy utility (BCP.exe) ou a classe System.Data.SqlClient.SqlBulkCopy ou use o SQL Database Migration Wizard no Codeplex.

    WarningAviso
    A ferramenta SQL Database Migration Wizard é integrada pela comunidade e não tem suporte.

Serviço de sincronização de dados e recuperação de desastre

O serviço Sincronização de Dados do Microsoft Banco de dados SQL do Windows Azure fornece recursos de sincronização de dados para instâncias do Banco de dados SQL do Windows Azure. O serviço tem atualmente dois recursos principais:

  • Sincronização de dados entre bancos de dados locais do SQL Server e instâncias do Banco de dados SQL do Windows Azure, permitindo que os bancos de dados locais e os baseados em nuvem utilizem os mesmos dados.

  • Sincronização de dados entre dois ou mais Banco de dados SQL; os bancos de dados podem estar no mesmo data center, em data centers diferentes ou em regiões diferentes. Esse recurso oferece um mecanismo de expansão de aplicativos por meio de várias cópias dos dados. Ele também permite que várias instâncias de aplicativos e bancos de dados sejam implantadas no mundo inteiro próximas aos usuários finais, com todos os bancos de dados sendo mantidos em sincronia. Observe que a Sincronização de Dados do SQL geralmente é usada com o Windows Azure Traffic Manager.

Ao usar a Sincronização de Dados do Banco de dados SQL do Windows Azure, você pode configurar a sincronização de dados em um intervalo fixo. Durante o processo de sincronização, somente os dados alterados são transmitidos após a primeira sincronização inicial; por exemplo, somente as linhas que foram inseridas, atualizadas ou excluídas desde a sincronização anterior. A Sincronização de Dados do SQL mantém várias cópias do seu banco de dados atualizadas, e essas cópias podem ser armazenadas na nuvem ou localmente.

Recomendamos que você avalie as seguintes considerações de design do serviço Sincronização de Dados do SQL antes de usá-lo como parte de sua estratégia de recuperação de desastre:

  • A Sincronização de Dados não sincroniza transações nem preserva limites de transações. A Sincronização de Dados aplica alterações em lotes uma tabela por vez, com cada lote sendo uma transação. Um pequeno número de alterações seria aplicado em um lote, mas um grande número de alterações pode ser aplicado em vários lotes. Se, por exemplo, uma linha Order e a linha OrderDetails correspondente forem inseridas em uma transação em um banco de dados, é possível que a linha Order e a linha OrderDetails sejam inseridas em diferentes transações do outro banco de dados. No caso de uma falha durante a sincronização, como um erro de rede, algumas transações talvez não sejam aplicadas até a próxima sincronização. Se houver um failover antes de as transações serem aplicadas na sincronização seguinte, os dados poderão ficar em um estado inconsistente para o aplicativo; por exemplo, a linha Order está presente, mas a linha OrderDetails não está.

  • O serviço Sincronização de Dados do SQL tem algumas limitações em relação aos esquemas de banco de dados com suporte. Por exemplo, a Sincronização de Dados do SQL não consegue sincronizar nenhuma tabela que não tenha uma Chave Primária. Além disso, a Sincronização de Dados do SQL sincroniza apenas dados, mas não procedimentos armazenados e gatilhos. Para obter mais informações, consulte Data Sync FAQ.

  • A Sincronização de Dados do SQL não mantém várias versões de um banco de dados disponíveis para permitir o failover ou a restauração em um horário em particular.

Se essas considerações forem aceitáveis para seu cenário e aplicativos, a Sincronização de Dados do SQL poderá ser uma opção para sua estratégia de recuperação de desastre.

Se você usa o serviço Sincronização de Dados como uma solução de recuperação de desastre, recomendamos a criação de lógica de aplicativo para validar a capacidade operacional do aplicativo após o failover.

Para obter mais informações sobre a Sincronização de Dados do SQL, consulte a documentação de SQL Data Sync e o tópico Data Sync Best Practices na biblioteca do MSDN.

WarningAviso
A Sincronização de Dados do SQL está disponível apenas como uma Visualização para fins de comentários sobre o produto para futuras versões e não deve ser usada em ambientes de produção.

Consulte também

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários

Contribuições da comunidade

ADICIONAR
Mostrar:
© 2014 Microsoft. Todos os direitos reservados.