Discussion :

[PierreY]

Je me suis fait grogner par les modos alors je fais un effort, attention !

Un espace disponible n'est pas forcément utilisé au prochain INSERT. De meme que la base ne se réduit JAMAIS apres avoir fait ne nombreux DELETES...

A l'usage on remarquera qu'une grosse base pleine de vide est plus performante qu'une base juste backup/restorée, l'espace disque est déjà alloué et c'est une opération très coûteuse. L'idéal serait de pouvoir préallouer l'espace nécessaire au fonctionnement de la base en production lors du restore. L'idée n'est pas de moi.

De traiter d'incompétant les membres du forum qui viennent ici pour apprendre et chercher des solutions, n'est pas tres sympatique...

Désolé les gars. C'est plus fort que moi. J'aimerais que tout le monde puisse utiliser Firebird aussi bien que je sais le faire (notez le "sais le faire").
N'empêche que cette phrase est sujette à interprêtation. Tout le monde n'est pas obligé de se sentir visé.

Il n'y a pas que les aspects techniques dans un projets. Et le saint graal des informaticiens de vouloir faire l'application sans bug et techniquement la meilleures, n'est jamais (et ne sera jamais) atteind...

Ce n'est pas une raison pour persister dans la médiocrité (je me risque à utiliser ce mot qui va choquer nos lecteurs, mais le lecteur est un être intelligent qui sait où sont ses points forts et ses faiblesses ), le propre du maître c'est d'arriver à ce que ses élèves le dépassent et ce n'est pas toujours facile. (qui a dit "bouh le prétentieux !" ?)

Alors de conseiller quelqu un de tout refaire en ayant un discourt plus que fataliste et alarmiste c'est facile mais pas très réaliste. Il ne faut pas s'étonner que de nombreux projets dérapent et mettent toujours beaucoup plus de temps à se terminer (voir ne se terminent jamais).

Maintenant à lui de juger, s'il a de l'argent et du temps pour tout refaire, qu'il le fasse.

Il a dit qu'il voulait tout refaire. L'application existe déjà, il peut ne s'agir que d'un simple toilettage et quelques heures de refactoring. Lorsque les applications sont bien conçues, changer les 30 lignes qui servent à l'interface vers la base de données n'est pas une gageure.

Mon point de vue c'est que les composants de Borland ne vous en déplaise permettent de faire des applications de gestion qui fonctionnent bien (de nombreuses applications sont là pour le prouver).

"Ne vous en déplaise" : c'est vrai que ca a plus de classe que "Que ça vous plaise ou pas"

Pour ma part pour mieux gérer les transactions j'utilise les composants FIBPlus. (Même si ce n'est pas encore parfait pour un puriste )

(Remplacer les IBX par les FIBPlus est certainement moins couteux que de devoir tout refaire.)

Exact. FIBPlus est une bonne solution, la base de code entre IBX et FIB+ est la même. Il n'empêche qu'un Dataset connecté directement à la base de données par une transaction requiert que la transaction reste ouverte, si cette transaction est ouverte pendant toute la durée d'exécution de l'application pour maintenir une table de référence active (le genre de table qui sert aux lookup, celles dans lesquelles ont range les types, les taux de tva, ...) alors 50 utilisateurs auront au moins une transaction active en permanence pendant toute la durée d'utilisation de la base. Autrement dit, si le premier des 50 utilisateurs ne reboot son PC que quand Windows plante ou installe des Updates, il peut des fois se passer plusieurs jours avant que ladite transaction ne soit fermée.

Ce n'est visiblement pas l'objectif de son application.

50 utilisateurs connectés en permanence, ca commence a être une grosse application.

Mais hélas lorsqu'un produit est mal concu dés le départ, de dire qu'il faut tout refaire est une chose, de pouvoir le faire en est une autre. Le plus souvant c'est la solution la moins couteuse qui sera retenu.

Entre avoir un logiciel qui fonctionne mais qui n'est pas optinal dans ses performances et ne rien avoir du tout (parcequ'il faut tout refaire), le choix sera vite fait il me semble...

Désir et réalité

C'est un peu du fatalisme aussi ça : c'est mal conçu tant pis, c'est notre croix, on se la traîne jusqu'au bout.

[makowski]

Il n'empêche qu'un Dataset connecté directement à la base de données par une transaction requiert que la transaction reste ouverte, si cette transaction est ouverte pendant toute la durée d'exécution de l'application pour maintenir une table de référence active (le genre de table qui sert aux lookup, celles dans lesquelles ont range les types, les taux de tva, ...) alors 50 utilisateurs auront au moins une transaction active en permanence pendant toute la durée d'utilisation de la base. Autrement dit, si le premier des 50 utilisateurs ne reboot son PC que quand Windows plante ou installe des Updates, il peut des fois se passer plusieurs jours avant que ladite transaction ne soit fermée.

c'est le point clé quand on utilise les datamodules par exemple
le grand classisque c'est de jeter un Tdatabase et un Ttransaction quelconque dans un datamodule et croire que l'on gère bien ainsi les transactions
alors que l'on va lier sans plus réfléchir toutes les tables lookup (voir quelque fois pire) au Tdatabase et c'est bien là le problème, car on ouvre sans vraiment la maitriser une transaction et donc on arrive à des très mauvais résultats comme le prouvaient les stats de cette base.
et il n'y a rien de pire ou presque pour faire de Firebird non plus un SGBD performant mais un mauvais Paradox avec des temps de réponses qui ne cessent de se détériorer.
Il ne faut pas oublier que tout est transaction, les transactions ne sont pas réservées aux Update, Insert, Delete, un Select aussi se passe dans le cadre d'une transaction.

[Barbibulle]

A l'usage on remarquera qu'une grosse base pleine de vide est plus performante qu'une base juste backup/restorée, l'espace disque est déjà alloué et c'est une opération très coûteuse. L'idéal serait de pouvoir préallouer l'espace nécessaire au fonctionnement de la base en production lors du restore. L'idée n'est pas de moi.

Oui mais c'etait pour expliquer que la taille d'une base peut grossir ennormément et suite à un backup/restore elle diminue.

L'idée de préallouer l espace lors d'un restore existe déjà dans d'autres gros SGBD. Et pour certain c'est meme la taille max de la base .
L'idéal, serait en effet de pouvoir donner un taux de remplissage autre que 80%.

Désolé les gars. C'est plus fort que moi. J'aimerais que tout le monde puisse utiliser Firebird aussi bien que je sais le faire (notez le "sais le faire").
N'empêche que cette phrase est sujette à interprêtation. Tout le monde n'est pas obligé de se sentir visé.

Ce genre de remarque n'apporte rien techniquement.
Les grandes difficultés des projets sont rarement technique mais humaines.

Ce n'est pas une raison pour persister dans la médiocrité (je me risque à utiliser ce mot qui va choquer nos lecteurs, mais le lecteur est un être intelligent qui sait où sont ses points forts et ses faiblesses ), le propre du maître c'est d'arriver à ce que ses élèves le dépassent et ce n'est pas toujours facile. (qui a dit "bouh le prétentieux !" ?)

Il faut savoir composer avec l'existant...
Et parfois il vaut mieux garder une chose qui n'est pas optimisée mais qui fonctionne que de tout casser.

Ceci dit, il n'est pas interdit de s'améliorer et de faire une V2 ou les projets suivant de mannière un peu plus optimale.
C'est l'expérience qui entre en jeux.

Il a dit qu'il voulait tout refaire. L'application existe déjà, il peut ne s'agir que d'un simple toilettage et quelques heures de refactoring. Lorsque les applications sont bien conçues, changer les 30 lignes qui servent à l'interface vers la base de données n'est pas une gageure.

Je lui ai donné une autre option (certe moins optimale) mais a lui de juger ce qu'il peut faire (en terme de temps, bubget etc...).

Ton discours est tres alarmiste et extremiste. Je mets juste un peu d'eau dans ton vin . Tout n'est pas noir ou blanc.

Exact. FIBPlus est une bonne solution, la base de code entre IBX et FIB+ est la même. Il n'empêche qu'un Dataset connecté directement à la base de données par une transaction requiert que la transaction reste ouverte, si cette transaction est ouverte pendant toute la durée d'exécution de l'application pour maintenir une table de référence active (le genre de table qui sert aux lookup, celles dans lesquelles ont range les types, les taux de tva, ...) alors 50 utilisateurs auront au moins une transaction active en permanence pendant toute la durée d'utilisation de la base. Autrement dit, si le premier des 50 utilisateurs ne reboot son PC que quand Windows plante ou installe des Updates, il peut des fois se passer plusieurs jours avant que ladite transaction ne soit fermée.

Tout à fait, dans ce cas il peut utiliser la propriété de transaction IdlTimer qui permet la fermeture automatique de la transaction au bout d'un certain temps d'innactivité.

C'est un peu du fatalisme aussi ça : c'est mal conçu tant pis, c'est notre croix, on se la traîne jusqu'au bout.

Non c'est l'expérience ^^. Etre fatalise c'est de dire qu'on va se trainer ca tout le temps. (Ce que je n'ai jamais dit)
Je te dirais que dans les fait il peut tres bien faire cette optimisation dans une V2, mais ca ne serait pas honette de ma part car une application qui fonctionne, n'est jamais modifiée juste pour le motif que l'informaticien veut redévelopper la meme chose de mannière plus académique ...


Donc pour revenir au sujet de la discution :

S'il à la possibilité de refaire son application (en terme de temps et budget) il peut suivre tes recommandations.
Mais il faudra qu'il commence par une bonne analyse préalable.

S'il n'a pas les moyens de le faire, il peut se contenter de corriger son application afin de toujours fermer ses transactions, ce qui n'a pas l'air d'être le cas actuellement. Si possible de mettre les mises à jours dans une transaction séparée la plus courte possible.

[PierreY]

L'idée de préallouer l espace lors d'un restore existe déjà dans d'autres gros SGBD. Et pour certain c'est meme la taille max de la base .
L'idéal, serait en effet de pouvoir donner un taux de remplissage autre que 80%.

Sauf que ca n'a d'intérêt que pour les quelques tables qui grossissent, les dizaines de tables qui ne grossissent pas ou très peu devraient être remplies à 100%, donc il faudrait pouvoir affiner tous les règlages de la création de la base et ce ne serait plus "Firebird, le SGBD qui n'a pas besoin de paramétrage, de maintenance ni de DBA".
En poussant un peu plus loin, les tables qui grossissent vite et beaucoup ne seraient pas vraiment avantagées par un taux de remplissage plus faible puisqu'il faudrait de toute manière allouer de nouvelles pages, beaucoup, et toujours aussi souvent.

[makowski]

on peut faire un restore en remplissant les pages à 100 %
mais ça n'est utile que pour un gain de performance possible sur une base en lecture seule

[Barbibulle]

Sauf que ca n'a d'intérêt que pour les quelques tables qui grossissent, les dizaines de tables qui ne grossissent pas ou très peu devraient être remplies à 100%, donc il faudrait pouvoir affiner tous les règlages de la création de la base et ce ne serait plus "Firebird, le SGBD qui n'a pas besoin de paramétrage, de maintenance ni de DBA".
En poussant un peu plus loin, les tables qui grossissent vite et beaucoup ne seraient pas vraiment avantagées par un taux de remplissage plus faible puisqu'il faudrait de toute manière allouer de nouvelles pages, beaucoup, et toujours aussi souvent.

Bonne analyse

[maamar1979]

Salam;

quand vous parlez du mode deconnecté, faut il en plus de fermer toutes les transaction (par commit ou rollback), fermer aussi la connexion vers la BD (c'est-à-dire mettre la proprièté Connected de IBDatabase à faulse)??

[PierreY]

quand vous parlez du mode deconnecté, faut il en plus de fermer toutes les transaction (par commit ou rollback), fermer aussi la connexion vers la BD (c'est-à-dire mettre la proprièté Connected de IBDatabase à faulse)??

C'est possible mais ce n'est pas nécessaire. Le mode totalement déconnecté s'utilise dans les applications multi-tiers lorsque ce sont des "serveurs d'application" qui fournissent les données à l'application.

Dans une application coonnectée, on peut conserver la connexion ouverte, ce qu'il faut impérativement fermer ce sont les transactions.

[Guigui_]

Je vais profiter de ce sujet pour voir si je gère à peu près correctement mes traitements de base de données (vu que je me suis jamais trop posé la question). Par contre, toutes les manipulations se faisaient en Python

Bon, j'ai une base qui fait avant un backup/restore 27 Mo, elle passe à 23 Mo après

Info avant le backup/restore:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              14524
        Page size               4096
        ODS version             10.1
        Oldest transaction      24
        Oldest active           14511
        Oldest snapshot         14511
        Next transaction        14523
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      0
        Implementation ID       16
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Jan 28, 2006 19:04:46
        Attributes              force write
 
    Variable header data:
        *END*

Info après le Backup/Restore:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              19
        Page size               4096
        ODS version             11.0
        Oldest transaction      1
        Oldest active           2
        Oldest snapshot         2
        Next transaction        13
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      0
        Implementation ID       16
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Nov 6, 2006 10:00:10
        Attributes              force write
 
    Variable header data:
        Sweep interval:         20000
        *END*

Est-ce que ces stats vous paraissent correctes ? Normale qu'il me change m'ont ODS Version ?

[PierreY]

Info avant le backup/restore:

Code :

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

1
2
3
4
5
 
        Oldest transaction      24
        Oldest active           14511
        Oldest snapshot         14511
        Next transaction        14523

Est-ce que ces stats vous paraissent correctes ?

Non, la différence entre la dernière transaction digne d'intérêt (OID : Oldest Interresting Transaction) et la prochaine (NT : Next Transaction) est trop importante. Quel connecteur Python utilises-tu ?

[Guigui_]

j'utilise kinterbasdb
- Je n'ouvre jamais de transaction explicitement. Il me semble qu'une transaction s'ouvre automatiquement si nécessaire
Ainsi, je peux avoir ce genre de code

Code PYTHON :

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

1
2
3
4
5
6
7
8
9
 
con = kinterbasdb.connect(... )
cur = con.cursor()
 
def fonction1():
    cur.execute("INSERT ...")
    cur.execute("INSERT ...")
    cur.execute("INSERT ...")
    con.Commit()

Et quand je sais que ca peut planter, je fais comme ceci:

Code PYTHON :

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

1
2
3
4
try: cur.execute("UPDATE ...")
except: pass
...  ## Autres traitement sur la base
con.Commit()

Au final, je n'ai aucun rollback dans mon appli. En revanche, toute fonction qui modifie la base se termine pas un Commit. Par contre, mes requêtes avec des Select n'ont pas de Commit.

[PierreY]

Par contre, mes requêtes avec des Select n'ont pas de Commit.

Le problème doit venir de là. Les problèmes de performance avec Firebird viennent essentiellement des requêtes SELECT qui restent ouvertes. Si c'est possible, essaye de les COMMITER systématiquement.

Il faut savoir qu'une requête SELECT, du point de vue du serveur doivent être répétables : si, dans le contexte de la MEME transaction, tu relances la même requête SELECT, le serveur mettra un point d'honneur à te renvoyer les mêmes données, quoi qu'il ait pu arriver dans les transactions concurrentes, chaque transaction propose à l'utilisateur une vision STABLE de la base de données.

Ne pas fermer les transactions sans lesquelles des SELECT ont été exécutés, signifie, pour le serveur que les données t'intéressent toujours et donc, il n'avancera pas l'OID.