Início / dba / Perguntas / 40254
Accepted
swasheck
Asked: 2013-04-18 09:32:34 +0800 CST

Como posso verificar se uma restauração completa do banco de dados reflete o banco de dados de origem exato no SQL Server?

  • 772

Estamos desativando nosso antigo SQL Server 2000 Ent. instância em favor do SQL Server 2008 R2 Ent. Meu caminho de migração planejado é:

  1. Encerrar conexões de cliente (2000)
  2. Backup completo (2000)
  3. Restaurar (2008 R2)

Estou sendo solicitado a fornecer provas conclusivas de que cada transação "conseguiu" e que os dados são uma replicação exata do que existia na instância 2000.

Espero poder usar a seguinte documentação como evidência:

No entanto, se isso não for suficiente, a única coisa em que consigo pensar é percorrer todas as linhas de todas as tabelas de todos os bancos de dados e calcular uma soma de verificação (em ambas as instâncias), bem como obter contagens de linhas para todas as tabelas em todos os bancos de dados.

Existe alguma maneira melhor de satisfazer os critérios de verificação de "réplica exata"? Também estou aberto a uma melhor documentação.

sql-server restore

3 respostas

  1. Best Answer

    Ao fazer o backup do banco de dados, o último LSN na origem será X. Se ocorrer alguma atividade (incluindo, digamos, um ponto de verificação automatizado), o LSN de origem avançará para X+n. Se houver alguma atividade que ocorreu na origem e não foi capturada no backup, ela deixará uma impressão no log de origem, em algum lugar entre LSN X e X+n. Usando fn_dblogum pode olhar para o log e ver se alguma dessas atividades ocorreu.

    Uma maneira fácil de garantir que essa atividade não ocorra após o backup é definir o banco de dados como read_only imediatamente após fazer o backup. Para evitar qualquer atividade entre o backup e a mudança para read_only, você pode desabilitar as conexões ou definir o banco de dados no modo single_user, até mesmo iniciar o servidor no modo single user .

    Portanto, um procedimento como o seguinte deve ser praticamente à prova de balas:

    • reinicie o servidor de origem no modo de usuário único ( -m)
    • conecte e faça o backup
    • mude o banco de dados para read_only
    • restaurar o banco de dados no novo servidor
    • execute todos os testes que você tem no novo servidor
    • conectar aplicativos ao novo servidor
    • descomissionar ou reiniciar servidor antigo
    • 9

  2. Eu diria:

    1. desativar conexões no servidor 2000.
    2. Crie um backup no servidor 2000 e verifique-o no banco de dados.
    3. Restaure no servidor 2008.
    4. Certifique-se de que as conexões ainda estejam desativadas no servidor 2000.
    5. Altere o nome no servidor 2000 e desative o serviço SQL Server.
    6. Assine que você restaurou a cópia verificada do banco de dados no novo servidor.
    7. Inicie o novo servidor.

    Não consigo ver como pode haver transações ausentes no novo servidor, supondo que não haja transações ocorrendo na máquina de origem durante e após o processo de backup.

    Como prova, a única coisa que você pode fazer é comparar os dados nos bancos de dados de origem e de destino; no entanto, isso é um exagero total, pois o backup e a verificação farão exatamente isso.

    • 3

  3. Existem várias maneiras de fazer isso.

    uma. Faça backup da instância 2000 e restaure-a na instância 2008R2. Isso exigirá o tempo de inatividade do aplicativo até que você restaure o backup com êxito para a instância 2008R2.

    Além disso, você deve eliminar todas as conexões com a instância 2000, pois não deseja perder os dados.

    b. Configure o logshipping de 2000 para 2008R2. Ao fazer o failover, você só precisa fazer um backup de log final e restaurar na instância secundária (2008R2) e, em seguida, colocar o banco de dados online.

    A opção b exigirá menos tempo de inatividade.

    EDITAR:

    Você pode ter Log-shipping entre SQL 2000 e SQL 2005/2008R2. MAS você não pode manter o secundário no modo STANDBY.

    Algumas referências sobre como implementar o envio de logs no SQL 2000. Observe que isso também se aplica à configuração do envio de logs de 2000 para 2005/2008/2008R2.

    Implementando Log Shipping

    Migrando uma configuração de envio de log do SQL Server 2000 para o SQL Server 2008

    Envio de Log Personalizado

    Envio de log usando Powershell

    • 1

relate perguntas