Condividi tramite

Usare OLTP in memoria per migliorare le prestazioni dell'applicazione in Istanza gestita di SQL di Azure

  • Articolo

Si applica a: Istanza gestita di SQL di Azure SQL

OLTP in memoria può essere usato per migliorare le prestazioni di elaborazione delle transazioni, l'inserimento dei dati e gli scenari di dati temporanei, nei database SQL di Azure Premium, senza aumentare il piano tariffario. Il livello di servizio Business Critical include una determinata quantità di memoria OLTP in memoria massima, un limite determinato dal numero di vCore.

Seguire i passaggi seguenti per adottare OLTP in memoria nel database esistente in Istanza gestita di SQL di Azure.

Passaggio 2: Identificare gli oggetti per eseguire la migrazione a OLTP In memoria

SQL Server Management Studio (SSMS) include un report Panoramica analisi delle prestazioni per le transazioni che è possibile eseguire su un database con un carico di lavoro attivo. Il report identifica le tabelle e le stored procedure candidate per la migrazione a OLTP in memoria.

In SSMS, per generare il report:

  • In Esplora oggettifare clic con il pulsante destro del mouse sul nodo del database.
  • Selezionare Report>Report standard>Panoramica dell'analisi delle prestazioni transazioni.

Per altre informazioni sulla valutazione dei benefici di OLTP in memoria, vedere Determinare se una tabella o una stored procedure deve essere trasferita a OLTP in memoria.

Passaggio 2: Creare un database di prova confrontabile

Si supponga che il report indichi che il database include una tabella che può trarre vantaggio dalla conversione in una tabella ottimizzata per la memoria. È consigliabile verificare prima di tutto l'indicazione eseguendo il test.

È necessaria una copia di test del database di produzione. Il database di test deve avere lo stesso livello di servizio (Business Critical) e conteggio vCore come database di produzione.

Per semplificare il test, perfezionare il database di test come segue:

  1. Connettersi al database di test usando Microsoft SQL Server Management Studio (SSMS).

  2. Per evitare di dover usare l'opzione WITH (SNAPSHOT) nelle query, impostare l’attuale opzione MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT di database come illustrato nell'istruzione T-SQL seguente:

    ALTER DATABASE CURRENT
 SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;

Passaggio 3: Eseguire la migrazione delle tabelle

È necessario creare e popolare una copia ottimizzata per la memoria della tabella che si vuole testare. È possibile crearla usando:

Ottimizzazione guidata per la memoria di SSMS

Per usare questa opzione di migrazione:

  1. Connettersi al database di test con SSMS.

  2. In Esplora oggetti è possibile fare clic con il pulsante destro del mouse su una tabella e quindi scegliere Ottimizzazione guidata per la memoria.

    Verrà visualizzata l' Ottimizzazione guidata per la memoria della tabella .

  3. Nella procedura guidata selezionare Convalida della migrazione o sul pulsante Avanti per verificare se la tabella include eventuali funzionalità non supportate nelle tabelle ottimizzate per la memoria. Per altre informazioni, vedi:

  4. Se la tabella non include funzionalità non supportate, la procedura guidata può eseguire automaticamente la migrazione effettiva dello schema e dei dati.

T-SQL manuale

Per usare questa opzione di migrazione:

  1. Connettersi al database di test tramite SSMS o un'utilità analoga.
  2. Ottenere lo script T-SQL completo per la tabella e i relativi indici.
    • In SSMS fare clic con il pulsante destro del mouse sul nodo della tabella.
    • Selezionare Crea script per tabella>CREA in>Nuova finestra Query.
  3. Nella finestra dello script aggiungere WITH (MEMORY_OPTIMIZED = ON) all'istruzione CREATE TABLE.
  4. Se esiste un indice CLUSTERED, modificarlo in NONCLUSTERED.
  5. Rinominare la tabella esistente in sp_rename.
  6. Creare la nuova copia della tabella ottimizzata per la memoria eseguendo lo script modificato CREATE TABLE.
  7. Copiare i dati nella tabella ottimizzata per la memoria usando l'istruzione INSERT...SELECT * INTO: 
    INSERT INTO [<new_memory_optimized_table>]
        SELECT * FROM [<old_disk_based_table>];

Passaggio 4 (facoltativo): Eseguire la migrazione di stored procedure

La funzionalità in memoria può anche modificare una stored procedure per migliorare le prestazioni.

Considerazioni sulle stored procedure compilate in modo nativo

Una stored procedure compilata in modo nativo deve avere le opzioni seguenti nella relativa clausola WITH T-SQL:

  • NATIVE_COMPILATION: significa che le istruzioni Transact-SQL nella procedura vengono tutte compilate in codice nativo per un'esecuzione efficiente.
  • SCHEMABINDING: indica le tabelle in cui la stored procedure non può modificare le definizioni di colonna in alcun modo che abbia effetto sulla stored procedure, a meno che non si rimuova la stored procedure.

Un modulo nativo deve usare blocchi ATOMICI di grandi dimensioni per la gestione delle transazioni. Non ci sono ruoli per BEGIN TRANSACTION o ROLLBACK TRANSACTION. espliciti Se il codice rileva una violazione di una regola business, è possibile che il blocco atomico venga terminato con un'istruzione THROW.

CREATE PROCEDURE tipica per le stored procedure compilate in modo nativo

In genere l'istruzione T-SQL per creare una stored procedure compilata in modo nativo è simile al modello seguente:

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;
  • Per TRANSACTION_ISOLATION_LEVEL, SNAPSHOT è il valore più comune per la stored procedure compilata in modo nativo. Tuttavia, è supportato anche un subset degli altri valori:
    • REPEATABLE READ
    • SERIALIZABLE
  • Il valore LANGUAGE deve essere presente nella vista sys.syslanguages, nella colonna name. Ad esempio: N'us_english'.

Come eseguire la migrazione di una stored procedure

Passaggi della migrazione:

  1. Ottenere lo script CREATE PROCEDURE per la stored procedure interpretata regolare.
  2. Riscrivere l'intestazione in modo che corrisponda al modello precedente.
  3. Verificare se il codice T-SQL della stored procedure usa funzionalità non supportate per le stored procedure compilate in modo nativo. Se necessario, implementare le soluzioni alternative. Per altre informazioni vedere Problemi di migrazione relativi alle stored procedure compilate in modo nativo.
  4. Rinominare la stored procedure precedente tramite sp_rename. In alternativa usare semplicemente DROP.
  5. Eseguire il codice T-SQL CREATE PROCEDURE modificato.

Passaggio 5: Eseguire il carico di lavoro nel test

Eseguire un carico di lavoro nel database di test simile al carico di lavoro eseguito nel database di produzione. Dovrebbe indicare il miglioramento delle prestazioni ottenuto con l'uso della funzionalità in memoria per tabelle e stored procedure.

Gli attributi principali del carico di lavoro sono i seguenti:

  • Numero di connessioni simultanee.
  • Rapporto di lettura/scrittura.

Per personalizzare ed eseguire il carico di lavoro di test, si consiglia di usare il pratico strumento ostress.exe.

Per ridurre al minimo la latenza di rete, eseguire il test nella stessa area geografica di Azure in cui è disponibile il database.

Passaggio 6: Monitoraggio post-implementazione

Tenere sotto controllo gli effetti sulle prestazioni delle implementazioni in memoria nell'ambiente di produzione:

Contenuto correlato