> Tech > Mettre en place le Database Hammer (2)

Mettre en place le Database Hammer (2)

Tech - Par iTPro - Publié le 24 juin 2010
email

Pour terminer le chargement, double-cliquez sur LoadMaster.exe dans le dossier DatabaseHammer. Dans cette boîte, entrez les noms du serveur et de la base de données que vous allez tester. Vous devez aussi entrer l'utilisateur de SQL Server que vous avez créé précédemment. LoadMaster.exe utilise Load- Slave.exe comme un objet COM

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

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par iTPro - Publié le 24 juin 2010