Por Joel Pérez
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).
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:
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.
A continuación trabajaremos con la opción nro.3:
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=<path>/BKFULL_MYDB_RMAN_$V_DATE.log rman target / @<path>/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 <schema_name>;
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 <username>; Grant succeeded. SQL> grant read, write on directory target_dir to <username>; 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';
Las posibles aplicaciones reales que podemos realizar con transferencias de piezas o archivos desde ASM hacia otros destinos son variadas. Listamos algunas:
Joel es un experto en DBA con más de 12 años de experiencia, especializado en las áreas de bases de datos con especial énfasis en la solución de alta disponibilidad (RAC, Data Guard, y otros). Es un conferencista habitual en eventos de Oracle como: OTN LAD TOUR y otros. Es el primer latinoamericano en ser nombrado "Experto OTN" en el año 2003 y Oracle ACE desde el año 2004.