Discussion :

[ludo00002]

Bonjour,
j'ai une base firebird 2.5 de 14Go sous windows serveur 2008 R2 64. J'ai constaté des temps anormalement longs lors de la violation de clé unique successives(RDB$4). Il y 80 000 000 lignes environ sur la table testée.
Est-ce que c'est un problème connu?
Est-ce lié à Firebird?
Est-ce que ça ne cache pas un autre problème?
Est-ce qu'il y aurait une configuration spécifique à faire sous windows 2008 R2 64?
Ci-dessous les stats simplifiée de la base:

Database header page information:
Flags 0
Checksum 12345
Generation 674807
Page size 8192
ODS version 11.2
Oldest transaction 673607
Oldest active 673608
Oldest snapshot 673608
Next transaction 673802
Bumped transaction 1
Sequence number 0
Next attachment ID 1348
Implementation ID 16
Shadow count 0
Page buffers 4096
Next header page 0
Database dialect 3
Creation date May 14, 2012 12:30:23
Attributes no reserve

Variable header data:
Sweep interval: 20000
*END*
TE_MESURE (132)
Primary pointer page: 193, Index root page: 194
Data pages: 773812, data page slots: 795721, average fill: 83%
Fill distribution:
0 - 19% = 9870
20 - 39% = 28927
40 - 59% = 85650
60 - 79% = 132611
80 - 99% = 516754

Index IDX_TE_MESURE (2)
Depth: 3, leaf buckets: 78067, nodes: 78851959
Average data length: 0.02, total dup: 78658567, max dup: 4162219
Fill distribution:
0 - 19% = 30
20 - 39% = 6949
40 - 59% = 24228
60 - 79% = 8945
80 - 99% = 37915

Index IDX_TE_MESUREDT (3)
Depth: 3, leaf buckets: 71331, nodes: 78852267
Average data length: 0.61, total dup: 57333360, max dup: 245
Fill distribution:
0 - 19% = 24
20 - 39% = 1622
40 - 59% = 6930
60 - 79% = 3208
80 - 99% = 59547

Index IDX_TE_MESUREDT2 (4)
Depth: 3, leaf buckets: 71331, nodes: 78852267
Average data length: 0.61, total dup: 57333360, max dup: 245
Fill distribution:
0 - 19% = 23
20 - 39% = 1622
40 - 59% = 6930
60 - 79% = 3214
80 - 99% = 59542

Index IDX_TE_MESUREID (5)
Depth: 3, leaf buckets: 63831, nodes: 78852409
Average data length: 0.00, total dup: 78851451, max dup: 2937189
Fill distribution:
0 - 19% = 38
20 - 39% = 3163
40 - 59% = 6261
60 - 79% = 3915
80 - 99% = 50454

Index IDX_TE_MESUREIDAPP (6)
Depth: 3, leaf buckets: 66491, nodes: 78851894
Average data length: 0.00, total dup: 78851893, max dup: 78851893
Fill distribution:
0 - 19% = 17
20 - 39% = 2162
40 - 59% = 8366
60 - 79% = 11331
80 - 99% = 44615

Index IDX_TE_MESUREN (7)
Depth: 3, leaf buckets: 73110, nodes: 78851978
Average data length: 1.01, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 12
20 - 39% = 2745
40 - 59% = 6877
60 - 79% = 2139
80 - 99% = 61337

Index RDB$4 (0)
Depth: 3, leaf buckets: 95135, nodes: 78852347
Average data length: 2.78, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 99
20 - 39% = 231
40 - 59% = 1381
60 - 79% = 333
80 - 99% = 93091

Index RDB$PRIMARY18 (1)
Depth: 3, leaf buckets: 73093, nodes: 78851978
Average data length: 1.01, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 6
20 - 39% = 2745
40 - 59% = 6855
60 - 79% = 2139
80 - 99% = 61348

[ludo00002]

J'ai testé la version snapshot Firebird-2.5.2.26485-0_Win32, j'ai l'impression que je n'ai plus de montée en RAM, par contre j'ai toujours des temps incroyablement long lorsqu'il se produit une exception et qu'on fait un rollback.

[makowski]

Firebird-2.5.2.26485-0_Win32

sur un windows 64 ?
pourquoi ne pas utiliser la version 64 bits de FIrebird ?

[ludo00002]

Nous ne sommes pas encore certain de la compatibilité totale de notre applicatif avec FB 64. Mais nous avons fait des essais avec FB 64 2.5.1, et nous avons constaté le même problème.
Il serait intéressant en effet de faire l'essai sur le snapshot FB 64 2.5.2 pour voir. Mais je n'ai plus d'accès au téléchargement des snapshots...

[ludo00002]

Je vais tester la version FB 64 2.5.2 cette nuit. Nous avons l'intention de laisser tomber les IBX mais ce n'est pas encore fait. Donc pour l'instant on est obligé de continuer avec ça. Est-ce qu'il y a des risques d'incompatibilité avec la version FB 64?

[ludo00002]

La FB 64 2.5.2 à l'air bien plus performante que La FB 32 2.5.2. Mais néanmoins lorsqu'un fait des inserts qui violent la clé unique de façon répétive, le CPU monte à 100%.