Create Different Types of RMAN Backups to Cater for Different Performance and Retention Requirements

1. Documentación en Tahiti -> Masters Book List -> Backup and Recovery User’s Guide -> 9 Backing Up the Database

2. Las directivas de RMAN nos permiten configurar los requisitos de retención de nuestros backups. Por defecto tenemos una retención de 1 backup. RMAN considera obsolete cualquier backup adicional (FULL o LEVEL 0) al último que hayamos hecho.

# Directiva por defecto para controlar la retención
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

3. Supongamos que tenemos un requisitio de negocio que nos dice que tenemos que almacenar los últimos tres backups de nuestra BD. Configurar este requisito es tan sencillo como utilizar una REDUNDANCY de 3.

# Configuramos RMAN para especificar que se guarden los 3 últimos backups (LEVEL 0 o FULL)
# Siempre que tengamos tres copias, la cuarta se marcará como OBSOLETE
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

4. Otro caso que ya hemos visto, es definir una ventana de recuperación para que RMAN gestione la retención en base al tiempo y no al número de copias. Un requisito bastante común es definir el número de semanas de retención de los backups. Supongamos que en nuestra empresa, tenemos que definir dos semanas de retención. Prestad atención a que voy a utilizar 15 días y no 14, ya que es una buena práctica añadir uno o dos días al requisito que nos impongan.

-- Lo primero es modificar el parámetro CONTROL_FILE_RECORD_KEEP_TIME
-- Esto nos permite registrar la info. de los backups en el CONTROLFILE durante 15 días
ALTER SYSTEM SET CONTROL_FILE_RECORD_KEEP_TIME=15 SCOPE=BOTH;
# Especificamos la ventana de recuperación en 15 días en RMAN
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;

5. También podemos controlar la retención de las piezas u objetos de backup que hemos realizado con la clausula KEEP. Sin embargo, esta clausula no se puede utilizar con backups realizados en la FRA, y además debemos utilizar el catálogo para ello.

# En el siguiente ejemplo realizamos un par de backups con clausula KEEP
# Debemos conectarnos al catálogo para hacer las pruebas
rman target / catalog rman/rman@OEM
# Lanzamos un backup de la BD que no expire nunca
BACKUP DATABASE KEEP FOREVER FORMAT '/tmp/%U';
# Probamos a definicar un tiempo de expiración de un día para el backup de un datafile
BACKUP DATAFILE 4 KEEP UNTIL TIME 'SYSDATE+1' FORMAT '/tmp/%U';

6. Cuando tenemos requisitos de rendimiento que afectan al rendimiento, tenemos ciertas clausulas que nos pueden ayudar. Vamos a utilizar varios ejemplos de requisitos de negocio y como resolverlos.

# Backup completo con impacto mínimo en la BD y una duración máxima de 30 minutos
BACKUP AS BACKUPSET DURATION 00:30 MINIMIZE LOAD PARTIAL DATABASE;

# Backup completo minimizando el tiempo de ejecucion y una duración máximo de 15 minutos
# Hemos eliminado PARTIAL para que en caso de que no se complete, se considere FALLIDO
BACKUP AS BACKUPSET DURATION 00:15 MINIMIZE TIME DATABASE;

7. El último ejercicio que vamos a hacer consiste en limitar la velocidad de cada canal con el parámetro RATE. De esta forma limitamos la velocidad de transferencia para no saturar los recursos.

# Limitamos la tasa de transferencia a un máximo de 20M por canal
RUN {
  ALLOCATE CHANNEL d1 DEVICE TYPE DISK RATE 20M;
  ALLOCATE CHANNEL d2 DEVICE TYPE DISK RATE 20M;
  BACKUP AS BACKUPSET DATABASE;
  RELEASE CHANNEL d1;
  RELEASE CHANNEL d2;
}

# Podemos establecer el límite por defecto con CONFIGURE CHANNEL
CONFIGURE CHANNEL DEVICE TYPE DISK RATE 20M;
# Eliminamos la configuración
CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR;

8. Otra aproximación que ya hemos utilizado para tener en consideración el rendimiento consiste en utilizar las siguientes recomendaciones (incluyo todas las recomendaciones vistas):

· Configurar la FRA (Fast Recovery Area)
· Configurar varios canales
· Habilitar BLOCK CHANGE TRACKING (para backups incrementales)
· Habilitar AUTOBACKUP
· Habilitar OPTIMIZATION
· Utilizar “RECOVER COPY OF DATABASE” + “BACKUP INCREMENTAL LEVEL 1”