Procedimientos recomendados para el vínculo de Instancia administrada: Azure SQL Managed Instance

Se aplica a: Azure SQL Managed Instance

En este artículo se describen los procedimientos recomendados al usar el Vínculo de instancia administrada para replicar datos entre Azure SQL Managed Instance y las instancias de SQL Server hospedadas en cualquier lugar, lo que proporciona replicación de datos casi en tiempo real entre las réplicas vinculadas.

Realizar copias de seguridad de registros con regularidad

Si SQL Server es la base de datos principal inicial, es importante realizar la primera copia de seguridad del registro en SQL Server una vez completada la inicialización, cuando la base de datos ya no esté en el estado Restaurar... en Azure SQL Managed Instance. A continuación, realice copias de seguridad del registro de transacciones de SQL Server periódicamente para mantener un tamaño de archivo de registro de transacciones correcto mientras SQL Server se encuentra en el rol principal.

La característica de vínculo replica los datos utilizando la tecnología de grupos de disponibilidad distribuida basada en grupos de disponibilidad Always On. La replicación de datos con grupos de disponibilidad distribuidos se basa en la replicación de registros de transacciones. No se pueden truncar registros de transacciones desde la base de datos de la instancia SQL Server principal hasta que se repliquen en la base de datos de la réplica secundaria. Si la replicación de registros de transacciones es lenta o está bloqueada debido a problemas de conexión de red, el archivo de registro sigue creciendo en la instancia principal. La velocidad de crecimiento depende de la intensidad de la carga de trabajo y la velocidad de la red. Si se produce una interrupción prolongada de la conexión de red y una carga de trabajo pesada en la instancia principal, el archivo de registro puede tardar todo el espacio de almacenamiento disponible.

Al realizar copias de seguridad periódicas del registro de transacciones, se trunca el registro de transacciones y se minimiza el riesgo de quedarse sin espacio en la instancia principal de SQL Server debido al crecimiento del archivo de registro. No es necesario realizar ninguna acción adicional cuando SQL Managed Instance es el principal, ya que las copias de seguridad de registros ya se realizan automáticamente. Al realizar copias de seguridad de registros periódicamente en su servidor principal SQL Server, la base de datos es más resistente a los eventos de crecimiento de registros no planeados. Considere la posibilidad de programar tareas de copia de seguridad de registros diarias mediante un trabajo del Agente SQL Server.

Puede usar un script de Transact-SQL (T-SQL) para realizar una copia de seguridad del archivo de registro, como la muestra proporcionada en esta sección. Reemplace los marcadores de posición del script de muestra por el nombre de la base de datos, el nombre y la ruta de acceso del archivo de copia de seguridad y la descripción.

Para realizar una copia de seguridad del registro de transacciones, use el siguiente script de ejemplo de Transact-SQL (T-SQL) en SQL Server:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Use el siguiente comando Transact-SQL (T-SQL) para comprobar el espacio de registro utilizado por la base de datos en SQL Server:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE); 

La salida de la consulta es similar a la del ejemplo siguiente para la base de datos de muestra tpcc:

En este ejemplo, la base de datos ha usado el 76 % del registro disponible, con un tamaño absoluto de archivo de registro de aproximadamente 27 GB (27 971 MB). Los umbrales de acción pueden variar en función de la carga de trabajo. En el ejemplo anterior, el tamaño del registro de transacciones y el porcentaje de uso del registro suele ser una indicación de que debe realizar una copia de seguridad del registro de transacciones para truncar el archivo de registro y liberar espacio, o bien, realizar copias de seguridad de registros más frecuentes. También podría ser una indicación de que las transacciones abiertas bloquean el truncamiento del registro de transacciones. Para más información sobre cómo solucionar problemas de un registro de transacciones en SQL Server, vea Solucionar problemas de un registro de transacciones lleno (Error 9002 de SQL Server). Para más información sobre cómo solucionar problemas de un registro de transacciones en Azure SQL Managed Instance, vea Solución de problemas del registro de transacciones con Azure SQL Managed Instance.

Nota:

Al participar en un vínculo, las copias de seguridad de registros de transacciones y completas automatizadas se toman de SQL Managed Instance tanto si es la réplica principal como si no. No se toman copias de seguridad diferenciales, lo que puede provocar tiempos de restauración más largos.

Coincidencia de la capacidad de rendimiento entre réplicas

Al usar la característica de vínculo, es importante que coincida con la capacidad de rendimiento entre SQL Server y SQL Managed Instance para evitar problemas de rendimiento si la réplica secundaria no puede mantenerse al día con la replicación desde la réplica principal o después de la conmutación por error. La capacidad de rendimiento incluye núcleos de CPU (o núcleos virtuales en Azure), memoria y rendimiento de E/S.

Puede comprobar el rendimiento de la replicación con el tamaño de la cola de puesta al día en la réplica secundaria. El tamaño de la cola de puesta al día indica el número de registros que están esperando a que se rehagan en la réplica secundaria. Un tamaño de cola de puesta al día constantemente alto indica que la réplica secundaria no puede mantenerse al día con la réplica principal. Puede comprobar el tamaño de la cola de puesta al día de las maneras siguientes:

• Valor redo_queue_size de la vista de administración dinámica sys.dm_hadr_database_replica_states en la réplica principal.
• Valor InstanceRedoLagReplicationSeconds de Get-AzSqlInstanceLink en la réplica principal.

Si el tamaño de la cola de puesta al día es constantemente alto, considere la posibilidad de aumentar los recursos en la réplica secundaria.

Rotación de certificados

Es posible que el certificado que use para proteger el punto de conexión de creación de reflejo de la base de datos expire, lo que puede provocar la degradación del vínculo. Para evitar este problema, rote el certificado antes de que expire.

Use el siguiente comando de Transact-SQL (T-SQL) para comprobar la fecha de expiración del certificado actual:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK' 

Si el certificado está a punto de expirar o ya ha expirado, puede crear un nuevo certificado y, a continuación, modificar el punto de conexión existente para reemplazar el certificado actual.

Una vez configurado el punto de conexión para usar el nuevo certificado, puede quitar el certificado expirado.

Adición de marcas de seguimiento de inicio

En SQL Server hay dos marcas de seguimiento (-T1800 y -T9567) que, cuando se agregan como parámetros de inicio, pueden optimizar el rendimiento de la replicación de datos desde el vínculo. Consulte Habilitación de marcas de seguimiento de inicio para obtener más información.

Contenido relacionado

Para usar el vínculo:

• Preparación del entorno para el vínculo de instancia administrada
• Configuración del vínculo entre SQL Server y SQL Managed Instance con SSMS
• Configuración del vínculo entre SQL Server y SQL Managed Instance con scripts
• Conmutación por error de un vínculo
• Migración con el vínculo

Para más información sobre el vínculo:

• Vínculo de Instancia administrada: información general
• Recuperación ante desastres con vínculo de instancia administrada

Para otros escenarios de replicación y migración, considere lo siguiente:

• Replicación transaccional con SQL Managed Instance
• Servicio de reproducción de registros (LRS)