RMAN Database 12c: Recuperación de tablas ( Parte I )

Por Joel Pérez y Wissem El Khlifi
Publicado en julio 2013

Índice de contenidos

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 recuperación de tablas provenientes de respaldos realizados con el utilitario RMAN ( Oracle Recovery Manager ).

“Database12c” la nueva versión de manejador de base de datos de Oracle Corporation, nosotros los tecnólogos Oracle nos preguntábamos “que mas…” podría Oracle adicionar como nuevas características?, de que forma Oracle nos iba a sorprender esta vez y como siempre, las nuevas características y nueva arquitectura no solo nos sorprenden sino que una vez mas nos llevan a otra era…, “Cloud Computing”…

Personalmente he tenido la oportunidad de trabajar con tecnología Oracle como DBA desde su versión 8. 8i la era del internet, 9i la era del internet con mayores elementos, recuerdo que uno de los componentes de mayor importancia fue la presentación de RAC9i “la era naciente de RAC…”, 10g nos sorprendió con el concepto de ASM… y filosofía Grid, 11g & 11g R2 sobre todo por sus mejoras de alto nivel relacionadas con RAC & Data Guard…, 12c… Cloud Computing, nuevas características… mas de 500 las cuales iremos cubriendo gradualmente a través de artículos y otros elementos de ayuda.

Entremos en materia… al momento de plantear una estrategia de respaldo y recuperación son diversos y múltiples los factores a tomar en cuenta para plantear y establecer una excelente estrategia. Y tal como siempre expreso en conferencias, artículos, y otros… “Jamás serás capaz de plantear una excelente estrategia de respaldo sino eres experto recuperando…”, es decir… el planteamiento de una excelente estrategia de recuperación se basa en establecer las condiciones y mecanismos, para poseer en cualquier momento en modo optimo los elementos necesarios para una recuperación rápida y efectiva de la base de datos en forma completa o parcial.

Al momento de plantear una estrategia de recuperación de base de datos se toma en cuenta los factores para una recuperación completa o parcial de la base de datos ( BBDD ), cuando se hace referencia a una recuperación parcial podríamos establecer que la parcialidad podria estar enfocada a: restauración completa de la estructura de la BBDD exceptuando “tablespaces”, TSPITR ( Tablespace Point-in-Time Recovery ) o parcialidad de su contenido ( objetos ) haciendo uso de Oracle “Flashback”.

Previo a la versión de base de datos 12cR1 la recuperación de un objeto no se podía realizar de forma directa desde un respaldo tomado con RMAN. La metodología usual consistía en realizar un “restore/recover” total o parcial de la BBDD y para así con un proceso posterior poder efectuar la extracción del mismo. Algunos mecanismos podrían ser los siguientes:

Export/Import
Insert-Select directo o con “Database links”
u otros

Algunas de las dificultades o implicaciones con el método anterior estaban basadas en:

Espacio para alojar la nueva BBDD: de forma regular la opción más rápida y común a implementar seria restaurar la BBDD completa hasta un determinado punto del tiempo. Bajo estas condiciones esto exigiría la disponibilidad del espacio total de la misma lo cual podría representar una dificultad si la BBDD original es de gran tamaño o si no se dispone del espacio necesario. Si se posee un poco mas de experiencia en términos de técnicas de restauración se podría pensar en la técnica de restauración total realizando el “skip” de todos aquellos tablespaces que no posean información deseada y asi ahorrar espacio de restauración de “datafiles”.

Técnica de Extracción manual: para el presente caso la técnica manual ( Export/Import ) no representaría mayor dificultad de llevado a cabo mas esta basado en pasos adicionales como exportar la tabla, importar la misma o crear “database links” entre la BBDD restaurada y la BBDD destino, etc

Con la nueva característica de recuperación de tablas y particiones de tablas de RMAN Database 12c podremos realizar el proceso de forma directa con una sola línea de comando.

Para llevar a cabo la tarea de utilizar la nueva característica es fundamental contar un respaldo full de los “tablespaces”:

UNDO
SYSTEM
SYSAUX
SYSEXT ( en caso de que existiese )

Y el “tablespace” correspondiente que posea la tabla o partición deseada a recuperar.

Los requisitos están basados en los elementos necesarios para conformar una nueva BBDD la cual será denominada como BBDD Auxiliar. La BBDD Auxiliar es una BBDD temporal creada para generar un “Data Pump export dump file” que será objeto de contenido de datos para la obtención finalmente del objeto deseado ( Tabla a Recuperar ). La BBDD Auxiliar no representa una BBDD que deba crearse previo al proceso de la ejecución del comando. La misma es creada de forma automática durante el proceso de “RECOVER” y los mecanismos de acción del mismo comando “RECOVER” remueven la misma al final del proceso.

La recuperación de tablas y/o particiones de tablas provenientes de un respaldo de RMAN son útiles en los siguientes escenarios:

Necesidad de recuperación de un número pequeño o específico de tablas a un determinado punto del tiempo. Tal como fue señalado en líneas anteriores, esto pudiese ser llevado a cabo con la técnica de TSPITR pero la restauración estaría limitada en su grado mas fino a realizarla a nivel de “tablespace” implicando así restauración de objetos no deseados.
Recuperación de tablas que han sido objeto de corrupciones lógicas o tablas que han sido removidas de la BBDD con opción regular o “purge” lo cual implica que la tabla ya no estaría disponible inclusive en el “recycle bin” de la BBDD.
Cuando el objeto ( tabla ) ha sido removido del “Undo” tablespace a causa de la política de retención del mismo, la característica “Flashback Table” no puede realizar la recuperación del mismo.
Posterior a la aplicación de una sentencia DDL ( Data Definition Languague ) la estructura de la tabla podría haber sufrido cambios, dichos cambios anulan la posibilidad de acción de recuperación utilizando la característica “Flashback Table”. “Flashback Table” posee la capacidad de recuperar datos sobre una tabla que aun disponga de la misma estructura original al momento de haber realizado la operación no deseada como borrar registros, actualizar registros no deseado o cualquier otra operación que se desee revertir.

Para la recuperación de tablas se utilizara el ya conocido comando “RECOVER” pero esta vez con funcionalidades nuevas propias de “Oracle Database 12c”. Para llevar a cabo la tarea de recuperación es necesario disponer de la siguiente información:

Nombre de la(s) tabla(s) y/o partición(es) a ser recuperadas
Punto en el tiempo ( Fecha con hora, minutos y segundos ) deseado para la recuperación
Especificar si la tabla será o no importada en la BBDD “target”

RMAN utiliza toda esta información para automatizar el proceso de recuperación de las tablas especificadas y/o particiones de tablas especificadas, como parte del proceso de recuperación, RMAN crea una base de datos auxiliar para alojar los objetos a ser restaurados.

Los pasos llevados a cabo por RMAN para la recuperación de tablas y/o particiones de tablas son los siguientes:

Determina cual respaldo ( backup sets ) poseen la tabla deseada a restaurar con el objetivo de llevarla al punto deseado en el tiempo. Internamente el proceso de búsqueda se establece bajo la misma filosofía como cuando deseamos restaurar la BBDD o un determinado “tablespace” a un determinado punto en el tiempo.
Crea la BBDD auxiliar y recupera en ella la(s)tabla(s) y/o partición(es) de tabla(s) especificadas en la sentencia de “RECOVER”. La locación de “datafiles” podrá ser especificada en diversos modos lo cual abordaremos en otra edición de esta misma serie de artículos, sin embargo en el ejemplo practico que realizaremos se especificara la ruta para los “datafiles” de la nueva BBDD auxiliar.
El proceso de recuperación genera un “Data Pump export dump file” con el contenido de la(s)tabla(s) y/o partición(es) de tabla(s) especificadas a ser recuperadas
Opcionalmente se podrían establecer las clausulas para renombrar tablas y/o particiones en la BBDD “target”. La BBDD “Target” es la BBDD original donde el objeto fue perdido o corrupto de alguna manera no deseada.

Veamos un ejemplo práctico de esta valiosa nueva característica.

Objetivo: Generar el “Data Pump export dump file” de una tabla a recuperar proveniente un respaldo realizado con “RMAN”. Para el presente escenario, solo se generara el “Data Pump export dump file”, no activaremos la opción de que el objeto deseado de recuperación sea importado en la BBDD “Target”

Nombre de BBDD “Pluggable” a ser usada en nuestro ejemplo: ORAWISS12C

Iniciemos...

Modo “Mount” & “Open” de la BBDD

Se establecerá conexión con la BBDD “ORAWISS12C” la cual se encuentra originalmente en estado “Mount”, procediendo posteriormente a su apertura.

Actividad	TSPITR	“RECOVER TABLE”
Creación de BBDD para la Recuperación	Debe ser creada manualmente o con el DBCA ( Database Configuration Assistant )	La BBDD Auxiliar es creada automáticamente
Establecimiento de valores para Archivos de Parametros ( SPfile & Init )	El DBA tomara un tiempo para escoger valores modestos con el objetivo de no sobrecargar el sistema operativo a raíz de esta nueva BBDD a crear	Los valores del archivo de parámetro de la instancia auxiliar son adjudicados de forma automática. Los valores automaticos escogidos son bajos, óptimos y suficientes para llevar a cabo la tarea
Proceso de “Restore” de la BBDD	El DBA deberá tomar un tiempo para escoger si el restaurado se llevara a cabo en el mismo servidor donde esta alojada la BBDD de producción o en un servidor alterno. Si decidiese escoger el mismo servidor donde se encuentra la BBDD de producción el método ideal seria utilizar “RMAN Duplicate” para evitar complicaciones de cambios de nombres de la nueva BBDD. Si decidiese utilizar algún otro servidor podría escoger utilizar el mismo nombre de la BBDD de producción u otro alternativo. Hay que destacar que pudiera haber riesgo de perjurio contra la BBDD original si se ejecuta “RMAN Duplicate” existiendo estas 2 condiciones: • Estando la BBDD original con sus “datafiles” en “filesystem” • Valores de conversión mal configurados ( DB_FILE_NAME_CONVERT & LOG_FILE_NAME_CONVERT ) Si esas 2 condiciones sucediesen podría haber el riesgo de que “datafiles” de la BBDD original pudiesen ser sobrescritos. Si el DBA decidiese llevar a cabo “RMAN Duplicate” en el mismo servidor de producción se aconsejaría que el mismo tuviese un alto “expertise” utilizando dicha técnica.	El nombre de la BBDD Auxiliar es adjudicado automáticamente, no existe riesgo alguno de realizar el procedimiento en el mismo servidor de producción siempre y cuando se este atento con el uso de la clausula “NOTABLEIMPORT”
Restaurado de “Tablespaces”	El DBA tendrá que tomar una porción de tiempo para determinar en cual “tablespace” se encuentra el objeto a ser recuperado. En modo optimo se podrá utilizar “RESTORE DATABASE” realizando “skip” de tablespaces no deseados, dejando solo los principales de toda BBDD Oracle ( System, Sysaux, Undo, etc… ) y el o los “tablespaces” que contengan la o las tablas a ser recuperadas. Es importante destacar que en el “tablespace” de datos donde se encuentre la(s) tabla(s) a ser recuperadas podrán existir más objetos que conlleven a la necesidad de que el proceso consuma mas espacio en disco y tiempo de restauración.	El proceso de “Restore/Recover” es automático, restaurando solo los “tablespaces” principales de la BBDD y el “tablespace” que contenga la(s) tabla(s) a ser recuperadas pero en dicho “tablespace” de datos solo se encontrara(n) el o los objetos deseados de recuperación. Por lo tanto el proceso es óptimo en espacio en disco y tiempo de restauración.
Generación de “Data Pump export dump file”	El DBA a través de un proceso manual deberá crear un directorio ( “Create Directory …” ) y realizara manualmente el proceso de exportar y/o importar la tabla en la BBDD original o también llamada “Target”	El proceso de creación del directorio, “export” e “import” es automático y todo se configura en el mismo comando “RECOVER TABLE”
Remoción de la BBDD	El DBA deberá remover la BBDD manualmente o a través del DBCA	El proceso del comando “RECOVER TABLE” remueve automáticamente la BBDD Auxiliar creada