Mettre en place le Database Hammer (2)

hors processus et il est donc subordonné
au démarrage préalable
de LoadSlave.exe. Avant de
continuer, soyez bien conscient
qu’en cliquant sur Start, vous
commencez à  insérer 10 millions
de lignes de données de test
dans la table TestTransaction.
Cette opération dure un certain
temps (presque 3 heures dans
mon test) et produit près de
400 Mo de données. Par
conséquent, veillez à  avoir suffisamment
d’espace disque et
d’espace base de données alloué
ou d’autocroissance définie, afin
que le chargement des données
ne soit pas stoppé prématurément.
(Vous pouvez définir l’autocroissance dans la boîte de dialogue
Database Properties par l’intermédiaire
d’Enterprise Manager ou en
utilisant la commande ALTER DATABASE.)

Attention au piège suivant : quand
LoadMaster.exe a fini de charger les
10 millions de lignes, il ne se ferme pas
et il ne vous signale rien. L’application
s’arrête quand elle atteint 10 millions
de lignes mais vous n’aurez aucune notification
visuelle du moment où il faut
fermer l’UI. Pour pallier cette lacune,
exécutez périodiquement

SELECT COUNT(*) FROM
dbo.TestTransaction
WITH (NOLOCK)

dans Query Analyzer pour voir s’il est
temps de terminer l’application. Un
autre moyen de vérification rapide
consiste à  consulter la table sysindexes
pour connaître le nombre de lignes
dans la table TestTransaction.

Le fait que mon journal de comptage
de performances fonctionne pendant
le chargement des données m’a
beaucoup appris. J’étais curieux de
voir quelle base de données se chargerait le plus rapidement. On analysant les résultats du chargement
d’enregistrements dans les deux scénarios
de test (données et log sur des
partitions séparées par rapport à  données
et log sur la même partition), on
voit que le chargement des données a
été plus rapide de 28 minutes quand
les fichiers log et de données étaient
sur la même partition. La seule autre
différence notable a été le temps SQL
Server Average Latch Wait plus élevé
(975,657 ms sur la base de données
avec les données et log sur des partitions
séparées, contre 461,306 ms sur
la base de données avec données et log
sur la même partition).