Discussion :

[gromijay]

Bonjour à tous,

Tout d'abord, je me présente en deux mots : je suis administrateur S&R et donc n'aurait aucunement la prétention de dire "être DBA !" (et je suis encore moins développeur).

J'ai une application métier au sein de mon entreprise avec des bases SQL qui tournent sous SQL Server 2005.

Suite à une récente montée de version de l'application, mes utilisateurs se sont plaint de lenteurs. La consommation CPU moyenne du serveur SQL avait pratiquement doublé par rapport à la précédente version. Selon l'éditeur, il n'y a aucune raison à cela : il s'agit d'une évolution de version mineure.

Après avoir enregistré une trace SQL de l'activité d'une après midi complète d'utilisation, j'ai appliqué les index proposés par le SQL Profiler. Les utilisateurs me disent dès le lendemain que les temps de réponse sont meilleurs et ma consommation CPU est effectivement plus faible.

Quelques jours après, des utilisateurs ont découvert que certaines fonctionnalités de l'application plantaient (un clique sur le bouton "propriété" d'une facture provoque tout simplement le crash de l'application !).

L'éditeur me dit que cela provient des index ajoutés par l'optimiseur de requête et qu'il faut les enlever (ce que je vais faire ce soir).

En quoi, la pose d'index supplémentaire peut-elle faire crasher l'application ? J'aimerais avoir votre avis et surtout l'explication si tel est le cas.

Je précise que la pose d'index a été faite avec les utilisateurs offline !

Merci d'avance de m'éclairer à ce sujet.

[SQLpro]

La pose d'index n'a en principe aucune influence sur les applicatifs. Mieux, cela ne peut qu'améliorer globalement le services de données.
Cependant, il faudrait que votre éditeur respecte les règles de l'art en matière de développement d'application bases de données. C'est malheureusement rarement le cas, la plupart des éditeurs ayant de très faibles connaissances en matières de SGBDR !
La question à se poser est donc la suivante : En quoi l'applicatif pourrait être remise en cause de manière fonctionnelle en cas de pose des index ?
Sur le retrait, c'est possible, sur la pose, je ne voit pas la relation...

Cependant, penser que poser des index ajoute du volume à votre base. Si vos fichiers sont en auto croissance, il est possible que ces derniers ait crut de manière trop élevé par rapport à l'espace disque résiduel. D'autres phénomènes similaire plus rares peuvent aussi se produire....

En tout état de cause, il faut obtenir des informations sur les erreurs et notamment quels sont les message d'erreur ou les événements dans les journaux Windows du client et du serveur...

Je parlais des règles de l'art... J'ai vu un jour un développement particulièrement débile ou l'applicatif identifiait les tables dans la vues des objets de la base par un "motif" du nom de l'objet. En gros, tous les objets de type TABLE avaient un nom commençant par DBT_. En créant un index ayant le même préfixe, cela faisait planter l'application, à cause d'une requête générique demandant à faire un SELECT COUNT(*) sur tout ce que l'appli croyait être une table au démarrage de l'application !.... Le tout étant développé sous WinDaubv...

A +

[gromijay]

Si je comprend bien, le plantage de l'application dans certaine fonction signifie que des requêtes sont mal écrites ?
La requête remonterait des infos à l'appli venant d'objet autre qu'une table ?

Dites-moi si je me trompe, mais la pose d'index créé des nouvelles vues et des infos de celles-ci sont embarqués avec des select * ou select count (*) ?

(J'ai capturé les requêtes SQL au moment de l'appuie sur le fameux bouton qui me fait planter l'appli : j'ai bien des select * et select count (*) ...

Est-ce si simple que cela ?
Puis indiquer cela à l'éditeur ?

La pose d'index n'a en principe aucune influence sur les applicatifs. Mieux, cela ne peut qu'améliorer globalement le services de données.
Cependant, il faudrait que votre éditeur respecte les règles de l'art en matière de développement d'application bases de données. C'est malheureusement rarement le cas, la plupart des éditeurs ayant de très faibles connaissances en matières de SGBDR !
La question à se poser est donc la suivante : En quoi l'applicatif pourrait être remise en cause de manière fonctionnelle en cas de pose des index ?
Sur le retrait, c'est possible, sur la pose, je ne voit pas la relation...

Cependant, penser que poser des index ajoute du volume à votre base. Si vos fichiers sont en auto croissance, il est possible que ces derniers ait crut de manière trop élevé par rapport à l'espace disque résiduel. D'autres phénomènes similaire plus rares peuvent aussi se produire....

En tout état de cause, il faut obtenir des informations sur les erreurs et notamment quels sont les message d'erreur ou les événements dans les journaux Windows du client et du serveur...

Je parlais des règles de l'art... J'ai vu un jour un développement particulièrement débile ou l'applicatif identifiait les tables dans la vues des objets de la base par un "motif" du nom de l'objet. En gros, tous les objets de type TABLE avaient un nom commençant par DBT_. En créant un index ayant le même préfixe, cela faisait planter l'application, à cause d'une requête générique demandant à faire un SELECT COUNT(*) sur tout ce que l'appli croyait être une table au démarrage de l'application !.... Le tout étant développé sous WinDaubv...

A +