dans certains cas, on peut faire un "upgrade", en fonction des versions de départ / arrivée.
Cela consiste à arrêter proprement l'instance d'origine (disons, 8.1.7), installer les binaires nouveaux (10g par exemple), remonter l'instance, et exécuter un script de mise à jour pour le dictionnaire interne de données.
-> pas de déplacement physique des données !!!! ce qui a son importance avec des bases volumineuses. Le temps d'upgrade est maîtrisé (grosso modo, 1 à 2h), quel que soit le volume
le dump (export / import), c'est bien pour les petites bases, mais pas jouables sur de vraies bases (d'autant plus qu'il faut être capable de recréer la structure physique de la base d'origine)... pour info, une base de 500 Go, c'est un arrêt de service de 2 jours ou plus....
[^] # Re: Mise à jour
Posté par antoinebrunel . En réponse à la dépêche Sortie de PostgreSQL 8.0. Évalué à 2.
dans certains cas, on peut faire un "upgrade", en fonction des versions de départ / arrivée.
Cela consiste à arrêter proprement l'instance d'origine (disons, 8.1.7), installer les binaires nouveaux (10g par exemple), remonter l'instance, et exécuter un script de mise à jour pour le dictionnaire interne de données.
-> pas de déplacement physique des données !!!! ce qui a son importance avec des bases volumineuses. Le temps d'upgrade est maîtrisé (grosso modo, 1 à 2h), quel que soit le volume
le dump (export / import), c'est bien pour les petites bases, mais pas jouables sur de vraies bases (d'autant plus qu'il faut être capable de recréer la structure physique de la base d'origine)... pour info, une base de 500 Go, c'est un arrêt de service de 2 jours ou plus....
qui dit mieux ????