Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Trasvase de registros

11/20/2024 Colaboradores

PDF

El objetivo de una migración mediante el envío de registros es crear una copia de los archivos de datos originales en una nueva ubicación y, a continuación, establecer un método de envío de cambios en el nuevo entorno.

Una vez establecido, el envío y la reproducción de registros se pueden automatizar para mantener la base de datos de réplicas en gran medida sincronizada con la fuente. Por ejemplo, se puede programar un trabajo cron para (a) copiar los logs más recientes en la nueva ubicación y (b) reproducirlos cada 15 minutos. De este modo, se genera una interrupción mínima en el momento de la transición, ya que no se deben volver a reproducir más de 15 minutos de registros de archivo.

El procedimiento que se muestra a continuación también es esencialmente una operación de clonado de base de datos. La lógica mostrada es similar al motor de NetApp SnapManager para Oracle (SMO) y el plugin para Oracle de NetApp SnapCenter. Algunos clientes han utilizado el procedimiento mostrado en los flujos de trabajo de WFA o en los scripts para operaciones de clonado personalizadas. Aunque este procedimiento es más manual que usar SMO o SnapCenter, todavía dispone de secuencias de comandos sencillas y las API de gestión de datos en ONTAP simplifican aún más el proceso.

Envío de registros: Sistema de archivos al sistema de archivos

Este ejemplo muestra la migración de una base de datos denominada WAFFLE de un sistema de archivos ordinario a otro sistema de archivos ordinario ubicado en un servidor diferente. También ilustra el uso de SnapMirror para realizar una copia rápida de los archivos de datos, pero esto no forma parte integral del procedimiento general.

Crear copia de seguridad de base de datos

El primer paso es crear una copia de seguridad de la base de datos. En concreto, este procedimiento requiere un juego de archivos de datos que se pueda utilizar para la reproducción del archive log.

Entorno Oracle

En este ejemplo, la base de datos de origen se encuentra en un sistema ONTAP. El método más sencillo para crear un backup de una base de datos es mediante una instantánea. La base de datos se coloca en modo de backup dinámico durante unos segundos mientras a. snapshot create la operación se ejecuta en el volumen que aloja los archivos de datos.

SQL> alter database begin backup;
Database altered.

Cluster01::*> snapshot create -vserver vserver1 -volume jfsc1_oradata hotbackup
Cluster01::*>

SQL> alter database end backup;
Database altered.

El resultado es una instantánea en disco llamada hotbackup que contiene una imagen de los archivos de datos mientras se encuentra en modo de copia de seguridad activa. Si se combinan con los archive logs adecuados para que los archivos de datos sean coherentes, se pueden utilizar los datos de esta copia Snapshot como base de la restauración o el clon. En este caso, se replica en el nuevo servidor.

Restauración al nuevo entorno

La copia de seguridad se debe restaurar ahora en el nuevo entorno. Esto puede realizarse de varias maneras, incluida Oracle RMAN, restauración desde una aplicación de backup como NetBackup o una operación de copia sencilla de archivos de datos ubicados en modo de backup dinámico.

En este ejemplo, se usa SnapMirror para replicar el backup en caliente de la copia Snapshot en una nueva ubicación.

Cree un volumen nuevo para recibir los datos de las snapshots. Inicialice el mirroring a partir de jfsc1_oradata para vol_oradata.

Cluster01::*> volume create -vserver vserver1 -volume vol_oradata -aggregate data_01 -size 20g -state online -type DP -snapshot-policy none -policy jfsc3
[Job 833] Job succeeded: Successful

Cluster01::*> snapmirror initialize -source-path vserver1:jfsc1_oradata -destination-path vserver1:vol_oradata
Operation is queued: snapmirror initialize of destination "vserver1:vol_oradata".
Cluster01::*> volume mount -vserver vserver1 -volume vol_oradata -junction-path /vol_oradata
Cluster01::*>

Una vez definido el estado mediante SnapMirror, que indica que la sincronización está completada, actualice el mirror según la snapshot que desee.

Cluster01::*> snapmirror show -destination-path vserver1:vol_oradata -fields state
source-path             destination-path        state
----------------------- ----------------------- ------------
vserver1:jfsc1_oradata vserver1:vol_oradata SnapMirrored

Cluster01::*> snapmirror update -destination-path vserver1:vol_oradata -source-snapshot hotbackup
Operation is queued: snapmirror update of destination "vserver1:vol_oradata".

La sincronización correcta se puede verificar en el newest-snapshot en el volumen de reflejo.

Cluster01::*> snapmirror show -destination-path vserver1:vol_oradata -fields newest-snapshot
source-path             destination-path        newest-snapshot
----------------------- ----------------------- ---------------
vserver1:jfsc1_oradata vserver1:vol_oradata hotbackup

El espejo puede romperse.

Cluster01::> snapmirror break -destination-path vserver1:vol_oradata
Operation succeeded: snapmirror break for destination "vserver1:vol_oradata".
Cluster01::>

Monte el nuevo sistema de archivos.Con los sistemas de archivos basados en bloques, los procedimientos precisos varían según el LVM en uso. Debe configurarse la división en zonas de FC o las conexiones iSCSI. Después de establecer la conectividad a las LUN, comandos como Linux pvscan Puede que sea necesario detectar qué grupos de volúmenes o LUN tienen que estar correctamente configurados para que ASM pueda detectar.

En este ejemplo, se utiliza un sistema de archivos NFS simple. Este sistema de archivos se puede montar directamente.
```
fas8060-nfs1:/vol_oradata        19922944   1639360   18283584   9% /oradata
fas8060-nfs1:/vol_logs            9961472       128    9961344   1% /logs
```

Crear plantilla de creación de archivo de control

A continuación, debe crear una plantilla de archivo de control. La backup controlfile to trace command crea comandos de texto para volver a crear un archivo de control. Esta función puede ser útil para restaurar una base de datos a partir de un backup bajo determinadas circunstancias, y se suele utilizar con scripts que realizan tareas como la clonación de bases de datos.

La salida del siguiente comando se utiliza para recrear los controlfiles para la base de datos migrada.
```
SQL> alter database backup controlfile to trace as '/tmp/waffle.ctrl';
Database altered.
```

Después de crear los archivos de control, copie el archivo en el nuevo servidor.

[oracle@jfsc3 tmp]$ scp oracle@jfsc1:/tmp/waffle.ctrl /tmp/
oracle@jfsc1's password:
waffle.ctrl                                              100% 5199     5.1KB/s   00:00

Archivo de parámetros de copia de seguridad

También se necesita un archivo de parámetros en el nuevo entorno. El método más simple es crear un pfile a partir del spfile o pfile actual. En este ejemplo, la base de datos de origen está utilizando un spfile.

SQL> create pfile='/tmp/waffle.tmp.pfile' from spfile;
File created.

Crear entrada oratab

La creación de una entrada oratab es necesaria para el correcto funcionamiento de utilidades como oraenv. Para crear una entrada de oratab, realice el siguiente paso.

WAFFLE:/orabin/product/12.1.0/dbhome_1:N

Preparar la estructura de directorios

Si los directorios necesarios no estaban presentes, debe crearlos o el procedimiento de inicio de la base de datos falla. Para preparar la estructura de directorios, complete los siguientes requisitos mínimos.

[oracle@jfsc3 ~]$ . oraenv
ORACLE_SID = [oracle] ? WAFFLE
The Oracle base has been set to /orabin
[oracle@jfsc3 ~]$ cd $ORACLE_BASE
[oracle@jfsc3 orabin]$ cd admin
[oracle@jfsc3 admin]$ mkdir WAFFLE
[oracle@jfsc3 admin]$ cd WAFFLE
[oracle@jfsc3 WAFFLE]$ mkdir adump dpdump pfile scripts xdb_wallet

Actualizaciones de archivos de parámetros

Para copiar el archivo de parámetros en el nuevo servidor, ejecute los siguientes comandos. La ubicación predeterminada es la $ORACLE_HOME/dbs directorio. En este caso, el archivo pfile se puede colocar en cualquier lugar. Sólo se utiliza como paso intermedio en el proceso de migración.

[oracle@jfsc3 admin]$ scp oracle@jfsc1:/tmp/waffle.tmp.pfile $ORACLE_HOME/dbs/waffle.tmp.pfile
oracle@jfsc1's password:
waffle.pfile                                             100%  916     0.9KB/s   00:00

Edite el archivo según sea necesario. Por ejemplo, si la ubicación del archive log ha cambiado, el archivo pfile debe modificarse para reflejar la nueva ubicación. En este ejemplo, sólo se reubican los archivos de control, en parte para distribuirlos entre los sistemas de archivos de registro y de datos.

[root@jfsc1 tmp]# cat waffle.pfile
WAFFLE.__data_transfer_cache_size=0
WAFFLE.__db_cache_size=507510784
WAFFLE.__java_pool_size=4194304
WAFFLE.__large_pool_size=20971520
WAFFLE.__oracle_base='/orabin'#ORACLE_BASE set from environment
WAFFLE.__pga_aggregate_target=268435456
WAFFLE.__sga_target=805306368
WAFFLE.__shared_io_pool_size=29360128
WAFFLE.__shared_pool_size=234881024
WAFFLE.__streams_pool_size=0
*.audit_file_dest='/orabin/admin/WAFFLE/adump'
*.audit_trail='db'
*.compatible='12.1.0.2.0'
*.control_files='/oradata//WAFFLE/control01.ctl','/oradata//WAFFLE/control02.ctl'
*.control_files='/oradata/WAFFLE/control01.ctl','/logs/WAFFLE/control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='WAFFLE'
*.diagnostic_dest='/orabin'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=WAFFLEXDB)'
*.log_archive_dest_1='LOCATION=/logs/WAFFLE/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'

Una vez finalizadas las ediciones, cree un archivo spfile basado en este archivo pfile.
```
SQL> create spfile from pfile='waffle.tmp.pfile';
File created.
```

Vuelva a crear los archivos de control

En un paso anterior, la salida de backup controlfile to trace se ha copiado en el nuevo servidor. La parte específica de la salida necesaria es la controlfile recreation comando. Esta información se puede encontrar en el archivo bajo la sección marcada Set #1. NORESETLOGS. Comienza con la línea create controlfile reuse database y debe incluir la palabra noresetlogs. Termina con el carácter de punto y coma (; ).

En este procedimiento de ejemplo, el archivo se lee de la siguiente manera.

CREATE CONTROLFILE REUSE DATABASE "WAFFLE" NORESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/logs/WAFFLE/redo/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/logs/WAFFLE/redo/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/logs/WAFFLE/redo/redo03.log'  SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  '/oradata/WAFFLE/system01.dbf',
  '/oradata/WAFFLE/sysaux01.dbf',
  '/oradata/WAFFLE/undotbs01.dbf',
  '/oradata/WAFFLE/users01.dbf'
CHARACTER SET WE8MSWIN1252
;

Edite este script como desee para reflejar la nueva ubicación de los distintos archivos. Por ejemplo, algunos archivos de datos conocidos por admitir una gran I/O podrían redirigirse a un sistema de archivos en un nivel de almacenamiento de alto rendimiento. En otros casos, los cambios podrían ser únicamente por motivos de administrador, como el aislamiento de los archivos de datos de una PDB determinada en volúmenes dedicados.

En este ejemplo, la DATAFILE stanza se deja sin cambios, pero los redo logs se mueven a una nueva ubicación en /redo en lugar de compartir espacio con archive logs /logs.

CREATE CONTROLFILE REUSE DATABASE "WAFFLE" NORESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/redo/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/redo/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/redo/redo03.log'  SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  '/oradata/WAFFLE/system01.dbf',
  '/oradata/WAFFLE/sysaux01.dbf',
  '/oradata/WAFFLE/undotbs01.dbf',
  '/oradata/WAFFLE/users01.dbf'
CHARACTER SET WE8MSWIN1252
;

SQL> startup nomount;
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
SQL> CREATE CONTROLFILE REUSE DATABASE "WAFFLE" NORESETLOGS  ARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
  7  LOGFILE
  8    GROUP 1 '/redo/redo01.log'  SIZE 50M BLOCKSIZE 512,
  9    GROUP 2 '/redo/redo02.log'  SIZE 50M BLOCKSIZE 512,
 10    GROUP 3 '/redo/redo03.log'  SIZE 50M BLOCKSIZE 512
 11  -- STANDBY LOGFILE
 12  DATAFILE
 13    '/oradata/WAFFLE/system01.dbf',
 14    '/oradata/WAFFLE/sysaux01.dbf',
 15    '/oradata/WAFFLE/undotbs01.dbf',
 16    '/oradata/WAFFLE/users01.dbf'
 17  CHARACTER SET WE8MSWIN1252
 18  ;
Control file created.
SQL>

Si alguno de los archivos está mal ubicado o los parámetros están mal configurados, se generan errores que indican lo que debe corregirse. La base de datos está montada, pero aún no está abierta y no se puede abrir porque los archivos de datos en uso siguen marcados como en modo de copia de seguridad en caliente. Los archive logs deben aplicarse primero para que la base de datos sea coherente.

Replicación de registro inicial

Se necesita al menos una operación de respuesta de log para que los archivos de datos sean consistentes. Hay muchas opciones disponibles para reproducir logs. En algunos casos, la ubicación original del archive log en el servidor original se puede compartir a través de NFS, y la respuesta del log se puede realizar directamente. En otros casos, los archive logs deben copiarse.

Por ejemplo, un simple scp la operación puede copiar todos los registros actuales del servidor de origen al servidor de migración:

[oracle@jfsc3 arch]$ scp jfsc1:/logs/WAFFLE/arch/* ./
oracle@jfsc1's password:
1_22_912662036.dbf                                       100%   47MB  47.0MB/s   00:01
1_23_912662036.dbf                                       100%   40MB  40.4MB/s   00:00
1_24_912662036.dbf                                       100%   45MB  45.4MB/s   00:00
1_25_912662036.dbf                                       100%   41MB  40.9MB/s   00:01
1_26_912662036.dbf                                       100%   39MB  39.4MB/s   00:00
1_27_912662036.dbf                                       100%   39MB  38.7MB/s   00:00
1_28_912662036.dbf                                       100%   40MB  40.1MB/s   00:01
1_29_912662036.dbf                                       100%   17MB  16.9MB/s   00:00
1_30_912662036.dbf                                       100%  636KB 636.0KB/s   00:00

Reproducción de log inicial

SQL> recover database until cancel;
ORA-00279: change 382713 generated at 05/24/2016 09:00:54 needed for thread 1
ORA-00289: suggestion : /logs/WAFFLE/arch/1_23_912662036.dbf
ORA-00280: change 382713 for thread 1 is in sequence #23
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00279: change 405712 generated at 05/24/2016 15:01:05 needed for thread 1
ORA-00289: suggestion : /logs/WAFFLE/arch/1_24_912662036.dbf
ORA-00280: change 405712 for thread 1 is in sequence #24
ORA-00278: log file '/logs/WAFFLE/arch/1_23_912662036.dbf' no longer needed for
this recovery
...
ORA-00279: change 713874 generated at 05/26/2016 04:26:43 needed for thread 1
ORA-00289: suggestion : /logs/WAFFLE/arch/1_31_912662036.dbf
ORA-00280: change 713874 for thread 1 is in sequence #31
ORA-00278: log file '/logs/WAFFLE/arch/1_30_912662036.dbf' no longer needed for
this recovery
ORA-00308: cannot open archived log '/logs/WAFFLE/arch/1_31_912662036.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

La respuesta final del archive log informa de un error, pero esto es normal. El registro lo indica sqlplus estaba buscando un archivo de registro en particular y no lo encontró. La razón es, lo más probable, que el archivo log no existe aún.

Si la base de datos de origen se puede cerrar antes de copiar archive logs, este paso debe realizarse una sola vez. Los archive logs se copian y se reproducen y, a continuación, el proceso puede continuar directamente con el proceso de transposición que replica los redo logs críticos.

Replicación y repetición de log incremental

En la mayoría de los casos, la migración no se realiza de forma inmediata. Pueden pasar días o incluso semanas antes de que se complete el proceso de migración, lo que significa que los registros deben enviarse continuamente a la base de datos de réplica y reproducirse. Por lo tanto, al llegar la transición, es necesario transferir y reproducir unos datos mínimos.

Al hacerlo se puede ejecutar un script de muchas maneras, pero uno de los métodos más populares es usar rsync, una utilidad común de replicación de archivos. La forma más segura de utilizar esta utilidad es configurarla como daemon. Por ejemplo, la rsyncd.conf el siguiente archivo muestra cómo crear un recurso llamado waffle.arch Al que se accede con las credenciales de usuario de Oracle y se asigna a. /logs/WAFFLE/arch. Lo que es más importante, el recurso se establece en solo lectura, lo que permite que los datos de producción se lean, pero no se alteren.

[root@jfsc1 arch]# cat /etc/rsyncd.conf
[waffle.arch]
   uid=oracle
   gid=dba
   path=/logs/WAFFLE/arch
   read only = true
[root@jfsc1 arch]# rsync --daemon

El siguiente comando sincroniza el destino del archive log del nuevo servidor con el recurso rsync waffle.arch en el servidor original. La t argumento en rsync - potg hace que la lista de archivos se compare en función de la marca de tiempo, y solo se copian los archivos nuevos. Este proceso proporciona una actualización incremental del nuevo servidor. Este comando también se puede programar en cron para que se ejecute de forma regular.

[oracle@jfsc3 arch]$ rsync -potg --stats --progress jfsc1::waffle.arch/* /logs/WAFFLE/arch/
1_31_912662036.dbf
      650240 100%  124.02MB/s    0:00:00 (xfer#1, to-check=8/18)
1_32_912662036.dbf
     4873728 100%  110.67MB/s    0:00:00 (xfer#2, to-check=7/18)
1_33_912662036.dbf
     4088832 100%   50.64MB/s    0:00:00 (xfer#3, to-check=6/18)
1_34_912662036.dbf
     8196096 100%   54.66MB/s    0:00:00 (xfer#4, to-check=5/18)
1_35_912662036.dbf
    19376128 100%   57.75MB/s    0:00:00 (xfer#5, to-check=4/18)
1_36_912662036.dbf
       71680 100%  201.15kB/s    0:00:00 (xfer#6, to-check=3/18)
1_37_912662036.dbf
     1144320 100%    3.06MB/s    0:00:00 (xfer#7, to-check=2/18)
1_38_912662036.dbf
    35757568 100%   63.74MB/s    0:00:00 (xfer#8, to-check=1/18)
1_39_912662036.dbf
      984576 100%    1.63MB/s    0:00:00 (xfer#9, to-check=0/18)
Number of files: 18
Number of files transferred: 9
Total file size: 399653376 bytes
Total transferred file size: 75143168 bytes
Literal data: 75143168 bytes
Matched data: 0 bytes
File list size: 474
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 204
Total bytes received: 75153219
sent 204 bytes  received 75153219 bytes  150306846.00 bytes/sec
total size is 399653376  speedup is 5.32

Una vez recibidos los registros, deben reproducirse. Ejemplos anteriores muestran el uso de sqlplus para ejecutar manualmente recover database until cancel, un proceso que se puede automatizar fácilmente. El ejemplo que se muestra aquí utiliza el script descrito en "Reproducir Logs en Base de Datos". Los scripts aceptan un argumento que especifica la base de datos que necesita una operación de reproducción. Esto permite utilizar el mismo script en un esfuerzo de migración de varias bases de datos.

[oracle@jfsc3 logs]$ ./replay.logs.pl WAFFLE
ORACLE_SID = [WAFFLE] ? The Oracle base remains unchanged with value /orabin
SQL*Plus: Release 12.1.0.2.0 Production on Thu May 26 10:47:16 2016
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> ORA-00279: change 713874 generated at 05/26/2016 04:26:43 needed for thread 1
ORA-00289: suggestion : /logs/WAFFLE/arch/1_31_912662036.dbf
ORA-00280: change 713874 for thread 1 is in sequence #31
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 814256 generated at 05/26/2016 04:52:30 needed for thread 1
ORA-00289: suggestion : /logs/WAFFLE/arch/1_32_912662036.dbf
ORA-00280: change 814256 for thread 1 is in sequence #32
ORA-00278: log file '/logs/WAFFLE/arch/1_31_912662036.dbf' no longer needed for
this recovery
ORA-00279: change 814780 generated at 05/26/2016 04:53:04 needed for thread 1
ORA-00289: suggestion : /logs/WAFFLE/arch/1_33_912662036.dbf
ORA-00280: change 814780 for thread 1 is in sequence #33
ORA-00278: log file '/logs/WAFFLE/arch/1_32_912662036.dbf' no longer needed for
this recovery
...
ORA-00279: change 1120099 generated at 05/26/2016 09:59:21 needed for thread 1
ORA-00289: suggestion : /logs/WAFFLE/arch/1_40_912662036.dbf
ORA-00280: change 1120099 for thread 1 is in sequence #40
ORA-00278: log file '/logs/WAFFLE/arch/1_39_912662036.dbf' no longer needed for
this recovery
ORA-00308: cannot open archived log '/logs/WAFFLE/arch/1_40_912662036.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
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

Transición

Cuando esté listo para realizar la transición al nuevo entorno, debe realizar una sincronización final que incluya tanto archive logs como redo logs. Si la ubicación de redo log original no se conoce todavía, se puede identificar de la siguiente manera:

SQL> select member from v$logfile;
MEMBER
--------------------------------------------------------------------------------
/logs/WAFFLE/redo/redo01.log
/logs/WAFFLE/redo/redo02.log
/logs/WAFFLE/redo/redo03.log

Cierre la base de datos de origen.
Realice una sincronización final de los archive logs en el nuevo servidor con el método deseado.

Los redo logs de origen se deben copiar en el nuevo servidor. En este ejemplo, los redo logs se reubicaron en un nuevo directorio en /redo.

[oracle@jfsc3 logs]$ scp jfsc1:/logs/WAFFLE/redo/* /redo/
oracle@jfsc1's password:
redo01.log                                                              100%   50MB  50.0MB/s   00:01
redo02.log                                                              100%   50MB  50.0MB/s   00:00
redo03.log                                                              100%   50MB  50.0MB/s   00:00

En esta etapa, el nuevo entorno de base de datos contiene todos los archivos necesarios para llevarlo al mismo estado que el origen. Los registros de archivos se deben reproducir por última vez.

SQL> recover database until cancel;
ORA-00279: change 1120099 generated at 05/26/2016 09:59:21 needed for thread 1
ORA-00289: suggestion : /logs/WAFFLE/arch/1_40_912662036.dbf
ORA-00280: change 1120099 for thread 1 is in sequence #40
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00308: cannot open archived log '/logs/WAFFLE/arch/1_40_912662036.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00308: cannot open archived log '/logs/WAFFLE/arch/1_40_912662036.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Una vez finalizado, los redo logs se deben volver a reproducir. Si el mensaje Media recovery complete se devuelve, el proceso se realiza correctamente y las bases de datos se sincronizan y se pueden abrir.
```
SQL> recover database;
Media recovery complete.
SQL> alter database open;
Database altered.
```

Envío de registros: ASM al sistema de archivos

Este ejemplo muestra el uso de Oracle RMAN para migrar una base de datos. Es muy similar al ejemplo anterior del envío de registros del sistema de archivos al sistema de archivos, pero los archivos de ASM no son visibles para el host. La única opción para migrar datos ubicados en dispositivos ASM es mediante la reubicación del LUN de ASM o mediante Oracle RMAN para realizar las operaciones de copia.

Aunque RMAN es un requisito para copiar archivos de Oracle ASM, el uso de RMAN no se limita a ASM. RMAN se puede utilizar para migrar de cualquier tipo de almacenamiento a cualquier otro tipo.

Este ejemplo muestra la reubicación de una base de datos llamada PANCAKE del almacenamiento de ASM a un sistema de archivos normal ubicado en un servidor diferente en las rutas de acceso /oradata y.. /logs.

Crear copia de seguridad de base de datos

El primer paso es crear una copia de seguridad de la base de datos que se migrará a un servidor alternativo. Dado que el origen utiliza Oracle ASM, se debe utilizar RMAN. Se puede realizar una copia de seguridad simple de RMAN del siguiente modo. Este método crea una copia de seguridad etiquetada que RMAN puede identificar fácilmente más adelante en el procedimiento.

El primer comando define el tipo de destino para la copia de seguridad y la ubicación que se utilizará. El segundo inicia la copia de seguridad de los archivos de datos solamente.

RMAN> configure channel device type disk format '/rman/pancake/%U';
using target database control file instead of recovery catalog
old RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/rman/pancake/%U';
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/rman/pancake/%U';
new RMAN configuration parameters are successfully stored
RMAN> backup database tag 'ONTAP_MIGRATION';
Starting backup at 24-MAY-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=251 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=+ASM0/PANCAKE/system01.dbf
input datafile file number=00002 name=+ASM0/PANCAKE/sysaux01.dbf
input datafile file number=00003 name=+ASM0/PANCAKE/undotbs101.dbf
input datafile file number=00004 name=+ASM0/PANCAKE/users01.dbf
channel ORA_DISK_1: starting piece 1 at 24-MAY-16
channel ORA_DISK_1: finished piece 1 at 24-MAY-16
piece handle=/rman/pancake/1gr6c161_1_1 tag=ONTAP_MIGRATION comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting full 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 24-MAY-16
channel ORA_DISK_1: finished piece 1 at 24-MAY-16
piece handle=/rman/pancake/1hr6c164_1_1 tag=ONTAP_MIGRATION comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 24-MAY-16

Copia de seguridad del archivo de control

Se necesita un archivo de control de copia de seguridad más adelante en el procedimiento del duplicate database funcionamiento.

RMAN> backup current controlfile format '/rman/pancake/ctrl.bkp';
Starting backup at 24-MAY-16
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 24-MAY-16
channel ORA_DISK_1: finished piece 1 at 24-MAY-16
piece handle=/rman/pancake/ctrl.bkp tag=TAG20160524T032651 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 24-MAY-16

Archivo de parámetros de copia de seguridad

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

Script de cambio de nombre de archivo de ASM

Varias ubicaciones de archivos definidas actualmente en los controlfiles cambian cuando se mueve la base de datos. El siguiente archivo de comandos crea un archivo de comandos de RMAN para facilitar el proceso. Este ejemplo muestra una base de datos con un número muy pequeño de archivos de datos, pero normalmente las bases de datos contienen cientos o incluso miles de archivos de datos.

Este script se puede encontrar en "Conversión de ASM a Nombre de Sistema de Archivos" y hace dos cosas.

En primer lugar, crea un parámetro para redefinir las ubicaciones de redo log llamadas log_file_name_convert. Es esencialmente una lista de campos alternos. El primer campo es la ubicación de un redo log actual y el segundo campo es la ubicación del nuevo servidor. El patrón se repite entonces.

La segunda función consiste en proporcionar una plantilla para el cambio de nombre del archivo de datos. El archivo de comandos pasa por los archivos de datos, extrae la información del nombre y el número de archivo y lo formatea como un archivo de comandos de RMAN. A continuación, hace lo mismo con los archivos temporales. El resultado es un script de rman simple que se puede editar como se desee para asegurarse de que los archivos se restauran en la ubicación deseada.

SQL> @/rman/mk.rename.scripts.sql
Parameters for log file conversion:
*.log_file_name_convert = '+ASM0/PANCAKE/redo01.log',
'/NEW_PATH/redo01.log','+ASM0/PANCAKE/redo02.log',
'/NEW_PATH/redo02.log','+ASM0/PANCAKE/redo03.log', '/NEW_PATH/redo03.log'
rman duplication script:
run
{
set newname for datafile 1 to '+ASM0/PANCAKE/system01.dbf';
set newname for datafile 2 to '+ASM0/PANCAKE/sysaux01.dbf';
set newname for datafile 3 to '+ASM0/PANCAKE/undotbs101.dbf';
set newname for datafile 4 to '+ASM0/PANCAKE/users01.dbf';
set newname for tempfile 1 to '+ASM0/PANCAKE/temp01.dbf';
duplicate target database for standby backup location INSERT_PATH_HERE;
}
PL/SQL procedure successfully completed.

Captura la salida de esta pantalla. La log_file_name_convert el parámetro se coloca en el archivo pfile como se describe a continuación. El archivo de datos RENAME y el archivo de comandos DUPLICATE de RMAN se deben editar en consecuencia para colocar los archivos de datos en las ubicaciones deseadas. En este ejemplo, se colocan todos /oradata/pancake.

run
{
set newname for datafile 1 to '/oradata/pancake/pancake.dbf';
set newname for datafile 2 to '/oradata/pancake/sysaux.dbf';
set newname for datafile 3 to '/oradata/pancake/undotbs1.dbf';
set newname for datafile 4 to '/oradata/pancake/users.dbf';
set newname for tempfile 1 to '/oradata/pancake/temp.dbf';
duplicate target database for standby backup location '/rman/pancake';
}

Preparar la estructura de directorios

Los scripts están casi listos para ejecutarse, pero primero debe estar la estructura de directorios en su lugar. Si los directorios necesarios no están ya presentes, se deben crear o el procedimiento de inicio de la base de datos falla. El ejemplo siguiente refleja los requisitos mínimos.

[oracle@jfsc2 ~]$ mkdir /oradata/pancake
[oracle@jfsc2 ~]$ mkdir /logs/pancake
[oracle@jfsc2 ~]$ cd /orabin/admin
[oracle@jfsc2 admin]$ mkdir PANCAKE
[oracle@jfsc2 admin]$ cd PANCAKE
[oracle@jfsc2 PANCAKE]$ mkdir adump dpdump pfile scripts xdb_wallet

Crear entrada oratab

El siguiente comando es necesario para que utilidades como oraenv funcionen correctamente.

PANCAKE:/orabin/product/12.1.0/dbhome_1:N

Actualizaciones de parámetros

El archivo pfile guardado se debe actualizar para reflejar cualquier cambio de ruta en el nuevo servidor. El script de duplicación de RMAN modifica los cambios de la ruta de acceso del archivo de datos y casi todas las bases de datos requieren cambios en el control_files y.. log_archive_dest parámetros. Es posible que también haya ubicaciones de archivos de auditoría que deban modificarse y parámetros como db_create_file_dest Puede que no sea relevante fuera de ASM. Un DBA con experiencia debe revisar cuidadosamente los cambios propuestos antes de continuar.

En este ejemplo, los cambios clave son las ubicaciones del archivo de control, el destino del archivo de registro y la adición del log_file_name_convert parámetro.

PANCAKE.__data_transfer_cache_size=0
PANCAKE.__db_cache_size=545259520
PANCAKE.__java_pool_size=4194304
PANCAKE.__large_pool_size=25165824
PANCAKE.__oracle_base='/orabin'#ORACLE_BASE set from environment
PANCAKE.__pga_aggregate_target=268435456
PANCAKE.__sga_target=805306368
PANCAKE.__shared_io_pool_size=29360128
PANCAKE.__shared_pool_size=192937984
PANCAKE.__streams_pool_size=0
*.audit_file_dest='/orabin/admin/PANCAKE/adump'
*.audit_trail='db'
*.compatible='12.1.0.2.0'
*.control_files='+ASM0/PANCAKE/control01.ctl','+ASM0/PANCAKE/control02.ctl'
*.control_files='/oradata/pancake/control01.ctl','/logs/pancake/control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='PANCAKE'
*.diagnostic_dest='/orabin'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=PANCAKEXDB)'
*.log_archive_dest_1='LOCATION=+ASM1'
*.log_archive_dest_1='LOCATION=/logs/pancake'
*.log_archive_format='%t_%s_%r.dbf'
'/logs/path/redo02.log'
*.log_file_name_convert = '+ASM0/PANCAKE/redo01.log', '/logs/pancake/redo01.log', '+ASM0/PANCAKE/redo02.log', '/logs/pancake/redo02.log', '+ASM0/PANCAKE/redo03.log',  '/logs/pancake/redo03.log'
*.open_cursors=300
*.pga_aggregate_target=256m
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=768m
*.undo_tablespace='UNDOTBS1'

Después de confirmar los nuevos parámetros, los parámetros deben ponerse en vigor. Existen varias opciones, pero la mayoría de los clientes crean un spfile basado en el archivo pfile de texto.

bash-4.1$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Fri Jan 8 11:17:40 2016
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Connected to an idle instance.
SQL> create spfile from pfile='/rman/pancake/pfile';
File created.

Inicio nomount

El último paso antes de replicar la base de datos es abrir los procesos de la base de datos pero no montar los archivos. En este paso, los problemas con el spfile pueden hacerse evidentes. Si la startup nomount el comando falla debido a un error de parámetro, es fácil de cerrar, corregir la plantilla pfile, recargarla como spfile e intentarlo de nuevo.

SQL> startup nomount;
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

Duplique la base de datos

La restauración de la copia de seguridad de RMAN anterior en la nueva ubicación consume más tiempo que otros pasos de este proceso. La base de datos se debe duplicar sin cambiar el identificador de base de datos (DBID) ni restablecer los logs. Esto evita que se apliquen los logs, lo que es un paso necesario para sincronizar completamente las copias.

Conéctese a la base de datos con RMAN como aux y emita el comando DUPLICATE DATABASE mediante el script creado en un paso anterior.

[oracle@jfsc2 pancake]$ rman auxiliary /
Recovery Manager: Release 12.1.0.2.0 - Production on Tue May 24 03:04:56 2016
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
connected to auxiliary database: PANCAKE (not mounted)
RMAN> run
2> {
3> set newname for datafile 1 to '/oradata/pancake/pancake.dbf';
4> set newname for datafile 2 to '/oradata/pancake/sysaux.dbf';
5> set newname for datafile 3 to '/oradata/pancake/undotbs1.dbf';
6> set newname for datafile 4 to '/oradata/pancake/users.dbf';
7> set newname for tempfile 1 to '/oradata/pancake/temp.dbf';
8> duplicate target database for standby backup location '/rman/pancake';
9> }
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting Duplicate Db at 24-MAY-16
contents of Memory Script:
{
   restore clone standby controlfile from  '/rman/pancake/ctrl.bkp';
}
executing Memory Script
Starting restore at 24-MAY-16
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=243 device type=DISK
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/oradata/pancake/control01.ctl
output file name=/logs/pancake/control02.ctl
Finished restore at 24-MAY-16
contents of Memory Script:
{
   sql clone 'alter database mount standby database';
}
executing Memory Script
sql statement: alter database mount standby database
released channel: ORA_AUX_DISK_1
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=243 device type=DISK
contents of Memory Script:
{
   set newname for tempfile  1 to
 "/oradata/pancake/temp.dbf";
   switch clone tempfile all;
   set newname for datafile  1 to
 "/oradata/pancake/pancake.dbf";
   set newname for datafile  2 to
 "/oradata/pancake/sysaux.dbf";
   set newname for datafile  3 to
 "/oradata/pancake/undotbs1.dbf";
   set newname for datafile  4 to
 "/oradata/pancake/users.dbf";
   restore
   clone database
   ;
}
executing Memory Script
executing command: SET NEWNAME
renamed tempfile 1 to /oradata/pancake/temp.dbf in control file
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 24-MAY-16
using channel ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to /oradata/pancake/pancake.dbf
channel ORA_AUX_DISK_1: restoring datafile 00002 to /oradata/pancake/sysaux.dbf
channel ORA_AUX_DISK_1: restoring datafile 00003 to /oradata/pancake/undotbs1.dbf
channel ORA_AUX_DISK_1: restoring datafile 00004 to /oradata/pancake/users.dbf
channel ORA_AUX_DISK_1: reading from backup piece /rman/pancake/1gr6c161_1_1
channel ORA_AUX_DISK_1: piece handle=/rman/pancake/1gr6c161_1_1 tag=ONTAP_MIGRATION
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:07
Finished restore at 24-MAY-16
contents of Memory Script:
{
   switch clone datafile all;
}
executing Memory Script
datafile 1 switched to datafile copy
input datafile copy RECID=5 STAMP=912655725 file name=/oradata/pancake/pancake.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=6 STAMP=912655725 file name=/oradata/pancake/sysaux.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=7 STAMP=912655725 file name=/oradata/pancake/undotbs1.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=8 STAMP=912655725 file name=/oradata/pancake/users.dbf
Finished Duplicate Db at 24-MAY-16

Replicación de registro inicial

Ahora debe enviar los cambios de la base de datos de origen a una nueva ubicación. Si lo hace, puede que sea necesario realizar una combinación de pasos. El método más sencillo sería tener RMAN en la base de datos de origen escribir archive logs en una conexión de red compartida. Si una ubicación compartida no está disponible, un método alternativo es utilizar RMAN para escribir en un sistema de archivos local y, a continuación, utilizar rcp o rsync para copiar los archivos.

En este ejemplo, la /rman Directory es un recurso compartido NFS que está disponible tanto para la base de datos original como para la migrada.

Una cuestión importante aquí es la disk format cláusula. El formato de disco del backup es %h_%e_%a.dbf, Lo que significa que debe utilizar el formato de número de hilo, número de secuencia e identificador de activación para la base de datos. Aunque las letras son diferentes, esto coincide con log_archive_format='%t_%s_%r.dbf en el pfile. Este parámetro también especifica archive logs en el formato de Núm. De thread, Núm. De secuencia e ID de activación. El resultado final es que los backups de los archivos de registro del origen utilizan una convención de nomenclatura que espera la base de datos. Al hacerlo, se realizan operaciones como recover database mucho más sencillo porque sqlplus anticipa correctamente los nombres de los archive logs que se van a reproducir.

RMAN> configure channel device type disk format '/rman/pancake/logship/%h_%e_%a.dbf';
old RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/rman/pancake/arch/%h_%e_%a.dbf';
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/rman/pancake/logship/%h_%e_%a.dbf';
new RMAN configuration parameters are successfully stored
released channel: ORA_DISK_1
RMAN> backup as copy archivelog from time 'sysdate-2';
Starting backup at 24-MAY-16
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=373 device type=DISK
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=54 RECID=70 STAMP=912658508
output file name=/rman/pancake/logship/1_54_912576125.dbf RECID=123 STAMP=912659482
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=41 RECID=29 STAMP=912654101
output file name=/rman/pancake/logship/1_41_912576125.dbf RECID=124 STAMP=912659483
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01
...
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=45 RECID=33 STAMP=912654688
output file name=/rman/pancake/logship/1_45_912576125.dbf RECID=152 STAMP=912659514
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=47 RECID=36 STAMP=912654809
output file name=/rman/pancake/logship/1_47_912576125.dbf RECID=153 STAMP=912659515
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01
Finished backup at 24-MAY-16

Reproducción de log inicial

Una vez que los archivos están en la ubicación del archive log, se pueden reproducir emitiendo el comando recover database until cancel seguido de la respuesta AUTO para reproducir automáticamente todos los logs disponibles. El archivo de parámetros está dirigiendo los archive logs al /logs/archive, Pero esto no coincide con la ubicación en la que se utilizó RMAN para guardar registros. La ubicación se puede redirigir temporalmente de la siguiente manera antes de recuperar la base de datos.

SQL> alter system set log_archive_dest_1='LOCATION=/rman/pancake/logship' scope=memory;
System altered.
SQL> recover standby database until cancel;
ORA-00279: change 560224 generated at 05/24/2016 03:25:53 needed for thread 1
ORA-00289: suggestion : /rman/pancake/logship/1_49_912576125.dbf
ORA-00280: change 560224 for thread 1 is in sequence #49
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00279: change 560353 generated at 05/24/2016 03:29:17 needed for thread 1
ORA-00289: suggestion : /rman/pancake/logship/1_50_912576125.dbf
ORA-00280: change 560353 for thread 1 is in sequence #50
ORA-00278: log file '/rman/pancake/logship/1_49_912576125.dbf' no longer needed
for this recovery
...
ORA-00279: change 560591 generated at 05/24/2016 03:33:56 needed for thread 1
ORA-00289: suggestion : /rman/pancake/logship/1_54_912576125.dbf
ORA-00280: change 560591 for thread 1 is in sequence #54
ORA-00278: log file '/rman/pancake/logship/1_53_912576125.dbf' no longer needed
for this recovery
ORA-00308: cannot open archived log '/rman/pancake/logship/1_54_912576125.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

La respuesta final del archive log informa de un error, pero esto es normal. El error indica que sqlplus estaba buscando un archivo log en particular y no lo encontró. La razón es más probable que el archivo log no exista aún.

Replicación y repetición de log incremental

En la mayoría de los casos, la migración no se realiza de forma inmediata. Pueden pasar días o incluso semanas antes de que se complete el proceso de migración, lo que significa que los registros deben enviarse continuamente a la base de datos de réplica y reproducirse. Al hacerlo, se garantiza que se deban transferir y reproducir unos datos mínimos al llegar la transición.

Este proceso se puede programar fácilmente. Por ejemplo, el siguiente comando se puede programar en la base de datos original para asegurarse de que la ubicación utilizada para el envío de registros se actualiza continuamente.

[oracle@jfsc1 pancake]$ cat copylogs.rman
configure channel device type disk format '/rman/pancake/logship/%h_%e_%a.dbf';
backup as copy archivelog from time 'sysdate-2';

[oracle@jfsc1 pancake]$ rman target / cmdfile=copylogs.rman
Recovery Manager: Release 12.1.0.2.0 - Production on Tue May 24 04:36:19 2016
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
connected to target database: PANCAKE (DBID=3574534589)
RMAN> configure channel device type disk format '/rman/pancake/logship/%h_%e_%a.dbf';
2> backup as copy archivelog from time 'sysdate-2';
3>
4>
using target database control file instead of recovery catalog
old RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/rman/pancake/logship/%h_%e_%a.dbf';
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/rman/pancake/logship/%h_%e_%a.dbf';
new RMAN configuration parameters are successfully stored
Starting backup at 24-MAY-16
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=369 device type=DISK
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=54 RECID=123 STAMP=912659482
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 05/24/2016 04:36:22
ORA-19635: input and output file names are identical: /rman/pancake/logship/1_54_912576125.dbf
continuing other job steps, job failed will not be re-run
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=41 RECID=124 STAMP=912659483
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 05/24/2016 04:36:23
ORA-19635: input and output file names are identical: /rman/pancake/logship/1_41_912576125.dbf
continuing other job steps, job failed will not be re-run
...
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=45 RECID=152 STAMP=912659514
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 05/24/2016 04:36:55
ORA-19635: input and output file names are identical: /rman/pancake/logship/1_45_912576125.dbf
continuing other job steps, job failed will not be re-run
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=47 RECID=153 STAMP=912659515
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 05/24/2016 04:36:57
ORA-19635: input and output file names are identical: /rman/pancake/logship/1_47_912576125.dbf
Recovery Manager complete.

Una vez recibidos los registros, deben reproducirse. Ejemplos anteriores mostraron el uso de sqlplus para ejecutar manualmente recover database until cancel, que se puede automatizar fácilmente. El ejemplo que se muestra aquí utiliza el script descrito en "Logs de Reproducción en Base de Datos en Espera". El script acepta un argumento que especifica la base de datos que necesita una operación de reproducción. Este proceso permite utilizar el mismo script en un esfuerzo de migración de varias bases de datos.

[root@jfsc2 pancake]# ./replaylogs.pl PANCAKE
ORACLE_SID = [oracle] ? The Oracle base has been set to /orabin
SQL*Plus: Release 12.1.0.2.0 Production on Tue May 24 04:47:10 2016
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> ORA-00279: change 560591 generated at 05/24/2016 03:33:56 needed for thread 1
ORA-00289: suggestion : /rman/pancake/logship/1_54_912576125.dbf
ORA-00280: change 560591 for thread 1 is in sequence #54
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 562219 generated at 05/24/2016 04:15:08 needed for thread 1
ORA-00289: suggestion : /rman/pancake/logship/1_55_912576125.dbf
ORA-00280: change 562219 for thread 1 is in sequence #55
ORA-00278: log file '/rman/pancake/logship/1_54_912576125.dbf' no longer needed for this recovery
ORA-00279: change 562370 generated at 05/24/2016 04:19:18 needed for thread 1
ORA-00289: suggestion : /rman/pancake/logship/1_56_912576125.dbf
ORA-00280: change 562370 for thread 1 is in sequence #56
ORA-00278: log file '/rman/pancake/logship/1_55_912576125.dbf' no longer needed for this recovery
...
ORA-00279: change 563137 generated at 05/24/2016 04:36:20 needed for thread 1
ORA-00289: suggestion : /rman/pancake/logship/1_65_912576125.dbf
ORA-00280: change 563137 for thread 1 is in sequence #65
ORA-00278: log file '/rman/pancake/logship/1_64_912576125.dbf' no longer needed for this recovery
ORA-00308: cannot open archived log '/rman/pancake/logship/1_65_912576125.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
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

Transición

Cuando esté listo para pasar al nuevo entorno, debe realizar una sincronización final. Cuando se trabaja con sistemas de archivos normales, es fácil asegurarse de que la base de datos migrada esté sincronizada al 100% con la original, ya que los redo logs originales se copian y se vuelven a reproducir. No hay una buena forma de hacerlo con ASM. Sólo los archive logs se pueden volver a copiar fácilmente. Para asegurarse de que no se pierden datos, el cierre final de la base de datos original debe realizarse con cuidado.

En primer lugar, la base de datos debe estar en modo inactivo, asegurándose de que no se realicen cambios. Esta desactivación puede incluir la desactivación de las operaciones programadas, el cierre de listeners y/o el cierre de aplicaciones.
Después de realizar este paso, la mayoría de los DBA crean una tabla ficticia que sirve como marcador del cierre.

Forzar un archivo log para asegurarse de que la creación de la tabla ficticia se registra en los archive logs. Para ello, ejecute los siguientes comandos:

SQL> create table cutovercheck as select * from dba_users;
Table created.
SQL> alter system archive log current;
System altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

Para copiar el último de los archive logs, ejecute los siguientes comandos. La base de datos debe estar disponible pero no abierta.

SQL> startup mount;
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
Database mounted.

Para copiar los archive logs, ejecute los siguientes comandos:

RMAN> configure channel device type disk format '/rman/pancake/logship/%h_%e_%a.dbf';
2> backup as copy archivelog from time 'sysdate-2';
3>
4>
using target database control file instead of recovery catalog
old RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/rman/pancake/logship/%h_%e_%a.dbf';
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/rman/pancake/logship/%h_%e_%a.dbf';
new RMAN configuration parameters are successfully stored
Starting backup at 24-MAY-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=8 device type=DISK
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=54 RECID=123 STAMP=912659482
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 05/24/2016 04:58:24
ORA-19635: input and output file names are identical: /rman/pancake/logship/1_54_912576125.dbf
continuing other job steps, job failed will not be re-run
...
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=45 RECID=152 STAMP=912659514
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 05/24/2016 04:58:58
ORA-19635: input and output file names are identical: /rman/pancake/logship/1_45_912576125.dbf
continuing other job steps, job failed will not be re-run
channel ORA_DISK_1: starting archived log copy
input archived log thread=1 sequence=47 RECID=153 STAMP=912659515
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 05/24/2016 04:59:00
ORA-19635: input and output file names are identical: /rman/pancake/logship/1_47_912576125.dbf

Por último, vuelva a reproducir los archive logs restantes en el nuevo servidor.

[root@jfsc2 pancake]# ./replaylogs.pl PANCAKE
ORACLE_SID = [oracle] ? The Oracle base has been set to /orabin
SQL*Plus: Release 12.1.0.2.0 Production on Tue May 24 05:00:53 2016
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> ORA-00279: change 563137 generated at 05/24/2016 04:36:20 needed for thread 1
ORA-00289: suggestion : /rman/pancake/logship/1_65_912576125.dbf
ORA-00280: change 563137 for thread 1 is in sequence #65
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 563629 generated at 05/24/2016 04:55:20 needed for thread 1
ORA-00289: suggestion : /rman/pancake/logship/1_66_912576125.dbf
ORA-00280: change 563629 for thread 1 is in sequence #66
ORA-00278: log file '/rman/pancake/logship/1_65_912576125.dbf' no longer needed
for this recovery
ORA-00308: cannot open archived log '/rman/pancake/logship/1_66_912576125.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
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

En esta fase, replique todos los datos. La base de datos está lista para convertirse de una base de datos en espera a una base de datos operativa activa y, a continuación, abrirse.
```
SQL> alter database activate standby database;
Database altered.
SQL> alter database open;
Database altered.
```

Confirme la presencia de la tabla ficticia y, a continuación, suéltela.

SQL> desc cutovercheck
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 USERNAME                                  NOT NULL VARCHAR2(128)
 USER_ID                                   NOT NULL NUMBER
 PASSWORD                                           VARCHAR2(4000)
 ACCOUNT_STATUS                            NOT NULL VARCHAR2(32)
 LOCK_DATE                                          DATE
 EXPIRY_DATE                                        DATE
 DEFAULT_TABLESPACE                        NOT NULL VARCHAR2(30)
 TEMPORARY_TABLESPACE                      NOT NULL VARCHAR2(30)
 CREATED                                   NOT NULL DATE
 PROFILE                                   NOT NULL VARCHAR2(128)
 INITIAL_RSRC_CONSUMER_GROUP                        VARCHAR2(128)
 EXTERNAL_NAME                                      VARCHAR2(4000)
 PASSWORD_VERSIONS                                  VARCHAR2(12)
 EDITIONS_ENABLED                                   VARCHAR2(1)
 AUTHENTICATION_TYPE                                VARCHAR2(8)
 PROXY_ONLY_CONNECT                                 VARCHAR2(1)
 COMMON                                             VARCHAR2(3)
 LAST_LOGIN                                         TIMESTAMP(9) WITH TIME ZONE
 ORACLE_MAINTAINED                                  VARCHAR2(1)
SQL> drop table cutovercheck;
Table dropped.

Migración de redo log no disruptiva

Hay veces en las que una base de datos está correctamente organizada en general con la excepción de los redo logs. Esto puede ocurrir por muchos motivos, el más común de los cuales está relacionado con las copias Snapshot. Productos como SnapManager para Oracle, SnapCenter y el marco de gestión de almacenamiento Snap Creator de NetApp permiten la recuperación casi instantánea de una base de datos, pero únicamente si revierte el estado de los volúmenes de archivos de datos. Si los redo logs comparten espacio con los archivos de datos, la reversión no se puede realizar de forma segura porque podría provocar la destrucción de los redo logs, lo que probablemente significa pérdida de datos. Por lo tanto, los redo logs deben reubicarse.

Este procedimiento es sencillo y puede realizarse sin interrupciones.

Configuración actual de redo log

Identifique el Núm. De grupos de redo logs y sus respectivos Núm.s de grupo.

SQL> select group#||' '||member from v$logfile;
GROUP#||''||MEMBER
--------------------------------------------------------------------------------
1 /redo0/NTAP/redo01a.log
1 /redo1/NTAP/redo01b.log
2 /redo0/NTAP/redo02a.log
2 /redo1/NTAP/redo02b.log
3 /redo0/NTAP/redo03a.log
3 /redo1/NTAP/redo03b.log
rows selected.

Introduzca el tamaño de los redo logs.

SQL> select group#||' '||bytes from v$log;
GROUP#||''||BYTES
--------------------------------------------------------------------------------
1 524288000
2 524288000
3 524288000

Crear nuevos logs

Para cada redo log, cree un nuevo grupo con un tamaño y un Núm. De miembros coincidentes.

SQL> alter database add logfile ('/newredo0/redo01a.log', '/newredo1/redo01b.log') size 500M;
Database altered.
SQL> alter database add logfile ('/newredo0/redo02a.log', '/newredo1/redo02b.log') size 500M;
Database altered.
SQL> alter database add logfile ('/newredo0/redo03a.log', '/newredo1/redo03b.log') size 500M;
Database altered.
SQL>

Verifique la nueva configuración.

SQL> select group#||' '||member from v$logfile;
GROUP#||''||MEMBER
--------------------------------------------------------------------------------
1 /redo0/NTAP/redo01a.log
1 /redo1/NTAP/redo01b.log
2 /redo0/NTAP/redo02a.log
2 /redo1/NTAP/redo02b.log
3 /redo0/NTAP/redo03a.log
3 /redo1/NTAP/redo03b.log
4 /newredo0/redo01a.log
4 /newredo1/redo01b.log
5 /newredo0/redo02a.log
5 /newredo1/redo02b.log
6 /newredo0/redo03a.log
6 /newredo1/redo03b.log
12 rows selected.

Borre los registros antiguos

Borre los registros antiguos (grupos 1, 2 y 3).

SQL> alter database drop logfile group 1;
Database altered.
SQL> alter database drop logfile group 2;
Database altered.
SQL> alter database drop logfile group 3;
Database altered.

Si encuentra un error que le impide borrar un log activo, fuerce un cambio al siguiente log para liberar el bloqueo y forzar un punto de control global. Vea el siguiente ejemplo de este proceso. Se ha denegado el intento de borrar el grupo de archivos de registro 2, que se encontraba en la ubicación anterior, porque todavía había datos activos en este archivo de registro.
```
SQL> alter database drop logfile group 2;
alter database drop logfile group 2
*
ERROR at line 1:
ORA-01623: log 2 is current log for instance NTAP (thread 1) - cannot drop
ORA-00312: online log 2 thread 1: '/redo0/NTAP/redo02a.log'
ORA-00312: online log 2 thread 1: '/redo1/NTAP/redo02b.log'
```

Un archivo log seguido de un punto de control permite borrar el archivo log.

SQL> alter system archive log current;
System altered.
SQL> alter system checkpoint;
System altered.
SQL> alter database drop logfile group 2;
Database altered.

A continuación, elimine los registros del sistema de archivos. Debe realizar este proceso con extremo cuidado.

Trasvase de registros

Creating your file...

Envío de registros: Sistema de archivos al sistema de archivos

Crear copia de seguridad de base de datos

Entorno Oracle

Restauración al nuevo entorno

Crear plantilla de creación de archivo de control

Archivo de parámetros de copia de seguridad

Crear entrada oratab

Preparar la estructura de directorios

Actualizaciones de archivos de parámetros

Vuelva a crear los archivos de control

Replicación de registro inicial

Reproducción de log inicial

Replicación y repetición de log incremental

Transición

Envío de registros: ASM al sistema de archivos

Crear copia de seguridad de base de datos

Copia de seguridad del archivo de control

Archivo de parámetros de copia de seguridad

Script de cambio de nombre de archivo de ASM

Preparar la estructura de directorios

Crear entrada oratab

Actualizaciones de parámetros

Inicio nomount

Duplique la base de datos

Replicación de registro inicial

Reproducción de log inicial

Replicación y repetición de log incremental

Transición

Migración de redo log no disruptiva

Configuración actual de redo log

Crear nuevos logs

Borre los registros antiguos