Joel Pérez Oracle ACE Director's Blog: 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

Publicado en octubre 2011

Reciban estimados tecnólogos Oracle un cordial saludo. A través del presente articulo, tendremos la oportunidad de visualizar y adentrarnos un poco en el tema de protección de los backups realizados con RMAN.

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 denominada ASM ( Automatic Storage Management ) el cual revoluciono la forma en que almacenábamos y manejábamos nuestras base de datos. Trajo consigo el concepto y modo de almacenamiento de nuestros backups, archived redo logs y otros elementos en el área denominada (Flashback| Flash Recovery Area). El FRA representa una respuesta a los cambios de costos y criticidad a la hora de gestar y recuperar nuestra información y 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 con 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 ( Fast Recovery Area: Area de recuperación rápida )

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 de alto nivel y practica para poseer la primera línea de backup en dispositivos rápidos ( discos ).

Habitualmente estos llamados discos realmente son particiones que provienen de una SAN (storage area network), 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, Voting Disks, etc.

En la actualidad nuestros backups están almacenados en primera línea en el FRA y la misma se basa sobre la constitución de una SAN. En particiones de la 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.

En primer lugar tenemos que listar las posibles opciones de almacenamiento diversas al FRA. Dentro de las cuales podemos poseer 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 otras

Para el presente artículo solo abordaremos una de las técnicas que poder trasladar nuestros backups a medios como: las 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. Este será la técnica utilizada para el presente arcticulo
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 ( Recovery Manager ). Esta opción será desarrollada en la parte II del presente articulo : “Protegiendo backups de RMAN contra fallos de la SAN ( Parte II )”
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 II del presente articulo : “Protegiendo backups de RMAN contra fallos de la SAN ( Parte III )”

A continuación trabajaremos con la opción nro.1:

cp comand de utilitario asmcmd

La comando cp del utilitario asmcmd ejecuta la transferencia de piezas ( archivos ) encontrados dentro del ASM hacia un destino diverso o igual al mismo. En este caso lo utilizaremos para un destino diverso al mismo. Llevaremos a cabo una transferencia de ASM a filesystem.

Concepto y Sintaxis:

cp Command
Purpose

Enables you to copy files between ASM disk groups on local instances to and from remote instances. The file copy cannot be between remote instances. The local ASM instance must be either the source or the target of the operation. You can also use this command to copy files from ASM disk groups to the operating system.

Syntax and Description

cp [-ifr] [connect_string:]src_fname [connect_string:]tgt_fname
cp [-ifr] [connect_string:]src_fnameN, src_fnameN+1…
      [connect_string:]tgt_directory

The syntax variables for the cp command are as follows:

```
connect_string 
```
- The ASMCMD
```
connection string 
```
for use with a remote instance copy. The
```
connect_string 
```
parameter is not required for a local instance copy, which is the default case. In the case of a remote instance copy, you need to specify the
```
connect string 
```
and ASM prompts for a password in a non-echoing prompt. The
```
connect_string 
```
is in the form of:
```
user_name@host_name[.port_number].SID 
```
The
```
user_name, host_name, 
```
and
```
SID 
```
are required. The default port number is
```
1521 
```
.
```
src_fname
```
(s) - Source file name to copy from. Enter either the fully qualified file name, the system-generated name, or the ASM alias.
```
tgt_fname 
```
- A user alias for the created target file name or alias directory name
```
tgt_directory 
```
- A target alias directory within an ASM disk group. The target directory must exist, otherwise the file copy returns an error.

The format of copied files is portable between Little-Endian and Big-Endian systems if the files exist in an ASM disk group. ASM automatically converts the format when it writes the files. For copying a non-ASM files from or to an ASM disk group, you can copy the file to a different endian platform and then use one of the commonly used utilities to convert the file

Table 7-2 Flags for the cp Command

Flag	Description
-i	Interactive, prompt before copy file or overwrite
-f	Force, if an existing destination file, remove it and try again without user interaction
-r	Recursive, copy forwarding sub-directories recursively
-help	Displays help text.

Examples

ASMCMD[+]>cp +DG1/vdb.ctf1 /backups/vdb.ctf1
copying file(s)...
source +DG1/vdb.ctf1
target /backups/vdb.ctf1
file, /backups/vdb.ctf1, copy committed.

ASMCMD[+DG1]> cp vdb.ctf1 /tmp
copying file(s)...
source +DG1/vdb.ctf1
target /tmp/vdb.ctf1
file, /tmp/vdb.ctf1, copy committed.

Oracle® Database Storage Administrator's Guide 11g Release 1 (11.1)

Part Number B31107-05
http://download.oracle.com/docs/cd/B28359_01/server.111/b31107/asm_util.htm#CHDJEIEA

Una vez visto en detalle el concepto del comando cp. Planteemos un ejemplo práctico y 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;
List of Backup Sets

===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
15      Full    878.57M    DISK        00:00:18     15-SEP-11
        BP Key: 16   Status: AVAILABLE  Compressed: NO  Tag: FULL_WEEKLY
        Piece Name: +FRA/mydb/backupset/2011_09_15/nnndf0_full_weekly_0.851.761928135
  List of Datafiles in backup set 15
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 7989338    15-SEP-11 +DATA/mydb/datafile/system.525.757028653
  2       Full 7989338    15-SEP-11 +DATA/mydb/datafile/undotbs1.466.757028655
  3       Full 7989338    15-SEP-11 +DATA/mydb/datafile/sysaux.638.757028653
  4       Full 7989338    15-SEP-11 +DATA/mydb/datafile/users.414.757028655
  5       Full 7989338    15-SEP-11 +DATA/mydb/datafile/undotbs2.893.757028727

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
16      Full    14.92M     DISK        00:00:03     15-SEP-11
        BP Key: 17   Status: AVAILABLE  Compressed: NO  Tag: FULL_WEEKLY
        Piece Name: +FRA/mydb/backupset/2011_09_15/ncsnf0_full_weekly_0.878.761928161
  Control File Included: Ckp SCN: 7990818      Ckp time: 15-SEP-11
  SPFILE Included: Modification time: 15-SEP-11
  
  RMAN>

En el log presentado se puede apreciar la generación de 2 piezas (+FRA/mydb/backupset/2011_09_15/nnndf0_full_weekly_0.851.761928135 & +FRA/mydb/backupset/2011_09_15/ncsnf0_full_weekly_0.878.761928161). Ambas piezas son el objetivo a transferir a una localización de disco diversa al FRA.

Paso2: Visualizando localizaciones de piezas generadas

Visualicemos las especificaciones de las piezas generadas a través del vistas de diccionario de datos de la base de datos.

SQL> select HANDLE from v$backup_piece
  2  where TAG='FULL_WEEKLY';

HANDLE
-------------------------------------------------------------------
+FRA/mydb/backupset/2011_09_15/nnndf0_full_weekly_0.851.761928135
+FRA/mydb/backupset/2011_09_15/ncsnf0_full_weekly_0.878.761928161

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 @<PATH>/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 <PATH>/Transfer_full_backup.sql


select 'export ORACLE_SID=+ASM' from dual;
select 'export ORACLE_HOME=/u01/app/11.2.0/grid' from dual;

select '/u01/app/11.2.0/grid/bin/asmcmd cp ''' || handle || 
''' /NAS_rman_backups/' from v$backup_piece
where TAG='FULL_WEEKLY';

spool off
exit;

Es apreciable destacar que la vista “V$BACKUP_PIECE” 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 nuestra transferencia.

Referencia de la vista “V$BACKUP_PIECE”

V$BACKUP_PIECE

V$BACKUP_PIECE displays information about backup pieces from the control file. Each backup set consists of one or more backup pieces.

Column	Datatype	Description
RECID	NUMBER	Backup piece record ID
STAMP	NUMBER	Backup piece record stamp
SET_STAMP	NUMBER	Backup set stamp
SET_COUNT	NUMBER	Backup set count
PIECE#	NUMBER	Backup piece number (1-N)
COPY#	NUMBER	Indicates the copy number for backup pieces created with duplex enabled. 1 if the backup piece is not duplexed.
DEVICE_TYPE	VARCHAR2(17)	Type of the device on which the backup piece resides. Set to DISK for backup sets on disk. See Also: V$BACKUP_DEVICE
HANDLE	VARCHAR2(513)	Backup piece handle identifies the backup piece on restore
COMMENTS	VARCHAR2(64)	Comment returned by the operating system or storage subsystem. Set to NULL for backup pieces on disk. This value is informational only; not needed for restore.
MEDIA	VARCHAR2(65)	Name of the media on which the backup piece resides. This value is informational only; not needed for restore.
MEDIA_POOL	NUMBER	The media pool in which the copy resides. This is the same value that was entered in the POOL operand of the Recovery Manager backup command.
CONCUR	VARCHAR2(3)	(YES \| NO) Indicates whether the piece on a media that can be accessed concurrently
TAG	VARCHAR2(32)	Backup piece tag. The tag is specified at backup set level, but stored at piece level.
STATUS	VARCHAR2(1)	Indicates the status of the piece: A (available), D (deleted), or X (expired)
START_TIME	DATE	Starting time
COMPLETION_TIME	DATE	Completion time
ELAPSED_SECONDS	NUMBER	Number of elapsed seconds
DELETED	VARCHAR2(3)	(YES/NO) NO indicates that the file still exists. YES indicates the file no longer exists because it has been deleted.
BYTES	NUMBER	Size of the backup piece (in bytes)
IS_RECOVERY_DEST_FILE	VARCHAR2(3)	Indicates whether the file was created in the flash recovery area (YES) or not (NO)
RMAN_STATUS_RECID	NUMBER	Owning V$RMAN_STATUS record ID
RMAN_STATUS_STAMP	NUMBER	Owning V$RMAN_STATUS record stamp
COMPRESSED	VARCHAR2(3)	Indicates whether the backup piece is compressed (YES) or not (NO)

Oracle® Database Reference 10g Release 1 (10.1)

Part Number B10755-01
http://download.oracle.com/docs/cd/B12037_01/server.101/b10755/dynviews_1029.htm

Por ejemplo, si se desea filtrar las piezas por:

TAG utilizamos el campo TAG
Tiempo o fecha utilizamos el campo START_TIME
Modo de compresión utilizamos el campo COMPRESSED
y así sucesivamente

Producto de la corrida del script “Pre_transfer_backup_full.sh” se generara el script “Transfer_full_backup.sql”. Dicho script posteriormente deberá ser corrido por el usuario grid, tomando en cuenta que en versión 11g el usuario dueño del Oracle Server en single instance o RAC es el usuario “oracle” y el usuario dueño del la Infraestructura de grid es el usuario grid.

El contenido del script “Transfer_full_backup.sql” será algo similar a esto:

/u01/app/11.2.0/grid/bin/asmcmd  cp 

'+FRA/mydb/backupset/2011_09_15/nnndf0_full_weekly_0.851.761928135'  /NAS_rman_backups/

/u01/app/11.2.0/grid/bin/asmcmd  cp 
'+FRA/mydb/backupset/2011_09_15/ncsnf0_full_weekly_0.878.761928161'  /NAS_rman_backups/

Paso4: Ejecutar el script “Transfer_full_backup.sql”

El script posteriormente tendrá que se ejecutado “Transfer_full_backup.sql” por el usuario grid. Nota: incluir al final de la generación del script “Transfer_full_backup.sql” el cambio de permisos adecuados a nivel de sistema operativo de manera que el usuario grid pueda ejecutar el mismo. El “feedback” de la ejecución seria de la siguiente manera:

copying  +FRA/mydb/backupset/2011_09_15/nnndf0_full_weekly_0.851.761928135-> 
/NAS_rman_backups// nnndf0_full_weekly_0.851.761928135

copying  +FRA/mydb/backupset/2011_09_15/ncsnf0_full_weekly_0.878.761928161->  
/NAS_rman_backups// ncsnf0_full_weekly_0.878.761928161

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

Articulo Publicado en OTN LAD Español:

http://www.oracle.com/technetwork/es/articles/database-performance/backups-rman-contra-fallos-san-522445-esa.html

Joel is an Expert DBA with over 12 years of experience specialized in several database areas with special focus in High Availability and Disaster Recovery Solutions ( RAC, RMAN, Data Guard, … ), Upgrades, Backup & Recovery, Database Hardening, Performance Tuning and others. During these years Joel has worked as a Senior Consultant with a large number of companies and clients in various countries: Venezuela, Panama, Costa Rica, Dominican Rep., Haiti, Nicaragua, Guatemala, Colombia, Honduras, Ecuador, Mexico, India and others. Joel is frequent speaker at many conferences such as OTN LAD TOUR and others. Among other complementary activities Joel teaches regularly High Availability courses in Oracle University of several countries in Latin America and publishes articles for OTN LAD. Joel was the first Latin American to be named “OTN Expert” in year 2003, Oracle ACE since 2004 and Oracle ACE Director since 2012.

Joel Pérez Oracle ACE Director's Blog

jueves, 15 de noviembre de 2012