Georgi Koemdzhiev's questions

Nossa equipe está migrando um de nossos bancos de dados para o Amazon RDS MS SQL Server. Como parte disso, temos que reescrever alguns de nossos procedimentos armazenados.

Temos um procedimento armazenado que realiza um backup do banco de dados para um armazenamento de rede.

BACKUP DATABASE [MyDB] TO DISK = '\\myserver\share\MydbBackup.bak'
WITH RETAINDAYS = 0,
    INIT

O procedimento armazenado acima está bloqueando, ou seja, ele pausará a linha de execução - exec stored_proc- até que o backup seja concluído.

Eu alterei esse procedimento armazenado para que ele use o rds_backup_databaseproc armazenado para que o backup seja salvo em um bucket do S3.

exec msdb.dbo.rds_backup_database
    @source_db_name='MyDB',
    @s3_arn_to_backup_to='arn:aws:s3:::temp-poc-bucket/db_backups/MyDBBackup.bak',
    @overwrite_s3_backup_file=1;

O problema é que nosso fluxo de trabalho (o procedimento armazenado é chamado de nosso aplicativo) exige que ele seja síncrono.

Existe alguma maneira de "aguardar" a execução do msdb.dbo.rds_backup_databaseprocedimento armazenado?

Documentos do AWS RDS .

Estou procurando uma maneira de configurar a replicação contínua de dados entre um Microsoft SQL Server local para o AWS RDS PostgreSQL. A tabela de origem é atualizada uma vez a cada 24 horas . O desafio aqui é que eu não tenho nenhum controle sobre o banco de dados de origem (on-prem). Tudo o que tenho é um usuário de banco de dados que posso usar para consultar o banco de dados. Em poucas palavras, estou procurando os seguintes requisitos:

• A máquina de origem não deve ser modificada de forma alguma (ou seja, aplicando configurações à máquina de origem)
• Barato (não requer um servidor de migração para funcionar 24 horas por dia, 7 dias por semana) e fácil de gerenciar (configure uma vez e esqueça)
• Idealmente, a solução deve migrar apenas as alterações feitas na tabela de banco de dados de origem, como adicionar/remover registros. Em outras palavras, evite esvaziar a tabela de destino e preenchê-la novamente com os registros da tabela de origem (é isso que o AWS DMS " Full-Load " faria)

Eu estava analisando a replicação contínua do AWS DMS, mas ela exige alterações na máquina de origem, então tive que descartar essa solução (consulte Usar um banco de dados do Microsoft SQL Server como origem para o AWS DMS ). Além disso, essa solução exigiria uma " Instância de replicação " para ser executada 24 horas por dia, 7 dias por semana.

Há mais alguma coisa que eu deveria estar olhando que satisfaça os requisitos acima? Ou minha única opção seria ir com a migração "Full-Load" do AWS DMS, que seria uma solução potencialmente cara, desde a frequência de atualizações na tabela do banco de dados de origem?

Agradeço qualquer opinião sobre o problema, por favor.