Usare OLTP in memoria per migliorare le prestazioni dell'applicazione in un database SQL di Azure
Si applica a: Database SQL di Azure
OLTP in memoria può essere usato per migliorare le prestazioni di elaborazione delle transazioni, l'inserimenti dati e gli scenari di dati temporanei, senza aumentare l’obiettivo di servizio del database o del in pool elastico.
- Database e pool elastici nei livelli di servizio Premium (DTU) e Business Critical (vCore) supportano le tabelle OLTP in memoria.
- Il livello di servizio Hyperscale supporta un sottoinsieme di oggetti OLTP in memoria, ma non include tabelle ottimizzate per la memoria. Per altre informazioni, vedi Limitazioni Hyperscale.
Seguire i passaggi seguenti per adottare OLTP in memoria nei database esistenti.
Passaggio 1: Assicurarsi di usare un database di livello Premium o Business Critical
OLTP in memoria è supportato se il risultato della query seguente è 1
(non 0
):
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');
XTP è l'acronimo di Extreme Transaction Processing, ovvero un nome informale della funzionalità OLTP in memoria.
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.
Per generare il report in SSMS:
- 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 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:
Connettersi al database di test usando Microsoft SQL Server Management Studio (SSMS).
Per evitare di dover usare l'opzione
WITH (SNAPSHOT)
nelle query, impostare l’attuale opzioneMEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT
di database 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 per la memoria di SSMS
Per usare questa opzione di migrazione:
Connettersi al database di test con SSMS.
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 .
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:
- Elenco di controllo relativo all'ottimizzazione per la memoria in Ottimizzazione guidata per la memoria.
- Costrutti transact-SQL non supportati da OLTP in memoria.
- Migrazione a OLTP in memoria.
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:
- Connettersi al database di test usando SSMS.
- Ottenere lo script T-SQL completo per la tabella e i relativi vincoli e 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.
- Nella finestra dello script aggiungere
WITH (MEMORY_OPTIMIZED = ON)
all'istruzioneCREATE TABLE
. Per altre informazioni, vedere Sintassi per le tabelle ottimizzate per la memoria. - Se esiste un indice CLUSTERED, modificarlo in NONCLUSTERED.
- Rinominare la tabella esistente in sp_rename.
- Creare la nuova copia della tabella ottimizzata per la memoria eseguendo lo script modificato
CREATE TABLE
. - 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 5 (facoltativo): Eseguire la migrazione di stored procedure
OLTP in memoria supporta anche stored procedure compilate in modo nativo che possono migliorare le prestazioni di T-SQL.
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 in alcun modo che abbia effetto sulla stored procedure, a meno che non si rimuova la stored procedure.
Un modulo compilato nativo deve usare blocchi ATOMICI per la gestione di transazioni. Non esiste alcun uso di istruzioni BEGIN TRANSACTION
o ROLLBACK TRANSACTION
esplicite. Se ad esempio il codice rileva una violazione di una regola di business, è possibile che il blocco atomico venga terminato con un'istruzione THROW.
Esempio di una stored procedure compilata in modo nativo.
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 vistasys.syslanguages
, nella colonnaname
. Ad esempio:N'us_english'
.
Come eseguire la migrazione di una stored procedure per usare la compilazione nativa
Passaggi della migrazione:
- Ottenere lo script
CREATE PROCEDURE
per la stored procedure normale (interpretata). - Riscrivere l'intestazione in modo che corrisponda al modello precedente.
- 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.
- Rinominare la stored procedure precedente tramite sp_rename o eliminarla.
- Eseguire il codice T-SQL
CREATE PROCEDURE
modificato.
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. Dovrebbe indicare il miglioramento delle prestazioni ottenuto con l'uso della funzionalità OLTP 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
del gruppo di strumenti RML Utilities. Per altre informazioni, vedere campione in memoria nel database SQL di Azure.
Per ridurre al minimo la latenza di rete, eseguire ostress.exe
nella stessa area di Azure in cui è disponibile il database.
Passaggio 7: Monitoraggio post-implementazione
Tenere sotto controllo gli effetti sulle prestazioni delle implementazioni OLTP in memoria nell'ambiente di produzione: