Votre modèle des données est parfait : justement normalisé et très légèrement dénormalisé par des techniques fiables et pour des données dont il est prouvé que cela apporte un gain significatif. Vos requêtes sont optimisées et les serveurs, tant logiques que physiques, comme leurs environnements sont taillés, dimensionnés, mesurés, configurés pour le volume de données et de transactions à subir. Enfin, vous avez pensé au découpage de vos espaces de stockage, choisi vos disques et constitué vos agrégats en conséquence… Pourtant il vous manque une brique pour parfaire votre oeuvre : penser l'exploitation de vos données au quotidien, c'est là SQL Server sur le site communautaire de developpez.com, un internaute postait un remarquable message. Il avait une procédure complexe longue et coûteuse en traitement qui importait des données dans une base, avec une planification quotidienne de nuit. Un matin quelle ne fût pas sa stupeur de constater que cette procédure qui durait habituellement un peu plus d'une heure, n'était pas encore terminée. Il attendit donc la fin du traitement et constata que ce dernier avait mis près de 10 heures, soit 8 fois plus qu'ordinairement. Que s'était-il passé ?
Contenu complémentaire
Numéro hors série : Gestion et optimisation des environnements multi bases de données
Le site du groupe utilisateurs de SQL Server : le GusS |
Nous avons déjà dit que les index sont une aide formidable pour optimiser les requêtes. La pose d’index entraîne la mise en place de statistiques sur les données de l’index, statistiques qui sont calculées à la création de l’index et recalculées lors de manoeuvres de remaniement d’index ou encore de manière automatique si cette option est activée. Si les index n’ont pas été recalculés depuis longtemps, alors le moteur SQL constate qu’un décalage existe entre l’échantillon sur lequel le calcul des statistiques a été fait et la réalité des données de la table.
Dès lors, le moteur SQL est en droit de considérer que ces statistiques n’ont plus d’intérêt car elles ne reflètent plus la réalité. Dans ce cas, le plan de requête est recalculé sans tenir compte des index suspects afin d’éviter d’utiliser lesdits index jugés obsolètes ! Voilà donc un premier point à surveiller : la mise à jour régulière des statistiques. Dans une base de moyenne importance, l’option automatique de mise à jour des statistiques peut s’avérer efficace, d’autant que la version 2005 de SQL Server permet de le faire de manière asynchrone. Dans de très grandes bases (VLDB) il vaut mieux planifier cela aux heures creuses.
Cependant, la seule mise à jour des statistiques n’est pas suffisante. Un index dont les données sont fortement impactées par des mises à jour (INSERT, UPDATE DELETE) peut s’avérer peu efficace en recherche. En effet, au fur et à mesure que les données évoluent, la structure de données qui stocke les index – en fait un arbre équilibré – peut se trouver en défaut : des pages peu pleines, des lignes déplacées, des lectures en zigzag… Comment cela est-il possible et comment y remédier ? Pour le remède, la chose est simple, il faut défragmenter l’index ou le reconstruire.
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
