Blog SQL d'un développeur Microsoft. » tuning

[SGBD] [Optimisation] Pourquoi l’écriture de fonctions encapsulées est à bannir en SQL ?

ylarvor — Thu, 27 Mar 2008 20:00:00 +0000

Je voudrais revenir sur un article de Rudi éclairant pour moi :

http://rudi.developpez.com/sqlserver/tutoriel/optimisation/

Dans cet article, il écrit « Une erreur commune, qui peut affecter fortement les performances, est d’écrire du code SQL avec la même approche intellectuelle que pour l’écriture de code procédural. »

Dans mon entreprise, nous avons une base qui a été conçu sur ce principe de l’encapsulation. Les requêtes de cette base, assez complexes, ont été rendu lisibles par l’application des principes du développement procédurale : « découpe et place dans des blocs plus petits ».

Cette base utilise donc de nombreuses fonctions tables. des fonctions. des fonctions à l’intérieur de fonctions tables. des fonctions tables à l’intérieur de fonctions tables…

Le résultat est lisible mais contre-performant comme l’explique rudi dans la partie II-D-1.

Par conséquent, si vous avez en charge le développement de requêtes, de procédures stockées : Oubliez ce que vous avez appris comme bon développeur, ne réutilisez pas, n’encapsulez pas, soyez économe avec les fonctions T-SQL.

Pour obtenir une requête rapide, vous devez écrire une requête littérale! d’un bloc! Pour rendre lisible, indentez! Organisez les jointures mais n’encapsulez pas! Ne factorisez pas en SQL !

Bon coding!

[SGBD] Pourquoi utiliser les Compteur … Reads plutôt que la durée de la requête ?

ylarvor — Fri, 21 Mar 2008 16:45:57 +0000

Apprenti DBA, je viens d’apprendre pourquoi les DBA Production utilisent les compteurs « logical reads,physical reads… » plutôt que la durée de la requête. Ecoutez donc…

En bon développeur, je me disais que la trace DURATION du profiler fournissait toute l’information nécessaire, une requête de plus de 10 secondes, était une requête à corriger!
En effet, cela se vérifie sur un serveur faiblement sollicité mais dans des configurations fortement sollicitées comme celles que rencontrent les DBA Production, la durée ne veut plus rien dire suivant l’heure de la journée.En effet, dans ces configurations, la durée de la requête devient variable en fonction de la charge du serveur.

Pour trouver des repères pour l’optimisation de la requête, on doit alors prendre des données fixes comme le nombres d’accès en lecture physique, logique…

Je vous rappelle que ce qui est le plus consommateur en temps dans une requête, ce sont les accès physiques au disque.

Si on réduit le nombre d’accès, on réduit proportionnellement la durée de la requête quelque soit la charge du serveur.

A quel moment doit avoir lieu l’optimisation d’une base ?

ylarvor — Wed, 16 Jan 2008 16:06:35 +0000

L’ importance de la normalisation de la base est essentiel. Le modèle relationnelle a fait passer le gros du travail de la partie développement à la partie conception.
L’ Architecte de la base, premier intervenant du projet, qui utilise POWER AMC ou Toad Data Modeler doit respecter absolument la 3 ème forme normale dans la définition de son modèle. On ne peut pas faire l’ économie d’un modéle relationnel dans la conception d’ une application.

Le deuxième pôle de l’ optimisation est le soin apporté à l’ écriture du SQL. Privilégié le plus possible l’ écriture de SQL à l’ écriture de Transact SQL. L’ utilisation de SQL permet l’ indexation et des performances supérieurs. Par exemple, la semaine dernière, mon patron me signale une application dont les temps de réponses dépassés 30 secondes. Fier de mes connaissances, je propose d’ optimiser la requête par une indexation adéquate. Je passe 3H00 sur la requête pour finalement découvrir que les 30 secondes sont perdus par l’ utilisation en cascade de fonctions. Évidemment, en tant que développeur, on doit répondre à des besoins fonctionnelles et l’encapsulation en fonction répond bien à nos besoins mais en production, avec 100000 lignes dans une table, on perd un temps précieux à l’ exécution.

Le troisième pôle de l’ optimisation est l’ indexation. Sur des tables de plus de 1000 lignes, il devient important d’ indexer. Un produit comme POWER AMC vous facilite le travail puisqu’ il génére la majorité des index à la conception pour des tables bien normalisé.

On découvre donc bien que l’ essentiel de l’ optimisation d’ une base de données ne se passe pas donc pas en production, par le DBA, mais lors de la fabrication, par le développeur et l’architecte de la base.

Ne simplifions pas trop, les développeurs règlent généralement très bien les problèmes apparents et les problèmes de performances apparaissent souvent très tard dans le cycle de vie et entraîne des interventions des DBA. Néanmoins, la montée en charge future d’ une application peut être prévu très tôt par le respect de normes.

Dénormaliser une base de données.

ylarvor — Thu, 06 Dec 2007 11:00:00 +0000

Pour optimiser une requete, la premiere des choses à faire, si la ou les tables comptent plusieurs miliers d’enregistrement avec des valeurs trés différentes, est de placer des index, de faire tourner et de supprimer les index non utilisés. Si vous avez exploré toute les possibilités des index, et que votre requete est toujours trop lente, la solution est la denormalisation. La dénormalisation doit être utilisée sans complexe dans les bases en lecture seule, sans mise à jour. Dans les bases transactionnelles, il est nécessaire de mettre en place des triggers pour assurer la cohérence de la base.

Imaginez deux tables en 3 eme forme normale.
element(idelement,nomelement)
structure(id, nom, idelement )
la dénormalisation consiste à garder element à l’identique et modifier structure de la façon suivante (2 eme forme normale):
structure(id,nom,idelement,nomelement)
ainsi la requete associant element et structure est instantannée…
SELECT id,nom,nomelement from structure.

bon developpement

pour aller plus loin, un debat : http://www.developpez.net/forums/showthread.php?t=6231