Discussion :

[mioux]

Bonjour

J'ai 2 bases de données dont la structure de donnée est la même (mêmes tables, mêmes procédures, bref, si on les regarde de loin ce sont les même). Il y a 2 bases, car chacune contient une liste de sites pour un pays donné, et que c'était beaucoup plus simple de faire une base de données par pays qu'une base générale avec tout les sites, enfin bref, là n'est pas la question.

Je lance la même requête sur les 2 bases afin de filtrer une partie des sites, et elle met beaucoup plus de temps sur la base Espagnole que sur la base Allemande (qui est la plus grosse au niveau du volume de sites présents). C'est pas comme si c'était le double (ce qui serait déjà gênant) mais elle met plus de 11x plus de temps à s'exécuter (moins d'une seconde pour la base allemande, environ 11s pour la base Espagnole)

Du coup, je cherche un moyen de comparer la structure "non visible" de la base de données (c'est à dire comparer les clefs primaires, les index et autres (de tête je ne voit que ca qui pourrait affecter les performances))

Pour info, les 2 bases de données sont sur le même serveur et sont rarement mises à jour (1x par mois) et ca c'est mis à ralentir en plein milieu du mois (je sais pas si ca peut aider mais je précise)

PS : Les shémas d'exécution des requêtes

Allemagne :


Espagne :


EDIT : J'allais oublier... Merci d'avance

[SQLpro]

vos images sont illisibles.

[mioux]

J'ai pas de problème pour les lire... Il suffit de cliquer dessus pour les visualiser (et de recliquer dessus pour les afficher en plein écran)

Enfin je pense rien vous apprendre

[rudib]

Bonjour,

Les outils pour comparer les structures :

RedGate SQL Compare
SQLDiff
SQL Delta
SQL Examiner

Ils ont des versions d'essai limitées dans le temps.

Ou en bricolant avec mon script d'export de structure :
http://www.babaluga.com/doku.php/sql...ort_de_scripts
et un outil de diff, comme winmerge.

[mioux]

J'ai testé SQL Compare (de Red-Gate) comme indiqué, j'ai regardé les différences, les seule qu'il y avait étaient une clef étrangère (que j'ai reporté de la base allemande sur la base espagnole) ainsi que 2 vues et 1 procédure stockée, mais pour ces 3 trucs, les différences sont dans un paramètre pays pour lire les données dans une autre base de données, donc c'est normal.

Du coup, je sais pas où chercher pour savoir d'où peut venir mon problème...

Vous n'auriez pas une idée par hasard ?

[ylarvor]

ce qui me vient à l'idée... c'est qu'une réindexation à eu lieu sur une base et pas sur l'autre ce qui explique la différence de performance.
est ce que tes index sont à jours ?

[mioux]

C'est une bonne question

Comment on vérifie ? Parce qu'en fait je fais le boulot du DBA (si on peut l'appeler comme ca, il s'occupe des bases mais il n'est pas DBA, il fait du développement en temps normal) qui est en vacances

Sinon voici les nouvelles du front... J'ai utilisé les outils mis à disposition par Red-Gate pour faire des tests (soit dit en passant, cette suite logicielle est bien pratique... mais un poil chère pour la petite entreprise dans laquelle je travaille, heureusement qu'il y a les versions de démonstration pour essayer tout ca )

J'ai comparé les structures des bases et synchronisées celles ci (comme dit dans le message prédcédent) et je n'ai pas d'amélioration... On s'est alors dit que ca pouvait provenir des données...

J'ai donc créé une nouvelle base de données, dans laquelle j'ai copié la structure de base depuis la base Allemande (table, clefs, index, etc...) mais sans copier les données (merci Red-Gate )

J'ai copié les données Espagnoles dans la nouvelle base de données et là ca fonctionne à vitesse normale dans la nouvelle base.

J'avais donc renommé les bases de données pour que la base fraichement créée remplace l'ancienne base lente

Manque de bol (je viens d'avoir le client au téléphone pendant que je tapais le message ) les données n'ont pas été copiées 100% à l'identique par SQL Data Compare (même si 99% d'entre elles ont l'air bonnes) donc je ne peux pas continuer à utiliser cette base, mais au moins, je sais que ca ne vient pas des données

Sur ce, je retourne dans mes tests

[ylarvor]

tu peux essayer de creer un plan de maintenance pour ta base lente dans lequel tu demandes une reindexation de ta base. tu verras si les performances redeviennent bonnes...

Les index lorsqu'il subissent de nombreuses modifications dans le temps finissent par se fragmenter, un peu comme le disque dur qu'il est necessaire de defragmenter de temps à autre... une reindexation remet en ordre tes index et améliore les requetes...

[mioux]

Ne sachant pas comment on vérifie les indexes des tables, j'ai reconstruit tous les indexes de toutes les tables de ma base de données Espagne, et ca y est ca fonctionne

Merci de tes conseils ylarvor

En plus j'allais justement poser la question savoir s'il était possible de reconstruire tous les indexes en 1x (parce que je viens de me taper toutes les tables une par une, aller dans "index" cliquer sur "tout reconstruire" et y a une 30aine de tables... Je sais ca pourait être pire, mais c'est déjà assez long comme ca ), et tu as répondu pendant que j'écrivais mon message

EDIT : C'est pratique GTalk quand même... J'ai vu "une réponse a été postée" juste avant que moi même je clique sur "Enregistrer les changements" (j'éditais mon précédent message)

[rudib]

Bonjour,

Tu peux te référer à mon article pour une initiation aux outils qui te permettent de tracer le comportement de SQL Server : http://rudi.developpez.com/sqlserver.../optimisation/