Skip to main content
Enterprise applications
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Copie des données hôte de la base de données Oracle

Contributeurs

À l'instar de la migration au niveau des bases de données, la migration au niveau de la couche hôte offre une approche indépendante du fournisseur de stockage.

En d'autres termes, parfois "juste copier les fichiers" est la meilleure option.

Bien que cette approche peu technologique puisse sembler trop basique, elle offre des avantages significatifs, car aucun logiciel spécial n'est requis et les données d'origine ne sont pas modifiées en toute sécurité pendant le processus. La principale limitation est le fait qu'une migration de données de copie de fichier est un processus perturbateur, car la base de données doit être arrêtée avant le début de l'opération de copie. Il n'y a pas de bonne façon de synchroniser les modifications dans un fichier, de sorte que les fichiers doivent être complètement suspendus avant le début de la copie.

Si l'arrêt requis par une opération de copie n'est pas souhaitable, la meilleure option basée sur l'hôte suivante consiste à exploiter un gestionnaire de volumes logiques (LVM). De nombreuses options LVM existent, y compris Oracle ASM, toutes avec des capacités similaires, mais avec certaines limitations qui doivent être prises en compte. Dans la plupart des cas, la migration peut s'effectuer sans interruption ni perturbation.

Copie du système de fichiers vers le système de fichiers

L'utilité d'une simple opération de copie ne doit pas être sous-estimée. Cette opération requiert un temps d'indisponibilité lors de la copie, mais le processus est extrêmement fiable et ne requiert aucune expertise particulière en matière de systèmes d'exploitation, de bases de données ou de systèmes de stockage. De plus, elle est très sûre car elle n'affecte pas les données d'origine. Généralement, un administrateur système modifie les systèmes de fichiers source pour qu'ils soient montés en lecture seule, puis redémarre un serveur pour garantir que rien ne risque d'endommager les données actuelles. Le processus de copie peut être scripté pour s'assurer qu'il s'exécute aussi rapidement que possible sans risque d'erreur de l'utilisateur. Comme le type d'E/S est un simple transfert séquentiel de données, il est très peu gourmand en bande passante.

L'exemple suivant illustre une option pour une migration sûre et rapide.

De production

L'environnement à migrer est le suivant :

  • Systèmes de fichiers actuels

    ontap-nfs1:/host1_oradata       52428800  16196928  36231872  31% /oradata
    ontap-nfs1:/host1_logs          49807360    548032  49259328   2% /logs
  • Nouveaux systèmes de fichiers

    ontap-nfs1:/host1_logs_new      49807360       128  49807232   1% /new/logs
    ontap-nfs1:/host1_oradata_new   49807360       128  49807232   1% /new/oradata

Présentation

Il suffit à l'administrateur de bases de données de fermer la base de données et de copier les fichiers pour migrer la base de données. Toutefois, ce processus peut être facilement scripté si de nombreuses bases de données doivent être migrées ou si la réduction des temps d'indisponibilité est essentielle. L'utilisation de scripts réduit également les risques d'erreur de l'utilisateur.

Les exemples de scripts présentés automatisent les opérations suivantes :

  • Arrêt de la base de données

  • Conversion des systèmes de fichiers existants en état de lecture seule

  • Copie de toutes les données de la source vers les systèmes de fichiers cibles, ce qui préserve toutes les autorisations de fichier

  • Démontage de l'ancien et du nouveau système de fichiers

  • Remontage des nouveaux systèmes de fichiers aux mêmes chemins que les systèmes de fichiers précédents

Procédure

  1. Arrêtez la base de données.

    [root@host1 current]# ./dbshut.pl NTAP
    ORACLE_SID = [oracle] ? The Oracle base has been set to /orabin
    SQL*Plus: Release 12.1.0.2.0 Production on Thu Dec 3 15:58:48 2015
    Copyright (c) 1982, 2014, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
    SQL> Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL> Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
    NTAP shut down
  2. Convertissez les systèmes de fichiers en lecture seule. Ceci peut être effectué plus rapidement en utilisant un script, comme indiqué dans la "Convertir le système de fichiers en lecture seule".

    [root@host1 current]# ./mk.fs.readonly.pl /oradata
    /oradata unmounted
    /oradata mounted read-only
    [root@host1 current]# ./mk.fs.readonly.pl /logs
    /logs unmounted
    /logs mounted read-only
  3. Vérifiez que les systèmes de fichiers sont maintenant en lecture seule.

    ontap-nfs1:/host1_oradata on /oradata type nfs (ro,bg,vers=3,rsize=65536,wsize=65536,addr=172.20.101.10)
    ontap-nfs1:/host1_logs on /logs type nfs (ro,bg,vers=3,rsize=65536,wsize=65536,addr=172.20.101.10)
  4. Synchroniser le contenu du système de fichiers avec le rsync commande.

    [root@host1 current]# rsync -rlpogt --stats --progress --exclude=.snapshot /oradata/ /new/oradata/
    sending incremental file list
    ./
    NTAP/
    NTAP/IOPS.dbf
     10737426432 100%  153.50MB/s    0:01:06 (xfer#1, to-check=10/13)
    NTAP/iops.dbf.zip
        22823573 100%   12.09MB/s    0:00:01 (xfer#2, to-check=9/13)
    ...
    NTAP/undotbs02.dbf
      1073750016 100%  131.60MB/s    0:00:07 (xfer#10, to-check=1/13)
    NTAP/users01.dbf
         5251072 100%    3.95MB/s    0:00:01 (xfer#11, to-check=0/13)
    Number of files: 13
    Number of files transferred: 11
    Total file size: 18570092218 bytes
    Total transferred file size: 18570092218 bytes
    Literal data: 18570092218 bytes
    Matched data: 0 bytes
    File list size: 277
    File list generation time: 0.001 seconds
    File list transfer time: 0.000 seconds
    Total bytes sent: 18572359828
    Total bytes received: 228
    sent 18572359828 bytes  received 228 bytes  162204017.96 bytes/sec
    total size is 18570092218  speedup is 1.00
    [root@host1 current]# rsync -rlpogt --stats --progress --exclude=.snapshot /logs/ /new/logs/
    sending incremental file list
    ./
    NTAP/
    NTAP/1_22_897068759.dbf
        45523968 100%   95.98MB/s    0:00:00 (xfer#1, to-check=15/18)
    NTAP/1_23_897068759.dbf
        40601088 100%   49.45MB/s    0:00:00 (xfer#2, to-check=14/18)
    ...
    NTAP/redo/redo02.log
        52429312 100%   44.68MB/s    0:00:01 (xfer#12, to-check=1/18)
    NTAP/redo/redo03.log
        52429312 100%   68.03MB/s    0:00:00 (xfer#13, to-check=0/18)
    Number of files: 18
    Number of files transferred: 13
    Total file size: 527032832 bytes
    Total transferred file size: 527032832 bytes
    Literal data: 527032832 bytes
    Matched data: 0 bytes
    File list size: 413
    File list generation time: 0.001 seconds
    File list transfer time: 0.000 seconds
    Total bytes sent: 527098156
    Total bytes received: 278
    sent 527098156 bytes  received 278 bytes  95836078.91 bytes/sec
    total size is 527032832  speedup is 1.00
  5. Démontez les anciens systèmes de fichiers et déplacez les données copiées. Ceci peut être effectué plus rapidement en utilisant un script, comme indiqué dans la "Remplacer le système de fichiers".

    [root@host1 current]# ./swap.fs.pl /logs,/new/logs
    /new/logs unmounted
    /logs unmounted
    Updated /logs mounted
    [root@host1 current]# ./swap.fs.pl /oradata,/new/oradata
    /new/oradata unmounted
    /oradata unmounted
    Updated /oradata mounted
  6. Vérifiez que les nouveaux systèmes de fichiers sont en place.

    ontap-nfs1:/host1_logs_new on /logs type nfs (rw,bg,vers=3,rsize=65536,wsize=65536,addr=172.20.101.10)
    ontap-nfs1:/host1_oradata_new on /oradata type nfs (rw,bg,vers=3,rsize=65536,wsize=65536,addr=172.20.101.10)
  7. Démarrez la base de données.

    [root@host1 current]# ./dbstart.pl NTAP
    ORACLE_SID = [oracle] ? The Oracle base has been set to /orabin
    SQL*Plus: Release 12.1.0.2.0 Production on Thu Dec 3 16:10:07 2015
    Copyright (c) 1982, 2014, Oracle.  All rights reserved.
    Connected to an idle instance.
    SQL> ORACLE instance started.
    Total System Global Area  805306368 bytes
    Fixed Size                  2929552 bytes
    Variable Size             390073456 bytes
    Database Buffers          406847488 bytes
    Redo Buffers                5455872 bytes
    Database mounted.
    Database opened.
    SQL> Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
    NTAP started

Mise en service entièrement automatisée

Cet exemple de script accepte les arguments du SID de la base de données suivis de paires de systèmes de fichiers délimitées par des points communs. Pour l'exemple ci-dessus, la commande est émise comme suit :

[root@host1 current]# ./migrate.oracle.fs.pl NTAP /logs,/new/logs /oradata,/new/oradata

Lorsqu'il est exécuté, l'exemple de script tente d'exécuter la séquence suivante. Il se termine s'il rencontre une erreur dans une étape :

  1. Arrêtez la base de données.

  2. Convertissez les systèmes de fichiers actuels en mode lecture seule.

  3. Utilisez chaque paire d'arguments de système de fichiers délimités par des virgules et synchronisez le premier système de fichiers avec le second.

  4. Démonter les systèmes de fichiers précédents.

  5. Mettez à jour le /etc/fstab classer comme suit :

    1. Créez une sauvegarde à /etc/fstab.bak.

    2. Commenter les entrées précédentes pour les systèmes de fichiers antérieurs et nouveaux.

    3. Créez une nouvelle entrée pour le nouveau système de fichiers qui utilise l'ancien point de montage.

  6. Montez les systèmes de fichiers.

  7. Démarrez la base de données.

Le texte suivant fournit un exemple d'exécution pour ce script :

[root@host1 current]# ./migrate.oracle.fs.pl NTAP /logs,/new/logs /oradata,/new/oradata
ORACLE_SID = [oracle] ? The Oracle base has been set to /orabin
SQL*Plus: Release 12.1.0.2.0 Production on Thu Dec 3 17:05:50 2015
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
NTAP shut down
sending incremental file list
./
NTAP/
NTAP/1_22_897068759.dbf
    45523968 100%  185.40MB/s    0:00:00 (xfer#1, to-check=15/18)
NTAP/1_23_897068759.dbf
    40601088 100%   81.34MB/s    0:00:00 (xfer#2, to-check=14/18)
...
NTAP/redo/redo02.log
    52429312 100%   70.42MB/s    0:00:00 (xfer#12, to-check=1/18)
NTAP/redo/redo03.log
    52429312 100%   47.08MB/s    0:00:01 (xfer#13, to-check=0/18)
Number of files: 18
Number of files transferred: 13
Total file size: 527032832 bytes
Total transferred file size: 527032832 bytes
Literal data: 527032832 bytes
Matched data: 0 bytes
File list size: 413
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 527098156
Total bytes received: 278
sent 527098156 bytes  received 278 bytes  150599552.57 bytes/sec
total size is 527032832  speedup is 1.00
Succesfully replicated filesystem /logs to /new/logs
sending incremental file list
./
NTAP/
NTAP/IOPS.dbf
 10737426432 100%  176.55MB/s    0:00:58 (xfer#1, to-check=10/13)
NTAP/iops.dbf.zip
    22823573 100%    9.48MB/s    0:00:02 (xfer#2, to-check=9/13)
... NTAP/undotbs01.dbf
   309338112 100%   70.76MB/s    0:00:04 (xfer#9, to-check=2/13)
NTAP/undotbs02.dbf
  1073750016 100%  187.65MB/s    0:00:05 (xfer#10, to-check=1/13)
NTAP/users01.dbf
     5251072 100%    5.09MB/s    0:00:00 (xfer#11, to-check=0/13)
Number of files: 13
Number of files transferred: 11
Total file size: 18570092218 bytes
Total transferred file size: 18570092218 bytes
Literal data: 18570092218 bytes
Matched data: 0 bytes
File list size: 277
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 18572359828
Total bytes received: 228
sent 18572359828 bytes  received 228 bytes  177725933.55 bytes/sec
total size is 18570092218  speedup is 1.00
Succesfully replicated filesystem /oradata to /new/oradata
swap 0 /logs /new/logs
/new/logs unmounted
/logs unmounted
Mounted updated /logs
Swapped filesystem /logs for /new/logs
swap 1 /oradata /new/oradata
/new/oradata unmounted
/oradata unmounted
Mounted updated /oradata
Swapped filesystem /oradata for /new/oradata
ORACLE_SID = [oracle] ? The Oracle base has been set to /orabin
SQL*Plus: Release 12.1.0.2.0 Production on Thu Dec 3 17:08:59 2015
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Connected to an idle instance.
SQL> ORACLE instance started.
Total System Global Area  805306368 bytes
Fixed Size                  2929552 bytes
Variable Size             390073456 bytes
Database Buffers          406847488 bytes
Redo Buffers                5455872 bytes
Database mounted.
Database opened.
SQL> Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
NTAP started
[root@host1 current]#

Migration Oracle ASM spfile et passwd

Le fichier spfile spécifique à ASM et le fichier de mots de passe constituent une difficulté pour terminer la migration impliquant ASM. Par défaut, ces fichiers de métadonnées critiques sont créés sur le premier groupe de disques ASM défini. Si un groupe de disques ASM particulier doit être évacué et supprimé, le fichier spfile et le fichier de mot de passe qui régissent cette instance ASM doivent être déplacés.

Un autre cas d'utilisation où il peut être nécessaire de déplacer ces fichiers est le cas lors du déploiement d'un logiciel de gestion de base de données, tel que SnapManager pour Oracle ou le plug-in SnapCenter pour Oracle. L'une des fonctionnalités de ces produits consiste à restaurer rapidement une base de données en rétablissant l'état des LUN ASM qui hébergent les fichiers de données. Pour ce faire, vous devez mettre le groupe de disques ASM hors ligne avant d'effectuer une restauration. Ce n'est pas un problème tant que les fichiers de données d'une base de données donnée sont isolés dans un groupe de disques ASM dédié.

Lorsque ce groupe de disques contient également le fichier ASM spfile/passwd, la seule façon de mettre le groupe de disques hors ligne est d'arrêter l'instance ASM entière. Il s'agit d'un processus perturbateur, ce qui signifie que le fichier spfile/passwd doit être déplacé.

De production

  1. SID de base de données = TOAST

  2. Fichiers de données actuels sur +DATA

  3. Fichiers journaux et fichiers de contrôle actuels sur +LOGS

  4. Nouveaux groupes de disques ASM définis en tant que +NEWDATA et +NEWLOGS

Emplacements des fichiers spfile/passwd ASM

La migration de ces fichiers peut s'effectuer sans interruption. Cependant, pour des raisons de sécurité, NetApp recommande de fermer l'environnement de base de données afin de vous assurer que les fichiers ont été déplacés et que la configuration est correctement mise à jour. Cette procédure doit être répétée si plusieurs instances ASM sont présentes sur un serveur.

Identifier les instances ASM

Identifier les instances ASM en fonction des données enregistrées dans le oratab fichier. Les instances ASM sont signalées par un symbole +.

-bash-4.1$ cat /etc/oratab | grep '^+'
+ASM:/orabin/grid:N             # line added by Agent

Il existe une instance ASM appelée +ASM sur ce serveur.

Assurez-vous que toutes les bases de données sont arrêtées

Le seul processus smon visible doit être le smon de l'instance ASM utilisée. La présence d'un autre processus smon indique qu'une base de données est toujours en cours d'exécution.

-bash-4.1$ ps -ef | grep smon
oracle     857     1  0 18:26 ?        00:00:00 asm_smon_+ASM

Le seul processus smon est l'instance ASM elle-même. Cela signifie qu'aucune autre base de données n'est en cours d'exécution et que vous pouvez continuer en toute sécurité sans risque d'interruption des opérations de la base de données.

Localisez les fichiers

Identifiez l'emplacement actuel du fichier spfile et du fichier de mots de passe ASM à l'aide du spget et pwget commandes.

bash-4.1$ asmcmd
ASMCMD> spget
+DATA/spfile.ora
ASMCMD> pwget --asm
+DATA/orapwasm

Les fichiers se trouvent tous deux à la base du +DATA groupe de disques.

Copier des fichiers

Copiez les fichiers dans le nouveau groupe de disques ASM avec le spcopy et pwcopy commandes. Si le nouveau groupe de disques a été créé récemment et est actuellement vide, il peut être nécessaire de le monter en premier.

ASMCMD> mount NEWDATA
ASMCMD> spcopy +DATA/spfile.ora +NEWDATA/spfile.ora
copying +DATA/spfile.ora -> +NEWDATA/spfilea.ora
ASMCMD> pwcopy +DATA/orapwasm +NEWDATA/orapwasm
copying +DATA/orapwasm -> +NEWDATA/orapwasm

Les fichiers ont été copiés depuis +DATA à +NEWDATA.

Mettre à jour l'instance ASM

L'instance ASM doit maintenant être mise à jour pour refléter le changement d'emplacement. Le spset et pwset Les commandes mettent à jour les métadonnées ASM requises pour démarrer le groupe de disques ASM.

ASMCMD> spset +NEWDATA/spfile.ora
ASMCMD> pwset --asm +NEWDATA/orapwasm

Activez ASM à l'aide de fichiers mis à jour

À ce stade, l'instance ASM utilise toujours les emplacements précédents de ces fichiers. L'instance doit être redémarrée pour forcer une relecture des fichiers à partir de leurs nouveaux emplacements et pour libérer les verrous sur les fichiers précédents.

-bash-4.1$ sqlplus / as sysasm
SQL> shutdown immediate;
ASM diskgroups volume disabled
ASM diskgroups dismounted
ASM instance shutdown
SQL> startup
ASM instance started
Total System Global Area 1140850688 bytes
Fixed Size                  2933400 bytes
Variable Size            1112751464 bytes
ASM Cache                  25165824 bytes
ORA-15032: not all alterations performed
ORA-15017: diskgroup "NEWDATA" cannot be mounted
ORA-15013: diskgroup "NEWDATA" is already mounted

Supprimez les anciens fichiers spfile et les anciens fichiers de mots de passe

Si la procédure a été effectuée avec succès, les fichiers précédents ne sont plus verrouillés et peuvent maintenant être supprimés.

-bash-4.1$ asmcmd
ASMCMD> rm +DATA/spfile.ora
ASMCMD> rm +DATA/orapwasm

Copie d'Oracle ASM vers ASM

Oracle ASM est essentiellement un gestionnaire de volumes combiné léger et un système de fichiers. Comme le système de fichiers n'est pas facilement visible, RMAN doit être utilisé pour effectuer des opérations de copie. Même si un processus de migration basé sur la copie est sûr et simple, il provoque certaines perturbations. Les interruptions peuvent être minimisées, mais pas totalement éliminées.

Si vous souhaitez effectuer une migration sans interruption d'une base de données ASM, il est préférable d'exploiter la capacité d'ASM à rééquilibrer les extensions ASM vers de nouveaux LUN lors de la suppression des anciennes LUN. Cette opération est généralement sûre et non disruptive, mais elle n'offre pas de chemin « back-out ». En cas de problèmes fonctionnels ou de performances, la seule option consiste à migrer les données vers la source.

Ce risque peut être évité en copiant la base de données vers le nouvel emplacement plutôt que de déplacer les données, afin que les données d'origine ne soient pas modifiées. La base de données peut être entièrement testée à son nouvel emplacement avant la mise en service, et la base de données d'origine est disponible comme option de retour en arrière si des problèmes sont détectés.

Cette procédure est l'une des nombreuses options impliquant RMAN. Il est conçu pour permettre un processus en deux étapes dans lequel la sauvegarde initiale est créée, puis synchronisée par la suite via la relecture du journal. Ce processus est recommandé pour réduire les temps d'indisponibilité, car il permet à la base de données de rester opérationnelle et d'assurer l'accès aux données pendant la copie de base initiale.

Copier la base de données

Oracle RMAN crée une copie de niveau 0 (complète) de la base de données source actuellement située sur le groupe de disques ASM +DATA vers le nouvel emplacement sur +NEWDATA.

-bash-4.1$ rman target /
Recovery Manager: Release 12.1.0.2.0 - Production on Sun Dec 6 17:40:03 2015
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
connected to target database: TOAST (DBID=2084313411)
RMAN> backup as copy incremental level 0 database format '+NEWDATA' tag 'ONTAP_MIGRATION';
Starting backup at 06-DEC-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=302 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=+DATA/TOAST/DATAFILE/system.262.897683141
...
input datafile file number=00004 name=+DATA/TOAST/DATAFILE/users.264.897683151
output file name=+NEWDATA/TOAST/DATAFILE/users.258.897759623 tag=ONTAP_MIGRATION RECID=5 STAMP=897759622
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental level 0 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 06-DEC-15
channel ORA_DISK_1: finished piece 1 at 06-DEC-15
piece handle=+NEWDATA/TOAST/BACKUPSET/2015_12_06/nnsnn0_ontap_migration_0.262.897759623 tag=ONTAP_MIGRATION comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 06-DEC-15

Forcer le changement de journal d'archivage

Vous devez forcer un commutateur de journal d'archivage pour vous assurer que les journaux d'archivage contiennent toutes les données nécessaires pour que la copie soit totalement cohérente. Sans cette commande, les données clés peuvent toujours être présentes dans les journaux de reprise.

RMAN> sql 'alter system archive log current';
sql statement: alter system archive log current

Arrêtez la base de données source

L'interruption commence à cette étape car la base de données est arrêtée et placée en mode lecture seule à accès limité. Pour arrêter la base de données source, exécutez les commandes suivantes :

RMAN> shutdown immediate;
using target database control file instead of recovery catalog
database closed
database dismounted
Oracle instance shut down
RMAN> startup mount;
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area     805306368 bytes
Fixed Size                     2929552 bytes
Variable Size                390073456 bytes
Database Buffers             406847488 bytes
Redo Buffers                   5455872 bytes

Sauvegarde Controlfile

Vous devez sauvegarder le fichier de contrôle si vous devez abandonner la migration et revenir à l'emplacement de stockage d'origine. Une copie du fichier de contrôle de sauvegarde n'est pas nécessaire à 100 %, mais elle facilite le processus de réinitialisation des emplacements des fichiers de base de données vers leur emplacement d'origine.

RMAN> backup as copy current controlfile format '/tmp/TOAST.ctrl';
Starting backup at 06-DEC-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=358 device type=DISK
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=/tmp/TOAST.ctrl tag=TAG20151206T174753 RECID=6 STAMP=897760073
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 06-DEC-15

Mises à jour des paramètres

Le fichier spfile actuel contient des références aux fichiers de contrôle sur leurs emplacements actuels dans l'ancien groupe de disques ASM. Il doit être édité, ce qui est facile à faire en éditant une version intermédiaire de pfile.

RMAN> create pfile='/tmp/pfile' from spfile;
Statement processed

Mettre à jour le fichier pfile

Mettez à jour tous les paramètres faisant référence aux anciens groupes de disques ASM pour refléter les nouveaux noms de groupes de disques ASM. Enregistrez ensuite le fichier pfile mis à jour. Assurez-vous que le db_create des paramètres sont présents.

Dans l'exemple ci-dessous, les références à +DATA ils ont été remplacés par +NEWDATA sont surlignés en jaune. Deux paramètres clés sont le db_create paramètres qui créent de nouveaux fichiers à l'emplacement correct.

*.compatible='12.1.0.2.0'
*.control_files='+NEWLOGS/TOAST/CONTROLFILE/current.258.897683139'
*.db_block_size=8192
*. db_create_file_dest='+NEWDATA'
*. db_create_online_log_dest_1='+NEWLOGS'
*.db_domain=''
*.db_name='TOAST'
*.diagnostic_dest='/orabin'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=TOASTXDB)'
*.log_archive_dest_1='LOCATION=+NEWLOGS'
*.log_archive_format='%t_%s_%r.dbf'

Mettre à jour le fichier init.ora

La plupart des bases de données ASM utilisent un init.ora fichier situé dans le $ORACLE_HOME/dbs Répertoire, qui est un point vers le fichier spfile sur le groupe de disques ASM. Ce fichier doit être redirigé vers un emplacement du nouveau groupe de disques ASM.

-bash-4.1$ cd $ORACLE_HOME/dbs
-bash-4.1$ cat initTOAST.ora
SPFILE='+DATA/TOAST/spfileTOAST.ora'

Modifiez ce fichier comme suit :

SPFILE=+NEWLOGS/TOAST/spfileTOAST.ora

Récréation du fichier de paramètres

Le fichier spfile est maintenant prêt à être rempli par les données du fichier pfile modifié.

RMAN> create spfile from pfile='/tmp/pfile';
Statement processed

Démarrez la base de données pour commencer à utiliser le nouveau fichier spfile

Démarrez la base de données pour vous assurer qu'elle utilise maintenant le fichier spfile nouvellement créé et que toute autre modification des paramètres système est correctement enregistrée.

RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area     805306368 bytes
Fixed Size                     2929552 bytes
Variable Size                373296240 bytes
Database Buffers             423624704 bytes
Redo Buffers                   5455872 bytes

Restaurer le fichier de contrôle

Le fichier de contrôle de sauvegarde créé par RMAN peut également être restauré directement par RMAN à l'emplacement spécifié dans le nouveau fichier spfile.

RMAN> restore controlfile from '+DATA/TOAST/CONTROLFILE/current.258.897683139';
Starting restore at 06-DEC-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=417 device type=DISK
channel ORA_DISK_1: copied control file copy
output file name=+NEWLOGS/TOAST/CONTROLFILE/current.273.897761061
Finished restore at 06-DEC-15

Montez la base de données et vérifiez l'utilisation du nouveau fichier de contrôle.

RMAN> alter database mount;
using target database control file instead of recovery catalog
Statement processed
SQL> show parameter control_files;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      +NEWLOGS/TOAST/CONTROLFILE/cur
                                                 rent.273.897761061

Relecture du journal

La base de données utilise actuellement les fichiers de données dans l'ancien emplacement. Avant de pouvoir utiliser la copie, elles doivent être synchronisées. Le temps s'est écoulé pendant le processus de copie initial et les modifications ont été enregistrées principalement dans les journaux d'archivage. Ces modifications sont répliquées comme suit :

  1. Effectuez une sauvegarde incrémentielle RMAN contenant les journaux d'archivage.

    RMAN> backup incremental level 1 format '+NEWLOGS' for recover of copy with tag 'ONTAP_MIGRATION' database;
    Starting backup at 06-DEC-15
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=62 device type=DISK
    channel ORA_DISK_1: starting incremental level 1 datafile backup set
    channel ORA_DISK_1: specifying datafile(s) in backup set
    input datafile file number=00001 name=+DATA/TOAST/DATAFILE/system.262.897683141
    input datafile file number=00002 name=+DATA/TOAST/DATAFILE/sysaux.260.897683143
    input datafile file number=00003 name=+DATA/TOAST/DATAFILE/undotbs1.257.897683145
    input datafile file number=00004 name=+DATA/TOAST/DATAFILE/users.264.897683151
    channel ORA_DISK_1: starting piece 1 at 06-DEC-15
    channel ORA_DISK_1: finished piece 1 at 06-DEC-15
    piece handle=+NEWLOGS/TOAST/BACKUPSET/2015_12_06/nnndn1_ontap_migration_0.268.897762693 tag=ONTAP_MIGRATION comment=NONE
    channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
    channel ORA_DISK_1: starting incremental level 1 datafile backup set
    channel ORA_DISK_1: specifying datafile(s) in backup set
    including current control file in backup set
    including current SPFILE in backup set
    channel ORA_DISK_1: starting piece 1 at 06-DEC-15
    channel ORA_DISK_1: finished piece 1 at 06-DEC-15
    piece handle=+NEWLOGS/TOAST/BACKUPSET/2015_12_06/ncsnn1_ontap_migration_0.267.897762697 tag=ONTAP_MIGRATION comment=NONE
    channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
    Finished backup at 06-DEC-15
  2. Relire le journal.

    RMAN> recover copy of database with tag 'ONTAP_MIGRATION';
    Starting recover at 06-DEC-15
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting incremental datafile backup set restore
    channel ORA_DISK_1: specifying datafile copies to recover
    recovering datafile copy file number=00001 name=+NEWDATA/TOAST/DATAFILE/system.259.897759609
    recovering datafile copy file number=00002 name=+NEWDATA/TOAST/DATAFILE/sysaux.263.897759615
    recovering datafile copy file number=00003 name=+NEWDATA/TOAST/DATAFILE/undotbs1.264.897759619
    recovering datafile copy file number=00004 name=+NEWDATA/TOAST/DATAFILE/users.258.897759623
    channel ORA_DISK_1: reading from backup piece +NEWLOGS/TOAST/BACKUPSET/2015_12_06/nnndn1_ontap_migration_0.268.897762693
    channel ORA_DISK_1: piece handle=+NEWLOGS/TOAST/BACKUPSET/2015_12_06/nnndn1_ontap_migration_0.268.897762693 tag=ONTAP_MIGRATION
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
    Finished recover at 06-DEC-15

Activation

Le fichier de contrôle restauré fait toujours référence aux fichiers de données à l'emplacement d'origine et contient également les informations de chemin des fichiers de données copiés.

  1. Pour modifier les fichiers de données actifs, exécutez switch database to copy commande.

    RMAN> switch database to copy;
    datafile 1 switched to datafile copy "+NEWDATA/TOAST/DATAFILE/system.259.897759609"
    datafile 2 switched to datafile copy "+NEWDATA/TOAST/DATAFILE/sysaux.263.897759615"
    datafile 3 switched to datafile copy "+NEWDATA/TOAST/DATAFILE/undotbs1.264.897759619"
    datafile 4 switched to datafile copy "+NEWDATA/TOAST/DATAFILE/users.258.897759623"

    Les fichiers de données actifs sont désormais les fichiers de données copiés, mais des modifications peuvent encore être contenues dans les journaux de reprise finaux.

  2. Pour relire tous les journaux restants, exécutez le recover database commande. Si le message s'affiche media recovery complete apparaît, le processus a réussi.

    RMAN> recover database;
    Starting recover at 06-DEC-15
    using channel ORA_DISK_1
    starting media recovery
    media recovery complete, elapsed time: 00:00:01
    Finished recover at 06-DEC-15

    Ce processus a uniquement modifié l'emplacement des fichiers de données normaux. Les fichiers de données temporaires doivent être renommés, mais ils n'ont pas besoin d'être copiés car ils sont temporaires uniquement. La base de données est actuellement inactive, il n'y a donc pas de données actives dans les fichiers de données temporaires.

  3. Pour déplacer les fichiers de données temporaires, identifiez d'abord leur emplacement.

    RMAN> select file#||' '||name from v$tempfile;
    FILE#||''||NAME
    --------------------------------------------------------------------------------
    1 +DATA/TOAST/TEMPFILE/temp.263.897683145
  4. Déplacez les fichiers de données temporaires à l'aide d'une commande RMAN qui définit le nouveau nom de chaque fichier de données. Avec Oracle Managed Files (OMF), le nom complet n'est pas nécessaire ; le groupe de disques ASM est suffisant. Lorsque la base de données est ouverte, OMF est lié à l'emplacement approprié sur le groupe de disques ASM. Pour déplacer des fichiers, exécutez les commandes suivantes :

    run {
    set newname for tempfile 1 to '+NEWDATA';
    switch tempfile all;
    }
    RMAN> run {
    2> set newname for tempfile 1 to '+NEWDATA';
    3> switch tempfile all;
    4> }
    executing command: SET NEWNAME
    renamed tempfile 1 to +NEWDATA in control file

Migration du journal de reprise

Le processus de migration est presque terminé, mais les journaux de reprise se trouvent toujours sur le groupe de disques ASM d'origine. Les journaux de reprise ne peuvent pas être transférés directement. Un nouvel ensemble de journaux de reprise est créé et ajouté à la configuration, suivi d'un DROP des anciens journaux.

  1. Identifiez le nombre de groupes de fichiers redo log et leurs numéros de groupe respectifs.

    RMAN> select group#||' '||member from v$logfile;
    GROUP#||''||MEMBER
    --------------------------------------------------------------------------------
    1 +DATA/TOAST/ONLINELOG/group_1.261.897683139
    2 +DATA/TOAST/ONLINELOG/group_2.259.897683139
    3 +DATA/TOAST/ONLINELOG/group_3.256.897683139
  2. Indiquez la taille des journaux de reprise.

    RMAN> select group#||' '||bytes from v$log;
    GROUP#||''||BYTES
    --------------------------------------------------------------------------------
    1 52428800
    2 52428800
    3 52428800
  3. Pour chaque journal de reprise, créez un groupe avec une configuration correspondante. Si vous n'utilisez pas OMF, vous devez spécifier le chemin complet. C'est également un exemple qui utilise le db_create_online_log paramètres. Comme indiqué précédemment, ce paramètre a été défini sur +NEWLOGS. Cette configuration vous permet d'utiliser les commandes suivantes pour créer de nouveaux journaux en ligne sans avoir à spécifier un emplacement de fichier ou même un groupe de disques ASM spécifique.

    RMAN> alter database add logfile size 52428800;
    Statement processed
    RMAN> alter database add logfile size 52428800;
    Statement processed
    RMAN> alter database add logfile size 52428800;
    Statement processed
  4. Ouvrez la base de données.

    SQL> alter database open;
    Database altered.
  5. Supprimez les anciens journaux.

    RMAN> alter database drop logfile group 1;
    Statement processed
  6. Si vous rencontrez une erreur qui vous empêche de supprimer un journal actif, forcez un commutateur au journal suivant pour libérer le verrouillage et forcer un point de contrôle global. Un exemple est illustré ci-dessous. La tentative de suppression du groupe de fichiers journaux 3, qui se trouvait sur l'ancien emplacement, a été refusée parce qu'il y avait encore des données actives dans ce fichier journal. Un archivage de journaux après un point de contrôle vous permet de supprimer le fichier journal.

    RMAN> alter database drop logfile group 3;
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of sql statement command at 12/08/2015 20:23:51
    ORA-01623: log 3 is current log for instance TOAST (thread 4) - cannot drop
    ORA-00312: online log 3 thread 1: '+LOGS/TOAST/ONLINELOG/group_3.259.897563549'
    RMAN> alter system switch logfile;
    Statement processed
    RMAN> alter system checkpoint;
    Statement processed
    RMAN> alter database drop logfile group 3;
    Statement processed
  7. Vérifiez l'environnement pour vous assurer que tous les paramètres basés sur l'emplacement sont mis à jour.

    SQL> select name from v$datafile;
    SQL> select member from v$logfile;
    SQL> select name from v$tempfile;
    SQL> show parameter spfile;
    SQL> select name, value from v$parameter where value is not null;
  8. Le script suivant explique comment simplifier ce processus :

    [root@host1 current]# ./checkdbdata.pl TOAST
    TOAST datafiles:
    +NEWDATA/TOAST/DATAFILE/system.259.897759609
    +NEWDATA/TOAST/DATAFILE/sysaux.263.897759615
    +NEWDATA/TOAST/DATAFILE/undotbs1.264.897759619
    +NEWDATA/TOAST/DATAFILE/users.258.897759623
    TOAST redo logs:
    +NEWLOGS/TOAST/ONLINELOG/group_4.266.897763123
    +NEWLOGS/TOAST/ONLINELOG/group_5.265.897763125
    +NEWLOGS/TOAST/ONLINELOG/group_6.264.897763125
    TOAST temp datafiles:
    +NEWDATA/TOAST/TEMPFILE/temp.260.897763165
    TOAST spfile
    spfile                               string      +NEWDATA/spfiletoast.ora
    TOAST key parameters
    control_files +NEWLOGS/TOAST/CONTROLFILE/current.273.897761061
    log_archive_dest_1 LOCATION=+NEWLOGS
    db_create_file_dest +NEWDATA
    db_create_online_log_dest_1 +NEWLOGS
  9. Si les groupes de disques ASM ont été complètement évacués, ils peuvent maintenant être démontés avec asmcmd. Cependant, dans de nombreux cas, les fichiers appartenant à d'autres bases de données ou au fichier ASM spfile/passwd peuvent toujours être présents.

    -bash-4.1$ . oraenv
    ORACLE_SID = [TOAST] ? +ASM
    The Oracle base remains unchanged with value /orabin
    -bash-4.1$ asmcmd
    ASMCMD> umount DATA
    ASMCMD>

Copie d'Oracle ASM vers le système de fichiers

La procédure de copie d'Oracle ASM vers un système de fichiers est très similaire à la procédure de copie d'ASM vers ASM, avec des avantages et des restrictions similaires. La différence principale est la syntaxe des différentes commandes et paramètres de configuration lors de l'utilisation d'un système de fichiers visible par opposition à un groupe de disques ASM.

Copier la base de données

Oracle RMAN permet de créer une copie de niveau 0 (complète) de la base de données source actuellement située sur le groupe de disques ASM +DATA vers le nouvel emplacement sur /oradata.

RMAN> backup as copy incremental level 0 database format '/oradata/TOAST/%U' tag 'ONTAP_MIGRATION';
Starting backup at 13-MAY-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=377 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=+ASM0/TOAST/system01.dbf
output file name=/oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSTEM_FNO-1_01r5fhjg tag=ONTAP_MIGRATION RECID=1 STAMP=911722099
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting datafile copy
input datafile file number=00002 name=+ASM0/TOAST/sysaux01.dbf
output file name=/oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSAUX_FNO-2_02r5fhjo tag=ONTAP_MIGRATION RECID=2 STAMP=911722106
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=+ASM0/TOAST/undotbs101.dbf
output file name=/oradata/TOAST/data_D-TOAST_I-2098173325_TS-UNDOTBS1_FNO-3_03r5fhjt tag=ONTAP_MIGRATION RECID=3 STAMP=911722113
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=/oradata/TOAST/cf_D-TOAST_id-2098173325_04r5fhk5 tag=ONTAP_MIGRATION RECID=4 STAMP=911722118
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=+ASM0/TOAST/users01.dbf
output file name=/oradata/TOAST/data_D-TOAST_I-2098173325_TS-USERS_FNO-4_05r5fhk6 tag=ONTAP_MIGRATION RECID=5 STAMP=911722118
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting incremental level 0 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 13-MAY-16
channel ORA_DISK_1: finished piece 1 at 13-MAY-16
piece handle=/oradata/TOAST/06r5fhk7_1_1 tag=ONTAP_MIGRATION comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 13-MAY-16

Forcer le changement de journal d'archivage

Forcer le commutateur de journal d'archivage est nécessaire pour s'assurer que les journaux d'archivage contiennent toutes les données requises pour rendre la copie entièrement cohérente. Sans cette commande, les données clés peuvent toujours être présentes dans les journaux de reprise. Pour forcer un commutateur de journal d'archivage, exécutez la commande suivante :

RMAN> sql 'alter system archive log current';
sql statement: alter system archive log current

Arrêtez la base de données source

L'interruption commence à cette étape car la base de données est arrêtée et placée en mode lecture seule à accès limité. Pour arrêter la base de données source, exécutez les commandes suivantes :

RMAN> shutdown immediate;
using target database control file instead of recovery catalog
database closed
database dismounted
Oracle instance shut down
RMAN> startup mount;
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area     805306368 bytes
Fixed Size                  2929552 bytes
Variable Size             331353200 bytes
Database Buffers          465567744 bytes
Redo Buffers                5455872 bytes

Sauvegarde Controlfile

Sauvegarder les fichiers de contrôle si vous devez abandonner la migration et revenir à l'emplacement de stockage d'origine. Une copie du fichier de contrôle de sauvegarde n'est pas nécessaire à 100 %, mais elle facilite le processus de réinitialisation des emplacements des fichiers de base de données vers leur emplacement d'origine.

RMAN> backup as copy current controlfile format '/tmp/TOAST.ctrl';
Starting backup at 08-DEC-15
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=/tmp/TOAST.ctrl tag=TAG20151208T194540 RECID=30 STAMP=897939940
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 08-DEC-15

Mises à jour des paramètres

RMAN> create pfile='/tmp/pfile' from spfile;
Statement processed

Mettre à jour le fichier pfile

Tous les paramètres faisant référence aux anciens groupes de disques ASM doivent être mis à jour et, dans certains cas, supprimés lorsqu'ils ne sont plus pertinents. Mettez-les à jour pour refléter les nouveaux chemins du système de fichiers et enregistrez le fichier pfile mis à jour. Assurez-vous que le chemin cible complet est répertorié. Pour mettre à jour ces paramètres, exécutez les commandes suivantes :

*.audit_file_dest='/orabin/admin/TOAST/adump'
*.audit_trail='db'
*.compatible='12.1.0.2.0'
*.control_files='/logs/TOAST/arch/control01.ctl','/logs/TOAST/redo/control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='TOAST'
*.diagnostic_dest='/orabin'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=TOASTXDB)'
*.log_archive_dest_1='LOCATION=/logs/TOAST/arch'
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=256m
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=768m
*.undo_tablespace='UNDOTBS1'

Désactivez le fichier init.ora d'origine

Ce fichier se trouve dans le $ORACLE_HOME/dbs Et se trouve généralement dans un fichier pfile qui sert de pointeur vers le fichier spfile sur le groupe de disques ASM. Pour vous assurer que le fichier spfile d'origine n'est plus utilisé, renommez-le. Ne le supprimez pas, cependant, car ce fichier est nécessaire si la migration doit être abandonnée.

[oracle@jfsc1 ~]$ cd $ORACLE_HOME/dbs
[oracle@jfsc1 dbs]$ cat initTOAST.ora
SPFILE='+ASM0/TOAST/spfileTOAST.ora'
[oracle@jfsc1 dbs]$ mv initTOAST.ora initTOAST.ora.prev
[oracle@jfsc1 dbs]$

Récréation du fichier de paramètres

Il s'agit de la dernière étape de la relocalisation de fichier spfile. Le fichier spfile d'origine n'est plus utilisé et la base de données est actuellement démarrée (mais pas montée) à l'aide du fichier intermédiaire. Le contenu de ce fichier peut être écrit dans le nouvel emplacement spfile comme suit :

RMAN> create spfile from pfile='/tmp/pfile';
Statement processed

Démarrez la base de données pour commencer à utiliser le nouveau fichier spfile

Vous devez démarrer la base de données pour libérer les verrous sur le fichier intermédiaire et démarrer la base de données en utilisant uniquement le nouveau fichier spfile. Le démarrage de la base de données prouve également que le nouvel emplacement spfile est correct et que ses données sont valides.

RMAN> shutdown immediate;
Oracle instance shut down
RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area     805306368 bytes
Fixed Size                     2929552 bytes
Variable Size                331353200 bytes
Database Buffers             465567744 bytes
Redo Buffers                   5455872 bytes

Restaurer le fichier de contrôle

Un fichier de contrôle de sauvegarde a été créé au niveau du chemin /tmp/TOAST.ctrl plus tôt dans la procédure. Le nouveau fichier spfile définit les emplacements des fichiers de contrôle comme /logfs/TOAST/ctrl/ctrlfile1.ctrl et /logfs/TOAST/redo/ctrlfile2.ctrl. Cependant, ces fichiers n'existent pas encore.

  1. Cette commande restaure les données du fichier de contrôle dans les chemins définis dans le fichier spfile.

    RMAN> restore controlfile from '/tmp/TOAST.ctrl';
    Starting restore at 13-MAY-16
    using channel ORA_DISK_1
    channel ORA_DISK_1: copied control file copy
    output file name=/logs/TOAST/arch/control01.ctl
    output file name=/logs/TOAST/redo/control02.ctl
    Finished restore at 13-MAY-16
  2. Exécutez la commande mount pour que les fichiers de contrôle soient correctement découverts et contiennent des données valides.

    RMAN> alter database mount;
    Statement processed
    released channel: ORA_DISK_1

    Pour valider le control_files paramètre, exécutez la commande suivante :

    SQL> show parameter control_files;
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ------------------------------
    control_files                        string      /logs/TOAST/arch/control01.ctl
                                                     , /logs/TOAST/redo/control02.c
                                                     tl

Relecture du journal

La base de données utilise actuellement les fichiers de données dans l'ancien emplacement. Avant de pouvoir utiliser la copie, les fichiers de données doivent être synchronisés. Le temps s'est écoulé pendant le processus de copie initial et les modifications ont été enregistrées principalement dans les journaux d'archivage. Ces modifications sont répliquées dans les deux étapes suivantes.

  1. Effectuez une sauvegarde incrémentielle RMAN contenant les journaux d'archivage.

    RMAN>  backup incremental level 1 format '/logs/TOAST/arch/%U' for recover of copy with tag 'ONTAP_MIGRATION' database;
    Starting backup at 13-MAY-16
    using target database control file instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=124 device type=DISK
    channel ORA_DISK_1: starting incremental level 1 datafile backup set
    channel ORA_DISK_1: specifying datafile(s) in backup set
    input datafile file number=00001 name=+ASM0/TOAST/system01.dbf
    input datafile file number=00002 name=+ASM0/TOAST/sysaux01.dbf
    input datafile file number=00003 name=+ASM0/TOAST/undotbs101.dbf
    input datafile file number=00004 name=+ASM0/TOAST/users01.dbf
    channel ORA_DISK_1: starting piece 1 at 13-MAY-16
    channel ORA_DISK_1: finished piece 1 at 13-MAY-16
    piece handle=/logs/TOAST/arch/09r5fj8i_1_1 tag=ONTAP_MIGRATION comment=NONE
    channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
    Finished backup at 13-MAY-16
    RMAN-06497: WARNING: control file is not current, control file AUTOBACKUP skipped
  2. Relire les journaux.

    RMAN> recover copy of database with tag 'ONTAP_MIGRATION';
    Starting recover at 13-MAY-16
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting incremental datafile backup set restore
    channel ORA_DISK_1: specifying datafile copies to recover
    recovering datafile copy file number=00001 name=/oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSTEM_FNO-1_01r5fhjg
    recovering datafile copy file number=00002 name=/oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSAUX_FNO-2_02r5fhjo
    recovering datafile copy file number=00003 name=/oradata/TOAST/data_D-TOAST_I-2098173325_TS-UNDOTBS1_FNO-3_03r5fhjt
    recovering datafile copy file number=00004 name=/oradata/TOAST/data_D-TOAST_I-2098173325_TS-USERS_FNO-4_05r5fhk6
    channel ORA_DISK_1: reading from backup piece /logs/TOAST/arch/09r5fj8i_1_1
    channel ORA_DISK_1: piece handle=/logs/TOAST/arch/09r5fj8i_1_1 tag=ONTAP_MIGRATION
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
    Finished recover at 13-MAY-16
    RMAN-06497: WARNING: control file is not current, control file AUTOBACKUP skipped

Activation

Le fichier de contrôle restauré fait toujours référence aux fichiers de données à l'emplacement d'origine et contient également les informations de chemin des fichiers de données copiés.

  1. Pour modifier les fichiers de données actifs, exécutez switch database to copy commande :

    RMAN> switch database to copy;
    datafile 1 switched to datafile copy "/oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSTEM_FNO-1_01r5fhjg"
    datafile 2 switched to datafile copy "/oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSAUX_FNO-2_02r5fhjo"
    datafile 3 switched to datafile copy "/oradata/TOAST/data_D-TOAST_I-2098173325_TS-UNDOTBS1_FNO-3_03r5fhjt"
    datafile 4 switched to datafile copy "/oradata/TOAST/data_D-TOAST_I-2098173325_TS-USERS_FNO-4_05r5fhk6"
  2. Bien que les fichiers de données soient parfaitement cohérents, une dernière étape est nécessaire pour relire les modifications restantes enregistrées dans les journaux de reprise en ligne. Utilisez le recover database pour relire ces modifications et rendre la copie identique à 100 % à l'original. Toutefois, la copie n'est pas encore ouverte.

    RMAN> recover database;
    Starting recover at 13-MAY-16
    using channel ORA_DISK_1
    starting media recovery
    archived log for thread 1 with sequence 28 is already on disk as file +ASM0/TOAST/redo01.log
    archived log file name=+ASM0/TOAST/redo01.log thread=1 sequence=28
    media recovery complete, elapsed time: 00:00:00
    Finished recover at 13-MAY-16

Déplacer les fichiers de données temporaires

  1. Identifiez l'emplacement des fichiers de données temporaires toujours en cours d'utilisation sur le groupe de disques d'origine.

    RMAN> select file#||' '||name from v$tempfile;
    FILE#||''||NAME
    --------------------------------------------------------------------------------
    1 +ASM0/TOAST/temp01.dbf
  2. Pour déplacer les fichiers de données, exécutez les commandes suivantes. S'il existe de nombreux fichiers tempfiles, utilisez un éditeur de texte pour créer la commande RMAN, puis coupez-la et collez-la.

    RMAN> run {
    2> set newname for tempfile 1 to '/oradata/TOAST/temp01.dbf';
    3> switch tempfile all;
    4> }
    executing command: SET NEWNAME
    renamed tempfile 1 to /oradata/TOAST/temp01.dbf in control file

Migration du journal de reprise

Le processus de migration est presque terminé, mais les journaux de reprise se trouvent toujours sur le groupe de disques ASM d'origine. Les journaux de reprise ne peuvent pas être transférés directement. Un nouvel ensemble de journaux de reprise est créé et ajouté à la configuration, suivant un DROP des anciens journaux.

  1. Identifiez le nombre de groupes de fichiers redo log et leurs numéros de groupe respectifs.

    RMAN> select group#||' '||member from v$logfile;
    GROUP#||''||MEMBER
    --------------------------------------------------------------------------------
    1 +ASM0/TOAST/redo01.log
    2 +ASM0/TOAST/redo02.log
    3 +ASM0/TOAST/redo03.log
  2. Indiquez la taille des journaux de reprise.

    RMAN> select group#||' '||bytes from v$log;
    GROUP#||''||BYTES
    --------------------------------------------------------------------------------
    1 52428800
    2 52428800
    3 52428800
  3. Pour chaque fichier redo log, créez un groupe en utilisant la même taille que le groupe de fichiers redo log actuel à l'aide du nouvel emplacement du système de fichiers.

    RMAN> alter database add logfile '/logs/TOAST/redo/log00.rdo' size 52428800;
    Statement processed
    RMAN> alter database add logfile '/logs/TOAST/redo/log01.rdo' size 52428800;
    Statement processed
    RMAN> alter database add logfile '/logs/TOAST/redo/log02.rdo' size 52428800;
    Statement processed
  4. Supprimez les anciens groupes de fichiers journaux qui se trouvent toujours sur le stockage précédent.

    RMAN> alter database drop logfile group 4;
    Statement processed
    RMAN> alter database drop logfile group 5;
    Statement processed
    RMAN> alter database drop logfile group 6;
    Statement processed
  5. Si une erreur bloque la suppression d'un journal actif, forcez un commutateur au journal suivant pour libérer le verrouillage et forcer un point de contrôle global. Un exemple est illustré ci-dessous. La tentative de suppression du groupe de fichiers journaux 3, qui se trouvait sur l'ancien emplacement, a été refusée parce qu'il y avait encore des données actives dans ce fichier journal. L'archivage des journaux suivi d'un point de contrôle permet la suppression des fichiers journaux.

    RMAN> alter database drop logfile group 4;
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of sql statement command at 12/08/2015 20:23:51
    ORA-01623: log 4 is current log for instance TOAST (thread 4) - cannot drop
    ORA-00312: online log 4 thread 1: '+NEWLOGS/TOAST/ONLINELOG/group_4.266.897763123'
    RMAN> alter system switch logfile;
    Statement processed
    RMAN> alter system checkpoint;
    Statement processed
    RMAN> alter database drop logfile group 4;
    Statement processed
  6. Vérifiez l'environnement pour vous assurer que tous les paramètres basés sur l'emplacement sont mis à jour.

    SQL> select name from v$datafile;
    SQL> select member from v$logfile;
    SQL> select name from v$tempfile;
    SQL> show parameter spfile;
    SQL> select name, value from v$parameter where value is not null;
  7. Le script suivant explique comment faciliter ce processus.

    [root@jfsc1 current]# ./checkdbdata.pl TOAST
    TOAST datafiles:
    /oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSTEM_FNO-1_01r5fhjg
    /oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSAUX_FNO-2_02r5fhjo
    /oradata/TOAST/data_D-TOAST_I-2098173325_TS-UNDOTBS1_FNO-3_03r5fhjt
    /oradata/TOAST/data_D-TOAST_I-2098173325_TS-USERS_FNO-4_05r5fhk6
    TOAST redo logs:
    /logs/TOAST/redo/log00.rdo
    /logs/TOAST/redo/log01.rdo
    /logs/TOAST/redo/log02.rdo
    TOAST temp datafiles:
    /oradata/TOAST/temp01.dbf
    TOAST spfile
    spfile                               string      /orabin/product/12.1.0/dbhome_
                                                     1/dbs/spfileTOAST.ora
    TOAST key parameters
    control_files /logs/TOAST/arch/control01.ctl, /logs/TOAST/redo/control02.ctl
    log_archive_dest_1 LOCATION=/logs/TOAST/arch
  8. Si les groupes de disques ASM ont été complètement évacués, ils peuvent maintenant être démontés avec asmcmd. Dans de nombreux cas, les fichiers appartenant à d'autres bases de données ou au fichier ASM spfile/passwd peuvent toujours être présents.

    -bash-4.1$ . oraenv
    ORACLE_SID = [TOAST] ? +ASM
    The Oracle base remains unchanged with value /orabin
    -bash-4.1$ asmcmd
    ASMCMD> umount DATA
    ASMCMD>

Procédure de nettoyage du fichier de données

Le processus de migration peut donner lieu à des fichiers de données avec une syntaxe longue ou chiffrée, selon la façon dont Oracle RMAN a été utilisé. Dans l'exemple illustré ici, la sauvegarde a été effectuée avec le format de fichier de /oradata/TOAST/%U. %U Indique que RMAN doit créer un nom unique par défaut pour chaque fichier de données. Le résultat est similaire à ce qui est affiché dans le texte suivant. Les noms traditionnels des fichiers de données sont incorporés dans les noms. Pour ce faire, utilisez l'approche par script illustrée à la "Nettoyage de migration ASM".

[root@jfsc1 current]# ./fixuniquenames.pl TOAST
#sqlplus Commands
shutdown immediate;
startup mount;
host mv /oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSTEM_FNO-1_01r5fhjg /oradata/TOAST/system.dbf
host mv /oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSAUX_FNO-2_02r5fhjo /oradata/TOAST/sysaux.dbf
host mv /oradata/TOAST/data_D-TOAST_I-2098173325_TS-UNDOTBS1_FNO-3_03r5fhjt /oradata/TOAST/undotbs1.dbf
host mv /oradata/TOAST/data_D-TOAST_I-2098173325_TS-USERS_FNO-4_05r5fhk6 /oradata/TOAST/users.dbf
alter database rename file '/oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSTEM_FNO-1_01r5fhjg' to '/oradata/TOAST/system.dbf';
alter database rename file '/oradata/TOAST/data_D-TOAST_I-2098173325_TS-SYSAUX_FNO-2_02r5fhjo' to '/oradata/TOAST/sysaux.dbf';
alter database rename file '/oradata/TOAST/data_D-TOAST_I-2098173325_TS-UNDOTBS1_FNO-3_03r5fhjt' to '/oradata/TOAST/undotbs1.dbf';
alter database rename file '/oradata/TOAST/data_D-TOAST_I-2098173325_TS-USERS_FNO-4_05r5fhk6' to '/oradata/TOAST/users.dbf';
alter database open;

Rééquilibrage d'Oracle ASM

Comme nous l'avons vu précédemment, un groupe de disques Oracle ASM peut être migré en toute transparence vers un nouveau système de stockage en utilisant le processus de rééquilibrage. En résumé, le processus de rééquilibrage nécessite l'ajout de LUN de taille égale au groupe existant de LUN, suivi d'une opération de DROP de la LUN précédente. Oracle ASM déplace automatiquement les données sous-jacentes vers un nouveau stockage selon une disposition optimale, puis libère les anciens LUN une fois l'opération terminée.

Le processus de migration utilise des E/S séquentielles efficaces et ne provoque généralement aucune interruption des performances. En revanche, le taux de migration peut être ralenti lorsque cela est nécessaire.

Identifiez les données à migrer

SQL> select name||' '||group_number||' '||total_mb||' '||path||' '||header_status from v$asm_disk;
NEWDATA_0003 1 10240 /dev/mapper/3600a098038303537762b47594c315864 MEMBER
NEWDATA_0002 1 10240 /dev/mapper/3600a098038303537762b47594c315863 MEMBER
NEWDATA_0000 1 10240 /dev/mapper/3600a098038303537762b47594c315861 MEMBER
NEWDATA_0001 1 10240 /dev/mapper/3600a098038303537762b47594c315862 MEMBER
SQL> select group_number||' '||name from v$asm_diskgroup;
1 NEWDATA

Créer des LUN

Créez de nouvelles LUN de la même taille et définissez l'appartenance des utilisateurs et des groupes selon les besoins. Les LUN doivent s'afficher comme CANDIDATE disques.

SQL> select name||' '||group_number||' '||total_mb||' '||path||' '||header_status from v$asm_disk;
 0 0 /dev/mapper/3600a098038303537762b47594c31586b CANDIDATE
 0 0 /dev/mapper/3600a098038303537762b47594c315869 CANDIDATE
 0 0 /dev/mapper/3600a098038303537762b47594c315858 CANDIDATE
 0 0 /dev/mapper/3600a098038303537762b47594c31586a CANDIDATE
NEWDATA_0003 1 10240 /dev/mapper/3600a098038303537762b47594c315864 MEMBER
NEWDATA_0002 1 10240 /dev/mapper/3600a098038303537762b47594c315863 MEMBER
NEWDATA_0000 1 10240 /dev/mapper/3600a098038303537762b47594c315861 MEMBER
NEWDATA_0001 1 10240 /dev/mapper/3600a098038303537762b47594c315862 MEMBER

Ajouter de nouvelles LUN

Même si les opérations d'ajout et de suppression peuvent être effectuées ensemble, il est généralement plus facile d'ajouter de nouvelles LUN en deux étapes. Commencez par ajouter les nouvelles LUN au groupe de disques. Cette étape entraîne la migration de la moitié des extensions des LUN ASM actuelles vers les nouvelles LUN.

La puissance de rééquilibrage indique la vitesse à laquelle les données sont transférées. Plus le nombre est élevé, plus le parallélisme du transfert de données est élevé. La migration s'effectue au moyen d'opérations d'E/S séquentielles efficaces, peu susceptibles d'entraîner des problèmes de performances. Toutefois, si nécessaire, le pouvoir de rééquilibrage d'une migration en cours peut être ajusté avec le alter diskgroup [name] rebalance power [level] commande. Les migrations types utilisent une valeur de 5.

SQL> alter diskgroup NEWDATA add disk '/dev/mapper/3600a098038303537762b47594c31586b' rebalance power 5;
Diskgroup altered.
SQL> alter diskgroup NEWDATA add disk '/dev/mapper/3600a098038303537762b47594c315869' rebalance power 5;
Diskgroup altered.
SQL> alter diskgroup NEWDATA add disk '/dev/mapper/3600a098038303537762b47594c315858' rebalance power 5;
Diskgroup altered.
SQL> alter diskgroup NEWDATA add disk '/dev/mapper/3600a098038303537762b47594c31586a' rebalance power 5;
Diskgroup altered.

Surveiller le fonctionnement

Une opération de rééquilibrage peut être contrôlée et gérée de plusieurs manières. Nous avons utilisé la commande suivante dans cet exemple.

SQL> select group_number,operation,state from v$asm_operation;
GROUP_NUMBER OPERA STAT
------------ ----- ----
           1 REBAL RUN
           1 REBAL WAIT

Une fois la migration terminée, aucune opération de rééquilibrage n'est signalée.

SQL> select group_number,operation,state from v$asm_operation;
no rows selected

Supprimez les anciennes LUN

La migration est maintenant terminée à mi-chemin. Il peut être souhaitable d'effectuer quelques tests de performances de base pour s'assurer que l'environnement est sain. Après confirmation, les données restantes peuvent être déplacées en déposant les anciennes LUN. Notez que cela ne provoque pas la publication immédiate des LUN. L'opération de DROP indique à Oracle ASM de déplacer d'abord les extensions, puis de libérer la LUN.

sqlplus / as sysasm
SQL> alter diskgroup NEWDATA drop disk NEWDATA_0000 rebalance power 5;
Diskgroup altered.
SQL> alter diskgroup NEWDATA drop disk NEWDATA_0001 rebalance power 5;
Diskgroup altered.
SQL> alter diskgroup newdata drop disk NEWDATA_0002 rebalance power 5;
Diskgroup altered.
SQL> alter diskgroup newdata drop disk NEWDATA_0003 rebalance power 5;
Diskgroup altered.

Surveiller le fonctionnement

L'opération de rééquilibrage peut être contrôlée et gérée de plusieurs manières. Nous avons utilisé la commande suivante dans cet exemple :

SQL> select group_number,operation,state from v$asm_operation;
GROUP_NUMBER OPERA STAT
------------ ----- ----
           1 REBAL RUN
           1 REBAL WAIT

Une fois la migration terminée, aucune opération de rééquilibrage n'est signalée.

SQL> select group_number,operation,state from v$asm_operation;
no rows selected

Supprimer les anciens LUN

Avant de supprimer les anciennes LUN du groupe de disques, vous devez effectuer une dernière vérification de l'état de l'en-tête. Une fois qu'une LUN est libérée d'ASM, son nom n'est plus répertorié et son état est répertorié comme FORMER. Cela signifie que ces LUN peuvent être supprimées du système en toute sécurité.

SQL> select name||' '||group_number||' '||total_mb||' '||path||' '||header_status from v$asm_disk;
NAME||''||GROUP_NUMBER||''||TOTAL_MB||''||PATH||''||HEADER_STATUS
--------------------------------------------------------------------------------
 0 0 /dev/mapper/3600a098038303537762b47594c315863 FORMER
 0 0 /dev/mapper/3600a098038303537762b47594c315864 FORMER
 0 0 /dev/mapper/3600a098038303537762b47594c315861 FORMER
 0 0 /dev/mapper/3600a098038303537762b47594c315862 FORMER
NEWDATA_0005 1 10240 /dev/mapper/3600a098038303537762b47594c315869 MEMBER
NEWDATA_0007 1 10240 /dev/mapper/3600a098038303537762b47594c31586a MEMBER
NEWDATA_0004 1 10240 /dev/mapper/3600a098038303537762b47594c31586b MEMBER
NEWDATA_0006 1 10240 /dev/mapper/3600a098038303537762b47594c315858 MEMBER
8 rows selected.

Migration LVM

La procédure présentée ici présente les principes d'une migration basée sur LVM d'un groupe de volumes appelé datavg. Les exemples sont tirés du LVM Linux, mais les principes s'appliquent également à AIX, HP-UX et VxVM. Les commandes précises peuvent varier.

  1. Identifiez les LUN actuellement dans le datavg groupe de volumes.

    [root@host1 ~]# pvdisplay -C | grep datavg
      /dev/mapper/3600a098038303537762b47594c31582f datavg lvm2 a--  10.00g 10.00g
      /dev/mapper/3600a098038303537762b47594c31585a datavg lvm2 a--  10.00g 10.00g
      /dev/mapper/3600a098038303537762b47594c315859 datavg lvm2 a--  10.00g 10.00g
      /dev/mapper/3600a098038303537762b47594c31586c datavg lvm2 a--  10.00g 10.00g
  2. Créez de nouvelles LUN de taille physique identique ou légèrement supérieure et définissez-les comme volumes physiques.

    [root@host1 ~]# pvcreate /dev/mapper/3600a098038303537762b47594c315864
      Physical volume "/dev/mapper/3600a098038303537762b47594c315864" successfully created
    [root@host1 ~]# pvcreate /dev/mapper/3600a098038303537762b47594c315863
      Physical volume "/dev/mapper/3600a098038303537762b47594c315863" successfully created
    [root@host1 ~]# pvcreate /dev/mapper/3600a098038303537762b47594c315862
      Physical volume "/dev/mapper/3600a098038303537762b47594c315862" successfully created
    [root@host1 ~]# pvcreate /dev/mapper/3600a098038303537762b47594c315861
      Physical volume "/dev/mapper/3600a098038303537762b47594c315861" successfully created
  3. Ajoutez les nouveaux volumes au groupe de volumes.

    [root@host1 tmp]# vgextend datavg /dev/mapper/3600a098038303537762b47594c315864
      Volume group "datavg" successfully extended
    [root@host1 tmp]# vgextend datavg /dev/mapper/3600a098038303537762b47594c315863
      Volume group "datavg" successfully extended
    [root@host1 tmp]# vgextend datavg /dev/mapper/3600a098038303537762b47594c315862
      Volume group "datavg" successfully extended
    [root@host1 tmp]# vgextend datavg /dev/mapper/3600a098038303537762b47594c315861
      Volume group "datavg" successfully extended
  4. Émettez le pvmove Commande permettant de déplacer les extensions de chaque LUN actuelle vers la nouvelle LUN. Le - i [seconds] l'argument surveille la progression de l'opération.

    [root@host1 tmp]# pvmove -i 10 /dev/mapper/3600a098038303537762b47594c31582f /dev/mapper/3600a098038303537762b47594c315864
      /dev/mapper/3600a098038303537762b47594c31582f: Moved: 0.0%
      /dev/mapper/3600a098038303537762b47594c31582f: Moved: 14.2%
      /dev/mapper/3600a098038303537762b47594c31582f: Moved: 28.4%
      /dev/mapper/3600a098038303537762b47594c31582f: Moved: 42.5%
      /dev/mapper/3600a098038303537762b47594c31582f: Moved: 57.1%
      /dev/mapper/3600a098038303537762b47594c31582f: Moved: 72.3%
      /dev/mapper/3600a098038303537762b47594c31582f: Moved: 87.3%
      /dev/mapper/3600a098038303537762b47594c31582f: Moved: 100.0%
    [root@host1 tmp]# pvmove -i 10 /dev/mapper/3600a098038303537762b47594c31585a /dev/mapper/3600a098038303537762b47594c315863
      /dev/mapper/3600a098038303537762b47594c31585a: Moved: 0.0%
      /dev/mapper/3600a098038303537762b47594c31585a: Moved: 14.9%
      /dev/mapper/3600a098038303537762b47594c31585a: Moved: 29.9%
      /dev/mapper/3600a098038303537762b47594c31585a: Moved: 44.8%
      /dev/mapper/3600a098038303537762b47594c31585a: Moved: 60.1%
      /dev/mapper/3600a098038303537762b47594c31585a: Moved: 75.8%
      /dev/mapper/3600a098038303537762b47594c31585a: Moved: 90.9%
      /dev/mapper/3600a098038303537762b47594c31585a: Moved: 100.0%
    [root@host1 tmp]# pvmove -i 10 /dev/mapper/3600a098038303537762b47594c315859 /dev/mapper/3600a098038303537762b47594c315862
      /dev/mapper/3600a098038303537762b47594c315859: Moved: 0.0%
      /dev/mapper/3600a098038303537762b47594c315859: Moved: 14.8%
      /dev/mapper/3600a098038303537762b47594c315859: Moved: 29.8%
      /dev/mapper/3600a098038303537762b47594c315859: Moved: 45.5%
      /dev/mapper/3600a098038303537762b47594c315859: Moved: 61.1%
      /dev/mapper/3600a098038303537762b47594c315859: Moved: 76.6%
      /dev/mapper/3600a098038303537762b47594c315859: Moved: 91.7%
      /dev/mapper/3600a098038303537762b47594c315859: Moved: 100.0%
    [root@host1 tmp]# pvmove -i 10 /dev/mapper/3600a098038303537762b47594c31586c /dev/mapper/3600a098038303537762b47594c315861
      /dev/mapper/3600a098038303537762b47594c31586c: Moved: 0.0%
      /dev/mapper/3600a098038303537762b47594c31586c: Moved: 15.0%
      /dev/mapper/3600a098038303537762b47594c31586c: Moved: 30.4%
      /dev/mapper/3600a098038303537762b47594c31586c: Moved: 46.0%
      /dev/mapper/3600a098038303537762b47594c31586c: Moved: 61.4%
      /dev/mapper/3600a098038303537762b47594c31586c: Moved: 77.2%
      /dev/mapper/3600a098038303537762b47594c31586c: Moved: 92.3%
      /dev/mapper/3600a098038303537762b47594c31586c: Moved: 100.0%
  5. Une fois ce processus terminé, supprimez les anciennes LUN du groupe de volumes à l'aide du vgreduce commande. En cas de réussite, la LUN peut être supprimée en toute sécurité du système.

    [root@host1 tmp]# vgreduce datavg /dev/mapper/3600a098038303537762b47594c31582f
    Removed "/dev/mapper/3600a098038303537762b47594c31582f" from volume group "datavg"
    [root@host1 tmp]# vgreduce datavg /dev/mapper/3600a098038303537762b47594c31585a
      Removed "/dev/mapper/3600a098038303537762b47594c31585a" from volume group "datavg"
    [root@host1 tmp]# vgreduce datavg /dev/mapper/3600a098038303537762b47594c315859
      Removed "/dev/mapper/3600a098038303537762b47594c315859" from volume group "datavg"
    [root@host1 tmp]# vgreduce datavg /dev/mapper/3600a098038303537762b47594c31586c
      Removed "/dev/mapper/3600a098038303537762b47594c31586c" from volume group "datavg"