Dossier SQL Server : Dans le secret des performances de SQL Server (1/3)

Les administrateurs de base de données (DBA) apportent une réponse au problème au lieu de le prévenir. Par ailleurs, la visibilité se limite, pour une large part, à la surveillance du serveur de base de données, au lieu de chercher à comprendre comme SQL Server affecte directement les utilisateurs d’applications.

L’analyse des temps d’attente vient changer cet état de fait, en proposant une méthode pour améliorer le service et les performances des bases de données SQL Server. Au lieu de surveiller l’état du système, l’analyse des temps d’attente cible le délai pendant lequel l’application attend le traitement des requêtes par SQL Server. Le résultat est une technique d’analyse qui peut répondre aux questions clé suivantes : Pourquoi la base de données impose-t-elle des délais d’attente aux utilisateurs des applications et comment y remédier ?

L’approche de l’analyse des temps d’attente est désormais pratique en raison des techniques de surveillance allégées et des architectures sans agent. Elle tire parti des nouveaux outils dans SQL Server afin d’exposer les types d’attente, à savoir les étapes individuelles qui accroissent les délais à mesure que SQL Server traite les requêtes.

Pour la structure informatique, l’analyse des temps d’attente aboutit à une réduction des coûts de fonctionnement des bases de données et à un service informatique plus performant. Les DBA peuvent accomplir plus avec moins de serveurs. Les migrations de SQL Server 2000 vers la version 2005, puis vers la version 2008 s’en trouvent accélérées et les cycles de développement en sont raccourcis. Pour les départements informatiques chargés d’offrir un service amélioré avec moins de ressources, l’analyse des temps d’attente constitue une réponse efficace.

Les DBA occupent souvent une position difficile. Ils sont responsables des temps de réponse de la base de données vis-à-vis des utilisateurs d’applications, mais ils n’ont aucune visibilité sur les lenteurs de la base de données en question.

Bien souvent, le problème ne se situe d’ailleurs pas à ce niveau, mais est imputable au code de l’application, au réseau ou à l’architecture du système. Pour faire modifier le code applicatif, les DBA doivent apporter des preuves aux développeurs, lesquels sont à leur tour suspicieux car ils considèrent la base de données comme une boîte noire qu’ils comprennent mal. « Prenez un serveur plus rapide ! », disent-ils, mais cette affirmation est erronée.
Ces problèmes sont un symptôme de l’utilisation de techniques obsolètes de surveillance de l’état du serveur pour comprendre réellement ce qu’il se produit à l’intérieur de SQL Server.