SQL Server 2016 : Maintenance des progiciels tiers

Améliorer les performances avec la compression

Testez gratuitement nos 1271 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
La compression que vous pouvez activer sur des tables et des index peut vous aider à améliorer les performances.
06:12

Transcription

Dans ce chapitre, je vais vous parler de deux ou trois choses que vous pouvez faire sur la base de données pour améliorer un peu les performances. Et je vais bâtir dans ces premières vidéos, sur ce qu'on a vu dans le chapitre précédent. C'est-à-dire on a utilisé le « profiler », on a regardé des « reads » notamment et puis on a essayé d'optimiser une requête en créant un indexe. Ce que j'ai fait pour ma démonstration, c'est que j'ai créé une deuxième table que j'ai appelée « ContactN ». Pourquoi « N »? Parce que « N » veut dire ici dans « nvarchar » par exemple, Unicode. Alors, qu'est-ce que j'ai fait? Dans ma première table « contact », le choix des types de données étaient assez correct, j'ai fait des « varchar » un peu partout et puis ici, le choix des types de données est franchement mauvais, « nchar 50 » pour le nom « nchar 50 » pour le prénom. Alors, qu'est-ce que ça veut dire juste en un mot? Le prénom va être stocké sur 50 caractères, comme je n’ai pas mis de varchar, si le prénom fait moins de 50 caractères, eh bien on va remplir ensuite avec des espaces pour toujours faire 50 caractères. Et comme j'ai rajouté le « N », eh bien j'ai un type de données Unicode et l'Unicode est destiné à stocker des caractères étendues, comme par exemple le chinois qui ne se représente pas dans les 256 possibilités du codage ANSI. Donc ce que je fais, c'est que pour chaque prénom je vais stocker 100 octets. Je vais donc augmenter un peu la taille de ma table. J'ai créé la table, j'ai fais une insertion dans la table. Maintenant j'ai autant de lignes dans « contact.contact », que dans « Contact.ContactN », mais la taille des données ne sera pas la même. Je vais le vérifier en faisant un clic-droit sur la base de données, en appelant dans les « rapports » et dans les « rapports standards », « l'utilisation du disque par table ». C'est un rapport qui va me montrer la taille du stockage de chaque table évidemment. J'ai donc « Contact » : 320000 lignes, « contactN » : 320000 lignes. Mais dans le premier cas, « Contact » coûte 45 mégas et dans le deuxième cas il coûte 200 mégaoctets. Et en fait, il faut regarder plutôt les données parce que la c'est réservé. Vous voyez qu'il y a des index que j'ai n'est pas ici dans « Contact ». Donc c'est plutôt ça en fait. Ici, 22 méga et ici, pratiquement 200 méga. Vous allez me dire : « ce n’est pas grave, on a beaucoup d'espace disque, et donc on ne va pas s'inquiéter d’un stockage particulier. On a assez d'espaces disque pour stocker tout ça. » Mais ce n'est pas une question d'espace disque, c'est une question des parcours des données. Même si par exemple vous avez assez d'argent pour vous acheter un très très grand jardin, une villa avec deux hectares de terrains. Eh bien quand vous passerez votre tondeuse il faut deux jours pour passer la tondeuse sur deux hectares de terrains. Par contre, si vous achetez une villa avec, on va dire 2000 de terrain, eh bien vous passez la tondeuse en une heure, un peu moins. Ce que je veux dire par là c'est que SQL Server fonctionne de la même façon, il fait qu'il parcourt les données pour aller chercher ce que les requêtes lui demandent. Et donc, plus on diminue la surface des données, meilleures sont les performances. Deuxième remarque, tout ce volume de données va être monté dans la mémoire vive, par SQL server dans un cache, qu'on appelle « le buffer », entre parenthèses. C'est un cache de données, et ça permet à SQL Server d'améliorer ses performances puisqu'il va parcourir ces données en RAM, qui est mille fois plus rapides que le disque. Si vous augmentez le volume des données, comme c'est le cas ici, eh bien vous aurez moins de possibilité de mettre toutes vos données dans votre « RAM » et vous travaillerez plus avec le disque et vous diminuerez les performances. Je pense vous avoir convaincu. Vous allez me dire : « bon bah voilà, on ne va pas changer les types de données des tables si on s'aperçoit qu'un éditeur a mal choisi son type de données pour certaines colonnes de table. Qu'est ce qu'on peut faire ? Eh bien, vous pouvez activer si vous êtes en édition entreprise, attention ça ne fonctionne qu'avec l'édition entreprise de SQL Server, vous pouvez activer de la compression. Je vais vous montrer. Je prends « ContactN », ma table mal structurée, je fais un clic-droit, je vais dans « Stockage », et puis je vais « Gérer la compression ». Et je vais avoir un assistant qui va me montrer. Je vais choisir en disant « Utiliser le même type de compression pour toutes les partitions ». La table n’est probablement pas partitionnée et donc on aura qu'une seule partition, et je vais chercher deux types de compression possibles. Je vais déjà regarder la compression de type « Row », et puis je vais calculer ici, voir quelle est l'estimation du gain. Voyez qu'on me dit que l'espace actuel est de 194 mégas et l'espace compressé va être de 18 mégas. Et c'est très intéressant parce que la table va être compressée sur le disque, mais aussi en mémoire. Ce qui va être monté en mémoire ce sont des pages qui sont elles aussi compressées et lorsque le moteur de stockage devra lire des données, il les décompressera toujours à la volée. Mais vous allez me dire : « ouais, d'accord mais la compression ça va coûter plus en temps de processeur, en CPU. » Certes un petit peu plus, mais c'est en général négligeable surtout sur ce type de compression, je vais vous en reparler, parce qu’une base de données travaille beaucoup plus à lire des données, donc à faire des entrées-sortie qu'à faire des calculs compliqués qui demandent des capacités de processeur importantes. Et si vous regardez l'activité de vos processeur sur vos serveurs de base de donnée, en général on est autour des 20, 30, 40%. Il reste du champ pour que le processeur travaille sur la compression, donc la procession base de données est pratiquement toujours bénéfique. Et ici, il faut absolument optimiser les « entrées-sorties », les I/O, c’est-à-dire le temps que le moteur SQL passe à parcourir toutes ces données.

SQL Server 2016 : Maintenance des progiciels tiers

Exploitez les fonctionnalités de SQL Server afin de diminuer les problèmes, et améliorer les performances des progiciels. Faites face à ce problème très souvent rencontré !

1h16 (15 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Spécial abonnés
Date de parution :4 août 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !