ApsaraDB RDS:Migrate incremental backup data to the cloud (SQL Server 2008 R2 on cloud disks and SQL Server 2012 or later)

Casos de uso

Utilize a migração incremental de dados para o RDS SQL Server nos seguintes cenários:

• Você deseja realizar uma migração física para o RDS SQL Server por meio de arquivos de backup, em vez de uma migração lógica.

  Nota

  • A migração física é baseada em arquivos, enquanto a migração lógica gera instruções DML a partir dos dados e as executa na instância de destino do RDS SQL Server.

  • A migração física garante que o banco de dados de destino seja 100% idêntico ao banco de dados de origem. Já a migração lógica não consegue garantir essa consistência. Por exemplo, atributos como fragmentação de índice e informações estatísticas podem divergir após a migração.

• Você precisa de um tempo de inatividade mínimo, limitado a poucos minutos.

  Nota

  Se um tempo de inatividade maior for aceitável (por exemplo, uma indisponibilidade de 2 horas) e o banco de dados tiver menos de 100 GB, migrate your database using a full backup file.

Pré-requisitos

• A instância do RDS for SQL Server deve atender aos seguintes requisitos:

  • A instância deve executar o SQL Server 2012 ou posterior, ou ser uma instância SQL Server 2008 R2 que utiliza cloud disks.

  • A instância não pode conter um banco de dados com o mesmo nome daquele que está sendo migrado.

  • O espaço de armazenamento disponível na instância deve ser maior do que o tamanho do arquivo de dados que será migrado. Se o espaço for insuficiente, upgrade the instance storage.

• O modelo de recuperação do banco de dados SQL Server local deve ser FULL.

  Nota

  • A migração incremental de dados requer backups de log de transações. O modelo de recuperação Simple não oferece suporte a backups de log de transações.

  • Um arquivo grande de backup diferencial pode prolongar a migração incremental de dados.

• Caso você faça logon como usuário RAM, os seguintes requisitos devem ser atendidos:

  • O usuário RAM deve ter as permissões AliyunOSSFullAccess e AliyunRDSFullAccess concedidas. Para mais informações sobre como conceder permissões a um usuário RAM, consulte Manage OSS permissions by using RAM e Manage ApsaraDB RDS permissions by using RAM.

  • Sua conta Alibaba Cloud (conta principal) deve ter autorizado a conta de service oficial do ApsaraDB RDS a acessar seus recursos OSS.

    Clique para visualizar o método de autorização

    1. Acesse a página Restoration da instância ApsaraDB RDS e, em seguida, clique em Restore Backup Data from OSS.

    2. Na página Import Guide, clique em Next duas vezes para acessar a etapa 3. Import Data.

       Se a mensagem You have authorized the ApsaraDB RDS official service account to access your OSS resources aparecer no canto inferior esquerdo da página, a autorização está concluída. Caso contrário, a autorização ainda não foi realizada. Nesse caso, clique em Authorization URL na página para conceder a autorização.

       Na página 3. Data Import, configure os seguintes parâmetros:

       • Database Name: insira o nome do banco de dados de destino.

       • OSS Bucket: selecione na lista suspensa o bucket que armazena o arquivo de backup enviado.

       • OSS File List: insira um prefixo de nome de arquivo para pesquisar o arquivo de backup e, em seguida, selecione o arquivo.

       • Migration Method: selecione Open Database (Only One Full Backup File) ou Do Not Open Database (Differential Backup or Log Files Available).

       • Consistency Check Method: selecione Synchronous DBCC ou Asynchronous DBCC.

  • create a permission policy manualmente na sua conta Alibaba Cloud (conta principal) e, em seguida, associe a política ao usuário RAM.

    Clique para visualizar o conteúdo da política

    {
        "Version": "1",
        "Statement": [
            {
                "Action": [
                    "ram:GetRole"
                ],
                "Resource": "acs:ram:*:*:role/AliyunRDSImportRole",
                "Effect": "Allow"
            }
        ]
    }

Preparações

Execute o comando DBCC CHECKDB no banco de dados autogerenciado para verificar a existência de allocation errors e consistency errors. A saída esperada é a seguinte:

...
CHECKDB found 0 allocation errors and 0 consistency errors in database 'xxx'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Observações

• Nível de migração: esta solução migra apenas um único banco de dados. Para migrar vários ou todos os bancos de dados, consulte SQL Server instance-level cloud migration.

• Compatibilidade de versão: não é possível restaurar um backup de uma instância SQL Server autogerenciada em uma instância ApsaraDB RDS for SQL Server que execute uma versão anterior do SQL Server.

• Gerenciamento de permissões: ao autorizar a conta de service do ApsaraDB RDS a acessar o OSS, uma função chamada AliyunRDSImportRole é criada no Resource Access Management (RAM). Não modifique nem exclua essa função. Caso contrário, a tarefa de migração para a cloud falhará. Se você modificar ou excluir essa função acidentalmente, será necessário conceder as permissões novamente por meio do assistente de migração.

• Gerenciamento de contas: após a conclusão da migração, as contas de banco de dados existentes não poderão ser usadas. Crie novas contas no console do ApsaraDB RDS.

• Retenção de arquivos no OSS: não exclua o arquivo de backup do OSS antes da conclusão da tarefa de migração para a cloud. Caso contrário, a tarefa falhará.

• Requisitos para arquivos de backup:

  • Restrições de nome de arquivo: o nome do arquivo de backup não pode conter caracteres especiais (como !@#$%^&*()_+-=). Caso contrário, a migração para a cloud falhará.

  • Extensões de arquivo: o ApsaraDB RDS oferece suporte a arquivos de backup com as seguintes extensões: .bak (backup completo), .diff (backup diferencial) e .trn ou .log (backup de log). O ApsaraDB RDS não reconhece outros tipos de arquivo.

    Nota

    • Na prática, a extensão de um arquivo não indica necessariamente o tipo de backup. Por exemplo, um arquivo .bak pode conter um backup completo, diferencial ou de log de transações.

    • Um SQL Server log backup file downloaded from the ApsaraDB RDS console usa por padrão o formato .zip.log. Esse formato difere do arquivo de backup .bak gerado pelo script oficial na Etapa 1. Após converter o formato do arquivo, você pode utilizá-lo para a migração incremental para a cloud.

      Método de processamento: altere a extensão do arquivo para .zip e descompacte o arquivo. Em seguida, renomeie o arquivo descompactado database_name.lbak para que tenha a extensão .bak. Por fim, faça upload desse arquivo .bak para o OSS como um backup de log incremental para a migração para a cloud.

Exemplo de fluxo de trabalho

Este fluxo de trabalho demonstra que o tempo de inatividade necessário da aplicação é muito curto. Basta interromper as gravações da aplicação imediatamente antes do backup de log final. Neste exemplo, o tempo total de inatividade é inferior a 5 minutos.

Etapa 1: Fazer backup do banco de dados local

1. Baixe o script de backup e abra-o no SSMS.

2. Modifique os parâmetros a seguir.

   Parâmetro	Descrição
   @backup_databases_list	Lista de bancos de dados a serem copiados, separados por ponto e vírgula ou vírgula.
   @backup_type	O tipo de backup a ser executado. Valores válidos: FULL: backup completo DIFF: backup diferencial LOG: backup de log
   @backup_folder	Diretório local para o arquivo de backup. O script cria esse diretório automaticamente caso ele não exista.
   @is_run	Determina se o backup será executado. Valores válidos: 1: executa o backup. 0: executa apenas uma verificação, sem realizar o backup.

3. Execute o script de backup.

   O script gera um arquivo .bak por padrão, independentemente do tipo de backup selecionado.

2. Faça upload do arquivo de backup para o OSS

1. Para fazer upload de um arquivo de backup para o OSS, primeiro é necessário criar um bucket.

   • Se você já possui um bucket no OSS, verifique se ele atende aos seguintes requisitos:

     • A storage class do bucket deve ser Standard. A classe de armazenamento não pode ser Infrequent Access (IA), Archive, Cold Archive nem Deep Cold Archive.

     • O bucket não pode ter Data encryption ativado.

   • Se você não possui um bucket no OSS, crie um. (Certifique-se de ter activated OSS.)

     1. Acesse o console do OSS, clique em Buckets e, em seguida, clique em Create bucket.

     2. Configure os parâmetros principais a seguir. Mantenha os valores padrão para os demais parâmetros.

        Importante

        • O bucket é utilizado exclusivamente para esta migração de dados basta configurar os parâmetros principais. Após a conclusão da migração, exclua o bucket imediatamente para evitar vazamento de dados e cobranças adicionais.

        • Não ative data encryption ao criar o bucket.

        Parâmetro	Descrição	Exemplo
        Bucket Name	Nome do bucket. O nome deve ser globalmente exclusivo e não pode ser alterado após a criação do bucket. Convenções de nomenclatura: Pode conter apenas letras minúsculas, dígitos e hifens (-). Deve começar e terminar com uma letra minúscula ou um dígito. Deve ter de 3 a 63 caracteres.	migratetest
        Region	Região onde o bucket está localizado. Para utilizar a rede interna no upload a partir de uma instância ECS e na restauração para uma instância RDS, a instância ECS, o bucket e a instância RDS devem estar na mesma região.	China (Hangzhou)
        Storage Type	Selecione Standard. O método de migração descrito neste tópico não oferece suporte a buckets de outras classes de armazenamento.	Standard

2. Faça upload do arquivo de backup para o OSS.

   Após realizar o backup do banco de dados local, faça upload do arquivo de backup para um bucket do OSS que esteja na mesma região da sua instância RDS. Isso permite a comunicação pela rede interna, evitando cobranças de tráfego de internet e melhorando a velocidade de upload. Utilize um dos métodos a seguir:

   Usar a ferramenta ossbrowser (Recomendado)

   1. Baixe o ossbrowser.

   2. Por exemplo, em um sistema Windows x64, descompacte o pacote oss-browser-win32-x64.zip baixado e clique duas vezes no aplicativo oss-browser.exe.

   3. Utilize o método de logon AK, insira o Access Key ID e o Access Key Secret, mantenha os valores padrão para os demais parâmetros e clique em Log On.

      Nota

      Um AccessKey é utilizado para verificação de identidade, garantindo a segurança dos dados. Mantenha seu par de AccessKey em local seguro.

   4. Após o logon, clique em no bucket desejado na lista de Buckets — por exemplo, migratetest — para abrir a página de gerenciamento de arquivos.

   5. Clique em , selecione o arquivo de backup a ser enviado e clique em Open.

   Usar o console do OSS para fazer upload de arquivos

   Nota

   Recomenda-se usar o console do OSS para arquivos menores que 5 GB.

   1. Acesse o console do OSS.

   2. No painel de navegação à esquerda, clique em Buckets. Localize o bucket desejado e clique em seu nome, como migratetest, para abrir a página de detalhes.

   3. Na aba Files, clique em Upload File.

   4. No painel Upload Object, arraste o arquivo de backup para a área Files to Upload ou clique em Select Files. Mantenha a configuração padrão de object ACL, ou seja, Inherit from Bucket. O tamanho máximo de arquivo para esse método é 5 GB. Para arquivos maiores que 5 GB, utilize uma ferramenta como o ossutil para realizar upload em múltiplas partes.

   5. Clique em Upload File na parte inferior da página.

   Usar a API do OSS para upload em múltiplas partes

   Nota

   Recomenda-se utilizar a API de upload em múltiplas partes para arquivos maiores que 5 GB.

   O exemplo Java a seguir demonstra como obter um access credential a partir de variáveis de ambiente. Antes de executar este código, verifique se as variáveis de ambiente estão configuradas. Para mais exemplos, consulte Multipart upload.

   import com.aliyun.oss.*;
   import com.aliyun.oss.common.auth.*;
   import com.aliyun.oss.common.comm.SignVersion;
   import com.aliyun.oss.internal.Mimetypes;
   import com.aliyun.oss.model.*;
   import java.io.File;
   import java.io.FileInputStream;
   import java.io.InputStream;
   import java.util.ArrayList;
   import java.util.List;
   
   public class Demo {
   
       public static void main(String[] args) throws Exception {
           // Use the endpoint of the China (Hangzhou) region as an example. Specify the actual endpoint.
           String endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
           // Obtain access credentials from environment variables. Before you run the sample code, make sure that the OSS_ACCESS_KEY_ID and OSS_ACCESS_KEY_SECRET environment variables are configured.
           EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
           // Specify the bucket name, for example, examplebucket.
           String bucketName = "examplebucket";
           // Specify the full path of the object, for example, exampledir/exampleobject.txt. The full path cannot contain the bucket name.
           String objectName = "exampledir/exampleobject.txt";
           // The path of the local file to upload.
           String filePath = "D:\\localpath\\examplefile.txt";
           // Specify the region where the bucket is located. For example, if the bucket is in the China (Hangzhou) region, set the region to cn-hangzhou.
           String region = "cn-hangzhou";
   
           // Create an OSSClient instance.
           // When the OSSClient instance is no longer used, call the shutdown method to release resources.
           ClientBuilderConfiguration clientBuilderConfiguration = new ClientBuilderConfiguration();
           clientBuilderConfiguration.setSignatureVersion(SignVersion.V4);
           OSS ossClient = OSSClientBuilder.create()
                   .endpoint(endpoint)
                   .credentialsProvider(credentialsProvider)
                   .clientConfiguration(clientBuilderConfiguration)
                   .region(region)
                   .build();
   
           try {
               // Create an InitiateMultipartUploadRequest object.
               InitiateMultipartUploadRequest request = new InitiateMultipartUploadRequest(bucketName, objectName);
   
               // Create an ObjectMetadata object and set the Content-Type.
               ObjectMetadata metadata = new ObjectMetadata();
               if (metadata.getContentType() == null) {
                   metadata.setContentType(Mimetypes.getInstance().getMimetype(new File(filePath), objectName));
               }
               System.out.println("Content-Type: " + metadata.getContentType());
   
               // Bind the metadata to the upload request.
               request.setObjectMetadata(metadata);
   
               // Initialize the multipart upload.
               InitiateMultipartUploadResult upresult = ossClient.initiateMultipartUpload(request);
               // Return the upload ID.
               String uploadId = upresult.getUploadId();
   
               // partETags is a collection of PartETag objects. A PartETag object consists of the ETag and part number of a part.
               List<PartETag> partETags = new ArrayList<PartETag>();
               // The size of each part. This is used to calculate the number of parts. Unit: bytes.
               // The minimum part size is 100 KB, and the maximum part size is 5 GB. The size of the last part can be smaller than 100 KB.
               // Set the part size to 1 MB.
               final long partSize = 1 * 1024 * 1024L;   
   
               // Calculate the number of parts based on the size of the data to upload. The following code provides an example of how to obtain the size of the data to upload from a local file using File.length().
               final File sampleFile = new File(filePath);
               long fileLength = sampleFile.length();
               int partCount = (int) (fileLength / partSize);
               if (fileLength % partSize != 0) {
                   partCount++;
               }
               // Traverse the parts and upload them.
               for (int i = 0; i < partCount; i++) {
                   long startPos = i * partSize;
                   long curPartSize = (i + 1 == partCount) ? (fileLength - startPos) : partSize;
                   UploadPartRequest uploadPartRequest = new UploadPartRequest();
                   uploadPartRequest.setBucketName(bucketName);
                   uploadPartRequest.setKey(objectName);
                   uploadPartRequest.setUploadId(uploadId);
                   // Set the stream of the part to upload.
                   // The following code provides an example of how to create a FileInputStream object from a local file and skip the specified data using the InputStream.skip() method.
                   InputStream instream = new FileInputStream(sampleFile);
                   instream.skip(startPos);
                   uploadPartRequest.setInputStream(instream);
                   // Set the part size.
                   uploadPartRequest.setPartSize(curPartSize);
                   // Set the part number. Each uploaded part has a part number that ranges from 1 to 10,000. If the part number is not in the range, OSS returns the InvalidArgument error code.
                   uploadPartRequest.setPartNumber(i + 1);
                   // Parts do not need to be uploaded in sequence. They can even be uploaded from different clients. OSS sorts the parts by part number to create a complete object.
                   UploadPartResult uploadPartResult = ossClient.uploadPart(uploadPartRequest);
                   // After each part is uploaded, the OSS response includes a PartETag. The PartETag is saved in partETags.
                   partETags.add(uploadPartResult.getPartETag());
   
                   // Close the stream.
                   instream.close();
               }
   
               // Create a CompleteMultipartUploadRequest object.
               // When you complete the multipart upload, you must provide all valid partETags. After OSS receives the submitted partETags, it verifies the validity of each part. After all parts are verified, OSS combines these parts into a complete object.
               CompleteMultipartUploadRequest completeMultipartUploadRequest =
                       new CompleteMultipartUploadRequest(bucketName, objectName, uploadId, partETags);
   
               // Complete the multipart upload.
               CompleteMultipartUploadResult completeMultipartUploadResult = ossClient.completeMultipartUpload(completeMultipartUploadRequest);
               System.out.println("Upload successful, ETag: " + completeMultipartUploadResult.getETag());
   
           } catch (OSSException oe) {
               System.out.println("Caught an OSSException, which means your request made it to OSS, "
                       + "but was rejected with an error response for some reason.");
               System.out.println("Error Message:" + oe.getErrorMessage());
               System.out.println("Error Code:" + oe.getErrorCode());
               System.out.println("Request ID:" + oe.getRequestId());
               System.out.println("Host ID:" + oe.getHostId());
           } catch (ClientException ce) {
               System.out.println("Caught a ClientException, which means the client encountered "
                       + "a serious internal problem while trying to communicate with OSS, "
                       + "such as not being able to access the network.");
               System.out.println("Error Message:" + ce.getMessage());
           } finally {
               if (ossClient != null) {
                   ossClient.shutdown();
               }
           }
       }
   }

3. Criar uma tarefa de migração para a cloud

1. Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS está localizada. Em seguida, localize a instância RDS e clique em seu ID.

2. No painel de navegação à esquerda, clique em Restoration.

3. Na parte superior da página, clique em Restore Backup Data from OSS.

4. Na página Import Guide, clique em Next duas vezes para acessar a etapa Import Data.

   Nota

   Se esta é a primeira vez que você utiliza o recurso de migração de dados de backup do OSS para o RDS, será necessário autorizar a conta RDS a acessar o OSS. Clique em Authorize para conceder as permissões necessárias. Caso contrário, a lista suspensa OSS Bucket ficará vazia.

5. Defina os parâmetros a seguir e clique em Yes.

   Aguarde a conclusão da tarefa de migração para a cloud. Clique em Refresh para visualizar o status mais recente da tarefa. Se a tarefa falhar, solucione o problema com base na mensagem de erro presente na descrição da tarefa. Para mais informações, consulte Common errors.

   Parâmetro	Descrição
   Database Name	O nome do banco de dados de destino na instância RDS. O nome deve estar em conformidade com as convenções de nomenclatura do SQL Server. Importante Antes de iniciar a migração, verifique se a instância de destino não possui banco de dados existente nem arquivo de banco de dados desanexado com o mesmo nome do banco de dados presente no arquivo de backup. Se já existir um banco de dados com o mesmo nome do especificado no arquivo de backup na instância de destino, ou se houver um arquivo de banco de dados desanexado com o mesmo nome, a migração para a cloud falhará.
   OSS Bucket	Selecione o bucket do OSS onde o arquivo de backup está armazenado.
   OSS File	Clique no ícone de lupa para realizar uma pesquisa aproximada de arquivos de backup por prefixo. Os resultados exibem o nome do arquivo, o tamanho e a data da última modificação. Selecione o arquivo de backup a ser migrado.
   Cloud Migration Method	Selecione Do Not Open Database. Immediate Access (Full Backup): utilize este método para uma migração completa de dados para a cloud quando houver um único arquivo de backup completo. Para esta opção, a operação CreateMigrateTask utiliza os seguintes parâmetros: BackupMode = FULL e IsOnlineDB = True. Access Pending (Incremental Backup): utilize este método para uma migração incremental de dados para a cloud quando for necessário migrar um backup completo seguido de backups diferenciais ou arquivos de log. Para esta opção, a operação CreateMigrateTask utiliza os seguintes parâmetros: BackupMode = UPDF e IsOnlineDB = False.

4. Importar backups diferenciais ou de log

Após migrar o backup completo do seu banco de dados SQL Server autogerenciado, importe os arquivos de backup diferencial ou de log.

1. Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS está localizada. Em seguida, localize a instância RDS e clique em seu ID.

2. No painel de navegação à esquerda, clique em Restoration e, em seguida, na aba Backup Data Upload History.

3. Na lista de tarefas, localize a tarefa correspondente e clique em Upload Incremental Files na coluna Actions. Selecione o arquivo incremental e clique em OK.

   Nota

   • Se houver múltiplos arquivos de backup de log, crie uma tarefa de migração separada para cada um.

   • Certifique-se de que o arquivo de backup final não ultrapasse 500 MB. Isso minimizará o tempo necessário para a migração incremental para a cloud.

   • Antes de gerar o arquivo de backup de log final, interrompa todas as operações de escrita no banco de dados autogerenciado. Isso garante a consistência dos dados entre o banco de dados autogerenciado e a instância RDS for SQL Server.

5. Abrir o banco de dados

Após importar um arquivo de backup, o banco de dados na instância ApsaraDB RDS for SQL Server entra no estado In Recovery ou Restoring. Para instâncias da edição High-availability, o estado é In Recovery; já para instâncias da edição Basic, o estado é Restoring. Em ambos os estados, o banco de dados fica indisponível para operações de leitura e escrita. É necessário abrir o banco de dados para torná-lo disponível.

1. Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS está localizada. Em seguida, localize a instância RDS e clique em seu ID.

2. No painel de navegação à esquerda, escolha Restoration e clique na aba Cloud Migration Records of Backup Data.

3. Na lista de tarefas, localize o registro da importação do arquivo de backup e clique em Open Database na coluna Actions.

4. Selecione uma opção de verificação de consistência do banco de dados e clique em OK.

   Nota

   As seguintes opções estão disponíveis para a verificação de consistência do banco de dados:

   • Asynchronous DBCC: esta opção executa a operação DBCC CHECKDB de forma assíncrona após a abertura do banco de dados. Esse método reduz o tempo de inatividade ao colocar o banco de dados online mais rapidamente. É ideal quando o banco de dados é grande e a operação DBCC CHECKDB consome muito tempo. Use esta opção se o seu serviço é sensível a tempo de inatividade e você não precisa dos resultados imediatos da verificação. Na chamada da API CreateMigrateTask, esta opção define o parâmetro CheckDBMode como AsyncExecuteDBCheck.

   • Synchronous DBCC: esta opção executa a operação DBCC CHECKDB no momento da abertura do banco de dados. Esse método permite verificar imediatamente a consistência dos dados e identificar eventuais erros. Opte por esta alternativa quando a verificação dos dados for prioritária — porém, tenha em mente que ela aumenta o tempo necessário para abrir o banco de dados. Na chamada da API CreateMigrateTask, esta opção define o parâmetro CheckDBMode como SyncExecuteDBCheck.

6. Visualizar detalhes do backup de migração para a cloud

Para visualizar os detalhes do arquivo de backup de uma tarefa de migração para a cloud, acesse a página Restoration no painel de navegação à esquerda da instância RDS. Na aba Cloud Migration Records of Backup Data, localize a tarefa e clique em View File Details na coluna mais à direita.

Erros comuns

Para erros comuns durante a migração de dados de backup completo, consulte Common errors in full backup data migration.

Os seguintes erros podem ocorrer durante um upload incremental:

• Falha ao abrir o banco de dados

  • Mensagem de erro: Failed to open database xxx.

  • Causa: o banco de dados SQL Server de origem utiliza recursos avançados não suportados pela edição da instância ApsaraDB RDS for SQL Server selecionada. Por exemplo, esse erro ocorre quando a instância SQL Server de origem executa a Enterprise Edition com compressão de dados ou particionamento ativado, e os dados são migrados para uma instância ApsaraDB RDS for SQL Server na edição Web.

  • Solução:

    • Desative os recursos avançados na instância SQL Server de origem, crie um novo backup e tente a migração novamente.

    • Adquira uma instância ApsaraDB RDS for SQL Server com a mesma edição do SQL Server da instância de origem. Para mais informações, consulte Create an ApsaraDB RDS for SQL Server instance.

      Nota

      Para mais informações, consulte Feature comparison among different SQL Server versions and RDS editions.

• Incompatibilidade de LSN na cadeia de backup

  • Mensagem de erro: The log in this backup set begins at LSN XXX, which is too recent to apply to the database. RESTORE LOG is terminating abnormally.

  • Causa: no SQL Server, um backup diferencial ou de log só pode ser restaurado se o seu Log Sequence Number (LSN) inicial estiver alinhado com o LSN do arquivo de backup restaurado anteriormente. Esse erro ocorre quando os LSNs não coincidem.

  • Solução: selecione os arquivos de backup com LSNs correspondentes para o upload incremental. Certifique-se de enviar os arquivos de backup em ordem cronológica.

• Falha no DBCC CHECKDB assíncrono

  • Mensagem de erro: asynchronously DBCC checkdb failed: CHECKDB found 0 allocation errors and 2 consistency errors in table 'XXX' (object ID XXX).

  • Causa: após a restauração do arquivo de backup na instância ApsaraDB RDS for SQL Server, o sistema executa um DBCC CHECKDB assíncrono. Se essa verificação falhar, isso indica que o banco de dados de origem já continha erros de consistência.

  • Solução:

    • Na instância ApsaraDB RDS for SQL Server de destino, execute o seguinte comando:

      DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)

      Importante

      Este comando de reparo pode causar perda de dados.

    • Na instância de origem, execute o comando a seguir para corrigir os erros e, em seguida, tente o upload incremental novamente.

      DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)

• Tipo de arquivo de backup incorreto para upload incremental

  • Mensagem de erro: Backup set (xxx) is a Database FULL backup, we only accept transaction log or differential backup.

  • Causa: durante um upload incremental para uma instância ApsaraDB RDS for SQL Server, o sistema aceita apenas arquivos de backup de log ou backups diferenciais após a restauração de um backup completo. Esse erro ocorre ao selecionar novamente um arquivo de backup completo.

  • Solução: selecione um arquivo de backup de log ou um arquivo de backup diferencial.

• Quantidade de bancos de dados excede o limite

  • Mensagem de erro: The database (xxx) migration failed due to databases count limitation.

  • Causa: esse erro ocorre ao migrar um banco de dados para uma instância que já atingiu seu limite máximo de bancos de dados.

  • Solução: migre o banco de dados para outra instância ApsaraDB RDS for SQL Server ou exclua bancos de dados desnecessários da instância atual.

• Permissões insuficientes do usuário RAM

  • P1: Na Etapa 5 de Create a data migration task, por que o botão OK está esmaecido e não pode ser clicado, mesmo com todos os parâmetros configurados?

  • R1: Isso pode ocorrer caso o usuário RAM não possua as permissões necessárias. Consulte a seção Prerequisites neste tópico e conceda as permissões necessárias.

  • P2: Como resolver o erro no permission que ocorre quando um usuário RAM tenta conceder a função AliyunRDSImportRole?

  • R2: Use sua conta Alibaba Cloud para conceder temporariamente a permissão AliyunRAMFullAccess ao usuário RAM. Para instruções sobre como conceder permissões a um usuário RAM, consulte Use RAM to manage ApsaraDB RDS permissions.

• Backup incremental restaurado em um backup completo incorreto

  • Mensagem de erro: This differential backup cannot be restored because the database is not in the correct state. RESTORE DATABASE is terminating abnormally.

  • Causa: esse erro ocorre quando um backup incremental mais recente é restaurado sobre um backup completo mais antigo. Isso rompe a cadeia de backup porque o LSN do arquivo de backup diferencial não está alinhado com o LSN do arquivo de backup completo restaurado com a opção NORECOVERY.

  • Solução: confirme que os arquivos de backup corretos foram selecionados e que estão sendo enviados na ordem correta. Você pode consultar a tabela msdb.dbo.backupset na instância de origem para verificar a ordem e a relação de LSN entre os arquivos de backup completo e diferencial.

• Erro com backups Striped de múltiplos arquivos

  • Mensagem de erro: Failed to verify (xxx.bak), error message:The media set has xxx media families but only 1 are provided. All members must be provided. VERIFY DATABASE is terminating abnormally.

  • Causa: o banco de dados de origem foi copiado utilizando o recurso Striped Backup, que grava um único backup completo em múltiplos arquivos .bak. No entanto, apenas um desses arquivos foi fornecido para a tarefa de migração. O ApsaraDB RDS for SQL Server não suporta a migração de dados a partir de múltiplos arquivos de backup em uma única tarefa.

  • Solução: faça o backup do banco de dados de origem em um único arquivo .bak e tente o upload novamente.

Operações de API relacionadas