

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)
<a name="phase2"></a>

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.

1. Créez une sauvegarde incrémentielle à partir de la base de données source.

1. Transférez la sauvegarde vers le système de destination.

1. Convertissez la sauvegarde au format endian du système de destination.

1. Appliquez la sauvegarde aux copies du fichier de données de destination converti pour les transférer vers l'avant.

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
<a name="phase2-step1"></a>

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
<a name="phase2-step2"></a>

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
<a name="phase2-step3"></a>

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'`--restore`option 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`.

****

1. Commentez les lignes suivantes :
   + Ligne 4867 : ` my $outputstart = `sqlplus -L -s \"/ as sysdba\" \@xttstartupnomount.sql`;`
   + Ligne 4868 : ` checkError ("Error in executing xttstartupnomount.sql", $outputstart);`
   + Ligne 4992 : ` my $outputstart = `sqlplus -L -s \"/ as sysdba\" \@xttdbopen.sql`;\`

1. Définissez le `NOMOUNT` statut de la base de données cible.

   ```
   sqlplus / as sysdba @xttstartupnomount.sql
   ```

1. Effectuez un report des sauvegardes incrémentielles en parallèle.

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

1. Après avoir reporté toutes les sauvegardes incrémentielles, définissez le `OPEN` statut de la base de données cible.

   ```
   sqlplus / as sysdba @xttdbopen.sql
   ```

À 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` `PROCEDURE``FUNCTION`, 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 sur`READ ONLY`. Pour le moment, vous devez conserver les objets source de base de données tels que `PACKAGE``PROCEDURE`, 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_SPEC``PACKAGE_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 sauf`SYSTEM`, `SYSAUX``UNDO`, 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 de`SYSTEM`, `SYSAUX``UNDO`, et. `TEMP` L'`USER`objet 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.