Discussion :

[dehorter olivier]

Bonjour à tous

Depuis quelques temps une de mes requête est plus longue que d'habitude. Donc j'ai voulu m'atteler au problème.

Pour ce cas, j'ai recopié la même version de ma base sur 2 répertoires différents. Le plan d'exécution est totalement différents entre les 2 (c'est évidemment la même requête ).
Dans un cas, le temps d'exécution est de quelques milisecondes, et pour l'autre il est de 40 secondes....

Cela est-il déjà arrivé à l'un d'entre-vous ?



Pour les 2 bases, j'ai recalculé tous les index.
Je suis sous Firebird 3.0.10
Je suis partie d'une base restaurée avant d'en copier une sous un autre répertoire
J'utilise IbExpert.

A+
olivier

NB : Evidemment en production, je fais appliquer le plan d'exécution le plus rapide pour ne plus avoir de problème

[SergioMaster]

Bonjour,

par recopié, s'agit-il de bases restaurées après backup ou une simple copie de fichier ?
Il pourrait s'agir d'un simple problème de transactions mal fermées pour l'une d'entre elle, difficile de se faire une idée

[dehorter olivier]

Bonjour et merci pour la réponse

La base source a été restaurée, et la base "supplémentaire" est une recopie du fichier de cette base restaurée (sans qu'aucune opération n'est été effectuée avant sur la base restaurée).

Comme info supplémentaire, le mauvais plan se produit sur la base "source" restaurée et non sur la base supplémentaire recopiée...

a+
olivier

[escartefigue]

Bonjour,

Le choix des chemins d'accès se base beaucoup sur les statistiques, peut-être ne sont elles pas à jour sur la base où les perfs sont mauvaises.

[dehorter olivier]

Bonjour, et merci

Ils n'auraient pas "mis à blanc" avec la restauration ?
Et sur la base recopiée de cette base restaurée, la requête donne un "bon" plan, alors qu'elle devrait avoir les mêmes chemins, non ?

En tout état de cause, ce n'est pas de toute évidence, quelque chose qui se passe couramment

[SergioMaster]

Il serait intéressant de faire le même test avec Flamerobin pour écarter un problème de GUI

[SQLpro]

Si ma mémoire est bonne, la sauvegarde dans Firebird n'est pas une sauvegarde binaire, mais une sauvegarde logique à base de CREATE / INSERT.
Donc, lorsque vous restaurez vous avez une base de données nettoyées de toutes scories et compactée au possible avec des statistiques "up to date".
Même si le contenu est identique du point de vue sémantique, ce n'est pas physiquement le même stockage ni les mêmes statistiques... Donc, pas les mêmes plans de requêtes et c'est logique !!!

par analogie...

Vous voulez vous rendre de paris à Versailles et il y a de nombreux chantiers sur la route... En temps normal sans ces chantiers vous mettez trois fois moins de temps. Pourtant vous faites toujours le même nombre de kilomètre et passez par les mêmes chemins....

A +

[dehorter olivier]

Bonjour à tous et merci encore

J'adore les analogies et les pratique beaucoup, surtout en stat...

J'ai quelques nouvelles. Tout d'abord de nouvelles requêtes ont été touchées par de forts ralentissements (il concentre les travaux pendant l'été, )


J'avais installé sur ma nouvelle machine (çà je ne crois pas l'avoir dit), les dernières versions de Firebird; la 32bits pour travailler sous IbExpert et la 64bits pour mon application.
Or, sur mon ancienne, tout fonctionnait parfaitement.

J'ai ainsi copié les 2 dll (fbclient) 32 et 64 de l'ancienne machine (version 3.0.6 ) vers la nouvelle. Et maintenant toutes les requêtes semblent tourner rapidement, comme avant.

Ce serait un bug dans la dernière version de Firebird ? Si oui, je ne sais même pas comment l'expliquer et quoi fournir pour que la correction puisse être effectuée ?

A+
olivier

[SergioMaster]

la 32bits pour travailler sous IbExpert

Ah, IBexpert est 32 bits !?

Ce serait un bug dans la dernière version de Firebird ?

Ou d'IBexpert, c'est pour cela que je suggérais un test avec FlameRobin (léger et facile à installer/désinstaller)

[dehorter olivier]

Ah, IBexpert est 32 bits !?

et oui

Ou d'IBexpert, c'est pour cela que je suggérais un test avec FlameRobin (léger et facile à installer/désinstaller)

non parce que le problème survient avec l'appli (en 64bits); c'est même "grâce à elle que le problème à été détecté.

A+

[SergioMaster]

J'ai ainsi copié les 2 dll (fbclient) 32 et 64 de l'ancienne machine (version 3.0.6 ) vers la nouvelle.

Donc, une différence entre version, étrange, elles ont été copiées ou ces dlls ? Il faudrait peut-être remonter l'information https://firebirdsql.org/file/documen...eral-bugreport
Je croyais, qu'à l'instar de Flamerobin (une nouvelle version, disponible depuis peu, permet de changer la dll cliente), une version des dlls était copiée dans le répertoire du GUI.

[alanglet]

Bonjour,

Ça me rappelle le problème des index inactifs lors de leur création signalé ici. RDB$INDEX_INACTIVE était nul au lieu de 0 et RDB$STATISTICS était à 0, ce qui peut être à l'origine d'un plan erroné.
Effectuez la requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
select RDB$INDEX_NAME
,RDB$RELATION_NAME
,RDB$INDEX_INACTIVE
,RDB$STATISTICS
from RDB$INDICES
where RDB$SYSTEM_FLAG=0
and RDB$STATISTICS=0

pour voir si ce n'est pas le cas.

André

[dehorter olivier]

Bonjour à tous,

et désolé pour le retard, j'étais sur un autre projet.

alanglet, j'ai testé ta requête et effectivement j'ai effectivement des "RDB$INDEX_INACTIVE à [NULL] ". Aussi j'ai recalculé les index et plus de NULL.

Ensuite, j'ai remplacé la dll (fbclient.dll) de la version 3.0.6 par la 3.0.10, et cela fonctionne.

J'aurais du le faire AVANT de recalculer les index afin de conserver des NULL pour tester le plan avec cette v10, dommage. Mais je garde la requête d'alanglet, histoire de tester de temps en temps la présence de NULL (on ne sait jamais).

Je vais noter la discussion "résolue", même si rien n'est sûr.

Encore merci à TOUS

[alanglet]

Bonjour,

alanglet, j'ai testé ta requête et effectivement j'ai effectivement des "RDB$INDEX_INACTIVE à [NULL] ". Aussi j'ai recalculé les index et plus de NULL.

Çà démontre qu'il y a bien une corrélation entre RDB$INDEX_INACTIVE null au lieu de 0 et des statistiques non calculées. Un backup/restore remet aussi tout en place.
Ce sont les statistiques qui permettent de déterminer le plan le plus efficace, alors sans elles...
Mais celà ne dit pas quelle opération a provoqué cette anomalie chez vous.

André

[dehorter olivier]

Re

Oui, et d'autant plus que j'avais réalisé ce backup/restaure avant ???

Merci encore