Ancestrologie - Développement > Développement

Optimisation...besoin d'une base test

<< < (2/4) > >>

BLefebvre:
Je l'envoie comment. C'est trop gros pour mettre en pièce jointe.

Bruno T.:
                   Tu peux utiliser un service gratuit en ligne comme dl.free.fr, et la compresser avant (zip, rar, ...)
Merci

(mail en message perso)

Bruno T.:
Merci Blefebvre,
j'identifie des éléments chiffrés prometteurs, je vais analyser tout ça et vous tiendrai au courant

Si d'autres ont des bases avant/après avec toujours différence de taille significative, je suis toujours preneur pour mieux établir un règle.
Merci

anorgeot:
bonjour Bruno,

est ce que la différence de "poids" entre le backup  .gbk et le fichier .bdd peut être un indicateur ?

ajout : pour être plus précis , évolution du ratio  .bdd /.gbk  avec comme référence le même ration après une optimisation

Bruno T.:
Faut queje recherche, mais je ne pense pas, le gbk doit être un genre de backup, par extraction des datas et règles, puis compression, il est obtenu par l'application gbak.exe, dans ancestro l'optimisation est en fait une sauvegarde/restauration avec cet outil, ce qui est tout a fait normal.
Sauf à avoir des exemples plus concrets, je pense qu'aujourd'hui l'optimisation d'une base, n'apporte plus grand chose sauf grosse base à usage élevé, le fractionnement étant relativement limité, le seul indicateur pertinent identifié à date serait la différence entre le nombre de transactions exécutées et le numéro de la suivante: ex base de lefebvre: on passe de 168Mo à 125Mo lors de optimisation, olors que le .gbk fait 82Mo pour un delta OldestTrans-NextTrans de 2036-174=1862 transactions "inutiles ou égarées", sur mes bases plus petites avec usage très modéré, je n'ai que 5 à 10 d'écart. Apres optimisation, li n'y a plus d'écart, voilà.
Mon idée créé la ratio à partir de ces infos, mais pas eu le temps de finir d'analyser. :oops: Suffit peut-être  d'imaginer que ce seul exemple est suffisament concret, pour edicter:
- 168 Mo / 125Mo = 25% de gain de taille pour environ 1800 transaction virées environ 175 utiles (soit un rapport de 10 environ)
- on pose 125Mo correspond 100% optimisé


Donc Merci d'avance au matheux qui va nous pondre une règle pas trop absurde, sur les données 1800, 175 (et éventuellement taille fichier) l'objectif étant de dire qu'un fractionnement ou gain potentiel de 10 % (arbitraire) de la taille du fichier, peut-être considérer suffisant pour déclencher l'optimisation, merci  :wink:

D'autre-part le sweep interval indique qu'en dessous de 20000 d'écart, la base ne "réagit" pas, on devrait je pense réduire cette valeur.

--- Code: ---"C:\Program Files (x86)\Firebird\Firebird_2_1\bin\gstat.exe" "Bruno-pc:C:\Users\Bruno\Projets\Base de donnees\Test\LEFEBVRECOMPLET.BDD" -header

"C:\Program Files (x86)\Firebird\Firebird_2_1\bin\gstat.exe" "Bruno-pc:C:\Users\Bruno\Projets\Base de donnees\Test\LEFEBVRECPL_OPTIM.BDD"
 -header

Database "C:\Users\Bruno\Projets\Base de donnees\Test\LEFEBVRECOMPLET.BDD"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              2051
        Page size               4096
        ODS version             11.1
        Oldest transaction      174
        Oldest active           2036
        Oldest snapshot         2036
        Next transaction        2041
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      9
        Implementation ID       16
        Shadow count            0
        Page buffers            32000
        Next header page        0
        Database dialect        3
        Creation date           Mar 5, 2012 14:34:20
        Attributes              no reserve

    Variable header data:
        Sweep interval:         20000
        *END*
               

C:\Users\Bruno>"C:\Program Files (x86)\Firebird\Firebird_2_1\bin\gstat.exe" "Bruno-pc:C:\Users\Bruno\Projets\Base de donnees\Test\LEFEBVRECPL_OPTIM.BD
D"

Database "C:\Users\Bruno\Projets\Base de donnees\Test\LEFEBVRECPL_OPTIM.BDD"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              189
        Page size               4096
        ODS version             11.1
        Oldest transaction      173
        Oldest active           174
        Oldest snapshot         173
        Next transaction        179
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      3
        Implementation ID       16
        Shadow count            0
        Page buffers            32000
        Next header page        0
        Database dialect        3
        Creation date           Mar 8, 2012 16:33:23
        Attributes              no reserve

    Variable header data:
        Sweep interval:         20000
        *END*
--- Fin du code ---

anorgeot:
bonjour Bruno,


--- Citer ---D'autre-part le sweep interval indique qu'en dessous de 20000 d'écart, la base ne "réagit" pas, on devrait je pense réduire cette valeur.
--- Fin de citation ---

j'ai fait plusieurs lecture dont cette page: http://www.firebirdsql.org/manual/gfix-housekeeping.html

De ce que je crois comprendre , et pour Firebird SuperServeur , ce Sweep Interval est à 20000 ,valeur sans doute appropriée pour des bases qui sont sollicitées par de nombreux utilisateurs, mais dans nos cas ???
Une valeur de 100 , permettrait le Garbage Collection (automatique ) de fonctionner effectivement .

Vais faire un essai long pour voir si je note une ou des différences à l'utilisation ( vais le mettre à 50)

ajout: c'est fait et vérifié

Navigation

[0] Index des messages

[#] Page suivante

[*] Page précédente