pg_upgrade — met à jour une instance du serveur PostgreSQL
pg_upgrade
-b
ancien_repertoire_executables
[-B
nouveau_repertoire_executables
] -d
ancien_repertoire_configuration
-D
nouveau_repertoire_configuration
[option
...]
pg_upgrade (antérieurement connu sous le nom pg_migrator) permet de mettre à jour les fichiers de données vers une version plus récente de PostgreSQL sans la sauvegarde et le rechargement de données typiquement requis pour les mises à jour d'une version majeure vers une autre, par exemple d'une version 12.14 à une version 13.10 ou à partir de 14.9 vers 15.5. Il n'est pas nécessaire pour les mises à jour de versions mineures, par exemple de 12.7 à 12.8 ou de 14.1 à 14.5.
Les sorties de version majeures de PostgreSQL ajoutent régulièrement de nouvelles fonctionnalités qui changent souvent la structure des tables système, mais le format interne des données stockées change rarement. pg_upgrade utilise ce fait pour effectuer des mises à jour rapides en créant de nouvelles tables systèmes et en réutilisant les anciens fichiers de données. Si jamais une future version majeure devait modifier le format d'enregistrement des données de telle sorte que l'ancien format des données soit illisible, pg_upgrade ne pourrait pas être utilisé pour ces mises à jour. (La communauté essaiera d'éviter de telles situations.)
pg_upgrade fait de son mieux pour être sûr que la nouvelle et l'ancienne instances soient compatibles au niveau binaire, par exemple en vérifiant que les options de compilation sont compatibles, y compris le format 32/64 bits des binaires. Il est également important que les modules externes soient aussi compatibles au plan binaire, bien que ceci ne puisse être vérifié par pg_upgrade.
pg_upgrade supporte les mises à jour à partir de la version 9.2.X et suivantes jusqu'à la version majeure courante de PostgreSQL, y compris les images et versions beta.
pg_upgrade accepte les arguments de ligne de commande suivants :
-b
repertoire_executables
--old-bindir=
repertoire_executables
l'ancien répertoire des exécutables PostgreSQL ;
variable d'environnement PGBINOLD
-B
repertoire_executables
--new-bindir=
repertoire_executables
le nouveau répertoire des exécutables PostgreSQL ;
la valeur par défaut est le répertoire d'installation de
pg_upgrade ; variable d'environnement
PGBINNEW
-c
--check
uniquement la vérification des instances, ne modifie aucune donnée
-d
repertoire_configuration
--old-datadir=
repertoire_configuration
répertoire de configuration de l'ancienne instance ;
variable d'environnementPGDATAOLD
-D
repertoire_configuration
--new-datadir=
repertoire_configuration
répertoire de configuration de la nouvelle instance ;
variable d'environnement PGDATANEW
-j njobs
--jobs=njobs
nombres de processus ou threads simultanés à utiliser
-k
--link
utiliser des liens physiques au lieu de copier les fichiers vers la nouvelle instance
-N
--no-sync
Par défaut, pg_upgrade
attendra que tous les fichiers
de l'instance mise à jour soient écrites sur disque. Cette option fait
que pg_upgrade
quitte sans attendre, ce qui est plus
rapide mais signifie qu'un crash ultérieur du système d'exploitation peut
laisser le répertoire de données corrompu. Généralement, cette option est
utile dans le cas de tests mais elle ne devrait pas être utilisée pour
une installation en production.
-o
options
--old-options
options
options à passer directement à l'ancienne commande
postgres
; les invocations multiples de cette
option sont cumulées
-O
options
--new-options
options
options à passer directement à la nouvelle
commande postgres
; les invocations multiples
de cette commande sont cumulées
-p
port
--old-port=
port
le numéro de port de l'ancienne instance ; variable
d'environnementPGPORTOLD
-P
port
--new-port=
port
le numéro de port de la nouvelle instance ; variable
d'environnementPGPORTNEW
-r
--retain
conserver les fichiers SQL et de traces y compris après avoir terminé avec succès
-s
dir
--socketdir=
dir
répertoire utilisé pour stocker les sockets lors de la
mise à jour ; la valeur par défaut est le répertoire courant ;
la variable d'environnement est PGSOCKETDIR
-U
username
--username=
username
nom d'utilisateur de l'instance d'installation ;
variable d'environnementPGUSER
-v
--verbose
activer la trace interne verbeuse
-V
--version
afficher les informations de version, puis quitter
--clone
Utilise le clonage efficace de fichiers (connu aussi sous le nom de
« reflinks » sur certains systèmes) au lieu de copier les
fichiers vers la nouvelle instance. Ceci peut résulter en une copie
pratiquement instantanée des fichiers de données, donnant l'avantage
en vitesse de l'option -k
/--link
tout en laissant l'ancienne instance non modifiée.
Le clonage de fichiers est seulement supporté sur certains systèmes d'exploitation et systèmes de fichiers. Si cette option est sélectionnée alors qu'elle n'est pas supportée, l'exécution de pg_upgrade renverra une erreur. Actuellement, cette option est supportée sous Linux (à partir du noyau 4.5) avec Btrfs et XFS (pour les systèmes de fichiers créés avec le support de reflink), et sur macOS avec APFS.
--copy
Copie les fichiers sur la nouvelle instance. Cette option est activée
par défaut. (Voir aussi
--link
et --clone
.)
-?
--help
afficher l'aide, puis quitter
Ci-dessous les étapes pour effectuer une mise à jour avec pg_upgrade :
Si nécessaire, déplacez l'ancienne instance
Si vous utilisez un répertoire d'installation spécifique par
version, exemple /opt/PostgreSQL/16
, vous
n'avez pas besoin de déplacer l'ancienne instance. Les installateurs
graphiques utilisent tous des répertoires d'installation
spécifiques par version.
Si votre répertoire d'installation n'est pas spécifique par
version, par exemple /usr/local/pgsql
, il est
nécessaire de déplacer le répertoire d'installation courant de
PostgreSQL de telle manière à ce qu'il n'interfère pas avec la nouvelle
installation de PostgreSQL. Une fois
que le serveur courant PostgreSQL
est éteint, il est sans danger de renommer le répertoire
d'installation de PostgreSQL ; en supposant que l'ancien
répertoire est /usr/local/pgsql
, vous
pouvez faire :
mv /usr/local/pgsql /usr/local/pgsql.old
pour renommer le répertoire.
Pour les installations à partir des sources, construisez la nouvelle version
Construisez la nouvelle version de PostgreSQL à partir des
sources avec des options de configure
qui sont compatibles avec l'ancienne instance.
pg_upgrade utilisera
pg_controldata
pour s'assurer que l'ensemble
des configurations sont compatibles avant de commencer la mise
à jour.
Installez les nouveaux binaires PostgreSQL
Installez les binaires du nouveau serveur et les fichiers associés. Par défaut, pg_upgrade est inclus dans une installation.
Pour les installations à partir des sources, si vous souhaitez
installer le nouveau serveur dans un répertoire personnalisé, utilisez
la variable prefix
:
make prefix=/usr/local/pgsql.new install
Initialisez la nouvelle instance PostgreSQL
Initialisez la nouvelle instance en utilisant la commande
initdb
. À nouveau, utilisez des options de
la commande initdb
compatibles avec l'ancienne
instance. Beaucoup d'installateurs pré-construits effectuent cette
étape automatiquement. Il n'est pas nécessaire de démarrer
la nouvelle instance.
Installez les fichiers objets partagés d'extension
Beaucoup d'extensions et de modules personnalisés, qu'ils viennent de
contrib
ou d'une autre source, utilisent les
fichiers d'objets partagés (ou DLL), par exemple
pgcrypto.so
. Si l'ancienne instance les utilisait,
les fichiers d'objets partagés correspondant aux binaires du nouveau
serveur doivent être installés dans la nouvelle instance, habituellement
avec les commandes du système d'exploitation. Ne chargez pas les
définitions de schéma, par exemple CREATE EXTENSION
pgcrypto
, parce qu'elles seront dupliquées à partir de
l'ancienne instance. Si des mises à jour d'extensions sont disponibles,
pg_upgrade l'indiquera et créera un script à
exécuter plus tard pour les mettre à jour.
Copier les fichiers personnalisés de recherche plein texte
Copiez tous les fichiers personnalisés de recherche plein texte (dictionnaire, synonymes, thésaurus, mots d'arrêt) de l'ancienne instance vers la nouvelle.
Ajuster l'authentification
pg_upgrade
se connectera à l'ancien et au
nouveau serveur plusieurs fois, aussi vous pourriez avoir besoin
de positionner l'authentification sur peer
ou d'utiliser un fichier ~/.pgpass
(voir
Section 34.16).
Arrêtez les deux serveurs
Assurez vous que les deux serveurs sont arrêtés en utilisant, sur Unix par exemple :
pg_ctl -D /opt/PostgreSQL/12 stop pg_ctl -D /opt/PostgreSQL/16 stop
ou sur Windows, en utilisant les noms de services corrects :
NET STOP postgresql-12 NET STOP postgresql-16
Les serveurs standby par réplication en flux et par copie des journaux doivent être en cours d'exécution jusqu'à une étape ultérieure.
Préparez la mise à jour d'un serveur standby
Si vous êtes en train de mettre à jour des serveurs standby
en suivant la description de la section Étape 11, vérifiez
en utilisant pg_controldata sur
les anciennes instances primaires et standby que les anciens
serveurs standby sont à jour. Vérifiez que les valeurs de
« Latest checkpoint location » correspondent dans
toutes les instances.
De plus, assurez-vous que le paramètre wal_level
ne
soit pas configuré avec la valeur minimal
dans le
fichier de configuration postgresql.conf
sur la
nouvelle instance primaire.
Lancez pg_upgrade
Lancez toujours le binaire pg_upgrade
du nouveau serveur, pas celui de
l'ancien. pg_upgrade exige la
spécification des anciens et des nouveaux répertoires de
données et des exécutables (bin
). Vous
pouvez aussi indiquer des valeurs pour les utilisateurs et les
ports, et si vous voulez que les fichiers de données soient liées ou clonées
plutôt que copiées (par défaut ce dernier).
Si vous utilisez le mode lien, la mise à jour sera beaucoup plus rapide
(pas de copie de fichiers) et utilisera moins d'espace disque, mais vous
ne serez plus en mesure d'accèder à votre ancienne instance une fois que
la nouvelle instance sera démarrée après la mise à jour. Le mode lien
exige également que le répertoire de données de l'ancienne et de la
nouvelle instance soient dans le même système de fichiers. (Les
tablespaces et pg_wal
peuvent être sur des systèmes
de fichiers différents.) Le mode de clonage fournit les mêmes avantages
au niveau vitesse et espace disque mais ne rend pas l'ancienne instance
inutilisable une fois que la nouvelle instance a été démarrée. Le mode de
clonage requiert aussi que les répertoires de données de l'ancienne et la
nouvelle instances soient dans le même système de fichiers. Ce mode est
seulement disponible sur certains systèmes d'exploitation et certains
systèmes de fichiers.
L'option --jobs
permet l'utilisation de plusieurs
cœurs CPU pour copier ou lier des fichiers, et pour sauvegarder
et recharger les schémas des bases de données en parallèle ;
un bon chiffre pour commencer est le maximum du nombre de cœurs
CPU et des tablespaces. Cette option peut réduire dramatiquement
le temps pour mettre à jour un serveur avec plusieurs bases de
données s'exécutant sur une machine multiprocesseur.
Pour les utilisateurs Windows, vous devez être connecté avec
un compte administrateur, et lancer un shell sous l'utilisateur
postgres
en positionnant le chemin correct :
RUNAS /USER:postgres "CMD.EXE" SET PATH=%PATH%;C:\Program Files\PostgreSQL\16\bin;
puis lancez pg_upgrade avec les répertoires entre guillemets, par exemple :
pg_upgrade.exe --old-datadir "C:/Program Files/PostgreSQL/12/data" --new-datadir "C:/Program Files/PostgreSQL/16/data" --old-bindir "C:/Program Files/PostgreSQL/12/bin" --new-bindir "C:/Program Files/PostgreSQL/16/bin"
Une fois démarré, pg_upgrade
vérifiera que les deux
instances sont compatibles avant d'effectuer la mise à jour. Vous pouvez
utiliser pg_upgrade --check
pour effectuer uniquement
la vérification, y compris si l'ancien serveur est actuellement en
fonctionnement. pg_upgrade --check
mettra également
en évidence les ajustements manuels nécessaires que vous aurez besoin de
faire après la mise à jour. Si vous désirez utiliser le mode lien ou le mode clone,
vous devriez indiquer l'option --link
ou --clone
avec l'option
--check
pour activer les vérifications spécifiques
au mode lien. pg_upgrade
doit avoir le droit
d'écrire dans le répertoire courant.
Évidemment, personne ne doit accèder aux instances pendant la mise à jour. pg_upgrade lance par défaut les serveurs sur le port 50432 pour éviter les connexions non désirées de clients. Vous pouvez utilisez le même numéro de port pour les deux instances lors d'une mise à jour car l'ancienne et la nouvelle instance ne fonctionneront pas en même temps. Cependant, lors de la vérification d'un ancien serveur en fonctionnement, l'ancien et le nouveau numéros de port doivent être différents.
Si une erreur survient lors de la restauration du schéma de la
base de données, pg_upgrade
quittera et vous
devrez revenir à l'ancienne instance comme décrit ci-dessous
(Étape 17). Pour réessayer
pg_upgrade
, vous aurez besoin de modifier
l'ancienne instance de telle manière que la restauration du
schéma par pg_upgrade réussisse. Si le problème est un module
contrib
, vous pourriez avoir besoin de
désinstaller le module contrib
de l'ancienne
instance et le réinstaller dans la nouvelle instance après la
mise à jour, en supposant que le module n'est pas utilisé pour
stocker des données utilisateur.
Mettez à jour les serveurs standby par réplication en flux et copie de journaux
Si vous utilisez le mode lien et avez des serveurs standby par réplication continue (voir Section 27.2.5) ou par copie des journaux de transactions (voir Section 27.2), vous pouvez suivre les étapes ci-dessous pour les mettre à jour rapidement. Vous ne lancerez pas pg_upgrade sur les serveurs standby, mais plutôt rsync sur le primaire. Ne démarrez encore aucun serveur.
Si vous n'utilisez pas le mode lien, n'avez pas ou ne voulez pas utiliser rsync, ou si vous voulez une solution plus simple, ignorez les instructions de cette section et recréez simplement les serveurs standbys une fois que pg_upgrade a terminé et que le nouveau primaire fonctionne de nouveau.
Installez les nouveaux binaires PostgreSQL sur les serveurs standy
Assurez-vous que les nouveaux binaires et fichiers de support sont installés sur tous les serveurs standby.
Assurez vous que les nouveaux répertoires de données sur les serveurs standby n'existent pas
Assurez vous que les nouveaux répertoires de données sur les serveurs standby n'existent pas ou sont vides. Si initdb a été lancé, détruisez les nouveaux répertoires de données des serveurs standby.
Installez les fichiers objets partagés d'extension
Installez les mêmes fichiers objets partagés d'extension sur les nouveaux serveurs standby que vous avez installé sur la nouvelle instance maître.
Arrêtez les serveurs standby
Si les serveurs standby sont encore lancés, arrêtez les maintenant en utilisant les instructions ci-dessus.
Sauvegardez les fichiers de configuration
Sauvegardez tous les fichiers de configuration des anciens serveurs
standby que vous avez besoin de conserver, par exemple
postgresql.conf
(et tout fichier qu'il inclut),
postgresql.auto.conf
,
pg_hba.conf
, dans la mesure où ceux-ci seront
réécrits ou supprimés dans l'étape suivante.
Lancez rsync
Lors de l'utilisation du mode lien, les serveurs standbys peuvent être rapidement mis à jour en utilisant rsync. Pour cela, à partir d'un répertoire du serveur primaire situé au-dessus des répertoires de l'ancienne et de la nouvelle instance de bases de données, exécutez cette commande sur le primaire pour chaque serveur standby :
rsync --archive --delete --hard-links --size-only --no-inc-recursive ancien_rep_config nouveau_rep_config repertoire_distant
où ancien_rep_config
et nouveau_rep_config
sont relatifs au répertoire courant du serveur primaire, et
repertoire_distant
est au-dessus
des ancien et nouveau répertoires des instances sur le serveur standby.
La structure des répertoires sous les répertoires spécifiés du primaire
et des secondaires doit correspondre. Consultez les pages du manuel de
rsync pour des détails sur la manière de
spécifier le répertoire distant, par exemple :
rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL/12 \ /opt/PostgreSQL/16 standby.example.com:/opt/PostgreSQL
Vous pouvez vérifier ce que la commande va faire en utilisant l'option
--dry-run
de rsync. Alors
que rsync doit être exécuté sur le primaire
pour au moins un serveur standby, il est possible d'exécuter
rsync sur un standby mis à jour pour mettre
à jour les autres standbys tant que le standby mis à jour n'est pas
démarré.
Cela enregistre les liens créés par le mode lien de pg_upgrade qui connecte les fichiers dans les ancienne et nouvelle instances du serveur primaire. Puis, il trouve les fichiers correspondant dans l'ancienne instance du standby et crée les liens pour eux dans la nouvelle instance du serveur standby. Les fichiers qui n'ont pas été liés sur le primaire sont copiés sur à partir du serveur primaire vers le serveur secondaire. (Ils sont généralement petits.) Ceci fournit des mises à jour rapides des serveurs secondaires. Malheureusement, rsync copie sans raison les fichiers associés aux tables temporaires et non journalisées parce que ces fichiers n'existent normalement pas sur les serveurs secondaires.
Si vous avez des tablespaces, vous aurez besoin de lancer une commande rsync similaire pour chaque répertoire de tablespace, par exemple :
rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_12_201909212 \ /vol1/pg_tblsp/PG_16_202307071 standby.example.com:/vol1/pg_tblsp
Si vous avez déplacé
pg_wal
en dehors des répertoires de
données, rsync doit être lancé
aussi sur ces répertoires.
Configurez les serveurs standby par réplication en flux et par copie de fichiers
Configurez les serveurs pour les copies des fichiers
de transactions. (Vous n'avez pas besoin d'exécuter
les fonctions pg_backup_start()
et
pg_backup_stop()
ou effectuer une sauvegarde
des fichiers car les secondaires sont toujours synchronisés avec
le primaire.) Les slots de réplication ne sont pas copiés et doivent
être créés de nouveau.
Restaurez pg_hba.conf
Si vous avez modifié pg_hba.conf
,
restaurez cette configuration d'origine. Il peut être aussi
nécessaire d'ajuster d'autres fichiers de configuration dans la
nouvelle instance pour correspondre à l'ancienne instance, par exemple
postgresql.conf
(et tout fichier qu'il inclut),
postgresql.auto.conf
.
Démarrez le nouveau serveur
Le nouveau serveur peut maintenant être démarré en toute sécurité, puis les autres serveurs standby synchronisés avec rsync.
Traitements après mise à jour
Si des traitements après mise à jour sont nécessaires, pg_upgrade affichera des avertissements lors de son travail. Il générera également des scripts qui devront être lancés par l'administrateur. Les scripts se connecteront à chaque base de données qui ont besoin de traitements après mise à jour. Chaque script devrait être lancé comme suit :
psql --username=postgres --file=script.sql postgres
Les scripts peuvvent être lancés dans n'importe quel ordre et détruits une fois terminés.
Généralement, il n'est pas sûr d'accèder des tables référencées dans les scripts de reconstruction avant la fin de leurs traitements ; le faire pourrait entraîner des résultats incorrects ou de médiocres performances. Les tables non référencées dans les scripts de reconstruction peuvent être accédées immédiatement.
Statistiques
Parce que les statistiques de l'optimiseur ne sont pas transférées
par pg_upgrade
, vous serez invités à lancer
une commande pour regénérer les statistiques à la fin de la mise
à jour. Vous pourriez avoir besoin de positionner les paramètres
de connexion pour qu'ils correspondent à votre nouvelle instance.
Détruire les anciennes instances
Une fois que vous êtes satisfait de la mise à jour, vous pouvez
détruire les répertoires de données des anciennes instances en
lançant le script indiqué par pg_upgrade
à la fin de son traitement. (La destruction automatique n'est
pas possible si vous avez défini des tablespaces personnalisés
dans l'ancien répertoire de données.) Vous pouvez également
supprimer les anciens répertoires d'installation (par exemple
bin
, share
).
Revenir à l'ancienne instance
Si, après avoir lancé pg_upgrade
, vous désirez
revenir à l'ancienne instance, il y a plusieurs options :
Si l'option --check
a été utilisée, l'ancienne
instance n'a pas été modifiée, elle peut être redémarrée.
Si l'option --link
n'a pas été
utilisée, l'ancienne instance n'a pas été modifiée, elle peut être
redémarrée.
Si l'option --link
a été utilisée, les fichiers de
données pourraient être partagés entre l'ancienne instance et la
nouvelle :
Si pg_upgrade
a annulé avant de réaliser les
liens, l'ancienne instance n'a pas été modifiée, elle peut être
redémarrée.
Si vous n'avez pas démarré la nouvelle
instance, l'ancienne instance n'a pas été modifiée sauf, quand les
liens ont commencé, un suffixe .old
a été ajouté
au fichier $PGDATA/global/pg_control
. Pour
utiliser de nouveau l'ancienne instance, supprimez le suffixe
.old
du fichier
$PGDATA/global/pg_control
; vous pouvez
alors redémarrer l'ancienne instance.
Si vous avez démarré la nouvelle instance, elle a écrit dans des fichiers partagés et il est dangereux d'utiliser l'ancienne instance. Cette dernière doit être restaurée d'une sauvegarde dans ce cas.
pg_upgrade crée différents fichiers de travail,
tel que des sauvegardes de schémas, enregistré dans le sous-répertoire
pg_upgrade_output.d
du répertoire principal de la nouvelle
instance. Chaque exécution crée un sous-répertoire nommé avec un horodatage
formaté d'après ISO 8601 (%Y%m%dT%H%M%S
), où tous ses
fichiers générés sont stockés.
pg_upgrade_output.d
et ses fichiers seront supprimés
automatiquement si pg_upgrade se termine
avec succès ; en cas de problème, ses fichiers pourraient fournir
des informations de debug très utiles.
pg_upgrade lance brièvement les serveurs dans
les ancien et nouveau répertoires de données. Les fichiers temporaires des
sockets Unix pour communiquer avec ces serveurs sont, par défaut, créés
dans le répertoire courant. Dans certaines situations, le nom du chemin
pour le répertoire courant pourrait être trop long pour être un nom de
socket valide. Dans ce cas, vous pouvez utiliser l'option
-s
pour placer les fichiers socket dans un autre
répertoire dont le nom du chemin est plus court. Pour des raisons de
sécurité, assurez-vous que le répertoire n'est ni lisible ni modifiable par
les autres utilisateurs. (Ceci n'est pas applicable à Windows.)
Tous les échecs, reconstructions et réindexations seront reportés par pg_upgrade s'ils affectent votre installation ; les scripts d'après mise à jour pour reconstruire les tables et index seront générés automatiquement. Si vous essayez d'automatiser la mise à jour de plusieurs instances, vous devriez constater que les instances avec des schémas de bases de données identiques ont besoin des mêmes étapes après mise à jour ; car les étapes après mise à jour sont basées sur les schémas des bases de données, et pas sur les données utilisateurs.
Pour les déploiements de tests, créez uniquement une copie du schéma de l'ancienne instance, insérez des données de tests, et faites la mise à jour.
pg_upgrade ne supporte pas la mise à jour de
bases de données contenant des colonnes de table utilisant les types de
données systèmes référençant les OID, nommés reg*
:
regcollation |
regconfig |
regdictionary |
regnamespace |
regoper |
regoperator |
regproc |
regprocedure |
(regclass
, regrole
et regtype
peuvent
être mis à jour.)
Si vous souhaitez utiliser le mode lien et ne voulez pas que
votre ancienne instance ne soit modifiée lorsque la nouvelle instance est
démarré, considérez l'utilisation du mode clone. Si ce n'est pas possible,
faites une copie de l'ancienne instance et faites la mise
à jour à partir de cette copie. Pour faire une copie valide de
l'ancienne instance, utilisez rsync
pour effectuer une
copie grossière de l'ancienne instance lancée, puis arrêtez l'ancien
serveur et lancez rsync --checksum
à nouveau
pour mettre à jour la copie dans un état cohérent avec tous les
changements. (L'option --checksum
est nécessaire
car rsync
n'a une granularité sur les dates de
modification de fichiers que d'une seconde.) Vous pourriez souhaiter
exclure certains fichiers, par exemple postmaster.pid
,
comme documenté à Section 26.3.3. Si
votre système de fichiers supporte les images de système de fichiers
ou la fonctionnalité Copy-On-Write, vous pouvez utiliser ces
fonctionnalités pour faire une sauvegarde de l'ancienne instance et
des tablespaces, bien que l'image et les copies doivent être créées
simultanément ou lorsque le serveur de bases de données est éteint.