Fazendo backup e restaurando um banco de dados

  • Artigo

Como em qualquer banco de dados de produção, deve-se fazer backup regularmente de um banco de dados envolvido em operações de sincronização. Se você tiver que restaurar um banco de dados a partir de um backup, há duas considerações principais:

  • As alterações feitas no banco de dados depois da restauração talvez não tenham sido propagadas para os clientes ou outros pares. Isso ocorre devido aos valores timestamp usados quando são selecionadas alterações de um banco de dados.

    Por exemplo, durante a sincronização do cliente e do servidor, o Sync Framework recupera um novo valor de âncora do banco de dados servidor e o armazena no banco de dados cliente. Esse valor é usado como o limite superior do conjunto atual de alterações que está sendo sincronizado. Para obter mais informações, consulte Controlando alterações no banco de dados do servidor. Depois da restauração do banco de dados servidor, o valor armazenado no banco de dados cliente pode estar logicamente à frente do valor retornado pelo banco de dados servidor.

  • Para cenários de carregamento e bidirecionais, os clientes ou outros pares podem ter alterações que o banco de dados recém-restaurado não tem.

Os exemplos neste tópico usam a sincronização de cliente e servidor como exemplo. Princípios semelhantes se aplicam à sincronização ponto a ponto, e são descritas considerações ponto a ponto. O banco de dados do servidor é o par remoto. O banco de dados do cliente é o par local. Para obter mais informações sobre como fazer backup e restaurar bancos de dados do SQL Server sincronizados usando o SqlSyncProvider, consulte Como fazer backup de um banco de dados e restaurá-lo (SQL Server).

Banco de dados do servidor

Para entender como o banco de dados do cliente pode estar logicamente à frente do banco de dados do servidor, considere como as atualizações são controladas na tabela Sales.Customer no banco de dados de exemplo do Sync Framework. A coluna UpdateTimestamp armazena um valor timestamp e o novo comando de âncora retorna um valor da função MIN_ACTIVE_ROWVERSION do SQL Server. Para fins de esclarecimento, os inteiros são usados em vez de valores hexadecimais no exemplo:

  1. Antes da restauração do banco de dados, MIN_ACTIVE_ROWVERSION retorna um valor igual a 31. Esse valor foi armazenado no banco de dados do cliente como a última âncora recebida.

  2. Depois da restauração do banco de dados, MIN_ACTIVE_ROWVERSION retorna um valor igual a 19.

  3. As atualizações são feitas de forma que o valor timestamp na coluna UpdateTimestamp atinja 32.

  4. A sincronização ocorre e MIN_ACTIVE_ROWVERSION retorna um valor igual a 32. A atualização final para Sales.Customer é baixada, pois 32 é maior do que o último valor de âncora recebido de 31. As atualizações entre 19 e 31 não são reconhecidas como alterações.

Qualquer esquema de controle que usa um relógio lógico como um carimbo de data/hora está suscetível a esse problema de alterações não reconhecidas. Os esquemas de controle que usam o tipo de dados com base em data e hora não estão suscetíveis porque o relógio de parede anda para a frente, independentemente do estado do banco de dados. Na sincronização ponto a ponto, um carimbo de data/hora é necessário para o controle de alterações.

Para lidar com o problema apresentado pela carimbo de data/hora, use um dos seguintes métodos:

  • Traga o carimbo de data/hora do servidor para o ponto em que estava antes da operação de restauração. No exemplo anterior, você poderia executar atualizações fictícias em uma tabela separada até que MIN_ACTIVE_ROWVERSION retornasse 31.

    Essa é a abordagem recomendada para a sincronização ponto a ponto.

  • Armazene a âncora de cada cliente no servidor. No exemplo anterior, a última âncora recebida do backup seria 19. Portanto, as atualizações subsequentes seriam reconhecidas e todas as alterações entre 19 e 32 seriam baixadas. O Sync Framework não fornece suporte integrado para isso, mas você poderia criar um sistema no servidor da seguinte forma:

    1. Crie uma tabela no banco de dados do servidor que tenha uma linha para cada cliente. A tabela incluiria uma coluna com a ID que o Sync Framework gera para cada cliente e uma coluna com a âncora daquele cliente. Durante a sincronização, o aplicativo poderia atualizar essa coluna com um novo valor de âncora.

    2. Altere os comandos de sincronização para selecionar o valor de âncora mais baixo para o cliente que está sincronizando. Esse valor poderia ser o valor armazenado no banco de dados do cliente ou o valor armazenado no banco de dados do servidor. Depois da operação de restauração do banco de dados, o valor no banco de dados do servidor deve ser menor. Se houver uma falha depois que você gravar um valor na tabela do servidor, mas antes que as alterações sejam aplicadas no cliente, o valor no banco de dados do cliente deverá ser menor. Se a sincronização estiver ocorrendo conforme o esperado, os valores deverão ser iguais. Um comando de inserção pode ser escrito da seguinte maneira:

      SELECT CustomerId, CustomerName, SalesPerson, CustomerType
FROM Sales.Customer
WHERE (InsertTimestamp > (SELECT AnchorValue from ServerAnchorTable WHERE ClientId = @sync_client_id)
OR InsertTimestamp > @sync_last_received_anchor) AND InsertTimestamp <= @sync_new_received_anchor
AND InsertId <> @sync_client_id

Bancos de dados do cliente

Após a restauração do banco de dados do servidor até o momento com relação aos metadados de sincronização, o banco de dados ainda poderá estar sem algumas alterações feitas nos clientes desde o backup do servidor. Para que um cliente responda de forma adequada, ele deve saber que o banco de dados do servidor foi restaurado. Você poderá usar uma tabela de controle no servidor que indique se uma restauração ocorreu desde a última vez que um cliente em particular foi sincronizado. Durante cada sessão de sincronização, o aplicativo cliente primeiro verificaria essa tabela para determinar se ela pode efetuar a sincronização normalmente ou se deve executar um código especial para funcionar com o banco de dados restaurado.

Depois que um aplicativo cliente reconhece que o banco de dados do servidor foi restaurado, o aplicativo pode tornar os bancos de dados do cliente e do servidor convergentes. Isso pode ser feito de várias formas, incluindo os seguintes métodos:

  • Reinicializar o banco de dados do cliente descartando todas as tabelas e, depois, sincronizando com o servidor. Esse é o método mais fácil, mas as alterações no cliente serão perdidas.

    A reinicialização é a abordagem recomendada para a sincronização ponto a ponto. Para obter informações sobre a inicialização de bancos de dados par, consulte "Inicializando um banco de dados servidor" em Como configurar e executar a sincronização de colaboração (não SQL Server).

  • Reinicialize o banco de dados do cliente depois de criar uma cópia das tabelas do cliente. Um aplicativo poderia seguir estas etapas:

    1. Identificar se o banco de dados do servidor foi restaurado.

    2. Criar uma cópia de todas as tabelas do banco de dados do cliente e, em seguida, descartar as tabelas originais.

    3. Sincronizar com o servidor para baixar novos dados e esquemas.

    4. Comparar as linhas nas novas tabelas com as cópias criadas.

    5. Identificar quaisquer diferenças entre os dois conjuntos de tabelas, e aplicar às novas tabelas quaisquer alterações necessárias.

    6. Sincronizar novamente para carregar alterações que foram aplicadas às novas tabelas.

Consulte também

Outros recursos

Considerações sobre implantação e design de aplicativos