Optimización del rendimiento mediante la actualización del grupo de SQL dedicado (anteriormente SQL DW) en Azure Synapse Analytics
Actualice el grupo de SQL dedicado (anteriormente SQL DW) a la última generación de arquitectura de almacenamiento y hardware de Azure.
¿Por qué actualizar?
Ahora puede actualizar sin problemas al grupo de SQL dedicado (anteriormente SQL DW) de nivel Gen2 optimizado para proceso en Azure Portal para las regiones compatibles. Si su región no admite la actualización automática, puede actualizar a una región admitida o esperar a que la actualización automática esté disponible en su región. Actualice ahora para beneficiarse de la última generación de hardware de Azure y de la arquitectura de almacenamiento mejorada, como un rendimiento más rápido, mayor escalabilidad y un almacenamiento en columnas ilimitado.
Importante
Esta actualización se aplica a los grupos de SQL dedicados (anteriormente SQL DW) de nivel Gen1 optimizados para proceso en regiones compatibles.
Antes de empezar
Compruebe si su región es compatible para la migración de GEN1 a GEN2. Tenga en cuenta las fechas de la migración automática. Para evitar conflictos con el proceso automatizado, planee la migración manual antes de la fecha de inicio del proceso automatizado.
Si está en una región que aún no es compatible, continúe con la comprobación de la región que se va a agregar o actualice mediante restauración a una región compatible.
Si la región es compatible, realice la actualización en Azure Portal.
Seleccione el nivel de rendimiento sugerido para el grupo de SQL dedicado (anteriormente SQL DW) en función del nivel de rendimiento actual en el nivel Gen1 optimizado para proceso mediante la asignación siguiente:
Nivel Gen1 optimizado para proceso Nivel Gen2 optimizado para proceso DW100 DW100c DW200 DW200c DW300 DW300c DW400 DW400c DW500 DW500c DW600 DW500c DW1000 DW1000c DW1200 DW1000c DW1500 DW1500c DW2000 DW2000c DW3000 DW3000c DW6000 DW6000c
Nota
Los niveles de rendimiento sugeridos no son una conversión directa. Por ejemplo, se recomienda pasar de DW600 a DW500c.
Actualización en una región compatible mediante Azure Portal
- La migración de Gen1 a Gen2 mediante Azure Portal es permanente. No hay ningún proceso para volver a Gen1.
- El grupo de SQL dedicado (anteriormente SQL DW) debe estar en ejecución para migrar a Gen2.
Antes de empezar
Nota:
Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure. Para comenzar, consulte Instalación de Azure PowerShell. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.
- Inicie sesión en Azure Portal.
- Compruebe que se está ejecutando el grupo de SQL dedicado (anteriormente SQL DW) para poder migrar a Gen2.
Comandos de actualización de PowerShell
Si el grupo de SQL dedicado (anteriormente SQL DW) de nivel Gen1 optimizado para proceso que se va a actualizar se ha pausado, reanude el grupo de SQL dedicado (anteriormente SQL DW).
Prepárese para unos minutos de inactividad.
Identifique todas las referencias de código para los niveles de rendimiento Optimizado para Compute Gen1 y modifíquelos a su nivel de rendimiento equivalente Optimizado para Compute Gen2. A continuación, se muestran dos ejemplos de dónde debe actualizar las referencias de código antes de actualizar:
Comando de PowerShell Gen1 original:
Set-AzSqlDatabase -ResourceGroupName "myResourceGroup" -DatabaseName "mySampleDataWarehouse" -ServerName "mynewserver-20171113" -RequestedServiceObjectiveName "DW300"Modificado a:
Set-AzSqlDatabase -ResourceGroupName "myResourceGroup" -DatabaseName "mySampleDataWarehouse" -ServerName "mynewserver-20171113" -RequestedServiceObjectiveName "DW300c"Nota
-RequestedServiceObjectiveName "DW300" cambiado a RequestedServiceObjectiveName "DW300c"
Comando de T-SQL Gen1 original:
ALTER DATABASE mySampleDataWarehouse MODIFY (SERVICE_OBJECTIVE = 'DW300') ;Modificado a:
ALTER DATABASE mySampleDataWarehouse MODIFY (SERVICE_OBJECTIVE = 'DW300c') ;Nota
SERVICE_OBJECTIVE = 'DW300' cambiado a SERVICE_OBJECTIVE = 'DW300c'
Iniciar la actualización
Vaya al grupo de SQL dedicado (anteriormente SQL DW) de nivel Gen1 optimizado para proceso en Azure Portal. Si el grupo de SQL dedicado (anteriormente SQL DW) de nivel Gen1 optimizado para proceso que se va a actualizar se ha pausado, reanude el grupo de SQL dedicado.
Seleccione la tarjeta Actualizar a Gen2 en la pestaña Tareas:
Nota:
Si no aparece la tarjeta Actualizar a Gen2 en la pestaña Tareas, su suscripción es de un tipo que tiene limitaciones en la región actual. Envíe una incidencia de soporte técnico para que se apruebe la suscripción.
Asegúrese de que la carga de trabajo ha terminado de ejecutarse y está en modo inactivo antes de actualizar. Experimentará un tiempo de inactividad durante unos minutos antes de que el grupo de SQL dedicado (anteriormente SQL DW) vuelva a estar en línea como grupo de SQL dedicado (anteriormente SQL DW) de nivel Gen2 optimizado para proceso.
Seleccione Actualizar.
Para supervisar la actualización, compruebe el estado en Azure Portal. Es probable que vea un mensaje emergente que indica "Este almacenamiento de datos se está actualizando a Gen2".
El primer paso del proceso de actualización recorre la operación de escalado ("Actualización: sin conexión") donde todas las sesiones se terminan y las conexiones se descartan.
El segundo paso del proceso de actualización es la migración de datos ("Actualización: en línea"). La migración de datos es un proceso en segundo plano lento y en línea. Durante este proceso, los datos en columnas se mueven lentamente desde la arquitectura de almacenamiento anterior hasta la nueva arquitectura de almacenamiento mediante una caché de SSD local. Durante este tiempo, el grupo de SQL dedicado (anteriormente SQL DW) estará en línea para consulta y carga. Los datos estarán disponibles para consulta tanto si se han migrado como si no. La migración de datos se produce a una velocidad variable, según el tamaño de los datos, el nivel de rendimiento y el número de segmentos del almacén de columnas.
Recomendación opcional: Una vez completada la operación de escalado, puede acelerar el proceso en segundo plano de migración de datos. Puede forzar el movimiento de datos ejecutando ALTER INDEX ... REBUILD en todas las tablas de almacén de columnas principales que consulte con una clase de recurso y un SLO de mayor tamaño. Esta operación está sin conexión, se degradará o bloqueará otras consultas, pero finalizará más rápido en comparación con el proceso en segundo plano, lo que puede tardar horas en completarse en función del número y el tamaño de las tablas. Sin embargo, una vez que haya finalizado, la migración de datos será mucho más rápida debido a la nueva arquitectura de almacenamiento mejorada con grupos de filas de alta calidad.
Nota
Alter Index rebuild es una operación sin conexión y las tablas no estarán disponibles hasta que se complete la recompilación.
La consulta siguiente genera los comandos ALTER INDEX ... REBUILD necesarios para acelerar la migración de datos:
SELECT 'ALTER INDEX [' + idx.NAME + '] ON ['
+ Schema_name(tbl.schema_id) + '].['
+ Object_name(idx.object_id) + '] REBUILD ' + ( CASE
WHEN (
(SELECT Count(*)
FROM sys.partitions
part2
WHERE part2.index_id
= idx.index_id
AND
idx.object_id =
part2.object_id)
> 1 ) THEN
' PARTITION = '
+ Cast(part.partition_number AS NVARCHAR(256))
ELSE ''
END ) + '; SELECT ''[' +
idx.NAME + '] ON [' + Schema_name(tbl.schema_id) + '].[' +
Object_name(idx.object_id) + '] ' + (
CASE
WHEN ( (SELECT Count(*)
FROM sys.partitions
part2
WHERE
part2.index_id =
idx.index_id
AND idx.object_id
= part2.object_id) > 1 ) THEN
' PARTITION = '
+ Cast(part.partition_number AS NVARCHAR(256))
+ ' completed'';'
ELSE ' completed'';'
END )
FROM sys.indexes idx
INNER JOIN sys.tables tbl
ON idx.object_id = tbl.object_id
LEFT OUTER JOIN sys.partitions part
ON idx.index_id = part.index_id
AND idx.object_id = part.object_id
WHERE idx.type_desc = 'CLUSTERED COLUMNSTORE';
Actualización desde una región geográfica de Azure mediante restauración en Azure Portal
Uso de Azure Portal para crear un punto de restauración definido por el usuario
- Inicie sesión en Azure Portal.
- Vaya al grupo de SQL dedicado (anteriormente SQL DW) para el que quiere crear un punto de restauración.
- En la barra de herramientas de la página Información general, seleccione + Nuevo punto de restauración.
- Especifique un nombre para el punto de restauración.
Uso de Azure Portal para restaurar una base de datos activa o en pausa
Inicie sesión en Azure Portal.
Vaya al grupo de SQL dedicado (anteriormente SQL DW) desde el que desea restaurar.
En la barra de herramientas de la sección Información general, seleccione Restaurar.
Seleccione Puntos de restauración automáticos o Puntos de restauración definidos por el usuario. En el caso de los puntos de restauración definidos por el usuario, seleccione un punto de restauración definido por el usuario o cree un punto de restauración definido por el usuario. En el servidor, seleccione Crear nuevo y elija un servidor en una región geográfica compatible con Gen2.
Uso de PowerShell para restaurar desde una región geográfica de Azure
Nota
Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure. Para comenzar, consulte Instalación de Azure PowerShell. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.
Para recuperar una base de datos, use el cmdlet Restore-AzSqlDatabase.
Nota
Puede realizar una restauración geográfica en Gen2. Para ello, especifique Gen2 ServiceObjectiveName (p. ej., DW1000c) como parámetro opcional.
- Abra Windows PowerShell.
- Conéctese a su cuenta de Azure y enumere todas las suscripciones asociadas a su cuenta.
- Seleccione la suscripción que contiene la base de datos que se va a restaurar.
- Obtenga la base de datos que desea recuperar.
- Cree la solicitud de recuperación para la base de datos, especificando un atributo ServiceObjectiveName para Gen2.
- Compruebe el estado de la base de datos restaurada geográficamente.
Connect-AzAccount
Get-AzSubscription
Select-AzSubscription -SubscriptionName "<Subscription_name>"
# Get the database you want to recover
$GeoBackup = Get-AzSqlDatabaseGeoBackup -ResourceGroupName "<YourResourceGroupName>" -ServerName "<YourServerName>" -DatabaseName "<YourDatabaseName>"
# Recover database
$GeoRestoredDatabase = Restore-AzSqlDatabase –FromGeoBackup -ResourceGroupName "<YourResourceGroupName>" -ServerName "<YourTargetServer>" -TargetDatabaseName "<NewDatabaseName>" –ResourceId $GeoBackup.ResourceID -ServiceObjectiveName "<YourTargetServiceLevel>" -RequestedServiceObjectiveName "DW300c"
# Verify that the geo-restored database is online
$GeoRestoredDatabase.status
Nota
Para configurar la base de datos una vez finalizada la restauración, consulte Configuración de la base de datos después de realizar la recuperación.
La base de datos recuperada estará habilitada para TDE si la base de datos de origen está habilitada para TDE.
Si experimenta problemas con el grupo de SQL dedicado, cree una solicitud de soporte técnico e indique que la posible causa es la "actualización a Gen2".
El grupo de SQL dedicado (anteriormente SQL DW) actualizado está en línea. Para aprovechar la arquitectura mejorada, obtenga más información sobre las clases de recursos.