IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

InterBase Discussion :

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


Sujet :

InterBase

  1. #1
    Membre habitué Avatar de maamar1979
    Inscrit en
    Mai 2006
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 174
    Points : 134
    Points
    134
    Par défaut [interbase] backup/restore et la taille de la BD !
    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.

  2. #2
    Candidat au Club
    Profil pro
    Étudiant
    Inscrit en
    Septembre 2006
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2006
    Messages : 3
    Points : 2
    Points
    2
    Par défaut
    Salut !

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

  3. #3
    Membre expert

    Homme Profil pro
    Consultant spécialité Firebird
    Inscrit en
    Mai 2002
    Messages
    2 342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 2 342
    Points : 3 712
    Points
    3 712
    Par défaut
    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

  4. #4
    Membre habitué Avatar de maamar1979
    Inscrit en
    Mai 2006
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 174
    Points : 134
    Points
    134
    Par défaut
    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 : 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;
    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.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.
    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.

  5. #5
    Membre expert

    Homme Profil pro
    Consultant spécialité Firebird
    Inscrit en
    Mai 2002
    Messages
    2 342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 2 342
    Points : 3 712
    Points
    3 712
    Par défaut
    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

  6. #6
    Membre habitué Avatar de maamar1979
    Inscrit en
    Mai 2006
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 174
    Points : 134
    Points
    134
    Par défaut
    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.

  7. #7
    Membre habitué Avatar de maamar1979
    Inscrit en
    Mai 2006
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 174
    Points : 134
    Points
    134
    Par défaut
    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.

  8. #8
    Membre régulier
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Moselle (Lorraine)

    Informations forums :
    Inscription : Mai 2002
    Messages : 56
    Points : 70
    Points
    70
    Par défaut
    Citation Envoyé par maamar1979
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Oldest transaction	686 
    Oldest active		2007 
    Oldest snapshot		2007 
    Next transaction	2183
    Ca suffit pour conclure que tu gères mal tes transactions.

  9. #9
    Membre régulier
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Moselle (Lorraine)

    Informations forums :
    Inscription : Mai 2002
    Messages : 56
    Points : 70
    Points
    70
    Par défaut
    Citation 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 : 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;
    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é.

  10. #10
    Membre habitué Avatar de maamar1979
    Inscrit en
    Mai 2006
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 174
    Points : 134
    Points
    134
    Par défaut
    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
    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.

  11. #11
    Membre habitué Avatar de maamar1979
    Inscrit en
    Mai 2006
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 174
    Points : 134
    Points
    134
    Par défaut
    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.

  12. #12
    Membre régulier
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Moselle (Lorraine)

    Informations forums :
    Inscription : Mai 2002
    Messages : 56
    Points : 70
    Points
    70
    Par défaut
    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.

  13. #13
    Membre habitué Avatar de maamar1979
    Inscrit en
    Mai 2006
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 174
    Points : 134
    Points
    134
    Par défaut
    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.

  14. #14
    Membre expert

    Homme Profil pro
    Consultant spécialité Firebird
    Inscrit en
    Mai 2002
    Messages
    2 342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 2 342
    Points : 3 712
    Points
    3 712
    Par défaut
    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

  15. #15
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    Citation 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.

  16. #16
    Membre expert

    Homme Profil pro
    Consultant spécialité Firebird
    Inscrit en
    Mai 2002
    Messages
    2 342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 2 342
    Points : 3 712
    Points
    3 712
    Par défaut
    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

  17. #17
    Membre habitué Avatar de maamar1979
    Inscrit en
    Mai 2006
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 174
    Points : 134
    Points
    134
    Par défaut
    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
    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.

  18. #18
    Membre habitué Avatar de maamar1979
    Inscrit en
    Mai 2006
    Messages
    174
    Détails du profil
    Informations forums :
    Inscription : Mai 2006
    Messages : 174
    Points : 134
    Points
    134
    Par défaut
    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.

  19. #19
    Membre régulier
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    56
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Moselle (Lorraine)

    Informations forums :
    Inscription : Mai 2002
    Messages : 56
    Points : 70
    Points
    70
    Par défaut
    Désolé de me fâcher avec toi, modérateur Barbibulle, mais :

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

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

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

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

  20. #20
    Membre expert
    Avatar de Barbibulle
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    2 048
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 2 048
    Points : 3 342
    Points
    3 342
    Par défaut
    Oui ce n'est pas très prudent de se facher tout rouge contre un modérateur

    Non blague à part :

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

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

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

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

    Citation 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é

Discussions similaires

  1. Taille de la BDD identique après Backup/Restore
    Par oumlike dans le forum Administration
    Réponses: 3
    Dernier message: 31/03/2011, 20h32
  2. [interbase] Backup et Restor
    Par maamar1979 dans le forum InterBase
    Réponses: 1
    Dernier message: 02/10/2006, 19h46
  3. Demande de précisions sur Backup/Restore et transactions
    Par lio33 dans le forum Connexion aux bases de données
    Réponses: 1
    Dernier message: 16/11/2005, 13h08
  4. interbase - grant - backup/restore
    Par frantzgac dans le forum InterBase
    Réponses: 2
    Dernier message: 22/04/2005, 14h21
  5. Too Many versions & Backup-Restore à rallonge
    Par Harry dans le forum Administration
    Réponses: 14
    Dernier message: 30/06/2004, 19h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo