[interbase] backup/restore et la taille de la BD !

[maamar1979]

salam;

en fesant un backup/restor de ma base, sa taille diminue de presque 60%.
quelqu'un peut il m'expliquer pourquoi.

merci.

[lyzzy]

Salut !

J'aimerai savoir comment fait on pour faire des backup et des restore sous interbase. Merci !

[makowski]

la diminution de taille c'est parce que ce processus à fait le ménage dans l'historique des transactions enregistré dans la base mais une telle différence veut dire aussi que ta base n'était pas en très bon état, devait accuser de sérieuses pertes de performances, tout ça parce que la ou les applications utilisées gérent mal les transactions

quand à comment faire : il faut utiliser gbak
cf : http://www.firebird-fr.eu.org/article.php3?id_article=5
mais depuis Firebird 2 il y a aussi une possibilité de sauvegardes incrémentales pour les grosses bases par exemple
cf :http://interbase.developpez.com/firebird/nbackup/

[maamar1979]

salam ; et merci de votre repense

Makowski

tout ça parce que la ou les applications utilisées gérent mal les transactions

ben tt les transaction sont à mon avi bien utulisées (c'est en delphi).

j'utililise la syntaxe suivante :

Code :

1
2
3
4
5
6
7
try
DataModule.IBTransaction.startTransaction;
 
DataModule.IBTransaction.CommitRetaining;
except
DataModule.IBTransaction.RollbackRetaining;
end;

ou alors

Code :

1
2
3
4
5
6
7
try
DataModule.IBTransaction.startTransaction;
 
DataModule.IBTransaction.Commit;
except
DataModule.IBTransaction.Rollback;
end;

si vous y voyer une annomalie quelconque ! serait il mieux que les transaction sont lancer directement par des procedure ou fonction sur le serveur ? ou alors que je doit utiliser autre chose que je connait pas vous me le faite savoir.

merci.

[makowski]

ben envoie les stats de ta base avant le backup restore et on verra

Code :

gstat -h <mabase> -user sysdba -password monpassword

[maamar1979]

pour cette base la taille avant le backup etait dans les 4,3 Mo et apres le restor 3,6 Mo. pour d'autre base c pire que ca 4Mo devien moin de 2 Mo.

voila Avant "gstat":

[CODE]Service started at 17/10/2006 09:24:53

Database header page information:
Flags 0
Checksum 12345
Generation 2197
Page size 4096
ODS version 10.1
Oldest transaction 686
Oldest active 2007
Oldest snapshot 2007
Next transaction 2183
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 Jul 16, 2006 14:02:44

[maamar1979]

et voila apres


[CODE]Service started at 17/10/2006 09:30:39

Database header page information:
Flags 0
Checksum 12345
Generation 28
Page size 4096
ODS version 10.1
Oldest transaction 21
Oldest active 22
Oldest snapshot 22
Next transaction 23
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 Oct 17, 2006 9:29:39

[PierreY]

Envoyé par maamar1979

Code :

Ca suffit pour conclure que tu gères mal tes transactions.

[PierreY]

Envoyé par maamar1979

ben tt les transaction sont à mon avi bien utulisées ...
si vous y voyer une annomalie quelconque ! serait il mieux que les transaction sont lancer directement par des procedure ou fonction sur le serveur ? ou alors que je doit utiliser autre chose que je connait pas vous me le faite savoir.

Mon lutin personnel m'engueule parce que je te dis que tu gères mal tes transactions sans t'expliquer comment ni pourquoi.

Le problème c'est que c'est un sujet long et fastidieux. Habituellement on le résume en quelques règles, un genre de tables de la loi de Delphi et de Firebird...

Genre :
- Tu liras l'article de PierreY concernant l'isolement des transactions qui est là : http://www.firebird-fr.eu.org/articl...?id_article=39
- Tu comprendras le concept de l'OID (Oldest Interresting Transaction)
- Tu n'utiliseras JAMAIS de transaction par défaut
- Tu n'utiliseras JAMAIS Commit/Rollback Retaining
- Tu éviteras les composants DBAware (c'est con, c'est un des seuls intérêts de Delphi) ou alors tu passeras par des DataSet mémoire qui permettent de tracvailler en mode déconnecté (Genre UIB + kbmMemoryTable). Les composants DBAware (TDBEdit, TDBComboBox, TDBLookupCombo...) sont un héritage de l'utilisation de Delphi avec Paradox, ils supposent que la connection aux données est persistante et le problème avec Firebird (et même Interbase quoi que veuille faire croire Borland) c'est qu'une connexion persistance implique une transaction ouverte.

Edit:
En fait : quand on fait des SELECT, on ne devrait jamais laisser la transaction ouverte plus que le temps nécessaire à la lecture de toutes les données. C'est une contrainte qui impose, en plus, de savoir gérer correctement ses données parce que remonter 800 000 lignes sous prétexte que c'est plus facile à gérer dans Delphi n'est pas une bonne solution.
/Edit

Quand on fait des mises à jour (insert/update/delete) on crée la transaction au début de l'ensemble de mises à jour qui doivent être vues comme une opération ATOMIQUE par le serveur, et une fois que c'est terminé : COMMIT.

Exemple : J'écris une facture dans une base de données Firebird, en pseudo-code ça donne :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
procedure EcrireFacture(AFacture: Facture)
begin
  CreerTransaction;
  try
    EcrireClient(AFacture.Client);
    EcrireEnteteFacture(AFacture.Entete);
    pour toute L: LigneFacture de AFacture.Lignes
      EcrireLigneFacture(L);
  except
    Rollback;
  finally
    Commit;
  end;
end;

Ici on écrit dans au moins 3 tables (Clients, Factures, LignesFactures) dans UNE SEULE transaction, si un problème se pose, on rollback et TOUTES les modifications réalisées depuis "CreerTransaction" sont annulées. Si tout se passe bien, TOUTES les modifications réalisées depuis "CreerTransaction" sont validées d'un coup, comme s'il ne s'agissait que d'une seule opération.

Tant que tu (vous car tu n'es pas tout seul dans ce cas...) n'aurez pas compris ça, vous n'utiliserez pas Firebird (ou n'importe quel autre SGBD-R qui se respecte) comme il est prévu pour être utilisé.

[maamar1979]

merci beaucoup pour tt les infos que tu m'a données.

PierreY:

- Tu liras l'article de PierreY concernant l'isolement des transactions qui est là : http://www.firebird-fr.eu.org/articl...?id_article=39

je vais le refaire, car je pense l'avoir déjà lu, et c sur que j'ai pas bien compris.

PierreY:
- Tu comprendras le concept de l'OID (Oldest Interresting Transaction)

jamais entendu parler si t'a des liens chui preneur et merci.

PierreY:
- Tu n'utiliseras JAMAIS de transaction par défaut

je n'utilise jamais de transaction par defaut.

PierreY:
- Tu n'utiliseras JAMAIS Commit/Rollback Retaining

par contre j'utilise un peu partou le Commit/Rollback Retaining, et je pense que c'est là le gros du problème. je les utilise pour laisser les données afficher et ne pas fermer la transaction.

PierreY:
- Tu éviteras les composants DBAware

je les utilise partout

PierreY:
tu passeras par des DataSet mémoire qui permettent de tracvailler en mode déconnecté (Genre UIB + kbmMemoryTable)

tu peut m'orienter là stp. je penser que pour utiliser le dataset il faller creer la table a la quelle il se connecte. et je connait pas c deux là UIB + kbmMemoryTable

PierreY:
Quand on fait des mises à jour (insert/update/delete) on crée la transaction au début de l'ensemble de mises à jour qui doivent être vues comme une opération ATOMIQUE par le serveur, et une fois que c'est terminé : COMMIT.

c'est ce que je fait sauf que pour le insert/update j'utilise CommitRetaining (toujour pour ne pas fermer la transaction, et laisser les données visible)

encor merci pour cette petite lecon, vraiment merci beaucoup

[maamar1979]

j'ai tt trouver ici http://www.firebird-fr.eu.org/

sauf pour ca :

PierreY:
tu passeras par des DataSet mémoire qui permettent de tracvailler en mode déconnecté (Genre UIB + kbmMemoryTable)

.

merci encor.

[PierreY]

UIB : www.progdigy.com

La dernière version dans le SVN (http://sourceforge.net/svn/?group_id=87878) contient un nouveau répertoire MISC dans lequel il y a quelques exemples avancés de l'utilisation d'UIB. Dans "AppServer" qui est un prototype de serveur d'application utilisant Firebird, il y a un fichier kbuibLoader.pas qui contient tout ce qu'il faut pour gérer le chargement de données depuis une query (TJvUIBQuery) vers une kbmMemoryTable (http://www.components4developers.com), kbmMemoryTable est un DataSet mémoire très rapide et super fonctionnel. La notion de "Delta Handler" permet ensuite de propager facilement les modifications du dataset en mémoire vers la base de données en écrivant les requêtes d'insert, d'update et de suppression dans les évènements déclenchés par le DeltaHandler.

Ca s'appelle travailler en mode déconnecté. Et pour une application "bureautique" qui gère plus ou moins de données c'est le mode qui est de loin le plus efficace. En limitant le lien à la base de données à une petite partie de l'application, on peut facilement le réécrire pour fonctionner en multi-tiers (avec kbmMW toujours chez http://www.components4developers.com, MidWare chez www.overbyte.be) ou changer de couche de persistance (firebird -> fichier csv, xml, binaire -> autre sgbd...)

Mais surtout on gère la concurrence comme c'est prévu par le SGBD, l'application devient beaucoup plus réactive, sécurisée et fiable.

[maamar1979]

salam;

merci beaucoup pour toutes ces information et tous ces liens

je voulais vous dire aussi, c'est pas que l'on veux pas apprendre ces choses, et les metriser, c'est juste qu'on ne trouve pas ce que vous venez de me faire connaitre ici (dans c'est quelque paragraphes "précieux") sur des bouquins (et dieux sais que j'en est des livre que j'ai lu et relus). on a just besoin de quelcun pour nous mettre sur les railles.

merci du fond du coeur.

[makowski]

il y a un bouquin référence :
http://www.ibphoenix.com/main.nfs?a=..._firebird_book
j'ai essayer plusieures fois déjà de faire un bouquin en français, mais pour l'instant les éditeurs n'en veulent pas
d'où la proposition de formation (qui aborde ces points)
http://www.developpez.net/forums/sho...d.php?t=209058
mais il existe aussi la conférence Firebird
http://www.developpez.net/forums/sho...d.php?t=213866

[Barbibulle]

Envoyé par maamar1979

salam;

en fesant un backup/restor de ma base, sa taille diminue de presque 60%.
quelqu'un peut il m'expliquer pourquoi.

merci.

Ce phénomène est tout a fait normale lorsque l'on a pas mal de delete. Les emplacements des données deletés ne sont pas forcément réutilisés et donc celà ne fait pas diminuer la taille du fichier.

Si ce n'est pas votre cas en effet vous avez peut etre des problemes de transactions mal fermées.

Les recommandations données ci dessus, sont tres bien pour les grosses applications ou qui risque de le devenir ou les applications utilisant un reseau peu stable.

Si votre application reste modeste et qu'elle est destinée à fonctionnée sur un reseau local, il ne sera pas rentable de tout réécrire... Le mode connecté fonctionne tres bien (comme le dit Borland...) et supporte quand meme de la charge.

Inutile donc de tout refaire

Par contre faite bien attention de bien fermer vos transactions c'est primordial.

[makowski]

non le mode connecté ne fonctionne pas "très bien" c'est source de pertes de performances notoires
c'est une hérésie

[maamar1979]

salam;

Barbibulle a dit :
Si votre application reste modeste et qu'elle est destinée à fonctionnée sur un reseau local, il ne sera pas rentable de tout réécrire... Le mode connecté fonctionne tres bien (comme le dit Borland...) et supporte quand meme de la charge. Inutile donc de tout refaire

ben c'est application de gestion de stock, qui sera utiliser au plus par 50 utilisateur (50PC). et je senger dèjà à tt refaire !

[QUOTE]

Barbibulle a dit :
Par contre faite bien attention de bien fermer vos transactions c'est primordial.

j'utilise beaucoup le CommitRetaining et je penser que si l'application etait fermer les transaction ouverte le seront aussi !

merci

[maamar1979]

merci pour les liens makowski

[PierreY]

Désolé de me fâcher avec toi, modérateur Barbibulle, mais :

Envoyé par Barbibulle

Ce phénomène est tout a fait normale lorsque l'on a pas mal de delete. Les emplacements des données deletés ne sont pas forcément réutilisés et donc celà ne fait pas diminuer la taille du fichier.

L'espace n'est pas réutilisé tant qu'il n'a pas été marqué comme étant disponible. Ca n'arrive que quand le Garbage Collector passe (sweep) et qu'il trouve des générations d'enregistrements périmées dans ce cas, il remonte la chaîne des transactions et si cet enregistrement n'est pas intéressant pour aucune des transactions ouvertes, l'espace qu'il utilise est marqué comme disponible.

Envoyé par Barbibulle

Si ce n'est pas votre cas en effet vous avez peut etre des problemes de transactions mal fermées.

Il faut tout lire tous les messages, gstat -h montre une différence de plus de 1500 générations entre l'OID (Oldest Interresting Transaction) et la prochaine qui sera utilisée ! Le peut-être ici est de trop et il arrive un peu tard.

Envoyé par Barbibulle

Les recommandations données ci dessus, sont tres bien pour les grosses applications ou qui risque de le devenir ou les applications utilisant un reseau peu stable.

Si votre application reste modeste et qu'elle est destinée à fonctionnée sur un reseau local, il ne sera pas rentable de tout réécrire... Le mode connecté fonctionne tres bien (comme le dit Borland...) et supporte quand meme de la charge.

Inutile donc de tout refaire

Edit :
C'est exactement avec des conseils comme ça qu'on fait semblant de rassurer les gens, de les conforter dans leur incompétence et qu'on ne les incite pas à faire mieux. Note : J'aurais certainement dû remettre 7 fois mon égo dans ma poche avant de me décider à écrire cette phrase. Le problème c'est qu'elle exprime assez clairement ce que je pense. Quand on ne sait pas faire quelque chose ou qu'on le fait mal, je suis désolé mais le mot pour ça c'est "incompétence" et, croyez moi, je ne suis pas épargné par ce fléau. Ca ne veut pas dire que c'est une fatalité et qu'on ne peut rien y faire, en tous cas, moi j'essaye d'y faire quelque chose. Voilà :-) Au pire, il reste les messages privés pour m'engueuler, c'est aussi fait pour ça.
/Edit

Moi, je suis pas d'accord. D'une part parce que Firebird n'est pas fait pour fonctionner comme vous aimeriez qu'il fonctionne parce que vous avez pris de mauvaise habitudes avec de mauvais outils, d'autre part, ce que dit Borland en la matière est loin d'être parole d'évangile (malgré les hordes de pseudo évangélistes qu'ils missionnent à travers le monde). Allez faire un tour sur les listes Architect et Devel de Firebird, relisez les interventions de Jim Starkey (le type qui a inventé Interbase et qui a réarchitecturé Firebird pour qu'il devienne Vulcan et le même type qui a été embauché par MySQL pour qu'il trouve une solution au problème de la gestion des transactions qui fait cruellement défaut à MySQL) et vous comprendrez peut-être ce qu'est un Serveur de Gestion de Bases de Données Relationnelles et à quoi ça sert.

Envoyé par Barbibulle

Par contre faite bien attention de bien fermer vos transactions c'est primordial.

C'est un conseil inapplicable parce qu'avec les technologies que le monsieur utilise (IBX + composants DBAware) c'est tout simplement IMPOSSIBLE !

C'est le prix à payer pour avoir une architecture Multi Générationnelle qui permet à plusieurs centaines (de milliers ?) de connexions de voir, en permanence et en simultané autant de versions de la base de données qu'il est nécessaire. Microsoft à copié ce MGA dans SQL Server 2005, PostGres l'a copié aussi et MySQL est en train de s'en inspirer. Pourquoi ? Parce que ça marche, ca ne nécessite aucune administration, aucune connaissance du fonctionnement sous-jacent, les données renvoyées sont toujours cohérentes, stables à travers les requêtes, c'est très performant et ce même au niveau d'isolement des transactions par défaut (SNAPSHOT) qui est (soit dit en passant) IMPOSSIBLE de reproduire dans aucune autre architecture client/serveur à base de lock optimistes ou pessimistes.

La seule condition c'est de comprendre l'outil, sa philosophie et de l'utiliser correctement.

Je me repête mais le clou dépasse encore un peu : Les outils par défaut de borland NE PERMETTENT PAS d'utiliser Firebird (et Interbase, c'est là le comble) correctement. Que ça vous plaise, ou pas.

Quand on veut faire une application un tant soit peu performante dans le temps et le volume des données à traiter ON NE PEUT PAS SE PASSER D'UNE PHASE MINIMUM DE CONCEPTION, coder en deux coups de cuiller à pot un truc vite fait avec les composants de Borland NE MARCHERA JAMAIS.

[Barbibulle]

Oui ce n'est pas très prudent de se facher tout rouge contre un modérateur

Non blague à part :

Envoyé par PierreY

L'espace n'est pas réutilisé tant qu'il n'a pas été marqué comme étant disponible. Ca n'arrive que quand le Garbage Collector passe (sweep) et qu'il trouve des générations d'enregistrements périmées dans ce cas, il remonte la chaîne des transactions et si cet enregistrement n'est pas intéressant pour aucune des transactions ouvertes, l'espace qu'il utilise est marqué comme disponible.

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

Envoyé par PierreY

C'est exactement avec des conseils comme ça qu'on fait semblant de rassurer les gens, de les conforter dans leur incompétence et qu'on ne les incite pas à faire mieux. Moi, je suis pas d'accord. D'une part parce que Firebird n'est pas fait pour fonctionner comme vous aimeriez qu'il fonctionne parce que vous avez pris de mauvaise habitudes avec de mauvais outils, d'autre part, ce que dit Borland en la matière est loin d'être parole d'évangile (malgré les hordes de pseudo évangélistes qu'ils missionnent à travers le monde). Allez faire un tour sur les listes Architect et Devel de Firebird, relisez les interventions de Jim Starkey (le type qui a inventé Interbase et qui a réarchitecturé Firebird pour qu'il devienne Vulcan et le même type qui a été embauché par MySQL pour qu'il trouve une solution au problème de la gestion des transactions qui fait cruellement défaut à MySQL) et vous comprendrez peut-être ce qu'est un Serveur de Gestion de Bases de Données Relationnelles et à quoi ça sert.

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

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

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.

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

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

Envoyé par PierreY

C'est un conseil inapplicable parce qu'avec les technologies que le monsieur utilise (IBX + composants DBAware) c'est tout simplement IMPOSSIBLE !

Celà s'appel IBTransaction.Commit; ou RollBack il me semblait.
(Là je taquine...)

Envoyé par PierreY

C'est le prix à payer pour avoir une architecture Multi Générationnelle qui permet à plusieurs centaines (de milliers ?) de connexions

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

Envoyé par PierreY

Quand on veut faire une application un tant soit peu performante dans le temps et le volume des données à traiter ON NE PEUT PAS SE PASSER D'UNE PHASE MINIMUM DE CONCEPTION, coder en deux coups de cuiller à pot un truc vite fait avec les composants de Borland NE MARCHERA JAMAIS.

Tout à fait d'accord avec ca, la conception est tres importante.

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é