205
6.5 Database Engine Tuning Advisor
Utilisation en ligne de commande
L’exécutable dta.exe vous permet d’exécuter une session d’analyse en mode ligne de
commande. Cela rend le DTA programmable et planifiable. Toutes les options sont
exprimables par des paramètres passés à l’exécutable, ou dans un fichier XML
d’entrée. Voici un exemple d’appel en ligne de commande :
dta.exe -S BABALUGA-XPS\SQL2005 -E –D AdventureWorks,AdventureWorksDW -d
AdventureWorks -s MaSession –if workload.sql –of rec.sql -fa IDX -A 0 -n 10000
qui signifie : connecte-toi au serveur BABALUGA-XPS\SQL2005 en sécurité
intégrée, dans le contexte de AdventureWorks ; crée la session nommée MaSession
pour analyser les bases AdventureWorks et AdventureWorksDW avec le fichier de requêtes workload.sql. Écris le script de génération des recommandations dans le fichier
rec.sql. N’ajoute que des index, fais une analyse sans durée limite, mais en ne prenant que les 10 000 premières instructions du workload d’entrée. Pour interrompre
dta.exe avant la fin du travail, utilisez la combinaison de touches CTRL+C.
Le DTA peut recevoir ses paramètres dans un fichier XML, mais aussi produire
ses recommandations dans un output en format XML (avec le paramètre -ox), pour
être par exemple utilisé comme outil d’optimisation intégré dans un outil tiers.
Vous trouverez la syntaxe d’appel complète dans les BOL, ou avec un
dta.exe -?
Analyse sur un serveur de test
Pour réaliser une bonne analyse, sans conséquence sur le serveur de production,
DTA permet de déplacer la charge de l’analyse sur un serveur de test. Il utilise pour
ce faire une méthodologie intelligente : une copie automatique de la base est effectuée sur le serveur de test, mais uniquement des métadonnées (structures d’objets) et
des statistiques de distribution des colonnes. Les données elles-mêmes sont inutiles
pour le processus d’optimisation, et il serait coûteux de les répliquer sur la machine
de test. DTA s’en passe donc. De plus, pour coller au plus près de la configuration du
serveur de production, il utilise les informations matérielles qu’il a glanées sur celuici (à l’aide de la procédure stockée étendue xp_msver) pour fonder son optimisation
sur le serveur de test. On profite donc d’une analyse au plus près de la réalité, sans les
inconvénients.
Pour ce faire, vous devez être sysadmin sur les deux serveurs, ou exécuter l’analyse
sous un login présent sur les deux instances.
Vous devez ensuite utiliser un fichier XML, qui spécifie dans l’élément
le passer en paramètre en ligne de commande, à dta.exe. L’outil graphique ne supporte pas le travail avec un serveur de test.
Ensuite, DTA importe dans une base de données de travail, sur le serveur de test,
les métadonnées de la base de production : tables vides, index et objets de code, statistiques de distribution, informations du matériel de production (nombre de processeurs, quantité de mémoire).
6.5 Database Engine Tuning Advisor
Utilisation en ligne de commande
L’exécutable dta.exe vous permet d’exécuter une session d’analyse en mode ligne de
commande. Cela rend le DTA programmable et planifiable. Toutes les options sont
exprimables par des paramètres passés à l’exécutable, ou dans un fichier XML
d’entrée. Voici un exemple d’appel en ligne de commande :
dta.exe -S BABALUGA-XPS\SQL2005 -E –D AdventureWorks,AdventureWorksDW -d
AdventureWorks -s MaSession –if workload.sql –of rec.sql -fa IDX -A 0 -n 10000
qui signifie : connecte-toi au serveur BABALUGA-XPS\SQL2005 en sécurité
intégrée, dans le contexte de AdventureWorks ; crée la session nommée MaSession
pour analyser les bases AdventureWorks et AdventureWorksDW avec le fichier de requêtes workload.sql. Écris le script de génération des recommandations dans le fichier
rec.sql. N’ajoute que des index, fais une analyse sans durée limite, mais en ne prenant que les 10 000 premières instructions du workload d’entrée. Pour interrompre
dta.exe avant la fin du travail, utilisez la combinaison de touches CTRL+C.
Le DTA peut recevoir ses paramètres dans un fichier XML, mais aussi produire
ses recommandations dans un output en format XML (avec le paramètre -ox), pour
être par exemple utilisé comme outil d’optimisation intégré dans un outil tiers.
Vous trouverez la syntaxe d’appel complète dans les BOL, ou avec un
dta.exe -?
Analyse sur un serveur de test
Pour réaliser une bonne analyse, sans conséquence sur le serveur de production,
DTA permet de déplacer la charge de l’analyse sur un serveur de test. Il utilise pour
ce faire une méthodologie intelligente : une copie automatique de la base est effectuée sur le serveur de test, mais uniquement des métadonnées (structures d’objets) et
des statistiques de distribution des colonnes. Les données elles-mêmes sont inutiles
pour le processus d’optimisation, et il serait coûteux de les répliquer sur la machine
de test. DTA s’en passe donc. De plus, pour coller au plus près de la configuration du
serveur de production, il utilise les informations matérielles qu’il a glanées sur celuici (à l’aide de la procédure stockée étendue xp_msver) pour fonder son optimisation
sur le serveur de test. On profite donc d’une analyse au plus près de la réalité, sans les
inconvénients.
Pour ce faire, vous devez être sysadmin sur les deux serveurs, ou exécuter l’analyse
sous un login présent sur les deux instances.
Vous devez ensuite utiliser un fichier XML, qui spécifie dans l’élément
le passer en paramètre en ligne de commande, à dta.exe. L’outil graphique ne supporte pas le travail avec un serveur de test.
Ensuite, DTA importe dans une base de données de travail, sur le serveur de test,
les métadonnées de la base de production : tables vides, index et objets de code, statistiques de distribution, informations du matériel de production (nombre de processeurs, quantité de mémoire).