Uso de OLTP en memoria en Azure SQL Managed Instance para mejorar el rendimiento de la aplicación

Se aplica a:Azure SQL Managed Instance

OLTP en memoria puede utilizarse para mejorar el rendimiento del procesamiento de transacciones, la ingesta de datos y los escenarios de datos transitorios. El nivel de servicio Crítico para la empresa incluye una cantidad determinada de memoria OLTP máxima en memoria, un límite determinado por el número de núcleos virtuales.

Siga estos pasos para adoptar OLTP en memoria en una base de datos existente en Azure SQL Managed Instance.

Paso 2: Identifique los objetos para migrar a OLTP en memoria

SQL Server Management Studio (SSMS) incluye un informe de información general del análisis de rendimiento de transacciones que se puede ejecutar en una base de datos con una carga de trabajo activa. El informe identifica las tablas y los procedimientos almacenados que son candidatos para la migración a OLTP en memoria.

En SSMS, para generar el informe:

  • En el Explorador de objetos, haga clic con el botón derecho en el nodo de la base de datos.
  • Haga clic en Informes>Informes estándar>Información general de análisis de rendimiento de transacciones.

Para obtener más información sobre la evaluación de las ventajas de OLTP en memoria, consulte Determinar si una tabla o un procedimiento almacenado se debe pasar a OLTP en memoria.

Paso 3: Cree una base de datos de prueba comparable

Supongamos que el informe indica que la base de datos tiene una tabla que se beneficiaría de convertirse en una tabla optimizada para memoria. Se recomienda que la pruebe primero para confirmar la indicación.

Necesitará una copia de prueba de la base de datos de producción. La base de datos de prueba debe estar en el mismo nivel de servicio (crítico para la empresa) y recuento de núcleos virtuales que la base de datos de producción.

Para facilitar las pruebas, ajuste la base de datos de prueba de la forma siguiente:

  1. Conectarse a la base de datos de prueba mediante SQL Server Management Studio (SSMS).

  2. Para evitar la necesidad de usar la opción WITH (SNAPSHOT) en las consultas, establezca la opción MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT de base de datos actual tal como se muestra en la siguiente instrucción T-SQL:

    ALTER DATABASE CURRENT
     SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;
    

Paso 4: Migre las tablas

Debe crear y rellenar una copia optimizada para memoria de la tabla que desea probar. Se puede crear mediante:

Asistente para optimización de memoria en SSMS

Para usar esta opción de migración:

  1. Conéctese a la base de datos de prueba con SSMS.

  2. En el Explorador de objetos, haga clic con el botón derecho en la tabla y después seleccione Asistente de optimización de memoria.

    Se muestra el asistente Asesor del optimizador de memoria de tablas .

  3. En el asistente, seleccione Validación de migración (o el botón Siguiente) para ver si la tabla tiene las características no admitidas en las tablas optimizadas para memoria. Para más información, vea:

  4. Si la tabla no tiene características no admitidas, el asesor puede realizar el esquema real y la migración de datos.

T-SQL manual

Para usar esta opción de migración:

  1. Conéctese a la base de datos de prueba mediante SSMS (o una utilidad similar).
  2. Obtenga el script T-SQL completo para la tabla y sus índices.
    • En SSMS, haga clic con el botón derecho en el nodo de tabla.
    • Seleccione Incluir tabla como>Crear en>Nueva ventana de consulta.
  3. En la ventana de script, agregue WITH (MEMORY_OPTIMIZED = ON) a la instrucción CREATE TABLE.
  4. Si hay un índice CLUSTERD, cámbielo a NONCLUSTERED.
  5. Cambie el nombre de la tabla existente mediante sp_rename.
  6. Cree la nueva copia de la tabla optimizada para memoria mediante la ejecución del script CREATE TABLE editado.
  7. Copie los datos en la tabla optimizada en memoria mediante INSERT...SELECT * INTO:
    INSERT INTO [<new_memory_optimized_table>]
            SELECT * FROM [<old_disk_based_table>];
    

Paso 4 (opcional): Migre los procedimientos almacenados

La característica en memoria también puede modificar un procedimiento almacenado para mejorar el rendimiento.

Consideraciones con procedimientos almacenados compilados de forma nativa

Un procedimiento almacenado compilado de forma nativa debe tener las siguientes opciones en su cláusula WITH de T-SQL:

  • NATIVE_COMPILATION: significa que las instrucciones Transact-SQL del procedimiento se compilan en código nativo para una ejecución eficaz.
  • SCHEMABINDING: son las tablas cuyas definiciones de columna no puede cambiar de ninguna forma el procedimiento almacenado que pueda afectar al procedimiento almacenado, a menos que quite el procedimiento almacenado.

Un módulo nativo debe usar un gran bloque ATOMIC para la administración de transacciones. No hay ningún rol para BEGIN TRANSACTION o ROLLBACK TRANSACTION. explícito. Si el código detecta una infracción de una regla de negocio, puede finalizar el bloque ATOMIC con una instrucción THROW.

CREATE PROCEDURE típico para compilar de forma nativa

Normalmente el T-SQL para crear un procedimiento almacenado compilado de forma nativa es similar a la siguiente plantilla:

CREATE PROCEDURE schemaname.procedurename
    @param1 type1, ...
    WITH NATIVE_COMPILATION, SCHEMABINDING
    AS
        BEGIN ATOMIC WITH
            (TRANSACTION ISOLATION LEVEL = SNAPSHOT,
            LANGUAGE = N'<desired sys.syslanuages.sysname value>'
            )
        ...
        END;
  • Para TRANSACTION_ISOLATION_LEVEL, SNAPSHOT es el valor más común para el procedimiento almacenado compilado de forma nativa. Sin embargo, también se admite un subconjunto de los demás valores:
    • REPEATABLE READ
    • SERIALIZABLE
  • El valor LANGUAGE debe estar presente en la vista sys.syslanguages, en la columna name. Por ejemplo, N'us_english'.

Migración de un procedimiento almacenado

Los pasos de migración son los siguientes:

  1. Obtenga el script CREATE PROCEDURE para el procedimiento almacenado regular interpretado.
  2. Vuelva a escribir el encabezado para que coincida con la plantilla anterior.
  3. Determine si el código T-SQL del procedimiento almacenado usa las características que no se admiten para los procedimientos almacenados compilados de forma nativa. Implemente soluciones alternativas si es necesario. Para obtener más información, consulte Problemas de migración para los procedimientos almacenados compilados de forma nativa.
  4. Cambie el nombre del procedimiento almacenado anterior por sp_rename. O bien, simplemente quítelo con la instrucción DROP.
  5. Ejecute el script T-SQL CREATE PROCEDURE editado.

Paso 5: Ejecute la carga de trabajo en la prueba

Ejecutar una carga de trabajo en la base de datos de prueba es similar a la carga de trabajo que se ejecuta en la base de datos de producción. Esto debería mostrar la mejora del rendimiento conseguida mediante el uso de la característica en memoria para tablas y procedimientos almacenados.

Los atributos principales de la carga de trabajo son los siguientes:

  • Número de conexiones simultáneas.
  • Relación de lectura/escritura.

Para personalizar y ejecutar la carga de trabajo de prueba, considere el uso de la práctica herramienta ostress.exe.

Para minimizar la latencia de red, ejecute la prueba en la misma región geográfica de Azure donde existe la base de datos.

Paso 6: Supervise después de la implementación

Considere la posibilidad de supervisar los efectos de rendimiento de las implementaciones en memoria en producción: