MERCADOS FINANCIEROS

Track all markets on TradingView

lunes, 9 de noviembre de 2015

Migración de Base de Datos a ASM “Zero Downtime”

Migración de Base de Datos a ASM “Zero Downtime”

Por Joel Pérez
Publicado en enero 2013
Reciban estimados tecnólogos Oracle un cordial saludo. A través del presente artículo, tendremos la oportunidad de visualizar y adentrarnos un poco en el tema de migración o traslado de una base de datos ( BBDD ) Oracle a ASM utilizando RMAN ( Oracle Recovery Manager ).
A partir de la versión de servidor de base de datos 10g contamos con la tecnología de almacenamiento ASM ( Automatic Storage Management ) la cual revoluciono la forma de almacenar y administrar nuestras base de datos.
Anterior al surgimiento de ASM , las opciones típicas de almacenamiento eran filesystems o Raw devices. Los raw devices eran y siguen siendo dispositivos rápidos en acceso, debido a que el sistema operativo no tiene la necesidad de establecer una capa adicional de manejo de volúmenes para trabajar con los mismos.
La desventaja de ellos son varias:
  • Las particiones no pueden ser redimensionadas una vez establecidas
  • Los archive logs de la base de datos no pueden estar almacenados en raw devices por lo poco flexible de sus constitución
  • Si existiese la necesidad de crear nuevos datafiles, se tendría la necesidad de crear nuevos dispositivos raw
  • Y en general son poco flexibles para su administración
Para nosotros los DBAs ASM constituyo un giro de 360 grados de cómo seria la tendencia de almacenamiento y administración de nuestras bases de datos.
  • Ya no habría necesidad de crear varios puntos de montaje o filesystems
  • Los datafiles tendrían mayor protección respecto a su almacenamiento en filesystems
  • Tendríamos a la mano nuevas filosofías de arquitectura de storage: solo 2 Diskgroups para todas las bases de datos
  • Los problemas de I/O por saturación y cuellos de botellas en puntos de monturas serian elementos del pasado al existir el concepto de “Rebalance” entre ASM Disks, etc
  • Estas y 1000 razones mas hay para justificar la migración de nuestras bases de datos de filesystem a ASM
Para el presente artículo desarrollaremos el traslado de una base de datos de filesystem a ASM implementando técnica para realizarlo en concepción “Zero Downtime”.
Una estrategia de migración y/o traslado “Zero Downtime” tiene consigo la concepción de llevar a cabo la tarea en el menos tiempo posible ( segundos…, minutos… ) y por lo general esta asociada a empresas con negocios y servicios de alta criticidad que generalmente trabajan 24x7x365. Este mismo articulo esta desarrollado para llevar a cabo la tarea en filosofía “No Zero Downtime”.
Escenario: se posee una base de datos single instance con todos sus elementos ( Controlfiles, Datafiles, Redo Logs & Archives ) en filesystem y se desea trasladar la misma a ASM. Asumiendo que previamente el software necesario esta instalado, vamos a iniciar la actividad. La técnica utilizada en este articulo es valida para los “Oracle Servers 10g” en adelante
BBDD Origen: SOURCE
Diskgroups disponibles para la migración: +DATA & +FRA
Reconocimiento de los elementos a trasladar de la BBDD “Source”
Reconocimiento de Datafiles:
oracle@MyjpServer ~]$ export ORACLE_SID=SOURCE
[oracle@MyjpServer ~]$
[oracle@MyjpServer ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Jul 28 18:34:39 2012

Copyright (c) 1982, 2008, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - 64bit Production
With the Real Application Clusters option

SQL> select file_name from dba_data_files;

FILE_NAME
--------------------------------------------------------------------------------
/home/oracle/SOURCE/users01.dbf
/home/oracle/SOURCE/undotbs01.dbf
/home/oracle/SOURCE/sysaux01.dbf
/home/oracle/SOURCE/system01.dbf
Reconocimiento de Tempfiles:
SQL> select file_name from dba_temp_files;

FILE_NAME
--------------------------------------------------------------------------------
/home/oracle/SOURCE/temp01.dbf
Reconocimiento de Controlfiles:
SQL> show parameters control_files

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      /home/oracle/SOURCE/control01.
                                                 ctl, /home/oracle/SOURCE/contr
                                                 ol02.ctl, /home/oracle/SOURCE/
                                                 control03.ctl
SQL>
SQL> select NAME from v$controlfile;
NAME
---------------------------------
/home/oracle/SOURCE/control01.ctl
/home/oracle/SOURCE/control02.ctl
/home/oracle/SOURCE/control03.ctl

SQL>
Reconocimiento de Redo Log files:
SQL> select GROUP#, MEMBER from v$logfile;

    GROUP# MEMBER
---------- ---------------------------------
         3 /home/oracle/SOURCE/redo03.log
         2 /home/oracle/SOURCE/redo02.log
         1 /home/oracle/SOURCE/redo01.log
“Backup as Copy” de la BBDD
En esta etapa hemos de iniciar la actividad. La BBDD se encontrara en modo “open” y se estará llevando a cabo un “Hot backup full”. Es de importancia denotar que el objetivo de las técnicas utilizadas en este artículo estarán enfocadas en generar el menor tiempo de “Downtime” posible.
RMAN> backup as copy database format '+DATA';

Starting backup at 06-08-2012 00:05:43
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=/home/oracle/SOURCE/system01.dbf
output file name=+DATA/source/datafile/system.270.790560345 tag=TAG20120806T000543 RECID=7 
 STAMP=790560348
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=/home/oracle/SOURCE/sysaux01.dbf
output file name=+DATA/source/datafile/sysaux.277.790560351 tag=TAG20120806T000543 RECID=8 
 STAMP=790560353
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=/home/oracle/SOURCE/undotbs01.dbf
output file name=+DATA/source/datafile/undotbs1.278.790560355 tag=TAG20120806T000543 RECID=9 
 STAMP=790560354
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=+DATA/source/controlfile/backup.279.790560355 tag=TAG20120806T000543 RECID=10 
 STAMP=790560355
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=/home/oracle/SOURCE/users01.dbf
output file name=+DATA/source/datafile/users.280.790560357 tag=TAG20120806T000543 RECID=11 
 STAMP=790560356
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 06-08-2012 00:05:57
channel ORA_DISK_1: finished piece 1 at 06-08-2012 00:05:58
piece handle=+DATA/source/backupset/2012_08_06/nnsnf0_tag20120806t000543_0.281.790560357 
 tag=TAG20120806T000543 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 06-08-2012 00:05:58

RMAN>
Bajando la BBDD para establecerla en modo mount y aplicar “Switch Database to copy”
Mientras se realiza el “Hot backup full” de la BBDD, se generan archive redo logs. Para que la BBDD se encuentre en un estado consistente respecto a los datafiles alojados en ASM, procederemos a realizar una recuperación completa de la misma para establecer consistencia de todos sus datafiles. En un caso real, el realizar el paso de “Recover” es realmente lo que representara en un 98% el “Downtime” de la actividad. Para ello tenemos que divisar cual es la tasa de generación de archive redo logs de la BBDD en la cual aplicaremos la técnica y cual es el tiempo promedio de “recover” de de archive redo logs en base a su tamaño.
Existen diversos factores que influirán en la rapidez de la etapa de “recover”:
  • Velocidad de acceso en modo lectura del área en la cual se encuentren alojados los archive redo logs
  • Nivel de Paralelismo establecido para la etapa de recuperación si así fuese establecido.
Mientras mejor estén afinadas las condiciones para obtener un rápido proceso de “recover”, en esa misma medida tendremos un “Downtime” mas corto, lo cual es el objetivo a lograr. Es oportuno destacar también que mientras mas tiempo consuma la realización del backup full, en esa medida también se acumularan mas Archive Redo Logs a aplicar en la etapa de “recover”, por lo tanto es importante afinar la rapidez del backup full para tal fin.
A partir de este momento inicia nuestro periodo de “Downtime”. Estableceremos la BBDD en modo “mount” para llevar a cabo el respectivo “Switch Database to copy” y “Recover Database”
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
Nota: se aconseja en este punto tomar backup de alguno de los controlfiles originales. Por estar en filesystem, bastara con realizar una simple copia con comando cp del sistema operativo ( Linux, Unix ), copy ( Windows ).
SQL>startup mount
ORACLE instance started.

Total System Global Area  651378688 bytes
Fixed Size                  2162520 bytes
Variable Size             184549544 bytes
Database Buffers          461373440 bytes
Redo Buffers                3293184 bytes
Database mounted.
SQL>
RMAN Report schema antes de la aplicación de “Switch Database to copy”
RMAN> report schema;

Report of database schema for database with db_unique_name SOURCE

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    700      SYSTEM               ***     /home/oracle/SOURCE/system01.dbf
2    550      SYSAUX               ***     /home/oracle/SOURCE/sysaux01.dbf
3    30       UNDOTBS1             ***     /home/oracle/SOURCE/undotbs01.dbf
4    5        USERS                ***     /home/oracle/SOURCE/users01.dbf

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    20       TEMP                 32767       /home/oracle/SOURCE/temp01.dbf

RMAN>
“Switch Database to copy”
RMAN> switch database to copy;

datafile 1 switched to datafile copy "+DATA/source/datafile/system.270.790560345"
datafile 2 switched to datafile copy "+DATA/source/datafile/sysaux.277.790560351"
datafile 3 switched to datafile copy "+DATA/source/datafile/undotbs1.278.790560355"
datafile 4 switched to datafile copy "+DATA/source/datafile/users.280.790560357"

RMAN>
RMAN Report schema posterior a la aplicación de “Switch Database to copy”
RMAN> report schema;

Report of database schema for database with db_unique_name SOURCE

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    700      SYSTEM               ***     +DATA/source/datafile/system.270.790560345
2    550      SYSAUX               ***     +DATA/source/datafile/sysaux.277.790560351
3    30       UNDOTBS1             ***     +DATA/source/datafile/undotbs1.278.790560355
4    5        USERS                ***     +DATA/source/datafile/users.280.790560357

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    20       TEMP                 32767       /home/oracle/SOURCE/temp01.dbf

RMAN>
Trabajo sobre Tempfiles
Tal como es apreciado en el cuadro anterior. Ya todos los datafiles se encuentran alojados en ASM a excepción de los tempfiles asociados a los tablespaces temporal. En nuestro caso, tenemos solo un tablespace temporal. Teniendo la BBDD aun en modo “mount” estableceremos el único tempfile existente en el ASM Diskgroup +DATA
rman target /

Recovery Manager: Release 11.1.0.7.0 - Production on Mon Aug 6 00:34:52 2012

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: SOURCE (DBID=2908920228, not open)

RMAN> run { set newname for tempfile 1 to '+DATA';
2> switch tempfile all; }

executing command: SET NEWNAME
using target database control file instead of recovery catalog

renamed tempfile 1 to +DATA in control file

RMAN>
En el articulo ”Migracion de Base de Datos a ASM “No Zero Downtime” reubicamos el tablespace temporal a través de la creación de un nuevo tablespace temporal en ASM y removiendo el anterior. La técnica utilizada en este articulo posee mayor eficiencia que la anterior, sin embargo quise denotar los dos procedimientos para plasmar diversas técnicas para lograr el mismo objetivo.
Recover Database
Estando aun en modo “mount”, llevaremos a cabo el recover de la BBDD para establecer consistencia en todos los datafiles alojados en ASM.
RMAN> recover database;

Starting recover at 06-08-2012 00:10:33
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=143 device type=DISK

starting media recovery

archived log for thread 1 with sequence 2 is already on disk as file /u01/app/oracle/
 flash_recovery_area/SOURCE/archivelog/2012_08_06/o1_mf_1_2_81yqsdbo_.arc
archived log for thread 1 with sequence 3 is already on disk as file /u01/app/oracle/
 flash_recovery_area/SOURCE/archivelog/2012_08_06/o1_mf_1_3_81yqsfhn_.arc
archived log for thread 1 with sequence 4 is already on disk as file /u01/app/oracle/
 flash_recovery_area/SOURCE/archivelog/2012_08_06/o1_mf_1_4_81yqsgck_.arc
archived log for thread 1 with sequence 5 is already on disk as file /u01/app/oracle/
 flash_recovery_area/SOURCE/archivelog/2012_08_06/o1_mf_1_5_81yqshh4_.arc
archived log for thread 1 with sequence 6 is already on disk as file /u01/app/oracle/
 flash_recovery_area/SOURCE/archivelog/2012_08_06/o1_mf_1_6_81yqsjlq_.arc
archived log file name=/u01/app/oracle/flash_recovery_area/SOURCE/archivelog/2012_08_06/
 o1_mf_1_2_81yqsdbo_.arc thread=1 sequence=2
archived log file name=/u01/app/oracle/flash_recovery_area/SOURCE/archivelog/2012_08_06/
 o1_mf_1_3_81yqsfhn_.arc thread=1 sequence=3
archived log file name=/u01/app/oracle/flash_recovery_area/SOURCE/archivelog/2012_08_06/
 o1_mf_1_4_81yqsgck_.arc thread=1 sequence=4
media recovery complete, elapsed time: 00:00:01
Finished recover at 06-08-2012 00:10:34
En este punto ya poseemos Datafiles & Tempfiles alojados en ASM de forma consistente. Ahora trabajaremos en reubicar los grupos de Redo Log
Creación de Directorio para Redo Log
ASMCMD> pwd
+DATA/source
ASMCMD>
ASMCMD> mkdir ONLINELOG
ASMCMD>
ASMCMD
Sustitución y/o cambios de Redo Logs
En esta base de datos tenemos originalmente 3 grupos de “Redo Logs” ( en filesystem ). El objetivo es crear grupos de redo logs con alojamiento en ASM. Para realizar esta tarea existen diversas técnicas.
Aperturamos la BBDD para crear los nuevos grupos de Redo Logs en ASM. Es importante destacar que esta etapa se puede llevar a cabo enteramente antes de iniciar el “Downtime” y así podríamos minimizar el mismo. Se utilizaría la misma técnica que se aplica para adicionar nuevos grupos de Redo Logs con distinta medida, ubicación o atributos en general.
Estado de la BBDD: “open”
Por estar trabajando en “Single Instance” no será necesario incluir el atributo “thread”. Si dicha técnica se estuviese aplicando para una BBDD en RAC se estableciera el parámetro “thread” para definir la asociación del grupo de Redo Log con el correspondiente “thread” ( thread=1/thread=2, etc )
Adición de Grupos de Redo Logs 4 y 5:
SQL> ALTER DATABASE
  2  ADD LOGFILE GROUP 4 ('+DATA/source/ONLINELOG/redo04.log') SIZE 50M;

Database altered.

SQL> ALTER DATABASE
  2  ADD LOGFILE GROUP 5 ('+DATA/source/ONLINELOG/redo05.log') SIZE 50M;

Database altered.
Visualización de grupos de Redo Logs después de la adiciones:
SQL> select GROUP#, MEMBER from V$LOGFILE

    GROUP# MEMBER
---------- --------------------------------------------------
         3 /home/oracle/SOURCE/redo03.log
         2 /home/oracle/SOURCE/redo02.log
         1 /home/oracle/SOURCE/redo01.log
         4 +DATA/source/onlinelog/redo04.log
         5 +DATA/source/onlinelog/redo05.log

SQL>
Borrado del grupo de Redo Log 1:
SQL> alter database drop logfile group 1;
Borrado del grupo de Redo Log 2. El mismo no puede ser removido aun debido a que la operación de redo log group para la BBDD se encuentra apuntando al mismo.
Database altered.
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 SOURCE (thread 1) - cannot drop
ORA-00312: online log 2 thread 1: '/home/oracle/SOURCE/redo02.log'
Borrado del grupo de Redo Log 3:
SQL> alter database drop logfile group 3;

Database altered.

SQL>
Visualización de grupos de Redo Logs posterior a las remociones:
SQL> select GROUP#, MEMBER from V$LOGFILE;

    GROUP# MEMBER
---------- --------------------------------------------------
         2 /home/oracle/SOURCE/redo02.log
         4 +DATA/source/onlinelog/redo04.log
         5 +DATA/source/onlinelog/redo05.log

SQL>
Estatus de los mismos. Tal como podemos visualizar. El grupo de redo log 1 se encuentra en “status”:current, con dicho estatus no podrá ser removido. Tenemos que aplicar diversos “switch logfile” para que el mismo se establezca en “status”:inactive y pueda ser removido ( esto aplica si la BBDD se encuentra abierta ), si la BBDD esta cerrada solo bastara que el grupo de redo log “current” sea el 4 o 5:
SQL> select GROUP#, STATUS, ARCHIVED from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         2 CURRENT          NO
         4 UNUSED           YES
         5 UNUSED           YES

SQL>
Realizaremos los “switchs” correspondientes:
SQL> alter system switch logfile;

System altered.

SQL> select GROUP#, STATUS, ARCHIVED from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         2 ACTIVE           NO
         4 CURRENT          NO
         5 UNUSED           YES


SQL> alter system switch logfile;

System altered.

SQL> select GROUP#, STATUS, ARCHIVED from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         2 ACTIVE           NO
         4 ACTIVE           NO
         5 CURRENT          NO
Tal cual fue el objetivo, el grupo de Redo log “current” actual es el 5. Podríamos haber escogido el 4 también. Lo importante es que no fuese el grupo de redo log 2, debido a que removeremos el mismo. Procederemos a cerrar la BBDD, establecimiento en modo “mount” de la misma y la remoción final del grupo de Redo Log 2:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  680607744 bytes
Fixed Size                  2162800 bytes
Variable Size             188747664 bytes
Database Buffers          486539264 bytes
Redo Buffers                3158016 bytes
Database mounted.
SQL>

SQL> alter database drop logfile group 2;

Database altered.

SQL> select GROUP#, STATUS, ARCHIVED from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         5 CURRENT          NO
         4 INACTIVE         NO

SQL>

SQL> alter database open;

Database altered.

SQL> alter system switch logfile;

System altered.

SQL> r
  1* alter system switch logfile

System altered.

SQL> r
  1* alter system switch logfile

System altered.
En este punto ya llevamos a cabo el objetivo de establecer operativamente solo grupos de Redo Logs en ASM:
SQL> select GROUP#, STATUS, ARCHIVED from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         4 CURRENT          NO
         5 INACTIVE         NO

SQL>
Reubicación de Controlfiles
Realizaremos cambios de parámetros a nivel de spfile ( Server Parameter File ) por lo tanto procederemos a respaldar el mismo para su restaurado en caso de ser necesitado.
Nota: Para respaldar el server parameter file la BBDD debe estar en estado “mount or open “
Estado actual de la BBBD: abierta.
rman target /

Recovery Manager: Release 11.1.0.7.0 - Production on Sat Jul 28 18:49:07 2012

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: SOURCE (DBID=2908208036)

RMAN> backup spfile format '/home/oracle/SOURCE/MySpfileBackup.ora';

Starting backup at 28-07-2012 18:49:11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=147 device type=DISK
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 28-07-2012 18:49:12
channel ORA_DISK_1: finished piece 1 at 28-07-2012 18:49:13
piece handle=/home/oracle/SOURCE/MySpfileBackup.ora tag=TAG20120728T184911 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 28-07-2012 18:49:13

RMAN>
Procedemos a cambiar los parámetros (controlfile y db_create_file_dest) a su nueva ruta. La ruta escogida va alineada a las rutas “Oracle Managed Files” para base de datos en ASM. Los nuevos datafiles serán creados por defecto en la ruta especificada por el parámetro db_create_file_dest. Se establecera en esta misma etapa l nueva ubicacion para el area “Flash”.
Choosing a Location for the Flash Recovery Area
Oracle® Database Backup and Recovery Basics
10g Release 2 (10.2)
http://docs.oracle.com/cd/B19306_01/backup.102/b14192/setup005.htm
SQL> Alter System set control_files=’+DATA/source/controlfiles/control01.ctl’ scope=spfile;
SQL> alter system set db_create_file_dest='+DATA' scope=spfile;
SQL> alter system set db_recovery_file_dest='+FRA' scope=spfile;



SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
Creación de Directorio en ASM donde se alojara el o los controlfiles
Para el presente caso trabajaremos creando solo 1 controlfile, si se desean crear controlfiles en distintos Diskgroups lo cual es el “best practice”, se podrá llevar a cabo de la misma manera. Se deberán crear los directorios respectivos en los Diskgroups respectivos y se deberá asignar rutas múltiples en el valor del parámetro control_files a nivel de spfile.
Recordemos que esta base de datos esta originalmente creada en filesystem y no posee ninguna relación con los ASM Diskgroups, por lo tanto es necesario crear los directorios de alojamiento de los Controlfiles, Datafiles, Redo Logs y otros. Para algunos de los elementos el procedimiento asociado ( RMAN restore ) los crea automáticamente, para otros no. En el caso del controlfile, el directorio tiene que ser creado
Nota: para el presente caso estamos trabajando con un Oracle Server 11g R1 el cual posee la misma la misma arquitectura de “homes” a implementarse en ( 10g R1, 10g R2 & 11g R1 ). Dicha arquitectura cuenta con un home para ASM cuyo dueño típicamente es el usuario oracle. Este “home” trabaja de la mano con un “home” de nivel superior ( en escala de “stack” de componentes ) perteneciente al Oracle Server cuyo dueño es el usuario oracle también. Es por ello que establecemos el “home” de ASM a través del mecanismo ( . oraenv ).
Si trabajáramos en 11g R2 el “best practice” será que el “Grid Infraestructure Software” pertenezca al usuario “grid” y el Oracle Server al usuario “oracle”, en caso de estar en esta arquitectura, este paso se realizaría conectado al usuario grid.
Creación de directorios necesarios para poseer finalmente la siguiente ruta: +DATA/SOURCE/controlfiles
[oracle@MyjpServer ~]$ . oraenv
ORACLE_SID = [TEST] ? +ASM
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/asm1 is /u01/app/oracle
[oracle@MyjpServer ~]$
[oracle@MyjpServer ~]$ asmcmd
ASMCMD>
ASMCMD> cd +DATA
ASMCMD>
ASMCMD> mkdir SOURCE
ASMCMD>
ASMCMD> cd SOURCE
ASMCMD>
ASMCMD> mkdir CONTROLFILES
ASMCMD>
ASMCMD> cd controlfiles
ASMCMD>
ASMCMD> pwd
+DATA/SOURCE/controlfiles
ASMCMD>
Restaurado de Controlfiles en ASM
SQL> startup nomount
ORACLE instance started.

Total System Global Area  680607744 bytes
Fixed Size                  2162800 bytes
Variable Size             180359056 bytes
Database Buffers          494927872 bytes
Redo Buffers                3158016 bytes
SQL>

RMAN> restore controlfile from '/home/oracle/SOURCE/control01.ctl';

Starting restore at 28-07-2012 19:12:25
using channel ORA_DISK_1

channel ORA_DISK_1: copied control file copy
output file name=+DATA/source/controlfiles/control01.ctl
Finished restore at 28-07-2012 19:12:26

RMAN>
Visualizando el Controlfile creado
ASMCMD> pwd
+DATA/SOURCE/controlfiles
ASMCMD>
ASMCMD> ls -lt
Type  Redund  Striped  Time   Sys  Name
                              N    control01.ctl => 
                                    +DATA/SOURCE/CONTROLFILE/current.261.789851545
ASMCMD>
Establecimiento de spfile en ASM Diskgroup
Una vez alcanzado este punto solo nos quedaría afinar la nueva ubicación para el archivo de parámetros de la BBDD.
[oracle@MyjpServer ~]$ rman target /

Recovery Manager: Release 11.1.0.7.0 - Production on Sun Aug 5 23:56:07 2012

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: SOURCE (DBID=2908920228)


RMAN> run { BACKUP AS BACKUPSET SPFILE;
2> RESTORE SPFILE TO '+DATA/SOURCE/spfilesource.ora';
3> }

Starting backup at 05-08-2012 23:57:45
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=140 device type=DISK
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-08-2012 23:57:46
channel ORA_DISK_1: finished piece 1 at 05-08-2012 23:57:47
piece handle=+FRA/SOURCE/backupset/2012_08_05/o1_mf_nnsnf_TAG20120805T235746_81yq6tkl_.bkp 
 tag=TAG20120805T235746 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 05-08-2012 23:57:47

Starting restore at 05-08-2012 23:57:47
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: restoring SPFILE
output file name=+DATA/SOURCE/spfilesource.ora
channel ORA_DISK_1: reading from backup piece +FRA/SOURCE/backupset/2012_08_05/
 o1_mf_nnsnf_TAG20120805T235746_81yq6tkl_.bkp
channel ORA_DISK_1: piece handle=+FRA/SOURCE/backupset/2012_08_05/
 o1_mf_nnsnf_TAG20120805T235746_81yq6tkl_.bkp tag=TAG20120805T235746
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 05-08-2012 23:57:50

RMAN>
Visualización de spfile generado en ASM Diskgroup
[oracle@MyjpServer ~]$ . oraenv
ORACLE_SID = [TEST] ? +ASM
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/asm1 is /u01/app/    oracle
[oracle@MyjpServer ~]$
[oracle@MyjpServer ~]$ asmcmd
ASMCMD>
ASMCMD> cd data
ASMCMD>
ASMCMD> cd source
ASMCMD>
ASMCMD> ls -lt
Type Redund Striped Time Sys Name
                         N   ONLINELOG/
                         N   CONTROLFILES/
                         Y   CONTROLFILE/
                         N   spfilesource.ora => +DATA/  DB_UNKNOWN/PARAMETERFILE/SPFILE.261.790559869
ASMCMD>
Ajuste de archivo initsource.ora
[oracle@MyjpServer ~]$ rm $ORACLE_HOME/dbs/spfileSOURCE.ora
[oracle@MyjpServer ~]$ cd $ORACLE_HOME/dbs/
[oracle@MyjpServer ~]$ echo "SPFILE=+DATA/SOURCE/PARAMETERFILE/spfilesource.ora" > initsource.ora
De esta manara la instancia tomara como primera opción el “Parameter File” de nuestra BBDD, el cual apunta internamente al spfile que se encuentra en ASM. Aperturamos la BBDD y hemos completado la tarea.
Reflexión
Si comparamos las técnicas, implicaciones, criticidad y orden de pasos realizados en el articulo Migracion de Base de Datos a ASM “No Zero Downtime” respecto a este, podremos notar que a pesar de que el objetivo sea llevar a cabo la misma tarea. El ciclo de vida de la misma cambia considerablemente. En líneas generales las tareas que impliquen siempre su realización con filosofía “Zero Downtime”, requerirá de técnicas de mayor criticidad y por consiguiente de mayor “expertice” por parte del DBA encargado. Siempre existirán tareas que puedan ser de duración muy cortas pero en ambientes muy críticos; cuando este es el cuadro, el DBA debe prepararse para las posibles implicaciones que conlleve la tarea.
Ej: puede usted pensar que por perdidas de grupos de redo logs posiblemente tenga que restaurar una BBDD completa… ?. Respuesta: si es posible… entonces, Pregunta: cualquier DBA puede cambiar, adicionar, administrar grupos de Redo Logs ?... Respuesta: si… Pregunta: cualquier DBA toma las precauciones de estar preparado ante los posibles escenarios al realizar un “task”… Respuesta: En mi experiencia. No todos… es allí donde puede estar la diferencia…
Para el presente articulo, la técnica a aplicar no es tan compleja pero posiblemente seria un poco más complejo diseñar un plan para que todo siga operando en caso de fallo en la aplicación de la misma. Esto se denomina “Plan de Contingencia”. Siempre que se va a realizar algo altamente critico en empresas con sistemas de alta criticidad, generalmente la misma solicita por escrito esto mencionado, pero… es necesario que lo soliciten para construirlo en nuestras mentes… Respuesta: No… por lo tanto, todo DBA debería de pensar en un plan para restituir la infraestructura en caso de fallo de la técnica a ser aplicada. Es por ello que plasmare lo siguiente:
Entonces:
  • Uno de los primeros pasos que realizamos es realizar un “Switch Database to Copy”, esto cambia las referencias dentro de los controlfiles. Por lo tanto es de precaución tomar un backup de controlfile cuando se cierra la BBDD por primera vez debido a que la información de contenido del mismo será cambiada.
    Estando la BBDD cerrada bastara con realizar una copia a nivel de filesystem de uno de los controlfiles. En este backup tomado, se encontrara la referencia de los datafiles, tempfiles y redo log los cuales están ubicados en filesystem.
  • Y en que condición quedaran mis datafiles, tempfiles and redo logs ?. Respuesta: consistentes en filesystem por lo tanto podremos volver a trabajar con la BBDD en filesystem si la técnica fallara. Para que los mismos queden en estado consistente es importante cerrar la BBDD con opción “immediate”
  • Otro elemento que se cambiara en el proceso es el spfile de la BBDD. Tomaremos un backup del mismo para su utilización en caso de ser necesitado en un reverso.
  • Teniendo estas precauciones podremos iniciar el “Task”.
Vamos a dibujar un escenario de falla para el mismo:
Iniciamos la actividad:
  • Se realizo el “Backup as Copy” sin problemas
  • “Switch Database to copy” sin problemas
  • Procedemos a la etapa de “recover database”, se aplicaran 100 archives. Los archives se encuentran en un filesystem de origen de discos no pertenecientes al servidor. El filesystem esta asociado a una LUN perteneciente a una SAN.
  • Cuando la BBDD estaba recuperando el archive 44, la SAN obtiene una falla parcial y se pierde el acceso al filesystem en el cual se encuentran los archives y no se posee backup de los mismos en otra locación.
  • Se había destinado 30min para la actividad. En medio de lo ocurrido se diagnostica que esa partición posee un problema que no será resuelto prontamente…
  • Nuestra BBDD quedo recuperada hasta el archive 44…
  • Se toma la decisión de que se realice lo necesario para que la BBDD continúe con su operación en filesystem o ASM al punto original. Al dpto. de IT y a la empresa solo le interesa en este momento, continuar con las actividades… con la data tal cual estaba al principio del “Task”
  • Es aquí en este punto donde jugara un papel fundamental el “expertice” del DBA y sobretodo las precauciones que tuvo que haber tomado para posibles escenarios de falla de la actividad.
  • Pasos a realizar:
         • Detener la BBDD
         • Restaurar a la locación original el controlfile respaldado y crear copias del mismo si fuese el caso de que estuviesen multiplexados los controlfiles. Notas: estos controlfiles referencian sus elementos totalmente a filesystem
         • Si el spfile fue cambiado. Restaurar el original
         • Si la ruta tradicional de archives no esta disponible. Cambiar a nivel de spfile la nueva ruta para el parámetro ( DB_RECOVERY_FILE_DEST )
         • Iniciar la BBDD y continuar con las operaciones
Aplicaciones y uso
Las técnicas para trasladar y/o alojar elementos de una base de datos en filesystem a ASM son llevados a cabo en situaciones como las siguientes:
  • Traslado de BBDD “Single Instance” de filesystem a BBDD “Single Instance” en ASM
  • Traslado de BBDD “Single Instance” de filesystem a BBDD “RAC” en ASM/OCFS/Certified NFS
  • Poseer una copia de BBDD en ASM o locación diversa para recuperaciones rápidas de datafiles
  • Poseer una copia de BBDD en ASM o locación diversa para recuperaciones rápidas de la BBDD completa
  • Y muchos otros casos mas
Publicado por en

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)