Utilizzo di un file di input XML per l'ottimizzazione
Tutte le operazioni di ottimizzazione che è possibile eseguire tramite l'interfaccia utente grafica (GUI) di Ottimizzazione guidata Motore di database e l'utilità da riga di comando dta possono essere definite nel file di input XML di Ottimizzazione guidata Motore di database. Il file di input XML, tuttavia, supporta ulteriori opzioni di ottimizzazione rispetto a quelle disponibili nella GUI e nell'utilità da riga di comando.
Il file di input XML utilizza lo schema XML di Ottimizzazione guidata Motore di database, disponibile nel percorso seguente della directory di installazione di SQL Server 2008:
C:\Programmi\Microsoft SQL Server\10\Tools\Binn\schemas\sqlserver\2004\07\dta\dtaschema.xsd
Lo schema può inoltre essere scaricato dall'URL seguente:
https://schemas.microsoft.com/sqlserver/2004/07/dta
Il file di input XML consente di utilizzare gli strumenti XML desiderati durante l'ottimizzazione dei database e offre agli amministratori di database esperti una maggiore flessibilità. Tramite il file di input XML, ad esempio, è possibile specificare una configurazione contenente una combinazione di strutture di progettazione fisica esistenti e ipotetiche, quali indici, viste indicizzate e partizioni. Sarà quindi possibile utilizzare l'utilità da riga di comando dta per ottimizzare un database come se la combinazione di strutture di progettazione fisica esistenti e ipotetiche fosse già stata implementata. In questo modo, sarà possibile eseguire analisi di simulazione, evitando il verificarsi dell'overhead provocato dall'implementazione di una configurazione effettiva, prima dell'ottimizzazione.
Nelle sottosezioni seguenti verranno illustrate le operazioni di ottimizzazione che è possibile eseguire solo tramite il file di input XML di Ottimizzazione guidata Motore di database. Per ulteriori informazioni sul file e sul relativo utilizzo, vedere Guida di riferimento ai file di input XML (Ottimizzazione guidata motore di database).
Definizione di configurazioni con l'elemento Configuration
Benché la funzionalità di configurazione specificata dall'utente possa essere utilizzata in modo limitato tramite la GUI di Ottimizzazione guidata Motore di database, è completamente supportata solo se si utilizza il file di input XML con l'utilità da riga di comando dta. Quando si utilizza il file di input XML, in questo file è possibile specificare una configurazione completamente ipotetica oppure una configurazione contenente una combinazione di strutture di progettazione fisica esistenti e ipotetiche. Quindi, dopo avere convalidato il file di input in base allo schema di Ottimizzazione guidata Motore di database, sarà possibile utilizzare il file come input nell'utilità da riga di comando dta. Durante la sessione di ottimizzazione, tramite Ottimizzazione guidata Motore di database il carico di lavoro specificato viene eseguito nei database, ma Ottimizzazione guida Motore di database non valuta la configurazione esistente di indici, viste indicizzate e partizioni. Ottimizzazione guidata Motore di database utilizza invece la configurazione che rappresenta una combinazione di strutture ipotetiche ed esistenti. L'utilizzo della configurazione ipotetica consente di analizzare gli effetti di una configurazione particolare sulle prestazioni del database, evitando il verificarsi dell'overhead provocato dall'implementazione della configurazione effettiva.
Per specificare una configurazione contenente strutture di progettazione fisica esistenti e ipotetiche, utilizzare il sottoelemento Configuration dopo l'elemento TuningOptions nel file di input XML di Ottimizzazione guidata Motore di database. Per ulteriori informazioni, vedere Procedura: Esecuzione dell'analisi esplorativa e Esempio di file di input XML con configurazione specificata dall'utente (DTA).
Ottimizzazione di carichi di lavoro inline con l'elemento EventString
Quando si utilizza il file di input XML con Ottimizzazione guidata Motore di database, è possibile evitare completamente l'uso di un file del carico di lavoro. È invece possibile specificare un carico di lavoro e il peso associato inline nel file di input XML. Evitando di utilizzare una tabella o un file del carico di lavoro distinto, si ottengono i vantaggi seguenti:
È possibile ottimizzare i server remoti con maggiore facilità, in quanto non è necessario verificare che la tabella o il file distinto sia disponibile per Ottimizzazione guidata Motore di database.
È possibile integrare più agevolmente le funzionalità di Ottimizzazione guidata Motore di database in script utilizzabili in tutto l'ambiente aziendale.
Per specificare un carico di lavoro inline, utilizzare il sottoelemento EventString, per cui è facoltativamente possibile specificare un peso associato. Se utilizzato, questo sottoelemento viene specificato per l'elemento padre Workload anziché indicare un file o tabella del carico di lavoro distinto. Negli esempi di codice seguenti vengono confrontati l'utilizzo di un elemento EventString con il file di input XML e l'utilizzo di un file del carico di lavoro normale con il file di input XML.
Esempi
A. Definizione di un file del carico di lavoro distinto con l'elemento Workload
<DTAInput>
...code removed
<Workload>
<File>MyWorkload.sql</File>
</Workload>
...code removed
</DTAInput>
B. Definizione di un carico di lavoro inline con l'elemento EventString
<DTAInput>
...code removed
<Workload>
<EventString Weight="100">
SELECT * FROM MyTable1
WHERE MyColumn1 > 200
ORDER BY MyColumn1
</EventString>
<EventString Weight="1">
SELECT * FROM MyTable2
WHERE MyColumn2 > 200
ORDER BY MyColumn2
</EventString>
</Workload>
...code removed
</DTAInput>
Nell'esempio precedente sono stati specificati pesi diversi per ogni query nell'elemento EventString: uno di valore 100 e uno di valore 1. Ciò significa che durante l'ottimizzazione delle query tramite Ottimizzazione guidata Motore di database, l'applicazione gestirà le query con peso pari a 100 come se fossero 100 istanze della query in confronto a un'istanza della query con peso pari a 1. Nell'esempio precedente la prima query è 100 volte più importante della seconda ai fini di Ottimizzazione guidata Motore di database. Si noti inoltre che il segno maggiore di (>) è stato convertito in >, poiché nel linguaggio XML > è un carattere riservato con un significato specifico.
Per un esempio di definizione di un carico di lavoro inline con l'elemento EventString, vedere Esempio di file di input XML con carico di lavoro inline (DTA).
Come ignorare le costanti in un carico di lavoro con l'elemento IgnoreConstantsInWorkload
I carichi di lavoro possono contenere istruzioni che fanno riferimento a costanti. Ottimizzazione guidata Motore di database può utilizzare tali costanti in un carico di lavoro per creare indicazioni relative a viste indicizzate con condizioni di selezione o funzioni di partizione RANGE per indici partizionati.
In alcuni casi, tuttavia, non è vantaggioso che Ottimizzazione guidata Motore di database consideri le costanti in un carico di lavoro. Si consideri ad esempio un carico di lavoro che contiene l'istruzione seguente:
UPDATE BankAccountTable
SET AccountBalance = AccountBalance - 1000.00
WHERE CustomerID =
(SELECT CustomerID FROM Customer WHERE CustomerName = 'Alice')
Questo carico di lavoro può includere la costante 'Alice' perché è stato acquisito quando Alice eseguiva una transazione. Se Ottimizzazione guidata Motore di database utilizzasse questa costante, potrebbe produrre indicazioni di ottimizzazione non ottimali. Per evitare questo problema, può essere utile impostare Ottimizzazione guidata Motore di database in modo che ignori le costanti quando utilizza questo carico di lavoro per ottimizzare un database.
Nel file di input XML è possibile specificare l'elemento IgnoreConstantsInWorkload, che risiede sotto l'elemento TuningOptions, affinché Ottimizzazione guidata Motore di database ignori tutte le costanti in un carico di lavoro. Quando si specifica questo elemento, le viste indicizzate per le quali Ottimizzazione guidata Motore di database può creare delle indicazioni non conterranno condizioni di selezione. Le costanti utilizzate nelle funzioni di partizione verranno inoltre derivate solo da dati e non dalle costanti contenute nel carico di lavoro.
Utilizzo di un server di prova per l'ottimizzazione di un carico di lavoro per un server di produzione
L'ottimizzazione di un carico di lavoro di dimensioni elevate può creare un overhead significativo nel server interessato a causa dell'ingente quantità di chiamate eseguite da Ottimizzazione guidata Motore di database a Query Optimizer durante il processo di ottimizzazione. L'utilizzo di un server di prova oltre al server di produzione consente di eliminare questo problema. Ottimizzazione guidata Motore di database supporta questo scenario in modo univoco:
Si verifica che l'utente che desidera eseguire l'ottimizzazione sia disponibile sia nel server di produzione che in quello di prova. Se si appartiene al ruolo predefinito del server sysadmin, questo passaggio non è necessario.
Si specifica un server di prova per l'ottimizzazione nel file di input XML insieme agli altri parametri che definiscono la sessione di ottimizzazione.
Si utilizza l'utilità da riga di comando dta per avviare la sessione di ottimizzazione e iniziare l'analisi del carico di lavoro.
Durante questa sessione di ottimizzazione del server di prova, Ottimizzazione guidata Motore di database esegue un numero minimo di chiamate al server di produzione per recuperarne le informazioni relative a profilo hardware, metadati del database e statistiche per consentire a Query Optimizer di ottimizzare accuratamente le query nel server di prova.
In realtà in questo scenario viene ottimizzato il server di prova, che duplica l'ambiente del server di produzione. Le informazioni sulla configurazione di una progettazione di database ricevute come risultato dell'ottimizzazione del server di prova potranno quindi essere implementate nel server di produzione durante una sessione di manutenzione. L'utilizzo di questo processo riduce al minimo l'impatto sulle prestazioni generato da Ottimizzazione guidata Motore di database. Il processo, inoltre, consente di evitare la copia effettiva dei dati dal server di produzione al server di prova e i costi necessari per duplicare il potente hardware del server di produzione nell'ambiente di prova.
Per specificare un server di prova, utilizzare il sottoelemento TestServer sotto l'elemento padre TuningOptions, come illustrato nell'esempio seguente:
Esempio
<DTAInput>
...code removed
<TuningOptions>
<TestServer>MyTestServer</TestServer>
<FeatureSet>IDX_IV</FeatureSet>
<Partitioning>NONE</Partitioning>
<KeepExisting>NONE</KeepExisting>
</TuningOptions>
...code removed
</DTAInput>
Per ulteriori informazioni sull'utilizzo di questa funzionalità e per altri esempi di codice, vedere Riduzione del carico di ottimizzazione del server di produzione.