lunes, 9 de noviembre de 2015

Protegiendo Backups de RMAN contra fallos de la SAN ( Parte II )

Protegiendo Backups de RMAN contra fallos de la SAN ( Parte II )

Por Joel Pérez
Publicado en enero 2012
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 protección de los backups realizados con RMAN ( Oracle Recovery Manager ).


Los artículos que conforman esta serie son los siguientes:
1. Base de datos 11g Release1: El comando cp perteneciente al utilitario asmcmd
2. Base de datos 11g: La opción Backup Backupset perteneciente al conjunto de comandos y opciones de RMAN.
3. Base de datos 11g: La existencia del paquete DBMS_TRANSFER


A partir de la versión de servidor de base de datos 10g contamos con la tecnología de almacenamiento de información ASM ( Automatic Storage Management ) la cual revoluciono la forma de almacenar y administrar nuestras base de datos. Trajo consigo el concepto y modo de almacenamiento de nuestros backups, archived redo logs y otros elementos en el área ( FRA: Flash Recovery Area ). El FRA representa una respuesta a los cambios de costos y criticidad a la hora de gestar y recuperar nuestra backups.
Siempre se ha tenido la tradición de almacenar los backups en unidades de cinta, NAS o cualquier otro medio adaptado para tal fin, llevándose a cabo así el objetivo de protegernos contra fallos de hardware o software. A partir de la versión de manejador de base de datos 10g, la primera línea de backup por excelencia y best-practice paso a ser el FRA, porque ?, porque no hay nada mas rápido para recuperar o realizar un backup desde o hacia los propios discos duros con los cuales hemos trabajado toda la vida. En tiempos anteriores, en contraste a nuestros días, el costo de los discos duros era bastante alto; ya hoy en día ya no es así en la mayoría de los casos. Es por ello que nace el concepto del FRA.
Cuando se planifica e implementa una estrategia de backup robusta para nuestras bases de datos, tenemos principalmente la misión de protegernos contra fallos parciales o totales de hardware o software.
El FRA representa una solución practica de alto nivel para poseer la primera línea de backup en dispositivos rápidos ( discos/particiones de SAN ).
Habitualmente estos llamados discos realmente son particiones que provienen de una SAN (storage area network). SAN ( Concepto ): es una red concebida para conectar servidores, matrices (arrays) de discos y librerías de soporte. Principalmente, está basada en tecnología fibre channel y más recientemente en iSCSI. Su función es la de conectar de manera rápida, segura y fiable los distintos elementos que la conforman.
En las instalaciones de RAC ( Real Application Cluster ) e inclusive Single Instance sobre ASM es común disponer de particiones o bien llamadas ( LUNs ) para conformar los denominados Diskgroups de ASM, finalmente sobre los Diskgroups ASM es donde se alojaran los componentes de nuestra BBDD y eventualmente otros elementos del Oracle Server, RAC Clusterware, y otros.
Generalmente en particiones de SAN es donde realmente poseemos nuestras bases de datos y backups pero que pasaría si ocurre una falla fatal en la SAN… ?, podemos permitirnos perder la data de nuestra compañía o negocio ?, definitivamente la respuesta es: No.
Tenemos que poseer protección contra ese posible caso. Para ellos presentaremos diversas técnicas que nos ayudaran a tener una segunda línea de protección de backup para nuestras bases de datos.
Listaremos posibles opciones de almacenamiento diversas y/o externas al FRA. Dentro de las cuales resaltamos las siguientes:
  • En infraestructura NAS : NAS (del inglés Network Attached Storage) es el nombre dado a una tecnología de almacenamiento dedicada a compartir la capacidad de almacenamiento de un computador (Servidor) con ordenadores personales o servidores clientes a través de una red (normalmente TCP/IP), haciendo uso de un Sistema Operativo optimizado para dar acceso con los protocolos CIFS, NFS, FTP o TFTP. Generalmente, los sistemas NAS son dispositivos de almacenamiento específicos a los que se accede desde los equipos a través de protocolos de red (normalmente TCP/IP). También se podría considerar un sistema NAS a un servidor (Linux, Windows, ...) que comparte sus unidades por red, pero la definición suele aplicarse a sistemas específicos
  • Discos duros externos
  • NFS
  • Cinta
  • Y otros
Para el presente artículo solo abordaremos una de las técnicas para poder trasladar nuestros backups a medios como: NAS, Discos duros externos, NFS o cualquier vía de almacenamiento presentable al o los servidor(es) donde poseemos nuestra(s) base(s) de datos.
Técnicas para extraer nuestros backups del ASM
  • Opción 1: Desde la versión de manejador de base de datos 11g Release1 tenemos disponible el comando cp perteneciente al utilitario asmcmd. Esta opción fue presentada y desarrollada en el articulo : “Protegiendo backups de RMAN contra fallos de la SAN ( Parte I )”
  • Opción 2: Desde versiones anteriores al manejador de base de datos 11g, tenemos las opciones de: Backup Backupset perteneciente al conjunto de comandos y opciones de RMAN. Esta será la técnica utilizada para el presente artículo.
  • Opción 3: Desde versiones anteriores al manejador de base de datos 11g, tenemos la existencia del paquete DBMS_TRANSFER. Esta opción será desarrollada en la parte III del presente articulo : “Protegiendo backups de RMAN contra fallos de la SAN ( Parte III )”
A continuación trabajaremos con la opción nro.2:
Backups of Backup Sets ( Concepto )
The RMAN 
BACKUP BACKUPSET
command backs up backup sets rather than actual database files. This command supports disk-to-disk or disk-to-tape backups, but not tape-to-tape backups.

The 
BACKUP BACKUPSET
command uses the default disk channel to copy backup sets from disk to disk. To back up from disk to tape, you must either manually allocate a channel of DEVICE TYPE sbt or configure an automatic sbt channel.

Una vez visto en detalle el concepto del comando “Backup Backupset”. Planteemos un ejemplo práctico ajustado a la realidad del día a día de nuestras labores como DBA.
Normalmente los backups full realizados con RMAN residen en nuestra área FRA y para el escenario que estamos planteando, existirá la necesidad de transferir las piezas del un backup full a filesystem ( filesystem perteneciente a una unidad NAS, NFS, DD externos o cualquier otro ).
Vamos a realizarlo:
Base de Datos: MYDB Diskgroup ( DATA ): +DATA Diskgroup ( FRA ): +FRA
Paso1: Tomar backup full con RMAN estableciendo una etiqueta que nos pueda ayudar a identificar unívocamente las piezas pertenecientes a este:
rman_backup_full.sh
export ORACLE_SID=MYDB
export V_DATE=`date +%d%m%Y_%H%M`
export V_LOGFILE=/BKFULL_MYDB_RMAN_$V_DATE.log 
rman target / @/run.rcv log=$V_LOGFILE 

run.rcv
run {    
    backup database tag='FULL_WEEKLY'; 
} 
exit
En el caso presente estamos tomando un backup full de la BBDD y el elemento que nos ayudara a identificar de forma univoca el mismo será el TAG aplicado en la sentencia de backup full.
Una vez tomado el backup, visualizamos la piezas generadas del mismo:
RMAN> List Backup;
using target database control file instead of recovery catalog
List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
5       Full    1019.86M   DISK        00:01:15     10-NOV-11
        BP Key: 5   Status: AVAILABLE  Compressed: NO  Tag: FULL_WEEKLY
        Piece Name: +FRA/mydb/backupset/2011_11_10/nnndf0_full_weekly_0.271.766859353
  List of Datafiles in backup set 5
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 1072131    09-NOV-11 +DATA/mydb/datafile/system.256.766584645
  2       Full 1072131    09-NOV-11 +DATA/mydb/datafile/sysaux.257.766584645
  3       Full 1072131    09-NOV-11 +DATA/mydb/datafile/undotbs1.258.766584647
  4       Full 1072131    09-NOV-11 +DATA/mydb/datafile/users.259.766584647
  5       Full 1072131    09-NOV-11 +DATA/mydb/datafile/example.276.766585261

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
6       Full    9.58M      DISK        00:00:01     10-NOV-11
        BP Key: 6   Status: AVAILABLE  Compressed: NO  Tag: FULL_WEEKLY
        Piece Name: +FRA/mydb/backupset/2011_11_10/ncsnf0_full_weekly_0.269.766859431
  SPFILE Included: Modification time: 09-NOV-11
  SPFILE db_unique_name: mydb
  Control File Included: Ckp SCN: 1072131      Ckp time: 09-NOV-11
RMAN>
En el log presentado se puede apreciar la generación de 2 piezas
+FRA/mydb/backupset/2011_11_10/nnndf0_full_weekly_0.271.766859353 & 
+FRA/mydb/backupset/2011_11_10/ncsnf0_full_weekly_0.269.766859431).
Cada pieza posee atributos únicos, en esta ocasión determinaremos las mismas a transferir mediante los atributos TAG & BS KEY. Ambas piezas representan el objetivo para transferir a una localización de disco diversa al FRA.
Paso2: Visualizando localizaciones de piezas generadas en el FRA
Visualicemos las especificaciones de las piezas generadas a través del vistas de diccionario de datos de nuestra base de datos.
SQL> select HANDLE from v$backup_piece
  2  where TAG='FULL_WEEKLY';

HANDLE
--------------------------------------------------------------------------------
+FRA/mydb/backupset/2011_11_10/nnndf0_full_weekly_0.271.766859353
+FRA/mydb/backupset/2011_11_10/ncsnf0_full_weekly_0.269.766859431
SQL>
Paso3: Construir script para transferir las piezas externamente al FRA
Base de Datos: MYDB
Version de Oracle Server: 11g Release2
ASM Home: /u01/app/11.2.0/grid
Diskgroup ( FRA ): +FRA
Pre_transfer_backup_full.sh
export ORACLE_SID=MYDB
sqlplus / as sysdba @/Extracting_script.sql

Extracting_script.sql

SET NEWPAGE    0
SET SPACE      0
SET PAGESIZE   0
SET ECHO     OFF
SET FEEDBACK OFF
SET HEADING  OFF
SET TERMOUT  OFF
SET VERIFY   OFF
set linesize 400

spool /Transfer_full_backup.sql

select distinct jp from (
select  'run { backup backupset ' || BS_KEY ||
' format ''/MyExternalFileSystem/PIECE_BSKEY_' || BS_KEY
|| '.BKP' || '''' || '; }' jp
from v$backup_files
where tag='FULL_WEEKLY'
);

spool off
exit;
Es apreciable destacar que la vista “V$BACKUP_FILES” posee campos altamente útiles para delimitar las piezas a transferir. A través de esta podemos ajustar y filtrar de forma adecuada las piezas requeridas para la labor.
Referencia de la vista “V$BACKUP_FILES”
V$BACKUP_FILES

Oracle® Database Reference 11g Release 1 (11.1)

Part Number B28320-03

http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/dynviews_1047.htm

Por ejemplo, si se desea filtrar las piezas por:
  • TAG utilizamos el campo TAG
  • BS_KEY representando la llave primaria que identifica la pieza perteneciente a un backupset
  • Modo de compresión utilizamos el campo COMPRESSED
  • y así sucesivamente
Producto de la ejecución del script “Pre_transfer_backup_full.sh” se generara el script “Transfer_full_backup.sql”. Dicho script posteriormente deberá ser ejecutado desde una sesión de RMAN.
El contenido del script “Transfer_full_backup.sql” será algo similar a lo siguiente:s
run { backup backupset 5 format '/MyExternalFileSystem/PIECE_BSKEY_5.BKP'; }
run { backup backupset 6 format '/MyExternalFileSystem/PIECE_BSKEY_6.BKP'; }
Paso4: Ejecutar el script “Transfer_full_backup.sql” desde RMAN
El script “Transfer_full_backup.sql” posteriormente tendrá que se ejecutado desde una sesión de RMAN. Para el presente caso se generan piezas equivalentes a las generadas en el FRA, el destino escogido para las mismas es el filesystem “/MyExternalFileSystem”. El “feedback” de la ejecución seria de la siguiente manera:
RMAN> run { backup backupset 5 format '/MyExternalFileSystem/PIECE_BSKEY_5.BKP'; }

Starting backup at 10-NOV-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=34 device type=DISK
channel ORA_DISK_1: input backup set: count=11, stamp=766859352, piece=1
channel ORA_DISK_1: starting piece 1 at 10-NOV-11
channel ORA_DISK_1: backup piece +FRA/mydb/backupset/2011_11_10/nnndf0_full_weekly_0.271.766859353
piece handle=/MyExternalFileSystem/PIECE_BSKEY_5.BKP comment=NONE
channel ORA_DISK_1: finished piece 1 at 10-NOV-11
channel ORA_DISK_1: backup piece complete, elapsed time: 00:01:05
Finished backup at 10-NOV-11

RMAN>

RMAN> run { backup backupset 6 format '/MyExternalFileSystem/PIECE_BSKEY_6.BKP'; }

Starting backup at 10-NOV-11
using channel ORA_DISK_1
channel ORA_DISK_1: input backup set: count=12, stamp=766859429, piece=1
channel ORA_DISK_1: starting piece 1 at 10-NOV-11
channel ORA_DISK_1: backup piece +FRA/mydb/backupset/2011_11_10/ncsnf0_full_weekly_0.269.766859431
piece handle=/MyExternalFileSystem/PIECE_BSKEY_6.BKP comment=NONE
channel ORA_DISK_1: finished piece 1 at 10-NOV-11
channel ORA_DISK_1: backup piece complete, elapsed time: 00:00:01
Finished backup at 10-NOV-11

RMAN>

Las piezas obtenidas son: PIECE_BSKEY_5.BKP & PIECE_BSKEY_6.BKP
Paso5: También se puede llevar a cabo la tarea con una sola instrucción de la siguiente manera:
RMAN> backup backupset 5,6 format '/MyExternalFileSystem/MyBackup_out_of_ASM_%t_s%s_s%p.BKP';

Starting backup at 10-NOV-11
using channel ORA_DISK_1
channel ORA_DISK_1: input backup set: count=15, stamp=766864699, piece=1
channel ORA_DISK_1: starting piece 1 at 10-NOV-11
channel ORA_DISK_1: backup piece +FRA/mydb/backupset/2011_11_10/nnndf0_full_weekly_0.271.766859353
piece handle=/MyExternalFileSystem/MyBackup_out_of_ASM_766864699_s15_s1.BKP comment=NONE
channel ORA_DISK_1: finished piece 1 at 10-NOV-11
channel ORA_DISK_1: backup piece complete, elapsed time: 00:00:55
channel ORA_DISK_1: input backup set: count=16, stamp=766864775, piece=1
channel ORA_DISK_1: starting piece 1 at 10-NOV-11
channel ORA_DISK_1: backup piece +FRA/mydb/backupset/2011_11_10/ncsnf0_full_weekly_0.269.766859431
piece handle=/MyExternalFileSystem/MyBackup_out_of_ASM_766864775_s16_s1.BKP comment=NONE
channel ORA_DISK_1: finished piece 1 at 10-NOV-11
channel ORA_DISK_1: backup piece complete, elapsed time: 00:00:01
Finished backup at 10-NOV-11

RMAN>
Tal cual como se puede apreciar, el identificador de las piezas es el atributo BS_KEY.
Visualizacion de archivos ( piezas de RMAN ) generadas en el sistema operativo
[oracle@MYSERVER-mydb MyExternalFileSystem]$ ls -lt
total 1057452
-rw-r----- 1 oracle dba   10059776 Nov 10 18:08 MyBackup_out_of_ASM_766864775_s16_s1.BKP
-rw-r----- 1 oracle dba 1071702016 Nov 10 18:07 MyBackup_out_of_ASM_766864699_s15_s1.BKP
[oracle@MYSERVER-mydb MyExternalFileSystem]$
Dichas piezas son perfectamente validas y consistentes para cualquier recuperación de nuestra base de datos. Las mismas quedan catalogadas en los controlfiles y/o catalogo de RMAN.

Aplicaciones y uso



Las posibles aplicaciones reales que podemos realizar con transferencias de piezas o archivos desde ASM hacia otros destinos son variadas. Listamos algunas:
  • Transferencia de Archived Redo Logs para resolver casos de GAP para Manual Standby Databases o Data Guard en versiones 10g
  • Extraer RMAN backups ( full, archives, controlfiles, etc… ) para procedimientos tales como: RMAN Dupliicate, Instanciacion de Standby o Data Guard Databases, etc… y otros
  • Transferencias de ASM a ASM para replicación de BBDDs
  • Y muchas otras mas
Publicado por en

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)