Partager via

Utiliser OLTP en mémoire pour améliorer les performances de votre application dans Azure SQL Database

  • Article

S’applique à : Azure SQL Database

L’OLTP en mémoire peut être utilisé pour améliorer les performances de traitement transactionnel, l’ingestion des données et des scénarios de données transitoires, sans augmenter l'objectif de service de la base de données ou du pool élastique.

  • Les bases de données et les pools élastiques des niveaux de service Premium (DTU) et Business Critical (vCore) prennent en charge In-Memory OLTP.
  • Le niveau de service Hyperscale prend en charge un sous-ensemble d’objets OLTP en mémoire, mais n’inclut pas les tables optimisées en mémoire. Pour plus d’informations, consultez Limitations d’hyperscale.

Suivez ces étapes pour commencer à utiliser In-Memory OLTP dans votre base de données existante.

Étape 1 : vérifiez que vous utilisez une base de données de niveau Premium ou Critique pour l'entreprise

OLTP en mémoire est pris en charge si le résultat de la requête suivante est 1 (pas 0) :

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');

XTP correspond à Traitement transactionnel extrême, qui est un nom informel de la fonctionnalité OLTP en mémoire.

Étape 2 : identifiez les objets à migrer vers In-Memory OLTP

SQL Server Management Studio (SSMS) inclut un rapport de présentation d’analyse des performances des transactions que vous pouvez exécuter sur une base de données avec une charge de travail active. Le rapport identifie les tables et procédures stockées candidates pour la migration vers In-Memory OLTP.

Dans SSMS, pour générer le rapport :

  • Dans l’ Explorateur d’objets, cliquez avec le bouton droit sur le nœud de votre base de données.
  • Cliquez sur Rapports>Rapports Standard>Présentation de l’analyse des performances des transactions.

Pour plus d'informations sur l'évaluation des avantages de l'OLTP In-Memory, consultez Déterminer si une table ou une procédure stockée doit être portée à In-Memory OLTP.

Étape 3 : créez une base de données de test comparable

Supposons que le rapport indique que votre base de données est équipée d’une table qui gagnerait à être convertie en table à mémoire optimisée. Nous vous recommandons de commencer par effectuer un test pour confirmer l’indication.

Vous avez besoin d’une copie de test de votre base de données de production. La base de données de test doit être au même niveau de service que votre base de données de production.

Pour faciliter le test, modifiez votre base de données comme suit :

  1. Connectez-vous à la base de données de test à l’aide de SQL Server Management Studio (SSMS).

  2. Pour éviter d’avoir recours à l’option WITH (SNAPSHOT) dans les requêtes, définissez l’option MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT de base de données actuelle, comme indiqué dans l’instruction T-SQL suivante :

    ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;

Étape 4 : migrez les tables

Vous devez créer et remplir une copie de mémoire optimisée de la table que vous souhaitez tester. Vous pouvez le créer en utilisant soit :

Assistant Optimisation de mémoire en SSMS

Pour utiliser cette option de migration :

  1. Se connecter à la base de données de test avec SSMS.

  2. Dans l’Explorateur d’objets, cliquez avec le bouton droit sur la table, puis cliquez sur Conseiller d’optimisation de la mémoire.

    L’assistant Conseiller d’optimiseur de mémoire de table s’affiche.

  3. Dans l’assistant, cliquez sur Validation de migration (ou sur le bouton Suivant) pour voir si la table possède des fonctionnalités dans les tables optimisées par mémoire. Pour plus d’informations, consultez l’article suivant :

  4. Si la table ne possède pas de fonctions non prises en charge, l’Assistant peut exécuter le schéma et la migration des données pour vous.

T-SQL manuel

Pour utiliser cette option de migration :

  1. Connectez-vous à votre base de données de test à l’aide de SSMS.
  2. Obtenir le script T-SQL complet pour votre table et ses contraintes et index.
    • Dans SSMS, cliquez avec le bouton droit sur le nœud de votre table.
    • Cliquez sur Générer un script de la table en tant que>CREATE To>Fenêtre de nouvelle requête.
  3. Dans la fenêtre de script, ajoutez WITH (MEMORY_OPTIMIZED = ON) à l’instruction CREATE TABLE . Pour plus d’informations, consultez Syntaxe pour les tables à mémoire optimisée.
  4. S’il existe un index CLUSTERED (ORDONNÉ) en clusters, le transformer en NONCLUSTERED (NON ORDONNÉ).
  5. Renommez la table existante à l’aide de sp_rename.
  6. Créez la nouvelle copie de la table de mémoire optimisée si la table en exécutant le script CREATE TABLE modifié.
  7. Copiez les données dans votre table mémoire optimisée à l’aide de INSERT...SELECT * INTO :
    INSERT INTO [<new_memory_optimized_table>]
SELECT * FROM [<old_disk_based_table>];

Étape 5 (facultatif) : migrez des procédures stockées

OLTP en mémoire prend également en charge les procédures stockées compilées en mode natif, ce qui peut améliorer les performances T-SQL.

Considérations relatives à des procédures stockées compilées en mode natif

Une procédure stockée compilée en mode natif doit avoir les options suivantes dans sa clause WITH T-SQL :

  • NATIVE_COMPILATION : ce qui signifie que les instructions Transact-SQL de la procédure sont toutes compilées en code natif pour une exécution efficace.
  • SCHEMABINDING : signifie que les tables référencées dans la procédure stockée ne peuvent voir leurs définitions modifiées de quelque manière que ce soit susceptible d’affecter la procédure stockée, à moins que vous ne glissiez la procédure stockée.

Un module natif compilé doit utiliser un bloc ATOMIQUE pour la gestion de transaction. Il n'y a pas lieu d'utiliser des instructions BEGIN TRANSACTION ou ROLLBACK TRANSACTION explicites. Votre code peut mettre fin au bloc atomique avec une instruction THROW, par exemple s'il détecte une violation des règles métier.

Un exemple de procédure stockée compilée en mode natif

Le code T-SQL pour créer une procédure stockée compilée en mode natif est similaire au modèle suivant :

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;
  • Pour le TRANSACTION_ISOLATION_LEVEL, SNAPSHOT est la valeur la plus commune pour la procédure stockée compilée de façon native. Cependant, un sous-ensemble d’autres valeurs est également pris en charge :
    • REPEATABLE READ
    • SERIALIZABLE
  • La LANGUAGE valeur doit être présente dans la sys.syslanguages vue, dans la name colonne. Par exemple : N'us_english'.

Comment migrer une procédure stockée pour utiliser la compilation native

Les étapes de la migration sont les suivantes :

  1. Obtenir le script CREATE PROCEDURE pour la procédure stockée régulière (interprétée).
  2. Réécrire son en-tête pour qu’il corresponde au modèle précédent.
  3. Déterminer si le code TSQL de procédure stocké utilise les fonctions non prises en charge pour les procédures stockées compilées en mode natif. Mettre en œuvre des solutions de contournement si nécessaire. Pour plus d’informations, consultez Procédures stockées compilées en mode natif.
  4. Renommez l’ancienne procédure stockée en utilisant sp_rename ou laissez-le tomber.
  5. Exécutez votre script CREATE PROCEDURE T-SQL modifié.

Étape 6 : exécutez votre charge de travail en mode test

L’exécution d’une charge de travail dans votre base de données de test est similaire à la charge de travail qui s’exécute dans votre base de données de production. Cela devrait révéler le gain de performance obtenu par l'utilisation de In-Memory OLTP pour les tables et les procédures stockées.

Les principaux attributs de la charge de travail sont :

  • Nombre de connexions simultanées.
  • Rapport Lecture/Écriture

Pour personnaliser et exécuter la charge de travail de test, envisagez d’utiliser l’outil ostress.exe à partir du groupe d’outils Utilitaires RML. Pour plus d’informations, consultez la section tempdb dans Azure SQL Database.

Pour réduire le temps de réponse du réseau, exécutez ostress.exe dans la même région Azure que la base de données.

Étape 7 : supervision post-implémentation

Veillez à surveiller les effets des performances de vos implémentations In-Memory OLTP en production :

Contenu connexe