Migrando una base de datos de filesystem hacia ASM con RMAN

‘Automatic Storage Managemet’ o ASM es una herramienta que integra un sistema de archivos de de alta disponibilidad y  un manejador de discos. Permite una administración avanzada de almacenamiento y elimina la necesidad de administrar manualmente discos y archivos de base de datos.  

 Pueden leer mas sobre ASM aquí.

Evidentemente, proporciona una ventaja superior comparada con almacenamiento normal de sistema operativo. Es por eso que a continuación voy a mostrar los pasos necesarios para migrar una base de datos que actualmente reside en archivos de sistema operativo hacia una instancia ASM.

La única herramienta capaz de realizar esta operación es RMAN, herramienta ya conocida para realizar tareas de respaldo y recuperación en una base de datos Oracle, esta herramienta es capaz de interactuar con ambos tipos de sistema de archivo.


Escenario inicial:


Tengo una instancia de base de datos denominada orcl, la base de datos actualmente reside en el sistema de archivos ext4, propio de Linux. También he creado una instancia ASM con el nombre default y un único diskgruop llamado DATA sobre el cual vamos a migrar los archivos de base de datos.

Para esta operación vamos a migrar los siguientes archivos que conforman la base de datos:
  • Control Files
  • Data Files
  • Online Redo Log files
  • Temporary files

Las ubicaciones físicas son las siguientes:

Control Files:
SQL> show parameter control_files

NAME                            TYPE    VALUE
----------------------------- ----------- --------------
control_files                   string  /oradata/orcl/control01.ctl,
                                         /oradata/orcl/control02.ctl

Data Files:
SQL> select file_id,file_name,tablespace_name from dba_Data_files;

   FILE_ID FILE_NAME                        TABLESPACE_NAME
---------- ------------------------------ --------------------
        4 /oradata/orcl/users01.dbf                USERS
        3 /oradata/orcl/undotbs01.dbf              UNDOTBS1
        2 /oradata/orcl/sysaux01.dbf               SYSAUX
        1 /oradata/orcl/system01.dbf               SYSTEM
        5 /oradata/orcl/example01.dbf              EXAMPLE

Online Redo Log files:
SQL> select * from v$logfile;

    GROUP# STATUS  TYPE    MEMBER                IS_
---------- ------- ------- ------------------------- ---
        3           ONLINE  /oradata/orcl/redo03.log    NO
        2           ONLINE  /oradata/orcl/redo02.log    NO
        1           ONLINE  /oradata/orcl/redo01.log    NO

Temporary files:
SQL> select file_id,file_name,tablespace_name from dba_temp_files;

   FILE_ID FILE_NAME                        TABLESPACE_NAME
---------- -------------------------------------- --------------------
        1   /oradata/orcl/temp01.dbf               TEMP


Paso 1: Migrando Control Files


Para migrar los Control File debemos establecer como nueva ubicación de estos el disco +DATA de la instancia ASM mediante el parámetro CONTROL_FILES y luego con la base de datos desmontada restaurar una copia del archivo actual utilizando RMAN.
SQL> alter system set control_files='+DATA' scope=spfile;

System altered.


SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.


SQL> startup nomount;
ORACLE instance started.

Total System Global Area  730714112 bytes
Fixed Size              2256832 bytes
Variable Size         566231104 bytes
Database Buffers      159383552 bytes
Redo Buffers            2842624 bytes


Restauramos el Control File desde RMAN hacia la nueva ubicación en ASM
RMAN> restore controlfile     
2> from '/oradata/orcl/control01.ctl';

Starting restore at 05-JUN-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=25 device type=DISK

channel ORA_DISK_1: copied control file copy
output file name=+DATA/orcl/controlfile/current.256.913682533
Finished restore at 05-JUN-16

Paso 2: Migrando Datafiles


Una vez restaurados los Control Files, podemos montar la base de datos. En estado MOUNT realizamos un ‘backup as copy’ de los actuales datafiles e inmediatamente los restauramos hacia la instancia ASM mediante un ‘switch database to copy’
RMAN> startup mount;

connected to target database (not started)
Oracle instance started
database mounted

Total System Global Area     730714112 bytes

Fixed Size                     2256832 bytes
Variable Size                566231104 bytes
Database Buffers             159383552 bytes
Redo Buffers                   2842624 bytes


RMAN> backup as copy database format '+DATA';

Starting backup at 05-JUN-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=26 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=/oradata/orcl/system01.dbf
output file name=+DATA/orcl/datafile/system.257.913682719 tag=TAG20160605T004518 RECID=2 STAMP=913682871
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:02:35
channel ORA_DISK_1: starting datafile copy
input datafile file number=00002 name=/oradata/orcl/sysaux01.dbf
output file name=+DATA/orcl/datafile/sysaux.258.913682875 tag=TAG20160605T004518 RECID=3 STAMP=913682979
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:55
channel ORA_DISK_1: starting datafile copy
input datafile file number=00005 name=/oradata/orcl/example01.dbf
output file name=+DATA/orcl/datafile/example.259.913682991 tag=TAG20160605T004518 RECID=4 STAMP=913683054
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:05
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=/oradata/orcl/undotbs01.dbf
output file name=+DATA/orcl/datafile/undotbs1.260.913683055 tag=TAG20160605T004518 RECID=5 STAMP=913683064
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=+DATA/orcl/controlfile/backup.261.913683071 tag=TAG20160605T004518 RECID=6 STAMP=913683075
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=/oradata/orcl/users01.dbf
output file name=+DATA/orcl/datafile/users.262.913683077 tag=TAG20160605T004518 RECID=7 STAMP=913683078
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting full 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 05-JUN-16
channel ORA_DISK_1: finished piece 1 at 05-JUN-16
piece handle=+DATA/orcl/backupset/2016_06_05/nnsnf0_tag20160605t004518_0.263.913683079 tag=TAG20160605T004518 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 05-JUN-16


RMAN> switch database to copy;

datafile 1 switched to datafile copy "+DATA/orcl/datafile/system.257.913682719"
datafile 2 switched to datafile copy "+DATA/orcl/datafile/sysaux.258.913682875"
datafile 3 switched to datafile copy "+DATA/orcl/datafile/undotbs1.260.913683055"
datafile 4 switched to datafile copy "+DATA/orcl/datafile/users.262.913683077"
datafile 5 switched to datafile copy "+DATA/orcl/datafile/example.259.913682991"


Habiendo restaurado los datafiles hacia ASM, podemos abrir la base de datos.
RMAN> alter database open;

database opened

Hasta este punto, aún tenemos un hibrido. Ya que los Online Redo Log Files y Temporary Files aun residen en el sistema de archivos local.

Paso 3: Migrando Online Redo Log Files


 Este paso es sencillo pero puede llegar a ser tedioso, según la cantidad de grupos y miembros de grupos de Online Redo Log que tengamos en nuestra base de datos. Lo primero será agregar nuevos miembros por cada grupo hacia la instancia ASM.
SQL> alter database add logfile member '+DATA' to group 1;

Database altered.

SQL> alter database add logfile member '+DATA' to group 1;

Database altered.

SQL> alter database add logfile member '+DATA' to group 2;

Database altered.

SQL> alter database add logfile member '+DATA' to group 2;

Database altered.

SQL> alter database add logfile member '+DATA' to group 3;

Database altered.

SQL> alter database add logfile member '+DATA' to group 3;

Database altered.

Se deben agregar tantos miembros como sea necesario por cada grupo con el objetivo de reemplazar cada uno de los archivos actuales en el filesystem.

A continuación, vamos a eliminar los miembros actuales utilizando:
SQL> alter database drop logfile member '/oradata/orcl/redo03.log';

Database altered.

SQL> alter database drop logfile member '/oradata/orcl/redo01.log';

Database altered.

SQL> alter database drop logfile member '/oradata/orcl/redo02.log';

Database altered.

Nota importante: No se podrá eliminar un miembro de grupo si el estado del grupo es ACTIVE o CURRENT. Si este el caso debemos ejecutar SQL> alter system switch logfile; hasta que el grupo entero se haya archivado o este inactivo.

Paso 4: Migrando Temporary Files


 Por último, pero no menos importantes esta los archivos temporales. Este paso ya no implica afectación de la base de datos puesto que la instancia puede estar corriendo y la base de datos estar abierta. Lo que haremos será crear un nuevo TEMPORARY TABLESPACE, redirigir nuestra operaciones hacia este y finalmente eliminar el antiguo TABLESPACE  y todo su contenido en sistema de archivos.

SQL> create temporary tablespace tempasm tempfile '+DATA' size 1G;

Tablespace created.

SQL> alter database default temporary tablespace tempasm;

Database altered.

SQL> drop tablespace temp including contents and datafiles;

Tablespace dropped.

Hasta aquí, nuestra base de datos ahora reside en una instancia ASM. Donde podemos disfrutar de las ventajas que ofrece esta herramienta.

Paso 5: Consideraciones finales


Existen parámetros importantes en una instancia que por la forma en que instalamos nuestra base de datos apuntaban a un sistema de archivos normal, para una total migración hacia ASM debemos considerar este tipo de parámetros. En mi caso considerare cambiar los siguientes:
#ruta de archivos de recuperación, backups y ruta default de archives
SQL> alter system set db_recovery_file_dest='+FRA';

System altered.

#ruta para depósito de Archive Log Files
SQL> alter system set log_archive_dest_1='LOCATION=+DATA';

System altered.

#otro parámetro importante podría ser db_create_file_dest si estamos usando OMF

Se puede mantener una base de datos en ambos tipos de sistema de archivos, pero no hay ventaja alguna en mantener un hibrido. Lo mejor y recomendado por Oracle es utilizar el manejador de archivos ASM.

Salud! 3:)

Comments

Post a Comment

Popular posts from this blog

Cómo extraer Archive Logs desde un Backup Piece

RMAN no es de mis herramientas favoritas en Oracle, quizás porque cada vez que nos vemos las caras es porque ha ocurrido algún desastre. En esta ocasión necesitaba extraer Archive Logs para aplicarlos a una operación de RECOVER pero resulta que los archives estaban catalogados en una ubicación externa y fuera de mi alcance. Cuando al fin logre catalogar los archivos de backup que contenían los Archive Logs era necesario colocarlos en una ubicación local para poder aplicarlos. Así que veamos como extraer los archivos necesarios. Una vez catalogados los archivos de backup en nuestro repositorio de RMAN, podemos visualizar los Archives contenidos con el comando LIST BACKUP OF ARCHIVELOG ALL. RMAN> list backup of archivelog all; using target database control file instead of recovery catalog List of Backup Sets =================== BS Key  Size       Device Type Elapsed Time Completion Time ------- ---------- ...
Read more

Ejemplo práctico con SQL Tuning Advisor y SQL Access Advisor

Parte del perfil de un administrador de base de datos es el afinamiento de sentencias SQL, el afinamiento (o tuning) nos ayuda a mejorar el rendimiento de sentencias SQL dentro de nuestras bases de datos, mejorando: tiempos de respuesta de aplicaciones, tiempo de respuesta de procesos batch, consumo de recursos del sistema, escalabilidad de las aplicaciones. En Oracle, la ejecución de una sentencia SQL requiere tres fases: parseo, enlace y ejecución ( parse, bind and execute ). La parte de parseo es la que nos interesa para fines de este artículo. En esta, nuestro servidor interpreta lo que la sentencia significa y cuál es la mejor manera de ejecutarla. El parseo involucra interacción con el segmento de memoria SHARED POOL dentro de la instancia de la base de datos. Las estructuras del SHARED POOL convierten el SQL en algo ejecutable mediante un plan de ejecución. Plan de ejecución: es el resultado de la fase de parseo, indica la forma en cómo se va a acceder a los datos solici...
Read more

Tips para administración de memoria en una base de datos Oracle 11GR2

Image
Gestión de memoria en Oracle 11gR2 Constantemente recibo peticiones para establecer el tamaño ideal de memoria para una instancia de base de datos. Aunque el mejor consejo es manejar un estándar para toda las bases de datos, a veces el valor estándar no es suficiente o es demasiado, todo depende de los recursos con los que contemos y la funcionalidad que tendrá la base de datos. Aunque Oracle recomienda utilizar servidores dedicados para base de datos, en las organizaciones no siempre siguen ese consejo, esto sucede mucho en servidores de desarrollo, pruebas o QA, donde el servidor soporta: aplicación, base de datos, es repositorio de fuentes y hasta servidor ftp (he visto casos). La memoria es uno de los recursos mas valiosos de un servidor, pero, ¿por que rompernos la cabeza buscando un valor ideal para nuestros segmentos de memoria si Oracle puede hacerlo automáticamente y de forma eficiente? A continuación veremos algunos tips para administración eficiente de memoria...
Read more