Migración de bases de datos de SQL Server a Azure SQL Managed Instance con Log Replay Service - Azure SQL Managed Instance

Se aplica a:Azure SQL Managed Instance

En este artículo se explica cómo migrar bases de datos a Azure SQL Managed Instance mediante el servicio de reproducción de registros (LRS). LRS es un servicio en la nube gratuito que está disponible para Azure SQL Managed Instance y que se basa en la tecnología de trasvase de registros de SQL Server.

Se admiten los siguientes orígenes:

  • SQL Server en Virtual Machines
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon RDS (Relational Database Service) para SQL Server
  • Google Compute Engine
  • Cloud SQL para SQL Server, GCP (Google Cloud Platform)

Prerrequisitos

Antes de empezar, tenga en cuenta los siguientes requisitos para su instancia de SQL Server y Azure.

SQL Server

Asegúrese de cumplir los siguientes requisitos para SQL Server:

  • Versiones 2008 a 2022 de SQL Server.
  • La base de datos de SQL Server usa el modelo de recuperación completa (obligatorio).
  • Copia de seguridad completa de las bases de datos (uno o varios archivos).
  • Copia de seguridad diferencial (uno o varios archivos).
  • Copia de seguridad de los registros (sin dividir en el caso del archivo de registro de transacciones).
  • Para las versiones 2008-2016 de SQL Server, realice una copia de seguridad en modo local y cárguela manualmente en su cuenta de Azure Blob Storage.
  • Para SQL Server 2016 y versiones posteriores, puede realizar la copia de seguridad directamente en su cuenta de Azure Blob Storage.

Aunque no es necesario tener CHECKSUM habilitado para copias de seguridad, se recomienda encarecidamente para agilizar las operaciones de restauración.

Azure

Asegúrese de cumplir los siguientes requisitos para Azure:

  • El módulo Az.SQL de PowerShell versión 4.0.0 o posterior (instalado o con acceso desde Azure Cloud Shell).
  • La CLI de Azure versión 2.42.0 o posterior (instalada).
  • Contenedor de Azure Blob Storage aprovisionado.
  • Token de seguridad de firma de acceso compartido (SAS) con permisos de lectura y lista generados para el contenedor de Blob Storage, o bien una identidad administrada que pueda acceder al contenedor.
  • Ponga los archivos de copia de seguridad de cada base de datos en una carpeta aparte en una cuenta de almacenamiento usando una estructura de archivos plana (obligatorio). No se admite el anidamiento de carpetas dentro de carpetas de base de datos.

Permisos de Azure RBAC

Para ejecutar LRS con los clientes proporcionados, se necesita alguno de los siguientes roles de Azure:

procedimientos recomendados

Cuando use LRS, tenga en cuenta los siguientes procedimientos recomendados:

  • Ejecute Data Migration Assistant para asegurarse de que las bases de datos están listas para la migración a SQL Managed Instance.
  • Divida las copias de seguridad completas y diferenciales en varios archivos, en lugar de usar uno solo.
  • Habilite la compresión de copia de seguridad para ayudar con las velocidades de transferencia de red.
  • Use Cloud Shell para ejecutar los scripts de la CLI o de PowerShell, ya que siempre está actualizado con los últimos cmdlets publicados.
  • Configure la ventana de mantenimiento para permitir la programación de actualizaciones del sistema en un día y hora específicos. Esta configuración permite predecir mejor el tiempo que tardará la migración de las bases de datos, ya que las actualizaciones del sistema pueden interrumpir las migraciones en curso.
  • Planee completar un único trabajo de migración de LRS en un máximo de 30 días. Cuando transcurre este período de tiempo, el trabajo de LRS se cancela automáticamente.
  • Para una restauración más rápida de las bases de datos, habilite CHECKSUM cuando cree las copias de seguridad. SQL Managed Instance comprueba la integridad de las copias de seguridad sin CHECKSUM, lo que aumenta el tiempo de restauración.

Las actualizaciones del sistema para SQL Managed Instance tienen prioridad sobre las migraciones de bases de datos en curso. Durante una actualización del sistema en una instancia, todas las migraciones de LRS pendientes se suspenden y se reanudan solo después de aplicar la actualización. Este comportamiento del sistema puede prolongar el tiempo de migración, especialmente en los casos de bases de datos de gran tamaño.

Para poder predecir el tiempo que tardará la migración de las bases de datos, puede configurar una ventana de mantenimiento para programar las actualizaciones del sistema en un día y hora específicos, y ejecutar y completar los trabajos de migración fuera del período de tiempo designado para el mantenimiento.

Importante

  • Las bases de datos que se están restaurando con LRS no se pueden usar hasta que finalice el proceso de migración.
  • LRS no admite el acceso de solo lectura a las bases de datos durante la migración.
  • Una vez completada la migración, el proceso de migración es final y no se puede reanudar con copias de seguridad diferenciales adicionales.

Migración de varias bases de datos

Si migra varias bases de datos usando el mismo contenedor de Azure Blob Storage, debe colocar los archivos de copia de seguridad de las distintas bases de datos en carpetas diferentes dentro del contenedor. Todos los archivos de copia de seguridad de una misma base de datos deben colocarse en una carpeta para esa base de datos dentro de una estructura de archivos plana. No se permite anidar carpetas. No se admite el anidamiento de carpetas dentro de carpetas de base de datos.

El siguiente es un ejemplo de una estructura de carpetas dentro de un contenedor de Azure Blob Storage. Esta estructura es necesaria para migrar varias bases de datos con LRS.

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure. 
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

Crear una cuenta de almacenamiento

Use una cuenta de Azure Blob Storage como almacenamiento intermedio para los archivos de copia de seguridad entre la instancia de SQL Server y la implementación de SQL Managed Instance. Para crear una nueva cuenta de almacenamiento y un contenedor de blobs dentro de esa cuenta:

  1. Crear una cuenta de almacenamiento.
  2. Cree un contenedor de blobs dentro de la cuenta de almacenamiento.

Configuración de Azure Storage detrás de un firewall

Se admite el uso de Azure Blob Storage protegido detrás de un firewall, pero requiere una configuración adicional. Para habilitar el acceso de lectura y escritura a Azure Storage con Azure Firewall activado, debe agregar la subred de la instancia administrada de SQL a las reglas de firewall de la red virtual para la cuenta de almacenamiento utilizando la delegación de subred MI y el punto de conexión del servicio de Storage. La cuenta de almacenamiento y la instancia administrada deben estar en la misma región o en dos regiones emparejadas.

Si Azure Storage está detrás de un firewall, es posible que vea el siguiente mensaje en el registro de errores de la instancia administrada de SQL:

Audit: Storage access denied user fault. Creating an email notification:

Esto genera un correo electrónico que le notifica que la auditoría de la instancia administrada de SQL no puede escribir registros de auditoría en la cuenta de almacenamiento. Si ve este error o recibe este correo electrónico, siga los pasos de esta sección para configurar el firewall.

Para configurar el firewall, siga estos pasos:

  1. Vaya a la instancia administrada en Azure Portal y seleccione la subred para abrir la página Subredes.

    Screenshot of the SQL managed instance Overview page of the Azure portal, with the subnet selected.

  2. En la página Subredes, seleccione el nombre de la subred para abrir la página de configuración de subred.

    Screenshot of the SQL managed instance Subnet page of the Azure portal, with the subnet selected.

  3. En Delegación de subred, elija Microsoft.Sql/managedInstances en el menú desplegable Delegar subred a un servicio. Espere aproximadamente una hora a que los permisos se propaguen y, en Puntos de conexión de servicio, elija Microsoft.Storage en la lista desplegable Servicios.

    Screenshot of the SQL managed instance Subnet configuration page of the Azure portal.

  4. A continuación, vaya a la cuenta de almacenamiento en Azure Portal, seleccione Redes en Seguridad y redes y elija la pestaña Firewalls y redes virtuales.

  5. En la pestaña Firewalls y redes virtuales de la cuenta de almacenamiento, elija +Agregar red virtual existente para abrir la página Agregar redes.

    Screenshot of the Storage Account Networking page of the Azure portal, with Add existing virtual network selected.

  6. Seleccione la suscripción adecuada, la red virtual y la subred de instancia administrada en los menús desplegables y, a continuación, elija Agregar para agregar la red virtual de la instancia administrada de SQL a la cuenta de almacenamiento.

Autenticación en la cuenta de Blob Storage

Use un token de SAS o una identidad administrada para acceder a la cuenta de Azure Blob Storage.

Advertencia

No se pueden usar un token de SAS y una identidad administrada en paralelo en la misma cuenta de almacenamiento. Puede usar un token de SAS o una identidad administrada, pero no ambos.

Generación de un token de autenticación de SAS de Blob Storage para LRS

Acceda a la cuenta de Azure Blob Storage con un token de SAS.

Puede usar una cuenta de Azure Blob Storage como almacenamiento intermedio para los archivos de copia de seguridad entre la instancia de SQL Server y la implementación de SQL Managed Instance. Genere un token de autenticación de SAS para LRS solo con permisos de lista y lectura. El token permite que LRS acceda a Blob Storage y use los archivos de copia de seguridad para restaurarlos en la instancia administrada.

Siga estos pasos para generar el token:

  1. En Azure Portal, abra el Explorador de Storage.

  2. Expanda Contenedores de blobs.

  3. Haga clic con el botón derecho en el contenedor de blobs y seleccione Obtener firma de acceso compartido.

    Screenshot that shows selections for generating a SAS authentication token.

  4. Seleccione el plazo de tiempo de expiración del token. Asegúrese de que el token sea válido durante la migración.

  5. Seleccione la zona horaria del token (UTC o la hora local).

    Importante

    Puede que la zona horaria del token y de la instancia administrada no coincidan. Asegúrese de que el token de SAS tenga la validez temporal adecuada teniendo en cuenta las zonas horarias. Para tener en cuenta las diferencias de zona horaria, establezca el valor DESDE del período de validez antes de que se inicie el período de migración, y el valor HASTA, bastante después del tiempo previsto para que finalice la migración.

  6. Seleccione únicamente los permisos Lectura y Lista.

    Importante

    No seleccione ningún otro permiso. Si lo hace, LRS no se iniciará. Este requisito de seguridad es así por naturaleza.

  7. Seleccione Crear.

    Screenshot that shows selections for SAS token expiration, time zone, and permissions, along with the Create button.

La autenticación de SAS se genera con la validez de tiempo que ha especificado. Necesita la versión del URI del token, como se muestra en la siguiente captura de pantalla:

Screenshot that shows an example of the URI version of a SAS token.

Nota:

Actualmente, no se admite el uso de tokens de SAS creados con permisos establecidos con la definición de una directiva de acceso almacenada. Siga las instrucciones de este artículo para especificar manualmente los permisos de lectura y lista para el token de SAS.

Copia de parámetros del token de SAS

Acceda a la cuenta de Azure Blob Storage con un token de SAS o una identidad administrada.

Antes de usar el token de SAS para iniciar LRS, debe comprender su estructura. El URI del token de SAS generado consta de dos partes separadas por un signo de interrogación (?), como se muestra en este ejemplo:

Example URI for a generated SAS token for Log Replay Service.

La primera parte, desde https:// hasta el signo de interrogación (?), se usa en el parámetro StorageContainerURI que se suministra como entrada a LRS. Proporciona a LRS información sobre la carpeta donde se almacenan los archivos de copia de seguridad de la base de datos.

La segunda parte, desde después del signo de interrogación (?) hasta el final de la cadena, es el parámetro StorageContainerSasToken. Esta parte es el token de autenticación firmado, que es válido durante el tiempo especificado. No es necesario que esta parte comience con sp= como se muestra en el ejemplo. En su caso, puede ser diferente.

Copie los parámetros de la manera siguiente:

  1. Copie la primera parte del token, desde https:// hasta el signo de interrogación (?), sin incluir el signo. Úsela como parámetro StorageContainerUri en PowerShell o en la CLI de Azure cuando inicie LRS.

    Screenshot that shows where to copy the first part of the token.

  2. Copie la segunda parte del token, desde después del signo de interrogación (?) hasta el final de la cadena. Úsela como parámetro StorageContainerSasToken en PowerShell o en la CLI de Azure cuando inicie LRS.

    Screenshot that shows where to copy the second part of the token.

Nota:

No incluya el signo de interrogación al copiar ninguna de las partes del token.

Validación del acceso de la instancia administrada al almacenamiento

Compruebe que la instancia administrada pueda acceder a la cuenta de Blob Storage.

Primero, cargue cualquier copia de seguridad de base de datos, como full_0_0.bak, en el contenedor de Azure Blob Storage.

Después, conéctese a la instancia administrada y ejecute una consulta de prueba para determinar si la instancia administrada puede acceder a la copia de seguridad en el contenedor.

Si usa un token de SAS para autenticarse en la cuenta de almacenamiento, reemplace <sastoken> por el token de SAS y ejecute la siguiente consulta en la instancia:

CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE' 
, SECRET = '<sastoken>' 

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak' 

Carga de las copias de seguridad en la cuenta de Blob Storage

Cuando el contenedor de blobs esté listo y haya confirmado que la instancia administrada puede acceder a él, puede empezar a cargar las copias de seguridad en Blob Storage. Puede:

  • Copie las copias de seguridad en la cuenta de Blob Storage.
  • Cree las copias de seguridad de SQL Server directamente en la cuenta de Blob Storage usando el comando BACKUP TO URL, si el entorno lo permite (a partir de las versiones 2012 SP1 CU2 y 2014 de SQL Server).

Copia de las copias de seguridad en la cuenta de Blob Storage

Si utiliza una versión anterior de SQL Server o su entorno no admite la copia de seguridad directamente en una dirección URL, realice las copias de seguridad en SQL Server como lo haría normalmente y, luego, cópielas en Azure Blob Storage.

Creación de copias de seguridad en una instancia de SQL Server

Establezca las bases de datos que quiere migrar en el modo de recuperación completa para permitir copias de seguridad de registros.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO

Para realizar manualmente copias de seguridad completas, diferenciales y de registros de la base de datos en el almacenamiento local, use los siguientes scripts de T-SQL de ejemplo. CHECKSUM no es necesario, pero se recomienda.

En el ejemplo siguiente, se realiza una copia de seguridad completa de la base de datos en el disco local:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

En el ejemplo siguiente, se realiza una copia de seguridad diferencial en el disco local:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

En el ejemplo siguiente, se realiza una copia de seguridad de registros en el disco local:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO

Copia de las copias de seguridad en la cuenta de Blob Storage

Cuando las copias de seguridad estén listas y quiera empezar a migrar las bases de datos a una instancia administrada usando LRS, puede usar los siguientes métodos para copiar las copias de seguridad en su cuenta de Blob Storage:

Nota

Para migrar varias bases de datos usando el mismo contenedor de Azure Blob Storage, ponga todos los archivos de copia de seguridad de cada base de datos en una carpeta aparte dentro del contenedor. Use una estructura de archivos plana para cada carpeta de base de datos. No se admite el anidamiento de carpetas dentro de carpetas de base de datos.

Creación de copias de seguridad directamente en la cuenta de Blob Storage

Si utiliza una versión admitida de SQL Server (a partir de las versiones 2012 SP1 CU2 y 2014) y las directivas corporativas y de red lo permiten, puede realizar copias de seguridad de SQL Server directamente en su cuenta de Blob Storage con la opción nativa de SQL Server BACKUP TO URL. Si puede usar BACKUP TO URL, no es necesario que realice las copias de seguridad en el almacenamiento local y las cargue después en Blob Storage.

Cuando realiza copias de seguridad nativas directamente en Azure Blob Storage, debe autenticarse en la cuenta de almacenamiento.

Use el siguiente comando para crear una credencial que importe el token de SAS a la instancia de SQL Server:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',  
SECRET = '<SAS_TOKEN>';  

Para obtener instrucciones detalladas sobre cómo trabajar con tokens de SAS, consulte el tutorial Uso de Azure Blob Storage con SQL Server 2016.

Después de crear la credencial para autenticar la instancia de SQL Server con Blob Storage, puede usar el comando BACKUP TO URL para realizar copias de seguridad directamente en la cuenta de almacenamiento. Se recomienda CHECKSUM, pero no es necesario.

En el ejemplo siguiente, se realiza una copia de seguridad completa de la base de datos en una dirección URL:

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

En el ejemplo siguiente, se realiza una copia de seguridad diferencial de la base de datos en una dirección URL:

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'  
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

En el ejemplo siguiente, se realiza una copia de seguridad de registros en una dirección URL:

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'  
WITH COMPRESSION, CHECKSUM

Inicio de sesión en Azure y selección de una suscripción

Utilice el siguiente cmdlet de PowerShell para iniciar sesión en Azure:

Login-AzAccount

Seleccione la suscripción en la que se encuentre la instancia administrada con el siguiente cmdlet de PowerShell:

Select-AzSubscription -SubscriptionId <subscription ID>

Inicio de la migración

Inicie la migración al iniciar LRS. Puede iniciar el servicio en modo autocompletar o continuo.

Cuando se utiliza el modo autocompletar, la migración finaliza automáticamente cuando se restaura el último de los archivos de copia de seguridad especificados. Esta opción requiere que toda la cadena de copia de seguridad esté disponible de antemano y se cargue en Azure Blob Storage. No permite agregar nuevos archivos de copia de seguridad mientras la migración está en curso. Esta opción requiere que el comando start especifique el nombre del último archivo de copia de seguridad. Se recomienda este modo para cargas de trabajo pasivas para las que no se requiere ninguna puesta al día de datos.

Cuando se usa el modo continuo, el servicio examina continuamente la carpeta de Azure Blob Storage y restaura los nuevos archivos de copia de seguridad que se siguen agregando mientras la migración está en curso. La migración solo se completa después de haberse solicitado la transición manual. La migración en modo continuo debe usarse cuando no se tiene la cadena de copia de seguridad entera de antemano y cuando se planea agregar nuevos archivos de copia de seguridad una vez que la migración esté en curso. Este modo se recomienda para las cargas de trabajo activas en las que se requiere la actualización de los datos.

Planee completar un único trabajo de migración de LRS en un máximo de 30 días. Cuando este tiempo expira, el trabajo LRS se cancela automáticamente.

Nota

Cuando se migran varias bases de datos, LRS debe iniciarse por separado para cada base de datos y apuntar a la ruta de acceso completa del URI del contenedor de Azure Blob Storage y la carpeta de la base de datos.

Inicio de LRS en modo autocompletar

Asegúrese de que se haya cargado toda la cadena de copia de seguridad en la cuenta de Azure Blob Storage. Esta opción no permite agregar nuevos archivos de copia de seguridad una vez que la migración está en curso.

Para iniciar LRS en modo autocompletar, use los comandos de PowerShell o de la CLI de Azure. Especifique el nombre del último archivo de copia de seguridad con el parámetro -LastBackupName. Una vez finalizada la restauración del último archivo de copia de seguridad especificado, el servicio inicia automáticamente una transición.

Restaure la base de datos desde la cuenta de almacenamiento usando el token de SAS o una identidad administrada.

Importante

  • Asegúrese de que toda la cadena de copia de seguridad se haya cargado en Azure Blob Storage antes de iniciar la migración en modo autocompletar. Este modo no permite que se agreguen nuevos archivos de copia de seguridad mientras la migración está en curso.
  • Asegúrese de que ha especificado correctamente el último archivo de copia de seguridad y de que no ha cargado más archivos después. Si el sistema detecta más archivos de copia de seguridad más allá del último archivo de copia de seguridad especificado, se producirá un error en la migración.

En el siguiente ejemplo de PowerShell, se inicia LRS en modo autocompletar usando un token de SAS:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

En el siguiente ejemplo de la CLI de Azure, se inicia LRS en modo autocompletar usando un token de SAS:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Inicio de LRS en modo continuo

Asegúrese de que ha cargado la cadena de copia de seguridad inicial en la cuenta de Azure Blob Storage.

Importante

Después de haberse iniciado LRS en modo continuo, puede agregar nuevas copias de seguridad diferenciales y de registro a Azure Blob Storage hasta que tenga lugar la transición manual. Una vez iniciada la transición manual, no se pueden agregar ni restaurar archivos diferenciales adicionales.

En el siguiente ejemplo de PowerShell, se inicia LRS en modo continuo usando un token de SAS:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

En el siguiente ejemplo de la CLI de Azure, se inicia LRS en modo continuo:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Scripting del trabajo de migración

Los clientes de PowerShell y de la CLI de Azure que inician LRS en modo continuo son sincrónicos. En este modo, PowerShell y la CLI de Azure esperan a la respuesta de la API para notificar la ejecución correcta o con errores antes de iniciar el trabajo.

Durante esta espera, el comando no devolverá el control al símbolo del sistema. Si va a usar un script para la migración y necesita que el comando de inicio de LRS devuelva el control inmediatamente para continuar con el resto del script, puede ejecutar PowerShell como trabajo en segundo plano con el modificador -AsJob. Por ejemplo:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

Cuando se inicia un trabajo en segundo plano, se devuelve inmediatamente un objeto de trabajo, incluso aunque el trabajo tarde mucho en finalizar. Puede seguir trabajando en la sesión sin interrupción mientras se ejecuta el trabajo. Para más información sobre la ejecución de PowerShell como un trabajo en segundo plano, consulte la documentación sobre el cmdlet Start-Job de PowerShell.

Del mismo modo, para iniciar un comando de la CLI de Azure en Linux como un proceso en segundo plano, use el signo de "y" comercial (&) al final del comando de inicio de LRS:

az sql midb log-replay start <required parameters> &

Supervisión del progreso de la migración

Az.SQL 4.0.0 y versiones posteriores proporciona un informe de progreso detallado. Revise Detalles de restauración de bases de datos administradas: Get para obtener una salida de ejemplo.

Para supervisar el progreso de la migración mediante PowerShell, use el siguiente comando:

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Para supervisar el progreso de la migración mediante la CLI de Azure, use el siguiente comando:

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

Detención de la migración (opcional)

Si tiene que detener la migración, utilice PowerShell o la CLI de Azure. Al detener la migración, se elimina la base de datos que se está restaurando en la instancia administrada, de modo que no es posible reanudar la migración.

Para detener el proceso de migración mediante PowerShell, use el siguiente comando:

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Para detener el proceso de migración mediante la CLI de Azure, use el siguiente comando:

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

Finalización de la migración (modo continuo)

Si inicia LRS en modo continuo, asegúrese de que la aplicación y la carga de trabajo de SQL Server se hayan detenido para evitar que se generen nuevos archivos de copia de seguridad. Asegúrese de que la última copia de seguridad de la instancia de SQL Server se haya cargado en su cuenta de Azure Blob Storage. Supervise el progreso de restauración en la instancia administrada y asegúrese de que se ha restaurado la última copia de seguridad de la cola de registros.

Cuando se haya restaurado la última copia de seguridad de la cola de registros en la instancia administrada, inicie la transición manual para completar la migración. Una vez finalizada la transición, la base de datos está disponible para el acceso de lectura y escritura en la instancia administrada.

Para finalizar el proceso de migración en modo continuo de LRS mediante PowerShell, use el siguiente comando:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Para finalizar el proceso de migración en modo continuo de LRS mediante la CLI de Azure, use el siguiente comando:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Solución de problemas de LRS

Después de iniciar LRS, utilice cualquiera de los siguientes cmdlets de supervisión para ver el estado de la operación:

  • Para PowerShell: get-azsqlinstancedatabaselogreplay
  • Para la CLI de Azure: az_sql_midb_log_replay_show

Si LRS no se inicia después de un tiempo y se produce un error, compruebe los problemas más comunes:

  • ¿Hay una base de datos en la instancia administrada que tenga el mismo nombre que la que está intentando migrar desde la instancia de SQL Server? Para resolver este conflicto, cambie el nombre de una de las bases de datos.
  • ¿Los permisos concedidos para el token de SAS son solo de lectura y lista?
  • ¿Ha copiado el token de SAS para LRS que aparece después del signo de interrogación (?), con un contenido similar a sv=2020-02-10...
  • ¿El tiempo de validez del token de SAS es adecuado para el período de tiempo de inicio y finalización de la migración? Puede haber discrepancias debido a que se usen distintas zonas horarias para la implementación de SQL Managed Instance y el token de SAS. Intente volver a generar el token de SAS ampliando la ventana de tiempo de validez del token antes y después de la fecha actual.
  • Al iniciar varias restauraciones de Reproducción de registros en paralelo en las que el destino es el mismo contenedor de almacenamiento, asegúrese de que se proporciona el mismo token de SAS válido para cada operación de restauración.
  • ¿Se han escrito correctamente los nombres de la base de datos, del grupo de recursos y de la instancia administrada?
  • Si inició LRS en modo autocompletar, ¿era válido el nombre del último archivo de copia de seguridad especificado?
  • ¿La ruta de acceso del URI de copia de seguridad contiene las palabras clave backup o backups? Cambie el nombre del contenedor o las carpetas que usan backup o backups ya que estas son palabras clave reservadas.

Pasos siguientes