Gestion transactions sous Firebird (v1.5.4)

**Zepeq** · 08/10/2007, 16h23

Bonjour à tous,

Je travaille sur une application Delphi se connectant à une base de données Firebird 1.5.4, contenant deux tables.

L'application effectue des requêtes de type 'SELECT' et d'autre de type 'UPDATE' et sont affiliées à des transactions différentes. Un DataSet et sa transaction permettent l'affichage des données dans un DBGrid.

Ayant parcouru pas mal de topic sur le sujet, je pensais avoir géré les transactions pas trop mal (exécution requête, manipulation données, fermeture transaction, sauf pour l'affichage) .

Or après quelques requêtes sur la base de données, je constate une augmentation de la taille de celle-ci.

CARAMBA, ENCORE RATé !

Voici les stats de la base :

Database header page information:
Flags 0
Checksum 12345
Generation 22690
Page size 4096
ODS version 10.1
Oldest transaction 22652
Oldest active 22653
Oldest snapshot 22653
Next transaction 22684
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 Sep 14, 2007 9:53:01
Attributes force write

Variable header data:
Sweep interval: 20000
*END*

Pour une dizaine d'enregistrements dans les 2 tables de la base de données, une augmentation de taille du fichier de l'ordre de 30-40% est constatée. Après un "Backup" - "Restore", la base de données retrouve sa taille "normale".

Quels conseils pouvez-vous me donné pour éviter ceci?

Merci d'avance pour votre aide

**makowski** · 08/10/2007, 18h21

met ta requete select dans une transaction READ ONLY READ COMMITED, dès que tu as le SELECT tu fais un COMMIT RETAIN
et tu raffraichis autant que besoin ta grille

Autre solution,faire un select dans une transaction, récupérer les données dans l'espace mémoire de ton clients (memdataset par exemple) fermer la transaction

mais bon tes stats ne sont pas mauvaises en soit, il faut bien que le moteur fasse son boulot, il lui faut un peu de place pour cela
tant que les perfs ne se dégradent pas je ne vois pas où est le problème

En plus de cela tous les jours tu fait un backup avec gbak (que le backup) cela participera à la collecte des données périmées et ta base devrait bien se comporter

**Zepeq** · 09/10/2007, 08h11

Merci Makowski pour tes conseils, je vais essayer tes 2 solutions proposées. You are the

Envoyé par makowski

mais bon tes stats ne sont pas mauvaises en soit, il faut bien que le moteur fasse son boulot, il lui faut un peu de place pour cela
tant que les perfs ne se dégradent pas je ne vois pas où est le problème

Elles ne sont pas si mauvaises en effet. Mais je voulais avoir un avis extérieur. L'application est implantée sur une machine de production contenant un PC industriel dont les perfs ne sont pas exceptionnelles. De plus, l'architecture de l'application actuelle n'est de loin pas parfaite et les ressources dispos sont assez limitées. Raison pour laquelle je préfère être sûr de mon coups. J'imagine également, si nécessaire, passer par la version "embedded" de firebird.

Envoyé par makowski

En plus de cela tous les jours tu fait un backup avec gbak (que le backup) cela participera à la collecte des données périmées et ta base devrait bien se comporter

Je pensais faire un backup-restore, mais à quoi peut bien me servir le backup seul? Si tu pouvais m'en dire un peu plus, je t'en serais très reconnaissant.

Merci de m'avoir lu et répondu

**makowski** · 09/10/2007, 08h53

e pensais faire un backup-restore, mais à quoi peut bien me servir le backup seul? Si tu pouvais m'en dire un peu plus, je t'en serais très reconnaissant.

je te l'ai dis :
cela participera à la collecte des données périmées

**Zepeq** · 09/10/2007, 09h05

Envoyé par makowski

je te l'ai dis :
cela participera à la collecte des données périmées

Ok pour la collecte des données permiées, mais selon la syntaxe

Code :

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

1
2
C:\Program Files\Firebird\Firebird_1_5\bin> gbak -b[ackup]
<options> source target [n]

Or si je te comprend bien, je ne devrais pas faire de restore du fichier "target"? Le backup de gbak a donc un effet sur le fichier "source"? J'avoue que je ne suis pas très bien...

**makowski** · 09/10/2007, 15h27

Envoyé par Zepeq

Ok pour la collecte des données permiées, mais selon la syntaxe

Code :

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

1
2
C:\Program Files\Firebird\Firebird_1_5\bin> gbak -b[ackup]
<options> source target [n]

Or si je te comprend bien, je ne devrais pas faire de restore du fichier "target"? Le backup de gbak a donc un effet sur le fichier "source"? J'avoue que je ne suis pas très bien...

oui
gbak visitant tous les enregistrements de la base, il participe à la collecte des données périmées par ce seul fait
donc il ne sert pas qu'à faire une sauvegarde, mais aussi participe à la maintenance de la base, sans qu'il y ait besoin de faire de restore
et heureusement d'ailleurs, il ne faut pas oubliez qu'il y a aussi des gens qui utilisent Firebird avec des bases devant absolument tourner 24h/24 !

**Zepeq** · 09/10/2007, 16h16

Merci à toi Philippe pour toutes ces précisions utiles.

Le temps de revoir le code, d'effectuer quelques tests et je passerai donner un feed-back.

Encore merci

**SergioMaster** · 12/10/2007, 08h32

j'ajoute mon grain de sel , dans ce fichier .BAT

Code :

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

1
2
3
 
gbak -v -t -user SYSDBA -password *****  "D:/Fichiers/Base.fdb" "D:\Fichiers\base.gbk"
gfix -user SYSDBA -password ****** "D:/Lalet/Base.fdb" -sweep

est-ce que, d'apres ce qui est raconté plus haut , le gfix ne servirait à rien , puisque déjà fait par le gbak ????

**makowski** · 12/10/2007, 10h01

hum, quasiment oui, surtout si le gbak est lancé à un moment où il est le seul à agir sur la base
Sweep fait un peu plus que gbak, mais dans la vie de tous les jours, cela devrait suffire, surtout avec les nouveaux réglages du sweep dans Firebird 2.

mais bon, comme d'habitude, il n'y a pas de vérité absolue, il faut voir le contexte globale de vie de la bd, les types de transactions utilisées, l'activité, à quels moment sont lancés gbak ou gfix, ...

Par contre il y a une chose qui est souvent oublié, c'est la maintenance des index cf http://blog.developpez.com/index.php...&c=1&tb=1&pb=1

**SergioMaster** · 13/10/2007, 08h16

Envoyé par makowski

Par contre il y a une chose qui est souvent oublié, c'est la maintenance des index cf http://blog.developpez.com/index.php...&c=1&tb=1&pb=1

Effectivement . Très intéressant mais il n'y aurait t-il pas un moyen de lancer cette procédure automatiquement ?

**makowski** · 13/10/2007, 23h36

un fichier de traitement par lot dans un cron
mais bon, le mieux est tout de même de faire ça quand la base n'est pas sollicitée

**SurfingJeff** · 16/10/2007, 12h01

Envoyé par makowski

Par contre il y a une chose qui est souvent oublié, c'est la maintenance des index cf http://blog.developpez.com/index.php...&c=1&tb=1&pb=1

Quel est la différence entre un recalcul de la sélectivité des index (SET STATISTICS) et un ALTER INDEX INACTIVE/ACTIVE ?

**makowski** · 16/10/2007, 14h11

Alter Index reconstruit complètement l'index

c'est bien aussi, mais un peu plus lourd et plus violent

**Zepeq** · 17/10/2007, 08h35

Envoyé par makowski

...
En plus de cela tous les jours tu fait un backup avec gbak (que le backup) cela participera à la collecte des données périmées et ta base devrait bien se comporter

Je reviens sur le gbak. L'application actuelle avec sa vieille base de données (paradox) contient un mécanisme de sauvegarde dont l'interval est paramètrable. De mémoire, certains utilisateurs paramètrent cet interval pour effectuer une backup toutes les 10min.

Y a-t-il un effet indésirable si toutes les 10min par exemple, un gbak (backup seul) est lancé!?

Gestion transactions sous Firebird (v1.5.4)

Connexion aux bases de données Firebird

Discussions similaires

Partager

Partager