Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Phase 2 — Phase de reconduction (la base de données source reste en ligne)

Vous pouvez répéter la phase de roll-forward autant de fois que nécessaire pour récupérer le fichier de données de destination dans la base de données source.

La phase de roll-forward comprend les étapes suivantes.

Chaque sauvegarde incrémentielle successive devrait prendre moins de temps et permettra de mettre les copies du fichier de données de destination à jour par rapport à la base de données source.

Étape 1 : effectuer des sauvegardes incrémentielles en parallèle

Effectuez des sauvegardes incrémentielles des groupes de tablespaces transportés sur le système source en parallèle.

Cette étape crée des sauvegardes incrémentielles pour tous les tablespaces= répertoriés dans le fichier. xtt.properties

Si vous pouvez activer la fonction BLOCK CHANGE TRACKING sur le système source, vous pouvez réduire considérablement la durée de la sauvegarde incrémentielle.

La commande suivante reconnaît automatiquement le SCN suivant après la sauvegarde complète.

cd /u01/oracle/expimp/xtt<nn>
export TMPDIR=/u01/oracle/expimp/out/out<nn>
$ORACLE_HOME/perl/bin/perl xttdriver.pl --backup --debug 3

Étape 2 : transférer les sauvegardes incrémentielles et le fichier res.txt vers le système de destination

Si vous disposez de suffisamment de bande passante, vous pouvez réduire la durée du transfert en utilisant Direct Connect.

Transférez les sauvegardes incrémentielles entre src_scratch_location et. dest_scratch_location Transférez le res.txt fichier entre $TMPDIR le système source et $TMPDIR le système de destination.

Si vous effectuez plusieurs sauvegardes incrémentielles, le res.txt fichier doit être copié après la dernière sauvegarde incrémentielle avant de pouvoir être appliqué au système de destination.

[source]$ scp $TMPDIR/res.txt oracle@[dest]:/u01/oracle/expimp/out/out<nn>
[source]$ scp <src_scratch_location>/* oracle@[dest]:<dest_scratch_location>

Étape 3 : convertir et appliquer des sauvegardes incrémentielles

Convertissez les sauvegardes incrémentielles au format endian du système de destination et appliquez des sauvegardes incrémentielles aux copies des fichiers de données de destination sur le système de destination.

Dans ce guide, supposons que les groupes d'espaces disque logiques sont au nombre de quatre. Exécutez chaque xttdriver.pl commande avec l'--restoreoption correspondant à chaque groupe d'espaces de table.

Au cours de cette étape, l'utilitaire Oracle XTTS redémarre la base de données cible. Pour exécuter la commande en parallèle, vous devez utiliser la personnalisation suivante dans le script Perl,xttdriver.pl.

À ce stade, vous pouvez répéter la phase 2 jusqu'à ce que SCNs les bases de données source et de destination soient suffisamment proches. Vous devez décider de passer à la phase 3 ou de répéter la phase 2, en fonction du temps d'arrêt cible donné.

Pour réduire le temps d'arrêt pendant la phase 3 (phase de transport), vous pouvez exporter et importer les métadonnées d'objets non segmentés, tels que,, et USER PACKAGE PROCEDUREFUNCTION, avant de définir la base de données source en tant que. READ ONLY

Si le nombre d'objets de base de données dans la base de données source est extrêmement important (des centaines de milliers), l'exportation et l'importation des métadonnées prendront plusieurs heures. Dans ce cas, pensez à exporter les métadonnées.

L'exportation d'objets non segmentés est exécutée read/write sur le système source. Vous devez ensuite importer les objets dans le système de destination avant que le système source ne soit défini surREAD ONLY. Pour le moment, vous devez conserver les objets source de base de données tels que PACKAGEPROCEDURE, et FUNCTION inchangés.

Il s'agit d'un exemple du fichier de paramètres de vidage utilisé pour exporter les métadonnées d'objets non segmentés, notamment,USER, PACKAGE_SPECPACKAGE_BODY, PROCEDURE et. FUNCTION

directory=dmpdir
dumpfile=xttsmsc%U.dmp
full=y
filesize=1048576000
logfile=expmsc.log
metrics=y
exclude=TABLE,INDEX,CONSTRAINT,COMMENT,
MATERIALIZED_VIEW,MATERIALIZED_VIEW_LOG,SCHEMA_CALLOUT

Utilisez la commande suivante pour exporter les métadonnées.

SQL> create directory dmpdir as <location>;
expdp system/<system password> parfile=<parameter file>

Il s'agit d'un exemple de fichier de paramètres de vidage permettant d'importer les métadonnées d'objets non segmentés.

directory=dmpdir
dumpfile=xttsmsc%U.dmp
full=y
logfile=impmsc1.log
EXCLUDE=TABLESPACE, PROCOBJ, RLS_CONTEXT, RLS_GROUP, RLS_POLICY, TABLESPACE_QUOTA
metrics=y
remap_tablespace=
APPS_TS_ARCHIVE:SYSTEM,
APPS_TS_INTERFACE:SYSTEM,
APPS_TS_SEED:SYSTEM,
APPS_TS_SUMMARY:SYSTEM,
…..

À l'heure actuelle, il n'existe aucun tablespace saufSYSTEM, SYSAUXUNDO, et TEMP sur le système de destination. Vous devez donc remapper tous les objets à importer dans le SYSTEM tablespace.

Utilisez la commande suivante pour importer des métadonnées.

SQL> create directory dmpdir as <location>;
impdp system/<system password> parfile=<parameter file>

Vous pouvez maintenant voir les objets créés dans la base de données de destination.

SQL> select object_type, count(*) from dba_objects group by object_type order by count(*) desc;
OBJECT_TYPE                  COUNT(*)
------------------------------- ----------
SYNONYM                          89327
PACKAGE                           55670
PACKAGE BODY                  54447
VIEW                                 41378
JAVA CLASS                        31978
SEQUENCE                         12766
…..

Il n'existe aucun tablespace à l'exception deSYSTEM, SYSAUXUNDO, et. TEMP L'USERobjet est créé avec USERS comme tablespace par défaut. Au cours de la phase 3, les tablespaces transportables seront créés, puis les objets USER seront modifiés avec les tablespaces par défaut d'origine.