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

  • Artículo

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. Revise cuidadosamente las limitaciones y las secciones de procedimientos recomendados para garantizar una migración correcta.

Importante

  • Antes de migrar bases de datos al nivel de servicio Crítico para la empresa, tenga en cuenta estas limitaciones, que no se aplican al nivel de servicio De uso general.
  • 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.

Antes de migrar bases de datos al nivel de servicio Crítico para la empresa, tenga en cuenta estas limitaciones, que no se aplican al nivel de servicio De uso general.

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 se requiere tener CHECKSUM habilitado para las copias de seguridad, se recomienda encarecidamente para evitar la migración involuntaria de una base de datos dañada y para realizar operaciones de restauración más rápidas.

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 Read y permisos de List generados para el contenedor de Blob Storage, o bien una identidad administrada que pueda acceder al contenedor. La concesión de permisos adicionales a Read y List provocará un error en LRS.
  • 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 una ventana de mantenimiento para que las actualizaciones del sistema se programen a un día y hora específicos fuera de la ventana de migración para evitar retrasos o interrupciones de la migración.
  • 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 evitar la migración involuntaria de una base de datos dañada y para una restauración de base de datos más rápida, habilite CHECKSUM cuando realice las copias de seguridad. Aunque SQL Managed Instance realiza una comprobación de integridad básica en las copias de seguridad sin CHECKSUM, no se garantiza la detección de todas las formas de daños. Realizar copias de seguridad con CHECKSUM es la única manera de asegurarse de que la copia de seguridad restaurada en SQL Managed Instance no está dañada. La comprobación de integridad básica en las copias de seguridad sin CHECKSUM aumenta el tiempo de restauración de una base de datos.
  • Al migrar al nivel de servicio Crítico para la empresa, tenga en cuenta un retraso prolongado en la disponibilidad de la base de datos después de la migración, mientras que las bases de datos se inicializarán en réplicas secundarias. Para bases de datos especialmente grandes con requisitos mínimos de tiempo de inactividad, considere la posibilidad de migrar primero al nivel de servicio De uso general y, a continuación, actualizar al nivel de servicio Crítico para la empresa o mediante el enlace Instancia administrada para migrar los datos.
  • Cargar miles de archivos de base de datos para restaurar puede provocar tiempos de migración excesivos y hasta errores. Consolide las bases de datos en menos archivos para acelerar el proceso de migración y asegúrese de que se ha realizado correctamente.

Configuración de una ventana de mantenimiento

Las actualizaciones del sistema para SQL Managed Instance tienen prioridad sobre las migraciones de bases de datos en curso.

La migración se ve afectada de forma diferente en función del nivel de servicio:

  • En el nivel de servicio De uso general, todas las migraciones 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.
  • En el nivel de servicio Crítico para la empresa, todas las migraciones LRS pendientes se cancelan y se reinician automáticamente 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. Por ejemplo, para una migración que se inicia el lunes, configure la ventana de mantenimiento personalizada el domingo para permitir la mayor parte del tiempo para completar la migración.

No es necesario configurar una ventana de mantenimiento, pero es muy recomendable para bases de datos de gran tamaño.

Nota:

Aunque una ventana de mantenimiento controla la previsibilidad de las actualizaciones planeadas, no garantiza que no se produzcan conmutaciones por error no planeadas ni actualizaciones de revisiones de seguridad. Una conmutación por error no planeada o una revisión de seguridad (que tiene prioridad sobre todas las demás actualizaciones) todavía puede interrumpir la migración.

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.

    Captura de pantalla de la página Información general de la instancia administrada de SQL de Azure Portal, con la subred seleccionada.

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

    Captura de pantalla de la página Subred de la instancia administrada de SQL de Azure Portal, con la subred seleccionada.

  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.

    Captura de pantalla de la página de configuración de subred de instancia administrada de SQL del 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.

    Captura de pantalla de la página Redes de la cuenta de almacenamiento del Azure Portal, con la opción Agregar red virtual existente seleccionada.

  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.

    Captura de pantalla que muestra las opciones seleccionadas para generar un token de autenticación de SAS.

  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.

    Captura de pantalla que muestra las opciones seleccionadas para la expiración del token de SAS, la zona horaria y los permisos, junto con el botón Crear.

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:

Captura de pantalla que muestra un ejemplo de la versión del URI de un token de SAS.

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:

Ejemplo de URI de un token de SAS generado para 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.

    Captura de pantalla que muestra la copia de la primera parte del 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.

    Captura de pantalla que muestra la copia de la segunda parte del 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 es recomendable para evitar la migración de una base de datos dañada y para tiempos de restauración más rápidos.

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:

Al migrar varias bases de datos, cada base de datos debe estar en su propia carpeta. LRS debe iniciarse por separado para cada base de datos, apuntando a la ruta de acceso URI completa del contenedor de Azure Blob Storage y a la carpeta de base de datos individual. No se admiten carpetas anidadas dentro de las carpetas de 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 en curso mediante PowerShell, use el siguiente comando:

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

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

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

Para rastrear detalles adicionales sobre una solicitud fallida, utilice el comando de PowerShell Get-AzSqlInstanceOperation o utilice el comando de la CLI de Azure az sql mi op show.

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"

Limitaciones

Tenga en cuenta las siguientes limitaciones al migrar con LRS:

  • Las bases de datos que se están restaurando con LRS no se pueden usar hasta que finalice el proceso de migración.
  • Durante el proceso de migración, las bases de datos que se están migrando no se pueden usar para el acceso de solo lectura en SQL Managed Instance.
  • Una vez completada la migración, el proceso de migración es final y no se puede reanudar con copias de seguridad diferenciales adicionales.
  • LRS solo admite archivos de base de datos .bak, .logy .diff . No se admiten archivos Dacpac y bacpac.
  • Tiene que configurar una ventana de mantenimiento para programar las actualizaciones del sistema en un día y hora específicos. Planee la ejecución y finalización de migraciones fuera de la ventana de mantenimiento programado.
  • Las copias de seguridad de base de datos realizadas sin CHECKSUM:
    • pueden migrar bases de datos dañadas.
    • tardan más tiempo en restaurarse que las copias de seguridad de base de datos con CHECKSUM.
  • El token de firma de acceso compartido (SAS) que LRS utiliza se debe generar para todo el contenedor de Azure Blob Storage y solo debe tener permisos de Read y List. Por ejemplo, si concede permisos Read, List y Write, LRS no se inicia debido al permiso adicional Write.
  • No se admite el uso de tokens de SAS creados con permisos que se hayan establecido con la definición de una directiva de acceso almacenada. Siga las instrucciones de este artículo para especificar manualmente permisos de lectura y enumeración para el token de SAS.
  • Los archivos de copia de seguridad de bases de datos distintas deben colocarse en carpetas independientes en la cuenta de Blob Storage en una estructura de archivos planos. No se admite el anidamiento de carpetas en las carpetas de base de datos.
  • Si usa el modo autocompletar, toda la cadena de copia de seguridad debe estar disponible con antelación en la cuenta de Blob Storage. No es posible agregar nuevos archivos de copia de seguridad en modo de autocompletar. Use el modo continuo si necesita agregar nuevos archivos de copia de seguridad mientras la migración está en curso.
  • LRS debe iniciarse por separado para cada base de datos que apunte a la ruta de URI completa que contiene una carpeta de base de datos individual.
  • La ruta de acceso del URI de copia de seguridad, el nombre del contenedor o los nombres de carpeta no deben contener backup o backups, ya que son palabras clave reservadas.
  • 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.
  • LRS puede admitir hasta 100 procesos de restauración simultáneos por cada instancia administrada.
  • Un trabajo LRS único se puede ejecutar durante un máximo de 30 días, después de los cuales se cancelará automáticamente.
  • Aunque es posible usar una cuenta de Azure Storage detrás de un firewall, se necesita una configuración adicional, y la cuenta de almacenamiento y la instancia administrada deben estar en la misma región o en dos regiones emparejadas. Consulte Configuración del firewall para obtener más información.
  • El número máximo de bases de datos que puede restaurar en paralelo es de 200 por cada suscripción. En algunos casos, es posible aumentar este límite abriendo una incidencia de soporte técnico.
  • Cargar miles de archivos de base de datos para restaurar puede provocar tiempos de migración excesivos y hasta errores. Consolide las bases de datos en menos archivos para acelerar el proceso de migración y asegúrese de que se ha realizado correctamente.

Nota:

Si necesita que una base de datos tenga acceso de solo lectura durante la migración, con un período de tiempo mucho más largo para realizar la migración y un tiempo de inactividad mínimo, considere la posibilidad de usar la característica de enlace de Managed Instance como solución de migración recomendada.

Limitaciones al migrar al nivel de servicio Crítico para la empresa

Al migrar a una SQL Managed Instance en el nivel de servicio Crítico para la empresa, tenga en cuenta las siguientes limitaciones:

  • Al migrar bases de datos grandes, puede haber un tiempo de inactividad considerable, ya que las bases de datos no están disponibles después de la migración, mientras que las bases de datos se propagan a las réplicas secundarias del nivel de servicio Crítico para la empresa. Las soluciones alternativas se enumeran en la sección de transición más larga.
  • La migración se reinicia automáticamente desde el principio si esta se interrumpe mediante una conmutación por error no planeada, una actualización del sistema o una revisión de seguridad, lo que dificulta planear una migración predecible sin sorpresas de último minuto.

Importante

Estas limitaciones solo son aplicables al migrar al nivel de servicio Crítico para la empresa y no al nivel de servicio De uso general.

Transición más larga en el nivel de servicio Crítico para la empresa

Si va a migrar a una instancia administrada de SQL en el nivel de servicio Crítico para la empresa, tenga en cuenta el retraso al poner las bases de datos en línea en la réplica principal mientras se propagan a las réplicas secundarias. Esto ocurre principalmente en bases de datos más grandes.

La migración a una instancia administrada de SQL en el nivel de servicio Crítico para la empresa tarda más tiempo en completarse que en el nivel de servicio De uso general. Una vez completada la migración a Azure, las bases de datos no están disponibles hasta que se hayan propagado de la réplica principal a las tres réplicas secundarias, y puede tardar un tiempo prolongado en función del tamaño de la base de datos. Cuanto mayor sea la base de datos, la propagación a las réplicas secundarias será más larga; puede tardar hasta varias horas.

Si es importante que las bases de datos estén disponibles en cuanto finalice la transición, tenga en cuenta las siguientes soluciones alternativas:

  • Migre primero al nivel de servicio De uso general y, a continuación, actualice al nivel de servicio Crítico para la empresa durante una ventana de mantenimiento posterior. La actualización del nivel de servicio es una operación en línea que mantiene las bases de datos en línea hasta una conmutación por error corta como último paso de la operación de actualización.
  • Use el enlace Instancia administrada para una migración en línea a una instancia Crítica para la empresa sin tener que esperar a que las bases de datos estén disponibles después de la migración total.

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 en curso:

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

Para revisar los detalles sobre una operación fallida:

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? La concesión de permisos adicionales a Read y List provocará un error en LRS.
  • ¿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