salam;
en fesant un backup/restor de ma base, sa taille diminue de presque 60%.
quelqu'un peut il m'expliquer pourquoi.
merci.
salam;
en fesant un backup/restor de ma base, sa taille diminue de presque 60%.
quelqu'un peut il m'expliquer pourquoi.
merci.
On fait tous les X choses nécessaires pour avoir comme résultats un Y, finalement c'est Z qu'on obtiens : c'est le destin.
Salut !
J'aimerai savoir comment fait on pour faire des backup et des restore sous interbase. Merci !
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/
Philippe Makowski
IBPhoenix - Firebird
Membre de l'April
salam ; et merci de votre repense
ben tt les transaction sont à mon avi bien utulisées (c'est en delphi).Makowski
tout ça parce que la ou les applications utilisées gérent mal les transactions
j'utililise la syntaxe suivante :
ou alors
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 try DataModule.IBTransaction.startTransaction; DataModule.IBTransaction.CommitRetaining; except DataModule.IBTransaction.RollbackRetaining; 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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 try DataModule.IBTransaction.startTransaction; DataModule.IBTransaction.Commit; except DataModule.IBTransaction.Rollback; end;
merci.
On fait tous les X choses nécessaires pour avoir comme résultats un Y, finalement c'est Z qu'on obtiens : c'est le destin.
ben envoie les stats de ta base avant le backup restore et on verra
Code : Sélectionner tout - Visualiser dans une fenêtre à part gstat -h <mabase> -user sysdba -password monpassword
Philippe Makowski
IBPhoenix - Firebird
Membre de l'April
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
On fait tous les X choses nécessaires pour avoir comme résultats un Y, finalement c'est Z qu'on obtiens : c'est le destin.
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
On fait tous les X choses nécessaires pour avoir comme résultats un Y, finalement c'est Z qu'on obtiens : c'est le destin.
Ca suffit pour conclure que tu gères mal tes transactions.Envoyé par maamar1979
Mon lutin personnel m'engueule parce que je te dis que tu gères mal tes transactions sans t'expliquer comment ni pourquoi.Envoyé par maamar1979
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 :
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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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;
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é.
merci beaucoup pour tt les infos que tu m'a données.
je vais le refaire, car je pense l'avoir déjà lu, et c sur que j'ai pas bien compris.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
jamais entendu parler si t'a des liens chui preneur et merci.PierreY:
- Tu comprendras le concept de l'OID (Oldest Interresting Transaction)
je n'utilise jamais de transaction par defaut.PierreY:
- Tu n'utiliseras JAMAIS de transaction par défaut
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 n'utiliseras JAMAIS Commit/Rollback Retaining
je les utilise partoutPierreY:
- Tu éviteras les composants DBAware
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 + kbmMemoryTablePierreY:
tu passeras par des DataSet mémoire qui permettent de tracvailler en mode déconnecté (Genre UIB + kbmMemoryTable)
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)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.
encor merci pour cette petite lecon, vraiment merci beaucoup
On fait tous les X choses nécessaires pour avoir comme résultats un Y, finalement c'est Z qu'on obtiens : c'est le destin.
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.
On fait tous les X choses nécessaires pour avoir comme résultats un Y, finalement c'est Z qu'on obtiens : c'est le destin.
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.
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.
On fait tous les X choses nécessaires pour avoir comme résultats un Y, finalement c'est Z qu'on obtiens : c'est le destin.
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
Philippe Makowski
IBPhoenix - Firebird
Membre de l'April
Envoyé par maamar1979
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.
non le mode connecté ne fonctionne pas "très bien" c'est source de pertes de performances notoires
c'est une hérésie
Philippe Makowski
IBPhoenix - Firebird
Membre de l'April
salam;
ben c'est application de gestion de stock, qui sera utiliser au plus par 50 utilisateur (50PC). et je senger dèjà à tt refaire !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
[QUOTE]j'utilise beaucoup le CommitRetaining et je penser que si l'application etait fermer les transaction ouverte le seront aussi !Barbibulle a dit :
Par contre faite bien attention de bien fermer vos transactions c'est primordial.
merci
On fait tous les X choses nécessaires pour avoir comme résultats un Y, finalement c'est Z qu'on obtiens : c'est le destin.
merci pour les liens makowski
On fait tous les X choses nécessaires pour avoir comme résultats un Y, finalement c'est Z qu'on obtiens : c'est le destin.
Désolé de me fâcher avec toi, modérateur Barbibulle, mais :
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
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
Edit :Envoyé par Barbibulle
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.
C'est un conseil inapplicable parce qu'avec les technologies que le monsieur utilise (IBX + composants DBAware) c'est tout simplement IMPOSSIBLE !Envoyé par Barbibulle
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.
Oui ce n'est pas très prudent de se facher tout rouge contre un modérateur
Non blague à part :
Un espace disponible n'est pas forcément utilisé au prochain INSERT.Envoyé par PierreY
De meme que la base ne se réduit JAMAIS apres avoir fait ne nombreux DELETES...
De traiter d'incompétant les membres du forum qui viennent ici pour apprendre et chercher des solutions, n'est pas tres sympatique...Envoyé par PierreY
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.)
Celà s'appel IBTransaction.Commit; ou RollBack il me semblait.Envoyé par PierreY
(Là je taquine...)
Ce n'est visiblement pas l'objectif de son application.Envoyé par PierreY
Tout à fait d'accord avec ca, la conception est tres importante.Envoyé par PierreY
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é
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager