ApsaraDB RDS:Migrar dados entre instâncias do ApsaraDB RDS for SQL Server

Tipo

Descrição

Limites do banco de dados de origem

• O servidor do banco de dados de origem deve ter largura de banda de saída suficiente. Largura de banda insuficiente reduz a velocidade da migração de dados.

• As tabelas a serem migradas devem ter uma chave primária ou restrição única, e as colunas na chave ou restrição devem ser únicas. Caso contrário, pode ocorrer duplicação de dados no banco de dados de destino.

• Se você selecionar tabelas específicas para migração e precisar editá-las (por exemplo, mapear nomes de tabelas ou colunas), uma única tarefa de migração pode migrar no máximo 1.000 tabelas. Se você exceder esse limite, a tarefa falhará no envio. Divida as tabelas em várias tarefas ou configure uma tarefa para migrar o banco de dados inteiro.

• Uma única tarefa de migração suporta no máximo 10 bancos de dados. Exceder esse limite pode causar problemas de estabilidade e desempenho. Divida a migração em várias tarefas, se necessário.

• Se você configurar uma tarefa para migrar objetos específicos em vez de um banco de dados inteiro, não será possível migrar objetos que tenham o mesmo nome de tabela, mas nomes de esquema diferentes, para o mesmo banco de dados de destino dentro de uma única tarefa.

• Se você realizar migração incremental de dados, os logs de transação devem atender aos seguintes requisitos:

  • O registro de transações deve estar habilitado, o modo de backup deve estar definido como Full e um backup físico completo deve ter sido realizado com êxito.

  • Para migração de dados apenas incremental, o Data Transmission Service (DTS) exige a retenção dos logs de transação do banco de dados de origem por mais de 24 horas. Se uma tarefa incluir migração completa e incremental de dados, retenha os logs por pelo menos sete dias. Após a conclusão da migração completa de dados, você pode reduzir o período de retenção para mais de 24 horas. Caso contrário, a tarefa do DTS pode falhar devido a logs de transação indisponíveis. Em casos extremos, pode ocorrer inconsistência ou perda de dados. Problemas causados por retenção insuficiente de logs não são cobertos pelo Acordo de Nível de Serviço (SLA) do DTS.

• Se você ativar o CDC (change data capture) para as tabelas de origem a serem migradas, elas devem atender às seguintes condições. Caso contrário, a pré-verificação falhará.

  • O valor do campo srvname na view sys.sysservers deve ser igual ao valor retornado pela função SERVERPROPERTY.

  • Se o banco de dados de origem for um SQL Server autogerenciado, o proprietário do banco de dados deve ser sa. Se o banco de dados de origem for uma instância do ApsaraDB RDS for SQL Server, o proprietário do banco de dados deve ser sqlsa.

  • Se o banco de dados de origem for Enterprise Edition, deve ser SQL Server 2008 ou posterior.

  • Se o banco de dados de origem for Standard Edition, deve ser SQL Server 2016 SP1 ou posterior.

  • Se o banco de dados de origem for SQL Server 2017 (Standard ou Enterprise Edition), atualize-o para uma versão posterior.

• O DTS usa a função fn_log para obter logs do banco de dados de origem. Essa função tem gargalos de desempenho, portanto, não limpe os logs do banco de dados de origem prematuramente. Caso contrário, a tarefa do DTS pode falhar.

• Limites nas operações no banco de dados de origem:

  • Durante as fases de migração de esquema e migração completa de dados, não execute operações DDL que alterem a estrutura do banco de dados ou da tabela. Caso contrário, a tarefa de migração de dados falhará.

  • Se você realizar apenas a migração completa de dados, não grave novos dados na instância de origem. Caso contrário, os dados nos bancos de dados de origem e destino ficarão inconsistentes. Para garantir consistência de dados em tempo real, selecione Migração de Esquema, Migração Completa de Dados e Migração Incremental de Dados.

• Se o banco de dados de origem for uma instância somente leitura, o DTS não migrará operações DDL.

• Se o banco de dados de origem for um Azure SQL Database, uma instância de migração pode migrar apenas um banco de dados.

• Se o banco de dados de origem for uma instância do ApsaraDB RDS for SQL Server e a tarefa de migração incluir migração incremental de dados, garanta que o Transparent Data Encryption (TDE) esteja desativado para garantir a estabilidade da tarefa. Para mais informações, consulte Desativar TDE.

• Se você usar o comando sp_rename para renomear objetos como procedimentos armazenados antes da execução da tarefa de migração de esquema, a tarefa pode não funcionar conforme o esperado ou pode falhar.

  Nota

  Use o comando ALTER para renomear objetos de banco de dados.

• No modo de análise baseada em log híbrida, o banco de dados de origem não suporta operações consecutivas de adição ou remoção de colunas com intervalo inferior a 10 minutos. Por exemplo, se você executar as seguintes instruções SQL consecutivamente, a tarefa falhará.

  ALTER TABLE test_table DROP COLUMN Flag;
  ALTER TABLE test_table ADD Remark nvarchar(50) not null default('');

• Se o banco de dados de origem for uma instância do ApsaraDB RDS for SQL Server executando a edição Web, defina o SQL Server Incremental Synchronization Mode como Incremental Synchronization Based on Logs of Source Database (Heap tables are not supported) ao configurar a tarefa.

• Durante a migração completa de dados, ative o parâmetro READ_COMMITTED_SNAPSHOT para o banco de dados de origem para evitar que a contenção de bloqueios compartilhados afete as gravações de dados. Caso contrário, pode ocorrer inconsistência de dados ou falha na tarefa. Problemas causados pela não ativação desse parâmetro não são cobertos pelo SLA do DTS.

Outros limites

• O DTS não suporta a migração de dados dos seguintes tipos: CURSOR, ROWVERSION, SQL_VARIANT, HIERARCHYID, POLYGON, GEOMETRY e GEOGRAPHY.

• Se os dados não puderem ser gravados em uma coluna do tipo de dados TIMESTAMP no banco de dados de destino, o DTS não suportará a migração completa ou incremental de dados. Isso pode levar a inconsistência de dados ou falha na tarefa.

• Para migrar triggers do banco de dados de origem, a conta de banco de dados usada para a tarefa de migração deve ter permissões de Owner no banco de dados de destino.

• Se você definir Configure Objects como SQL Server Incremental Synchronization Mode na etapa Incremental Synchronization Based on Logs of Source Database (Heap tables are not supported), as tabelas a serem migradas devem ter um índice clusterizado que inclua a coluna de chave primária. O DTS não suporta a migração de tabelas heap, tabelas sem chaves primárias, tabelas compactadas, tabelas com colunas computadas ou tabelas com colunas esparsas neste modo. Essas limitações não se aplicam no modo de análise baseada em log híbrida.

  Nota

  Para obter informações sobre como visualizar detalhes da tabela, consulte Como visualizo informações sobre tabelas heap, tabelas sem chaves primárias, tabelas compactadas, tabelas com colunas computadas e tabelas com colunas esparsas no SQL Server?

• Se você definir Configure Objects como SQL Server Incremental Synchronization Mode na etapa Log-based Parsing for Non-heap Tables and CDC-based Incremental Synchronization for Heap Tables (Hybrid Log-based Parsing), os seguintes limites também se aplicam:

  • O DTS depende do componente CDC para migração incremental. Garanta que o job de CDC no banco de dados de origem esteja sendo executado conforme o esperado. Caso contrário, a tarefa do DTS falhará.

  • Por padrão, o componente CDC armazena dados incrementais por três dias. Ajuste o período de retenção executando o comando exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>;.

    Nota

    • <time> especifica o período de retenção em minutos.

    • Se o número médio diário de alterações SQL incrementais para uma única tabela exceder 10 milhões, defina <time> como 1440.

  • Em uma única tarefa de migração, ative o CDC para no máximo 1.000 tabelas. Caso contrário, a tarefa pode apresentar alta latência ou tornar-se instável.

  • O módulo de pré-verificação de uma tarefa de migração incremental de dados do DTS ativa o CDC no banco de dados de origem. Durante esse processo, as limitações internas do mecanismo do SQL Server podem causar bloqueio temporário de tabelas no banco de dados de origem.

• Se você definir Configure Objects como SQL Server Incremental Synchronization Mode na etapa Polling and querying CDC instances for incremental synchronization, os seguintes limites também se aplicam:

  • A conta do banco de dados de origem usada pela instância do DTS deve ter permissões para ativar o CDC. Uma conta com a função sysadmin é necessária para ativar o CDC no nível do banco de dados. Uma conta privilegiada é necessária para ativar o CDC no nível da tabela.

    Nota

    • A conta mais privilegiada (administrador do servidor) fornecida pelo console do Azure SQL Database atende aos requisitos. Para bancos de dados adquiridos com base no modelo vCore, o CDC pode ser ativado para todas as especificações. Para bancos de dados adquiridos com base no modelo DTU, o CDC só pode ser ativado para camadas de serviço S3 ou superiores.

    • A conta privilegiada de uma instância do Amazon RDS for SQL Server atende aos requisitos e suporta a ativação do CDC no nível do banco de dados via procedimentos armazenados.

    • Não é possível ativar o CDC para tabelas que possuem um índice columnstore clusterizado.

    • O módulo de pré-verificação de uma tarefa de migração incremental de dados do DTS ativa o CDC no banco de dados de origem. Durante esse processo, as limitações internas do mecanismo do SQL Server podem causar bloqueio temporário de tabelas no banco de dados de origem.

  • O DTS obtém dados incrementais consultando e fazendo polling da instância de CDC de cada tabela no banco de dados de origem. Migre no máximo 1.000 tabelas do banco de dados de origem. Caso contrário, a tarefa pode apresentar alta latência ou tornar-se instável.

  • Por padrão, o componente CDC armazena dados incrementais por três dias. Ajuste o período de retenção executando o comando exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>;.

    Nota

    • <time> especifica o período de retenção em minutos.

    • Se o número médio diário de alterações SQL incrementais para uma única tabela exceder 10 milhões, defina <time> como 1440.

  • Operações consecutivas de adição ou remoção de colunas não são suportadas (mais de duas operações DDL ADD COLUMN ou DROP COLUMN em um minuto). Caso contrário, a tarefa pode falhar.

  • Não modifique as instâncias de CDC do banco de dados de origem. Caso contrário, a tarefa de migração de dados pode falhar ou pode ocorrer perda de dados.

• Se você migrar dados entre versões diferentes do SQL Server, verifique a compatibilidade antecipadamente.

• Para garantir relatórios precisos de latência na migração incremental de dados, o DTS cria objetos no banco de dados de origem. No modo de análise baseada em log, o DTS cria um trigger dts_cdc_sync_ddl, uma tabela de heartbeat dts_sync_progress e uma tabela de armazenamento de DDL dts_cdc_ddl_history. No modo de análise baseada em log híbrida, o DTS cria os mesmos objetos e também ativa o CDC nos níveis de banco de dados e tabela. Para tabelas onde o CDC está ativado, a taxa de alteração de dados não deve exceder 1.000 linhas por segundo (RPS).

• Antes de migrar dados, avalie o desempenho dos bancos de dados de origem e destino e realize a migração fora dos horários de pico. Durante a migração completa de dados, o DTS consome recursos de leitura e gravação em ambos os bancos de dados, o que pode aumentar a carga deles.

• Durante a migração completa de dados, operações INSERT concorrentes podem causar fragmentação nas tabelas de destino, de modo que o espaço de armazenamento da tabela no banco de dados de destino pode ser maior do que no banco de dados de origem após a migração.

• Verifique se a precisão que o DTS usa para migrar colunas do tipo de dados FLOAT ou DOUBLE atende aos seus requisitos de negócio. O DTS usa a função ROUND(COLUMN,PRECISION) para ler valores dessas colunas. Se uma precisão não for explicitamente definida, o DTS migrará valores FLOAT com precisão de 38 dígitos e valores DOUBLE com precisão de 308 dígitos.

• O DTS tenta retomar uma tarefa falha por até sete dias. Antes de alternar suas cargas de trabalho de negócios para a instância de destino, encerre ou libere a tarefa de migração. Alternativamente, revogue as permissões de gravação da conta do DTS na instância de destino usando o comando revoke para evitar que uma tarefa retomada sobrescreva os dados de destino.

• Se uma tarefa de migração incluir migração incremental de dados, você não poderá realizar operações de reindexação. Isso pode causar falha na tarefa ou resultar em perda de dados.

  Nota

  Você não pode modificar a chave primária de uma tabela para a qual o CDC está ativado.

• Se o número de tabelas com CDC ativado em uma única tarefa de migração exceder o valor definido no parâmetro The maximum number of tables for which CDC is enabled that DTS supports., a pré-verificação falhará.

• Se uma tarefa incluir migração incremental e um único campo em uma tabela com CDC ativado a ser gravado contiver mais de 64 KB de dados, execute o comando exec sp_configure 'max text repl size', -1; para ajustar a configuração do banco de dados de origem antecipadamente.

  Nota

  Por padrão, um job de CDC pode processar um tamanho máximo de dados de 64 KB para um único campo.

• Para realizar a migração incremental de dados, desative triggers e chaves estrangeiras que estejam habilitados no banco de dados de destino. Caso contrário, a tarefa falhará.

• Quando várias instâncias de migração usam o mesmo banco de dados SQL Server de origem, seus módulos de coleta de dados incrementais operam independentemente.

• Se uma tarefa falhar, a equipe de suporte do DTS tentará restaurá-la dentro de oito horas. Durante a restauração, eles podem reiniciar a tarefa ou ajustar seus parâmetros.

  Nota

  Apenas os parâmetros da tarefa do DTS são modificados — não os parâmetros do banco de dados. Os parâmetros que podem ser ajustados incluem aqueles listados em Modificar parâmetros da instância.

• O SQL Server é um banco de dados comercial e de código fechado cujo formato de log pode causar problemas inevitáveis durante o CDC incremental e a análise no DTS. Antes de habilitar o DTS para sincronização incremental a partir de uma origem SQL Server em um ambiente de produção, realize testes abrangentes de prova de conceito (POC) que cubram todos os cenários de alteração de negócios, ajustes de esquema e testes de estresse de carga máxima. A consistência entre a lógica do seu ambiente de produção e a fase de POC é essencial para operações estáveis do DTS.

• Durante a migração incremental de dados, rollbacks parciais de transação no banco de dados de origem não são suportados e podem ser ignorados.

Casos especiais

• Se a origem for uma instância do ApsaraDB RDS for SQL Server, o DTS cria uma conta de sistema chamada rdsdt_dtsacct na instância para migração de dados. Não exclua esta conta nem altere sua senha enquanto a tarefa estiver em execução. Caso contrário, a tarefa pode falhar. Para mais informações, consulte Contas de sistema.

• Se o destino for uma instância do ApsaraDB RDS for SQL Server, o DTS cria o banco de dados automaticamente. No entanto, se o nome do banco de dados não seguir as convenções de nomenclatura do ApsaraDB RDS for SQL Server, crie o banco de dados na instância de destino antes de configurar a tarefa de migração. Para mais informações, consulte Criar um banco de dados.