lunes, 9 de noviembre de 2015

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

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

Por Joel Pérez oracle ace
Publicado en septiembre 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, por qué?, 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 opción fue presentada y desarrollada en el articulo: "Protegiendo backups de RMAN contra fallos de la SAN (Parte II)"
  • Opción 3: Desde la versión de base de datos 10g tenemos la existencia del paquete DBMS_TRANSFER. Esta será la técnica utilizada para el presente artículo.
A continuación trabajaremos con la opción nro.3:

DBMS_FILE_TRANSFER

The DBMS_FILE_TRANSFER package provides procedures to copy a binary file within a database or to transfer a binary file between databases.
Oracle® Database PL/SQL Packages and Types Reference
11g Release 2 (11.2)
http://docs.oracle.com/cd/E11882_01/appdev.112/e25788/d_ftran.htm
Vamos a realizarlo:
Base de Datos: DB
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 de las 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: Creación del paquete DBMS_FILE_TRANSFER.
Una vez divisadas las piezas a transferir externamente de nuestro almacenamiento ASM. Procederemos a verificar si el paquete DBMS_FILE_TRANSFER esta creado.
SQL> desc dbms_file_transfer
PROCEDURE COPY_FILE
Argument Name                  Type               In/Out Default?
------------------------------ ------------------ ------ --------
SOURCE_DIRECTORY_OBJECT        VARCHAR2                IN
SOURCE_FILE_NAME               VARCHAR2                IN
DESTINATION_DIRECTORY_OBJECT   VARCHAR2                IN
DESTINATION_FILE_NAME          VARCHAR2                IN
PROCEDURE GET_FILE
Argument Name                  Type               In/Out Default?
------------------------------ ------------------ ------ --------
SOURCE_DIRECTORY_OBJECT        VARCHAR2                IN
SOURCE_FILE_NAME               VARCHAR2                IN
SOURCE_DATABASE                VARCHAR2                IN
DESTINATION_DIRECTORY_OBJECT   VARCHAR2                IN
DESTINATION_FILE_NAME          VARCHAR2                IN
PROCEDURE PUT_FILE
Argument Name                  Type               In/Out Default?
------------------------------ ------------------ ------ --------
SOURCE_DIRECTORY_OBJECT        VARCHAR2                IN
SOURCE_FILE_NAME               VARCHAR2                IN
DESTINATION_DIRECTORY_OBJECT   VARCHAR2                IN
DESTINATION_FILE_NAME          VARCHAR2                IN
DESTINATION_DATABASE           VARCHAR2                IN

SQL>
Si el mismo no esta creado, podremos crearlo con el siguiente script:
{ORACLE_HOME}/rdbms/admin/dbmsxfr.sql
Si algún usuario diferente de sys necesita acceso al mismo, podemos otorgar el privilegio de la siguiente manera:
GRANT EXECUTE ON dbms_file_transfer TO ;
Paso4: Creación de directorios origen y destino para la transferencia
SQL> create directory source_dir as
 2  '+FRA/mydb/backupset/2011_11_10';

Directory created.

SQL> create directory target_dir as
 2  '/home/oracle/MyExternalFileSystem';

Directory created.
Para cualquier usuario que necesite acceder a estos directorios se deberá otorgar los permisos necesarios:
SQL> grant read, write on directory source_dir to ;

Grant succeeded.

SQL> grant read, write on directory target_dir to ;

Grant succeeded.

SQL>
Paso5: Llevando a cabo las transferencias:
BEGIN
 sys.dbms_file_transfer.copy_file(source_directory_object =>
 'SOURCE_DIR', source_file_name => 'nnndf0_full_weekly_0.271.766859353',
 destination_directory_object => 'TARGET_DIR' ,
 destination_file_name => 'MyFullBackupPiece01.bkp');
END;
/
PL/SQL procedure successfully completed.

BEGIN
 sys.dbms_file_transfer.copy_file(source_directory_object =>
 'SOURCE_DIR', source_file_name => 'ncsnf0_full_weekly_0.269.766859431',
 destination_directory_object => 'TARGET_DIR' ,
 destination_file_name => 'MyFullBackupPiece02.bkp');
END;
/
PL/SQL procedure successfully completed.
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 MyFullBackupPiece01.bkp
-rw-r----- 1 oracle dba 1071702016 Nov 10 18:07 MyFullBackupPiece02.bkp
[oracle@MYSERVER-mydb MyExternalFileSystem]$
Para utilizar las piezas generadas en recuperaciones de nuestra base de datos, debemos catalogar las mismas. Esto se podrá llevar a cabo a través del comando CATALOG de RMAN.
RMAN> catalog start with '/home/oracle/MyExternalFileSystem';

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/11g.
  • Extraer RMAN backups (full, archives, controlfiles, etc...) para procedimientos tales como: RMAN Duplicate, Instanciación 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)