Utilizzo di un file di input XML per l'ottimizzazione

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

<DTAInput>
...code removed
  <Workload>
    <File>MyWorkload.sql</File>
  </Workload>
...code removed
</DTAInput>

<DTAInput>
...code removed
  <Workload>
    <EventString Weight="100">
     SELECT * FROM MyTable1
     WHERE MyColumn1 &gt; 200
     ORDER BY MyColumn1
    </EventString>
    <EventString Weight="1">
     SELECT * FROM MyTable2
     WHERE MyColumn2 &gt; 200
     ORDER BY MyColumn2
    </EventString>
  </Workload>
...code removed
</DTAInput>

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:

1. 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.

2. Si specifica un server di prova per l'ottimizzazione nel file di input XML insieme agli altri parametri che definiscono la sessione di ottimizzazione.

3. 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>

Vedere anche

Altre risorse