Eventi
Ottieni gratuitamente la certificazione in Microsoft Fabric.
19 nov, 23 - 10 dic, 23
Per un periodo di tempo limitato, il team della community di Microsoft Fabric offre buoni per esami DP-600 gratuiti.
Prepara oraQuesto browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
Si applica a: SQL Server Database SQL di Azure Istanza gestita di SQL di Azure
Questo articolo contiene descrizioni approfondite di varie funzionalità di Elaborazione di query intelligenti (IQP), note sulla versione e altri dettagli. La famiglia di funzionalità di elaborazione di query intelligenti include funzionalità ad ampio spettro che migliorano le prestazioni di carichi di lavoro esistenti con un impegno minimo per l'implementazione.
È possibile impostare automaticamente i carichi di lavoro come idonei all'elaborazione di query intelligenti abilitando il livello di compatibilità applicabile per il database. Questa opzione è impostabile con Transact-SQL. Ad esempio, per impostare il livello di compatibilità di un database su SQL Server 2022 (16.x):
ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;
Per altre informazioni sulle modifiche introdotte con le nuove versioni, vedere:
Si applica a: SQL Server, a partire da SQL Server 2017 (14.x), e database SQL di Azure
La funzionalità di join adattivo in modalità batch consente di rimandare a dopo la scansione del primo input la scelta tra l'esecuzione di un metodo hash join e l'esecuzione di un metodo join a cicli annidati, usando un singolo piano memorizzato nella cache. L'operatore Join adattivo definisce una soglia che viene usata per stabilire quando passare a un piano Cicli annidati. Durante l'esecuzione il piano può pertanto passare a una strategia di join più efficace.
Per altre informazioni, incluso come disabilitare i join adattivi senza modificare il livello di compatibilità, vedere Informazioni sui join adattivi.
Si applica a: SQL Server, a partire da SQL Server 2017 (14.x), e database SQL di Azure
Una Funzione con valori di tabella a più istruzioni (MSTVF) è un tipo di funzione definita dall'utente che può accettare parametri, eseguire più istruzioni T-SQL e RETURN
una tabella.
L'esecuzione interleaved riduce i problemi di prestazioni del carico di lavoro dovute alle stime della cardinalità fisse associate alle funzioni con valori di tabella con istruzioni multiple (MSTVF). Con l'esecuzione interleaved, il conteggio effettivo delle righe viene usato per adottare decisioni più mirate relativamente a un piano di query downstream.
Le funzioni con valori di tabella con istruzioni multiple hanno una stima di cardinalità predefinita pari a 100 a partire da SQL Server 2014 (12.x) e pari a 1 nelle versioni di SQL Server precedenti.
L'esecuzione interleaved cambia il limite unidirezionale tra le fasi di ottimizzazione ed esecuzione nel caso di un'esecuzione a query singola e consente l'adattamento dei piani in base alle stime di cardinalità aggiornate. Se durante l'ottimizzazione il motore di database rileva un candidato per l'esecuzione interleaved che usa funzioni con valori di tabella con istruzioni multiple (MSTVFs) si sospende l'ottimizzazione, si esegue il sottoalbero appropriato, si acquisiscono stime di cardinalità accurate e quindi si riprende l'ottimizzazione per le operazioni downstream.
L'immagine seguente rappresenta un output di Statistiche query dinamiche, un subset di un piano di esecuzione complessivo che mostra l'impatto delle stime della cardinalità fisse da funzioni con valori di tabella con istruzioni multiple (MSTVFs).
È possibile visualizzare il flusso di righe effettivo e le righe stimate. Tre aree del piano sono degne di nota (il flusso va da destra a sinistra):
Confrontare il piano precedente al piano reale generato con l'esecuzione interleaved attivata:
Attualmente le funzioni MSTVF che fanno riferimento a istruzioni nell'esecuzione interleaved devono essere di sola lettura e non far parte di un'operazione di modifica dei dati. Le funzioni MSTV, poi, sono idonee per l'esecuzione interleaved solo se non usano costanti di runtime.
In generale, maggiore è lo scarto tra il numero di righe stimato e il numero reale (associato al numero di operazioni del piano downstream), maggiore è l'impatto sulle prestazioni.
L'esecuzione interleaved può risultare vantaggiosa nelle query in cui:
SELECT *
di una funzione MSTVF non trae vantaggio dall'esecuzione interleaved.Il sovraccarico previsto è minimo o nullo. Le funzioni con valori di tabella con istruzioni multiple (MSTVFs) venivano già materializzate prima dell'introduzione dell'esecuzione interleaved, ma ora grazie all'abilitazione dell'ottimizzazione differita tali funzioni usano la stima della cardinalità del set di righe materializzate. È possibile che in seguito alle modifiche alcuni piani registrino un miglioramento della cardinalità per il sottoalbero ma una riduzione dell'efficienza per la query nel suo complesso. La prevenzione può includere il ripristino del livello di compatibilità o l'uso di Query Store per imporre la versione non regredita del piano.
Dopo che un piano di esecuzione interleaved viene memorizzato nella cache, il piano con le stime aggiornate alla prima esecuzione viene usato per le esecuzioni consecutive e non viene creata di nuovo l'istanza di esecuzione interleaved.
È possibile visualizzare gli attributi d'uso nel piano di esecuzione query:
Attributo del piano di esecuzione | Descrizione |
---|---|
ContainsInterleavedExecutionCandidates | Si applica al nodo QueryPlan. Quando è true, il piano contiene candidati per l'esecuzione interleaved. |
IsInterleavedExecuted | Attributo dell'elemento RuntimeInformation in RelOp per il nodo TVF. Quando è true, l'operazione è stata materializzata come parte di un'operazione di esecuzione interleaved. |
È anche possibile rilevare le occorrenze di esecuzione interleaved con i seguenti eventi estesi:
XEvent | Descrizione |
---|---|
interleaved_exec_status |
Questo evento viene generato quando si verifica l'esecuzione interleaved. |
interleaved_exec_stats_update |
Questo evento descrive le stime della cardinalità aggiornate dall'esecuzione interleaved. |
Interleaved_exec_disabled_reason |
Questo evento viene generato quando in una query con un possibile candidato per l'esecuzione interleaved non viene applicata tale modalità di esecuzione. |
Per consentire all'esecuzione interleaved di rivedere le stime della cardinalità MSTVF è necessario eseguire la query. Tuttavia il piano di esecuzione stimato viene ancora visualizzato quando sono presenti candidati per l'esecuzione interleaved tramite l'attributo showplan ContainsInterleavedExecutionCandidates
.
Se un piano è viene cancellato o espulso dalla cache, durante l'esecuzione della query l'esecuzione interleave viene usata da una nuova compilazione.
Un'istruzione che usa OPTION (RECOMPILE)
crea un nuovo piano usando l'esecuzione interleaved e non lo memorizza nella cache.
È possibile forzare i piani che usano l'esecuzione interleaved. Il piano è la versione che presenta stime della cardinalità corrette sulla base dell'esecuzione iniziale.
È possibile disabilitare l'esecuzione interleaved nell'ambito del database o dell'istruzione mantenendo comunque la compatibilità sul livello 140 o superiore. Per disabilitare l'esecuzione interleaved per tutte le esecuzioni di query provenienti dal database, eseguire l'istruzione seguente all'interno del contesto del database applicabile:
-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;
-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;
Quando è abilitata, questa impostazione viene visualizzata come abilitata in sys.database_scoped_configurations. Per abilitare nuovamente l'esecuzione interleaved per tutte le esecuzioni di query provenienti dal database, eseguire l'istruzione seguente all'interno del contesto del database applicabile:
-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;
-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;
È anche possibile disabilitare l'esecuzione interleaved per una query specifica definendo DISABLE_INTERLEAVED_EXECUTION_TVF
come hint per la query USE HINT. Ad esempio:
SELECT [fo].[Order Key], [fo].[Quantity], [foo].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession',
'1-01-2013',
'10-15-2014') AS [foo] ON [fo].[Order Key] = [foo].[Order Key]
AND [fo].[City Key] = [foo].[City Key]
AND [fo].[Customer Key] = [foo].[Customer Key]
AND [fo].[Stock Item Key] = [foo].[Stock Item Key]
AND [fo].[Order Date Key] = [foo].[Order Date Key]
AND [fo].[Picked Date Key] = [foo].[Picked Date Key]
AND [fo].[Salesperson Key] = [foo].[Salesperson Key]
AND [fo].[Picker Key] = [foo].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));
L'hint per la query USE HINT ha la precedenza rispetto una configurazione con ambito database o un'impostazione del flag di traccia.
Si applica a: SQL Server, a partire da SQL Server 2019 (15.x) e database SQL di Azure
L'inlining di funzioni definite dall'utente scalari trasforma automaticamente le funzioni definite dall'utente scalari in espressioni relazionali e le incorpora nella query SQL chiamante. Questa trasformazione migliora le prestazioni dei carichi di lavoro che sfruttano le funzioni definite dall'utente scalari. L'inlining di funzioni definite dall'utente scalari facilita l'ottimizzazione basata sui costi delle operazioni all'interno delle funzioni definite dall'utente. I risultati sono efficienti, orientati ai set e paralleli, al contrario dei piani di esecuzione seriale iterativi e poco efficienti. Questa funzionalità è abilitata per impostazione predefinita nel livello di compatibilità del database 150.
Per altre informazioni, vedere Inlining di funzioni definite dall'utente scalari.
Si applica a: SQL Server, a partire da SQL Server 2019 (15.x) e database SQL di Azure
La compilazione posticipata delle variabili di tabella migliora la qualità del piano e le prestazioni generali per le query che fanno riferimento a variabili di tabella. Durante l'ottimizzazione e la compilazione iniziale del piano, questa funzionalità propaga le stime della cardinalità basate sui conteggi effettivi delle righe di variabili di tabella. Queste informazioni esatte sui conteggi delle righe verranno quindi usate per ottimizzare le operazioni del piano a valle.
Con la compilazione posticipata delle variabili di tabella, la compilazione di un'istruzione che fa riferimento a una variabile di tabella viene posticipata fino alla prima esecuzione effettiva dell'istruzione. Questo comportamento della compilazione posticipata è identico a quello delle tabelle temporanee. Questo cambiamento determina l'uso della cardinalità effettiva invece dell'ipotesi originale di una sola riga.
Per abilitare la compilazione posticipata delle variabili di tabella, abilitare il livello di compatibilità database 150 o superiore per il database a cui si è connessi quando si esegue la query.
La compilazione posticipata delle variabili di tabella non modifica altre caratteristiche delle variabili di tabella. Ad esempio, questa funzionalità non aggiunge statistiche di colonna alle variabili di tabella.
La compilazione posticipata delle variabili di tabella non aumenta la frequenza di ricompilazione. Piuttosto, sposta la posizione di esecuzione della compilazione iniziale. Il piano memorizzato nella cache risultante viene generato in base al conteggio delle righe delle variabili di tabella della compilazione posticipata iniziale. Il piano memorizzato nella cache viene riusato da query consecutive, fino a quando non viene rimosso o ricompilato.
Il conteggio delle righe delle variabili di tabella usato per la compilazione del piano iniziale rappresenta un valore tipico e potrebbe essere diverso da un'ipotesi di conteggio di righe fisso. Se è diverso, è un vantaggio per le operazioni a valle. Se il conteggio delle righe delle variabili di tabella varia notevolmente tra le esecuzioni, questa funzionalità potrebbe non migliorare le prestazioni.
Disabilitare la compilazione posticipata delle variabili di tabella nell'ambito del database o dell'istruzione mantenendo comunque un livello di compatibilità del database 150 o superiore. Per disabilitare la compilazione posticipata delle variabili di tabella per tutte le esecuzioni di query originate dal database, eseguire questo esempio nel contesto del database applicabile:
ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;
Per riabilitare la compilazione posticipata delle variabili di tabella per tutte le esecuzioni di query originate dal database, eseguire questo esempio nel contesto del database applicabile:
ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;
È anche possibile disabilitare la compilazione posticipata delle variabili di tabella per una query specifica assegnando DISABLE_DEFERRED_COMPILATION_TV come hint per la query USE HINT. Ad esempio:
DECLARE @LINEITEMS TABLE
(L_OrderKey INT NOT NULL,
L_Quantity INT NOT NULL
);
INSERT @LINEITEMS
SELECT L_OrderKey, L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;
SELECT O_OrderKey,
O_CustKey,
O_OrderStatus,
L_QUANTITY
FROM
ORDERS,
@LINEITEMS
WHERE O_ORDERKEY = L_ORDERKEY
AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));
Si applica a: SQL Server 2022 (16.x) Database Azure SQL Istanza gestita di SQL di Azure
L'ottimizzazione del piano sensibile ai parametri (PSP) fa parte della famiglia di funzionalità di elaborazione di query intelligenti. Fa riferimento allo scenario in cui un singolo piano memorizzato nella cache per una query con parametri non risulta ottimale per tutti i possibili valori dei parametri in ingresso. Questa situazione si verifica in caso di distribuzioni di dati non uniformi.
L'elaborazione delle query approssimativa è una nuova famiglia di funzionalità, che aggrega set di dati di grandi dimensioni in cui la velocità di risposta è più importante della precisione assoluta. Un esempio è il calcolo di COUNT(DISTINCT())
su 10 miliardi di righe, per la visualizzazione in un dashboard. In questo caso, la precisione assoluta non è importante, ma la velocità di risposta è fondamentale.
Si applica a: SQL Server, a partire da SQL Server 2019 (15.x) e database SQL di Azure
La nuova funzione di aggregazione APPROX_COUNT_DISTINCT restituisce il numero approssimativo di valori univoci non Null in un gruppo.
Questa funzionalità è disponibile a partire da SQL Server 2019 (15.x), indipendentemente dal livello di compatibilità.
Per altre informazioni, vedere APPROX_COUNT_DISTINCT (Transact-SQL).
Si applica a: SQL Server, a partire da SQL Server 2022 (16.x) e al database SQL di Azure
Queste funzioni di aggregazione calcolano i percentili per un set di dati di grandi dimensioni con limiti di errore basati sulla classificazione accettabili per prendere decisioni rapide usando funzioni di aggregazione percentile approssimative.
Per altre informazioni, vedere APPROX_PERCENTILE_DISC (Transact-SQL) e APPROX_PERCENTILE_CONT (Transact-SQL)
Si applica a: SQL Server, a partire da SQL Server 2019 (15.x) e database SQL di Azure
La modalità batch per rowstore abilita l'esecuzione in modalità batch per i carichi di lavoro analitici senza richiedere indici columnstore. Questa funzionalità supporta l'esecuzione in modalità batch e i filtri bitmap per gli heap su disco e gli indici con albero B. La modalità batch per rowstore abilita il supporto per tutti gli operatori esistenti abilitati alla modalità batch.
Nota
Nella documentazione viene usato in modo generico il termine albero B in riferimento agli indici. Negli indici rowstore, il motore di database implementa un albero B+. Ciò non si applica a indici columnstore o a indici in tabelle ottimizzate per la memoria. Per altre informazioni, vedere Architettura e guida per la progettazione degli indici SQL Server e Azure SQL.
SQL Server 2012 (11.x) ha introdotto una nuova funzionalità per accelerare i carichi di lavoro analitici: gli indici columnstore. In ogni versione successiva di SQL Server sono stati estesi i casi d'uso e migliorate le prestazioni degli indici columnstore. La creazione di indici columnstore nelle tabelle può migliorare le prestazioni per i carichi di lavoro analitici. Esistono tuttavia due set di tecnologie correlate ma distinte:
I due set di funzionalità interagiscono per migliorare input/output (I/O) e uso della CPU:
Le due tecnologie sfruttano i vantaggi reciproci laddove possibile. Ad esempio, le aggregazioni in modalità batch possono essere valutate come parte di un'analisi dell'indice columnstore. Anche i dati columnstore compressi con la codifica RLE vengono elaborati in modo molto più efficiente con i join e le aggregazioni in modalità batch.
È tuttavia importante tenere presente che le due funzionalità sono indipendenti:
Usando le due funzionalità insieme, si ottengono in genere i risultati migliori. Prima di SQL Server 2019 (15.x), SQL Server Query Optimizer ha considerato l'elaborazione in modalità batch solo per le query che coinvolgono almeno una tabella con un indice columnstore.
Gli indici columnstore potrebbero non essere appropriati per alcune applicazioni. Un'applicazione potrebbe usare altre funzionalità non supportate con gli indici columnstore. Le modifiche sul posto, ad esempio, non sono compatibili con la compressione columnstore, quindi i trigger non sono supportati nelle tabelle con indici columnstore in cluster, ma soprattutto gli indici columnstore aggiungono un overhead per le istruzioni DELETE e UPDATE.
Per alcuni carichi di lavoro ibridi analitico-transazionali l'overhead di un carico di lavoro transazionale è maggiore dei vantaggi offerti dagli indici columnstore. Questi scenari possono trarre vantaggio dall'uso ottimale della CPU tramite l'elaborazione solo in modalità batch. Questo è il motivo per cui la modalità batch per rowstore considera la modalità batch per tutte le query, indipendentemente dal tipo di indici interessati.
I carichi di lavoro seguenti possono trarre vantaggio dalla modalità batch per rowstore:
Nota
La modalità batch per rowstore consente solo di ridurre l'utilizzo della CPU. Se il collo di bottiglia è associato alle operazioni di I/O e i dati non sono già memorizzati nella cache (cache "a freddo"), la modalità batch per rowstore non ridurrà il tempo trascorso per le query. Analogamente, se la memoria del computer non è sufficiente per memorizzare nella cache tutti i dati, un miglioramento delle prestazioni è improbabile.
La modalità batch in rowstore richiede che il database sia di livello di compatibilità 150.
Anche se una query non accede a nessuna tabella con indici columnstore, Query Processor usa l'euristica per decidere se prendere in considerazione la modalità batch. L'euristica è costituita da questi controlli:
Se la modalità batch per rowstore viene usata, la modalità di esecuzione effettiva visualizzata nel piano di query è la modalità batch. L'operatore di analisi usa la modalità batch per gli heap su disco e gli indici albero B. Questa analisi in modalità batch può valutare i filtri bitmap in modalità batch. Nel piano è possibile vedere anche altri operatori della modalità batch. Alcuni esempi sono gli hash join, le aggregazioni basate su hash, gli ordinamenti, le aggregazioni finestra, i filtri, la concatenazione e gli operatori scalari di calcolo.
I piani di query non usano sempre la modalità batch. Query Optimizer potrebbe decidere che la modalità batch non è utile per la query.
Lo spazio di ricerca di Query Optimizer cambia. Il piano in modalità riga eventualmente ottenuto potrebbe quindi non essere uguale a quello ottenuto a un livello di compatibilità inferiore e il piano in modalità batch eventualmente ottenuto potrebbe non essere uguale a quello ottenuto con un indice columnstore.
I piani potrebbero anche cambiare per le query che combinano gli indici columnstore e rowstore a causa della nuova analisi rowstore in modalità batch.
Esistono attualmente alcune limitazioni per la nuova modalità batch per analisi di rowstore:
Esistono query per le quali la modalità batch non viene usata neppure con gli indici columnstore. Un esempio sono le query che richiedono cursori. Queste stesse esclusioni vengono estese anche alla modalità batch per rowstore.
La configurazione con ambito database BATCH_MODE_ON_ROWSTORE
è per impostazione predefinita su ON.
È possibile disabilitare la modalità batch per rowstore senza cambiare il livello di compatibilità del database:
-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;
-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;
È possibile disabilitare la modalità batch per rowstore tramite configurazione con ambito database. È tuttavia possibile eseguire l'override dell'impostazione a livello di query usando l'hint per la query ALLOW_BATCH_MODE
. L'esempio seguente abilita la modalità batch per rowstore anche con la funzionalità disabilitata tramite la configurazione con ambito database:
SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));
È anche possibile disabilitare la modalità batch per rowstore per una query specifica usando l'hint per la query DISALLOW_BATCH_MODE
. Vedere l'esempio seguente:
SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));
Le funzionalità di feedback per l'elaborazione delle query fanno parte della famiglia di funzionalità di elaborazione intelligente delle query.
Il feedback sull'elaborazione delle query è un processo in base al quale Query Processor in SQL Server, database SQL di Azure e Istanza gestita di SQL di Azure usa dati storici sull'esecuzione di una query per decidere se la query potrebbe ricevere assistenza da una o più modifiche alla modalità di compilazione ed esecuzione. I dati sulle prestazioni vengono raccolti in Query Store, con vari suggerimenti per migliorare l'esecuzione delle query. In caso di esito positivo, le modifiche apportate al disco vengono mantenute in memoria e/o in Query Store per un uso futuro. Se i suggerimenti non producono miglioramenti sufficienti, vengono eliminati e la query continua a essere eseguita senza tale feedback.
Per informazioni sulle funzionalità di feedback per l'elaborazione delle query disponibili in versioni diverse di SQL Server o in database SQL di Azure o Istanza gestita di SQL di Azure, vedere Elaborazione intelligente delle query nei database SQL o negli articoli seguenti per ogni funzionalità di feedback.
Il feedback sulle concessioni di memoria è stato introdotto in parti rispetto alle principali versioni precedenti di SQL Server.
Per informazioni sul feedback delle concessioni di memoria in modalità batch, vedere Feedback sulle concessioni di memoria in modalità batch.
Per informazioni sul feedback delle concessioni di memoria in modalità riga, vedere Feedback sulle concessioni di memoria in modalità riga.
Per informazioni sul feedback sulle concessioni di memoria percentile e in modalità persistenza, vedere Feedback sulle concessioni di memoria in modalità percentile e persistenza.
Per informazioni sui feedback DOP, vedere Feedback sul grado di parallelismo (DOP).
Per informazioni sul feedback sulla stima di cardinalità, visitare Feedback sulla stima di cardinalità (CE).
Per informazioni sull'uso forzato del piano ottimizzato con Query Store, vedere Utilizzo forzato del piano ottimizzato con Query Store.
Eventi
Ottieni gratuitamente la certificazione in Microsoft Fabric.
19 nov, 23 - 10 dic, 23
Per un periodo di tempo limitato, il team della community di Microsoft Fabric offre buoni per esami DP-600 gratuiti.
Prepara oraFormazione
Modulo
Informazioni su come usare i miglioramenti della funzionalità di query intelligence integrata di SQL Server 2022.
Certificazione
Microsoft Certified: Azure Database Administrator Associate - Certifications
Amministrare un'infrastruttura di database SQL Server per database relazionali, ibridi, locali e cloud con le offerte di database relazionali Microsoft PaaS.