Sujet: Optimisation...besoin d'une base test

[Bruno T.]

Bonjour,
J'ai peut-être trouvé quelque chose de rationnel par rapport au problème latent de mesure du besoin ou pas d'optimiser, mais j'ai besoin d'une base de test

Rappel:
Aujourd'hui la mesure n'en est pas une, c'est un indicateur arbitraire de durée d'usage de la base, il diminue même si il n'y a pas de transaction sur la base, solution provisoire mais qui dure faute de mieux.

Donc je fait appel à une bonne âme, qui aurait une base non optimisée, ayant subit "énormément" de travaux, une base dont la taille sur le disque avant optimisation est "largement" plus importante qu'après.

S vous pensez avoir cela, merci de répondre ici

[emable]

Bonjour,
Ma base avant Optimisation fait 506 068 Ko et après 503 640 KO, cela suffit-il en écart ?
Cordialement

[BLefebvre]

La mienne faisait 137000ko après la dernière optimisation, et 168000 aujourd'hui.
Si ça peut vous convenir.

[Bruno T.]

Bonjour à tous les 2,
@ emable: je pense que ce ne serait pas suffisamment significatif par rapport à Blefebvre, merci quand même d'avoir répondu.
@ Blefebvre: Si je comprends la dernière sauvegarde après optimisation faisait 137 mo et aujourd'hui après usage et sans optimisation elle serait "grimpée" à 168 Mo, cela me semble intéressant, surtout en faire une copie a mettre de coté ou m'envoyer, avant de faire une optimisation, merci.

Je vais mettre un petit prg en lien , il donnera 2 ou 3 indications   sur la base et ça me renseignera pour voir si mon idée tient debout ou   pas .

[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. 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 

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: [Sélectionner]

"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*

[anorgeot]

bonjour Bruno,

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.

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é

[Bruno T.]

Bonsoir Alain, Philippe

Intéressant ton retour,
tu veux bien dire qu'avec le sweep à 50, l'optimisation parait devenir inutile, et que avant/après optimisation il n'y a pas de différence de taille perceptible ?

Si c'est confirmé, je pense qu'il faudra malgré-tout laissé la possibilité de lancer cette optimisation dans un menu, ou fenetre, au cas ou.
Par contre supprimer la barre et le lancement automatique.

PS: désolé de ma présence rare ces derniers temps, mais ayant repris un emploi, les 1er mois sont assez chargés pour faire sa place, je reviendrais plus régulièrement d'ici quelques semaines, de plus la v2 finale des arbres est sur le feu, faudrait que je boucle avant l'hiver, m'enfin le taf reste plus important.

[anorgeot]

bonsoir,

j'ai préparé un tableau avec les résultats journaliers de :
taille .BDD en Octets ||  taille .GBK en octets || ratio BDD/GBK || Nbre de Nouv enreg. || Nbre enreg. modifié

je le posterai demain

je ne compte pas faire d'optimisation , ceci pour voir ce qui se passe !

je compte aussi faire (mais sur une sauvegarde) la manip en BOA comme pour récupérer les CP sur toute la base

[anorgeot]

Bonjour,

voici le tableau

La base : 15000 individus, 4500 unions , quand les actes sont mémorisés c'est uniquement en mode fichier ,
               seulement qques photos en mode images pour les Identité

Le Sweep a été mis à 50 le 3 octobre

le .BDD faisait 47.240    le .GBK faisait 45.513  Ko (lecture sur l'explorateur)
après optimisation
le .BDD faisait 47.240    le .GBK faisait 45.517 Ko (lecture sur l'explorateur)

ensuite dans le tableau qui suit le poids des fichiers est lu dans les propriétés du fichier
               

Date                   BDD octets    GBK octets    Créées         Modifiées         BDD/GBK
04/10/2012           48 373 xxx    46 644 xxx    37                 75                 1.037
05/10/2012           48 373 xxx    46 809 xxx    17                36                     1.033
06/10/2012           48 373 xxx    46 854 xxx    8                 12                 1.032
07/10/2012           51 396 xxx    46 927 xxx    25                 36                 1.095
08/10/2012           51 396 xxx    46 964 xxx    22                 25                  1.094
09/10/2012           51 396 xxx    47 010 xxx     25                30                  1.093
10/10/2012           51 396 xxx    47 042 xxx    14                34                 1.093

         

ce jour le 11 octobre , avant toute opération , voici ce que donne le gstat      
               

P:\Program Files\Firebird\Firebird_2_1_5\bin>gstat sw50_1360_5130_01oct.bdd
can't format message 21:6 -- message file E:\Fich_Recus\Firebird-2.1.5.18496-0_W
in32\firebird.msg not found
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              3571
        Page size               4096
        ODS version             11.1
        Oldest transaction      3545
        Oldest active           3546
        Oldest snapshot         3546
        Next transaction        3547
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      85
        Implementation ID       16
        Shadow count            0
        Page buffers            32000
        Next header page        0
        Database dialect        3
        Creation date           Oct 3, 2012 15:20:32
        Attributes              force write

    Variable header data:
        Sweep interval:         50
        *END*

               
               
et ci-dessous le gstat sur ma base que j'avais nommée Sweep20000.bdd
je ne trouve pas de trace d'optimisation avant 15h23 et la sauvegarde que j'ai utilisé    est de 12h13 le 03 oct 2012   

P:\Program Files\Firebird\Firebird_2_1_5\bin>gstat sweep20000.bdd121003-1213
can't format message 21:6 -- message file E:\Fich_Recus\Firebird-2.1.5.18496-0_W
in32\firebird.msg not found
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              2294
        Page size               4096
        ODS version             11.1
        Oldest transaction      1532
        Oldest active           2256
        Oldest snapshot         2254
        Next transaction        2285
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      34
        Implementation ID       16
        Shadow count            0
        Page buffers            32000
        Next header page        0
        Database dialect        3
        Creation date           Sep 28, 2012 18:43:38
        Attributes              force write

    Variable header data:
        Sweep interval:         20000
        *END*   

               

Ce qui me semble significatif c'est qu'avec un sweep à 50 la base semble se maintenir toute seule dans un état où les données en gras restent avec un très faible écart , .... comme après une optimisation !!
               
               
               
               

[anorgeot]

bonsoir,

toujours en observation, comparaison,... (j'en passe!!!)  je viens en relisant le sujet de bout en bout , et en comparant les DataBase Header  de la base transmise par LEFEBVRE et la mienne de noter une différence qui doit avoir une certaine importance...

Sa base est avec      Attributes   :    no reserve     la mienne avec   Attributes  : Force Write

Attributes: This part of the report displays information about various attributes of the database. Examples of what you may see are:

    no reserve - All pages will be filled to 100% and will be most useful on read-only databases. No space is reserved in each page for updates and/or deletions.

    force write - Disc writes are not cached. They are written out to the hardware at the time of the write request. This is used mainly on Windows databases where the cache management system can lead to lost writes and database corruption.

source : http://www.firebirdsql.org/manual/bk02ar17s03.html
et aussi dans cette question/réponse à Firebird-Support
http://ancestrologie.org/forum/index.php?action=post;topic=11836.0;num_replies=12

enfin , je trouve que c'est encourageant de voir les données ci-après au bout d'une semaine de fonctionnement avec le Garbage collection à 50. et après avoir créé à ce jour +/- 150 individus

Oldest transaction      3545
        Oldest active           3546
        Oldest snapshot         3546
        Next transaction        3547

Les explications que l'on trouve dans le premier lien semble dire que jusqu'ici c'est encourageant.

[anorgeot]

bonjour,

mise à jour de mes relevés


voir image

je continue sur la base non optimisée                              

[anorgeot]

Bonjour,

je stoppe mes enregistrements et vous donne le résumé:

Configuration Firebird
- version 2.1.5  en super serveur
- Database properties
  page size 4096
  allocated pages  12548  ( après une optimisation )
  page buffers  32000
  sweep interval   50 (passé à 5 le 02 dec 2012)
  Force Writes

  Firebird.conf
     #RootDirectory =
Je ne suis pas bien clair là dessus , ce qui fait que pour le reste ..., est ce bien pris en compte ??

    # File system cache usage
    #
    # Sets the threshold whether Firebird will use file system cache or not.
   # File system caching is used if database cache pages (sets explicitly in
   # database header or implicitly via DefaultDbCachePages setting) is less
   # than MaxFileSystemCache value.
   # To always use file system cache set MaxFileSystemCache to some big value.
   # To never use file system cache set MaxFileSystemCache to zero.
  #
  # Type: integer, measured in database pages
  #
  #MaxFileSystemCache = 65536
  #MODIF perso ALAIN
  MaxFileSystemCache = 0
( risques de corruption de la base avec le cache système )

Bref ! j'ai observé pendant plus de 30 jours  , voir le tableau XL.

1/ d'une base optimisée le 03 oct 12
    voir les repérages en vert --> optimisation sur la base de travail
    voir les repérages en jaune ---> optimisation intermédiaire sur une copie de la base de travail

2/  la taille de la .BDD n'augmente que périodiquement et par "bonds" (pages allouées X Page size )
     voir les répèrages en bleu
     la fréquence de ces bonds est fonction de l'activité
          dans cette activité , sont particulièrement déclencheurs : Renumérotation Sosa et création, alimentation d'un nouveau dossier

3/ en résumé :
    le 3 oct 12   BDD= 48 373 760    GBK= 46 690 304    ratio  BDD/GBK = 1,036 055 7944    départ optimisé

   entre le 03 oct et le 06 nov , il y a eu 2 "bonds" intermédiaires de la taille de la BDD

                           les ratios BDD/GBK  ont progressé alors comme suit : = 1,095 237 5757    NON optimisé
                                                                                                           = 1,152 950 5875    NON optimisé
     le 17 nov 12 BDD= 58 019 840    GBK= 49 676 800    ratio  BDD/GBK = 1,167 946 4056    NON optimisé
     le 17 nov 12 BDD= 51 396 608    GBK= 49 677 824    ratio  BDD/GBK = 1,034 598 6169    OPTIMISÉ

Si cela peut vous inspirer ... c'est tant mieux

bien amicalement

(tableau en zip à suivre en AJOUT

[Bruno T.]

Bonjour,
Je viens de relire ce post, et après plusieurs tests, j'en arrive à la même conclusion:
- le sweep n'a pas l'air d'avoir d'influence sur la taille de la base
- la valeur de oldest transaction s'aligne sur celle de next transaction-1

Malgré tout, j'ai quand même positionné le sweep inteval à 50 au lieu de 2000 dans le nouveau script d'installation et la mise à jour (pas encore en ligne) en attendant de trouver le "truc"

Je rajoute: le sweep influe quand même sur la vitesse d'augmentation de la taille de la base d'après ce je lit par ci par là, celà reste à confirmer, peut-être avec des tests partant de la même base, avec les mêmes opérations, mais un sweep 50 et l'autre 2000 par exemple.