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

  • Articolo

Si applica a:database SQL di Azure

OLTP in memoria può essere usato per migliorare le prestazioni di elaborazione delle transazioni, inserimento dati e scenari di dati temporanei, nei database di livello Premium e Business Critical senza aumentare il piano tariffario.

Seguire questa procedura per adottare OLTP in memoria nel database esistente.

Passaggio 1: Assicurarsi di usare un database di livello Premium o Business Critical

OLTP in memoria è supportato solo nel livello Premium (DTU) e Business Critical (vCore) di database SQL di Azure. OLTP in memoria è supportato se il risultato restituito è 1 (non 0):

SELECT DatabasePropertyEx(Db_Name(), 'IsXTPSupported');

XTP è l'acronimo di Extreme Transaction Processing.

Passaggio 2: Identificare gli oggetti di cui eseguire la migrazione a OLTP in memoria

SQL Server Management Studio (SSMS) include un report Di panoramica dell'analisi delle prestazioni delle transazioni che è possibile eseguire su un database con un carico di lavoro attivo. Il report identifica tabelle e 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 Standard Reports Transaction Performance Analysis Overview (Panoramica dell'analisi delle prestazioni delle transazioni dei report>>standard).

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

Passaggio 3: 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 del database di produzione.

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

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

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

    ALTER DATABASE CURRENT
 SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;

Passaggio 4: 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 memoria utile in SSMS.
  • Usare i comandi T-SQL.

Ottimizzazione guidata per la memoria di SSMS

Per usare questa opzione di migrazione:

  1. Connettersi al database di test con SSMS.

  2. Nella Esplora oggetti fare clic con il pulsante destro del mouse sulla tabella e quindi scegliere Ottimizzazione guidata memoria.

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

  3. Nella procedura guidata selezionare Convalida della migrazione (o il pulsante Avanti ) per verificare se la tabella include funzionalità non supportate 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 tabella script come>CREA in>una nuova finestra di 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 usando sp_rename.
  6. Creare la nuova copia ottimizzata per la memoria della tabella eseguendo lo script modificato CREATE TABLE .
  7. Copiare i dati nella tabella ottimizzata per la memoria usando INSERT...SELECT * INTO: 
    INSERT INTO [<new_memory_optimized_table>]
        SELECT * FROM [<old_disk_based_table>];

Passaggio 5 (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 clausola T-SQL WITH :

  • NATIVE_COMPILATION: significa che le istruzioni Transact-SQL nella procedura vengono tutte compilate in codice nativo per un'esecuzione efficiente.
  • SCHEMABINDING: ovvero le tabelle che la stored procedure non può avere le relative definizioni di colonna modificate in alcun modo che influiscano sulla stored procedure, a meno che non si esegua l'eliminazione della stored procedure.

Un modulo nativo deve usare un blocco ATOMIC grande per la gestione delle transazioni. Non esiste alcun ruolo per un oggetto esplicito BEGIN TRANSACTION o ROLLBACK TRANSACTION. Se il codice rileva una violazione di una regola business, può terminare il blocco atomico 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;
  • TRANSACTION_ISOLATION_LEVELPer , SN piattaforma di strumenti analitici HOT è il valore più comune per la stored procedure compilata in modo nativo. Tuttavia, è supportato anche un subset degli altri valori:
    • REPEATABLE READ
    • SERIALIZABLE
  • Il LANGUAGE valore deve essere presente nella sys.syslanguages vista, nella name colonna . Ad esempio: N'us_english'.

Come eseguire la migrazione di una stored procedure

Passaggi della migrazione:

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

Passaggio 6: 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. Questo dovrebbe rivelare il miglioramento delle prestazioni ottenuto dall'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, è consigliabile usare lo strumento ostress.exe pratico. Per altre informazioni, vedere Esempio in memoria in database SQL di Azure.

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

Passaggio 7: Monitoraggio post-implementazione

Valutare la possibilità di monitorare gli effetti delle prestazioni delle implementazioni in memoria nell'ambiente di produzione:

Contenuto correlato