Introducción:
Flashback es una tecnología introducida desde “Oracle Database 10g”. La tecnología Flashback nos permite realizar varias operaciones dentro de la base de datos con la intención de poder encontrar soluciones ante problemas lógicos principalmente, tales como restaurar una tabla a un momento antes de algún “DELETE” involuntario, o restaurar una tabla que fue eliminada, consultar los datos de una tabla en un momento específico en el pasado, o regresar la base de datos completa a un punto en el tiempo en el pasado, entre otros. Lo bueno de esta tecnología es que no necesita de una restauración física de los Datafiles de la base de datos. Flashback utiliza datos Undo o “Flashback Logs” dependiendo de qué función de Flashback se esté utilizando. Entonces, tal como se ve Flashback no es un reemplazo a métodos de recuperación como “RMAN restore/recover”, export/import, Respaldos en frio u otros; sino más bien es un complemento.
A continuación, se muestra una tabla en donde se puede ver por cada función de Flashback qué tipo de información se utiliza para deshacer los cambios:
| Flashback Technology | Información usada | Escenarios de ejemplos |
|---|---|---|
| Database | Flashback logs | Deshacer un TRUNCATE TABLE, Cambios no deseados en muchas tablas |
| Drop | Recycle Bin | Deshacer un DROP TABLE |
| Table | Datos Undo | Deshacer un UPDATE con un mal WHERE |
| Query | Datos Undo | Comparar datos de una tabla entre dos puntos en el tiempo. |
| Version | Datos Undo | Comparar versiones de una fila |
| Transaction | Datos Undo | Investigar varios estados de los datos históricamente |
En este artículo se tratará específicamente la función “Flashback Database”.
Algunos administradores de Bases de Datos suelen confundir mucho un “RMAN restore/recover” con una operación “Flashback Database”, pero hay una gran diferencia entre uno y el otro. “RMAN Restore / recover” como su nombre lo indica, necesita restaurar todos los Datafiles a un punto en el tiempo y luego necesita aplicar información Redo desde los “Archived Logs” para llevar la base de datos a un punto consistente. Esto implica que para utilizar “RMAN Restore/recover” se necesita tener respaldos previamente realizados. Mientras que Flashback Database confía en que todos los Datafiles están físicamente correctos, pues Flashback Database no es utilizado para reparar errores físicos, sino lógicos. Por lo tanto, Flashback Database necesita una base de datos físicamente sin problemas para poder funcionar, y desde ese punto empieza a restaurar los bloques que fueron modificados desde los “Flashback Logs”. Luego de restaurar los bloques que fueron modificados gracias a los “Flashback Logs” se aplica información Redo para restaurar las últimas operaciones. Se ve entonces que con “Flashback Database” no se necesita tener respaldos previamente realizados, sin embargo, sí necesita de los Archivelogs para el período de tiempo que se está utilizando con la operación “Flashback Database”.
Con cada versión las funciones de Flashback han sido mejoradas. Cuando surgió “Oracle Database 12cR1” en el año 2013, la arquitectura Multitenant fue introducida. Con esta nueva arquitectura se introdujeron los conceptos de “Container Database” y “Pluggable Database”. En Oracle Database 12cR1 bajo una arquitectura Multitenant la operación “Flashback Database” era aplicado al “Container Database” en su totalidad, impactando así todos los “Pluggable Databases” dentro de él. Es decir, si queríamos deshacer un problema lógico en una “Pluggable Database” en específico, teníamos que aplicar “Flashback Database” a todo el “Container Database”, esto hacia que el problema lógico en la “Pluggable Database” en particular fuera solucionado, pero todas las demás “Pluggable Database” también eran regresadas hasta el mismo punto en el tiempo en que se aplicó el “Flashback Database”. Para algunos administradores de bases de datos esto era una desventaja. Pero Oracle está constantemente innovando y mejorando sus productos, y en noviembre del año 2016, cuando liberó la versión Oracle Database 12cR2 para su nube (Oracle Public Cloud) ya incluía una gran mejora en “Flashback Database”, permitiendo ahora poder realizar “Flashback Database” a nivel de una “Pluggable Database”, a esta nueva funcionalidad se le llamó “Flashback Pluggable Database”.
Escenarios en donde puede ser utilizado “Flashback Database”:
- Útil para realizar pruebas de aplicaciones y luego deshacerlas.
- Para pruebas de Upgrade
- Deshacer cambios no deseados
- Deshacer un “OPEN RESETLOGS”. Regresar a una encarnación anterior
- Llevar una PDB a diferentes puntos en el tiempo
- otros
Prerrequisitos para utilizar Flashback Pluggable Database
Configurar el “Fast Recovery Area”:
SQL> alter system set db_recovery_file_dest='/u03/app/oracle/fast_recovery_area' scope=both;
System altered. Configurar la retención de los “Flashback Logs”
SQL> alter system set db_flashback_retention_target=4320 scope=both;
System altered.
NOTA: Este parámetro es expresado en minutos.
Es importante tomar en cuenta que esta retención no es ninguna garantía de que los “Flashback Logs” necesarios estarán disponibles para cubrir este periodo de tiempo. Este tiempo de retención es un “tiempo deseado” en que Oracle tratará de retener los “Flashback Logs” pero si el espacio en el “Fast Recovery Area” no es suficiente para mantener este periodo de tiempo, entonces los “Flashback Logs” más viejos serán eliminados para darle espacio a nuevos.
Habilitar Flashback a nivel de Container Database:
A partir de Oracle Database 11gR2 la siguiente sentencia puede ser ejecutada mientras la base de datos está abierta en “read write”, sin embargo, un prerrequisito para habilitar flashback es que la base de datos esté ya en “Archive Mode”. Esta operación se debe realizar en el CDB$ROOT:
SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT
SQL> alter database flashback;
Database altered.En la versión Oracle Database 12.2.0.1.0 Enterprise Edition Extreme Performance (Oracle Public Cloud) aún no es posible habilitar Flashback a nivel de una sola “Pluggable Database”, tal como se ve a continuación. Sin embargo, la sintaxis es aceptada, por lo que se podría esperar que en las próximas versiones esta función ya esté implementada.
SQL> alter session set container=NuvolaPDB1;
Session altered.
SQL> alter database flashback on;
alter database flashback on
*
ERROR at line 1:
ORA-03001: unimplemented feature
Verificar si el “Container Database” tiene habilitado Flashback:
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
YES
Como buena práctica se recomienda utilizar “force logging” en la “Pluggable Database” en donde se planea utilizar “Flashback Pluggable Database”, pues Flashback no puede regenerar operaciones que fueron realizadas con “no logging”. A partir de la versión Oracle Database 12.1.0.2 se puede habilitar “Force Logging” a nivel de “Pluggable Database”, de esta manera esta configuración no impactará a las demás “Pluggable Databases”.
SQL> select pdb_name, force_logging, force_nologging from cdb_pdbs
PDB_NAME FORCE_LOGGING FORCE_NOLOGGING
---------- ------------- ---------------
PDB$SEED NO NO
NUVOLAPDB1 YES NO
NUVOLAPDB2 NO NOComo buena practicas se aconseja verificar que todos los Tablespaces de la “Pluggable Database” en donde se planea utilizar “Flashback Pluggable Database” tengan habilitado Flashback:
SQL> show con_name
CON_NAME
-------------------------
NUVOLAPDB1
SQL> select ts#, flashback_on from v$tablespace;
TS# FLASHBACK_ON
--- -------------
0 YES
1 YES
2 YES
3 YESSeleccionar marcas de tiempos de restauración:
Para poder utilizar la operación “Flashback Pluggable Database” se necesitan marcas de tiempos de restauración. Estas marcas pueden ser las siguientes:
SCN: Se puede saber el actual SCN mediante la siguiente función:
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
1760506 Si se necesita saber un SCN en base a una fecha puedes utilizar la siguiente función:
SQL> select timestamp_to_scn(to_date('11-28-2016 04:52:41','mm-dd-yyyy hh24:mi:ss') ) SCN from dual;
SCN
------------
1761245
Una fecha en específico:
SQL> select to_char(sysdate,'mm-dd-yyyy hh24:mi:ss') cdate from dual;
CDATE
-------------------
11-28-2016 04:52:41Un punto de retención:
SQL> create restore point T3 guarantee flashback database;
Restore point created.
Un punto de retención garantizado
SQL> create restore point T3 guarantee flashback database;
Restore point created.Un punto de retención limpio: Un punto de restauración limpio es cualquier punto de restauración creado cuando la Pluggable Database está cerrada y por lo tanto no hay transacciones activas. Estos puntos de restauración son creados desde el CDB$ROOT y solamente pueden crearse cuando se utiliza “Shared Undo”. Estos puntos no funcionan en “Local Undo”.
Asumiendo que se tiene “Shared Undo” configurado:
SQL> alter pluggable database NuvolaPDB1 close;
Pluggable database altered.
SQL> alter session set container=NuvolaPDB1;
Session altered.
SQL> create clean restore point CleanPoint;
Restore point created.
SQL> alter pluggable database NuvolaPDB1 open;
Pluggable database altered.Ambiente utilizado para los ejemplos:
Ahora se realizarán unos ejemplos de “Flashback Pluggable Database”, se utilizarán dos “Pluggable Databases”: “NuvolaPDB1” y “NuvolaPDB2”. Todas las operaciones se realizarán sobre “NuvolaPDB1”, mientras que “NuvolaPDB2” servirá para demostrar que después de una operación “Flashback Pluggable Database” sobre “NuvolaPDB1”, la PDB “NuvolaPDB2” no fue impactada. En ambas “Pluggable Databases” se analizará cuatro puntos en el tiempo:
T0: 4 filas existen en la tabla “Nuvola.Country” en ambas “Pluggable Databases.
T1: El registro “USA” es eliminado en la tabla “Nuvola.Country” en “NuvolaPDB1”.
T2: El registro “Canada” es eliminado en la tabla “Nuvola.Country” en “NuvolaPDB1”.
T3: El registro “Brazil” es eliminado en la tabla “Nuvola.Country” en “NuvolaPDB1”.
T4: El registro “Guatemala” es eliminado en la tabla “Nuvola.Country” en “NuvolaPDB1”.
En los ejemplos se realizarán cuatro operaciones “Flashback Pluggable Database”, y entre cada operación se irá mostrando las filas en la tabla “Nuvola.Country” en ambas “Pluggable Databases”, con la intención de mostrar que dichos cambios fueron desechos únicamente en “NuvolaPDB1”, sin impactar en lo absoluto “NuvolaPDB2.
Flashback Pluggable Database cuando se utiliza “Local Undo”
Tiempo actual (T4):
Actualmente NuvolaPDB1 está en “T4”, lo cual significa que no hay ninguna fila en la tabla Nuvola.Country. “NuvolaPDB2” también está actualmente en “T4”, lo que significa que hay 4 filas en la tabla Nuvola.Country:
SQL> show con_name
CON_NAME
--------------------------
NUVOLAPDB1
SQL> select * from Nuvola.Country;
no rows selected
SQL> show con_name
CON_NAME
--------------------------
NUVOLAPDB2
SQL> select * from Nuvola.Country;
COUNTRY
--------------
Guatemala
Brazil
Canada
USAFlashback PDB a “T3” usando un punto garantizado de restauración
Conectarse utilizando un usuario que tenga los privilegios “SYSDBA” o “SYSBACKUP”:
SQL> show user
USER is "SYS"
Conectarse al CDB$ROOT:
SQL> show con_name
CON_NAME
--------------------------
CDB$ROOT
Cerrar la “Pluggable Database” en donde se ejecutará la operación Flashback:
SQL> alter pluggable database NuvolaPDB1 close;
Pluggable database altered.Verificar que la “Pluggable Database” NuvolaPDB1 esté cerrada y que NuvolaPDB2 permanezca abierta:
SQL> select name, open_mode from v$pdbs
NAME OPEN_MODE
----------- ----------
PDB$SEED READ ONLY
NUVOLAPDB1 MOUNTED
NUVOLAPDB2 READ WRITEEjecutar la operación “Flashback Pluggable Database”:
SQL> flashback pluggable database NuvolaPDB1 to restore point T3;
Flashback completeAbrir la “Pluggable Database” con “OPEN RESETLOGS”:
SQL> alter pluggable database NuvolaPDB1 open resetlogs;
Pluggable database altered.
Verificar los datos en el tiempo “T3” en “NuvolaPDB1”:
SQL> select * from Nuvola.Country;
COUNTRY
---------------
Guatemala
Verificar los datos en el tiempo “T3” en “NuvolaPDB2”:
SQL> select * from Nuvola.Country;
COUNTRY
---------------
Guatemala
Brazil
Canada
USANOTA: Todos los pasos mostrados hasta acá deben de ser ejecutados cada vez que se realiza un “Flashback Pluggable Database”. Sin embargo, de ahora en adelante se omitirán la mayoría de los pasos y solamente se mostrarán los pasos relevantes para las posteriores operaciones.
Flashback PDB hacia “T2” utilizando un tiempo específico
SQL> flashback pluggable database NuvolaPDB1
to timestamp to_timestamp('11-28-2016 04:52:41','mm-dd-yyyy hh24:mi:ss');
Flashback complete.
Verificar los datos en el tiempo “T2” en “NuvolaPDB1”:
SQL> select * from Nuvola.Country;
COUNTRY
---------------
Guatemala
Brazil
Flashback PDB hacia “T1” usando un punto de restauración
SQL> flashback pluggable database NuvolaPDB1 to restore point T1;
Flashback complete.
Verificar los datos en el tiempo “T1” en “NuvolaPDB1”:
SQL> select * from Nuvola.Country;
COUNTRY
---------------
Guatemala
Brazil
Canada
Flashback PDB hacia “T0” usando un SCN
SQL> flashback pluggable database NuvolaPDB1 to scn 1760506;
Flashback complete.
Verificar los datos en el tiempo “T0” en “NuvolaPDB1”:
SQL> select * from Nuvola.Country;
COUNTRY
---------------
Guatemala
Brazil
Canada
USAFlashback Pluggable Database cuando se utiliza “Shared Undo”
Ahora se mostrarán algunos ejemplos utilizando la configuración “Shared Undo”.
Flashback PDB sin usar un punto limpio de restauración:
La documentación de Oracle Database 12.2.0.1.0 señala que es posible realizar una operación “Flashback Pluggable Database” sin necesidad de requerir Puntos limpios de restauración. Esto es a un SCN, un punto de restauración (no limpio) o un tiempo cualquiera. Dado que el Undo Tablespace del CDB$ROOT es compartido en una configuración “Shared Undo” los datos undo para varias “Pluggable Databases” pueden estar mezclados dentro del Tablespace undo, e incluso a nivel de bloques, un mismo bloque podría tener información undo de varias “Pluggable Databases”, esto hace complejo realizar la operación “Flashback Pluggable Database”. Para llevar a cabo esto en una configuración de “Shared Undo”, Oracle se apoya en una instancia auxiliar. En esta instancia auxiliar Oracle restaura el Tablespace undo que está siendo compartido y algunos otros Tablespaces necesarios para realizar la operación flashback y así poder llevar la “Pluggable Database” hasta el punto en el tiempo requerido. Esto por supuesto, requiere que respaldos existan y sus respectivos “Archivelogs”.
La sentencia que la documentación muestra es la siguiente y debe ser ejecutada desde RMAN:
RMAN> flashback pluggable database NuvolaPDB1 to scn 1768131 auxiliary destination '/u01/auxiliary/';
Starting flashback at 28-NOV-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=370 device type=DISK
using channel ORA_DISK_1
RMAN-05026: warning: presuming following set of tablespaces applies to specified point-in-time
List of tablespaces expected to have UNDO segments
Tablespace SYSTEM
Tablespace UNDOTBS1
Creating automatic instance, with SID='vkin'
...
...
...La necesidad de utilizar una Instancia Auxiliar desaparece si se utiliza un punto de restauración limpio. En este caso, aunque la configuración sea “Shared Undo”, la operación “Flashback Pluggable Database” no requiere instancia auxiliar.
Flashback PDB usando un punto de restauración limpio:
SQL> flashback pluggable database NuvolaPDB1 to restore point CleanPoint;
Flashback complete.
Si se utiliza un punto limpio de restauración, la “Pluggable Database” no se necesita abrir con “OPEN RESETLOGS”.
SQL> alter pluggable database NuvolaPDB1 open;
Pluggable database altered.Conclusión:
Oracle Database 12.2.0.1.0 trae definitivamente muchas mejoras en comparación con la versión predecesora 12.1.0.2, la introducción de “Flashback Pluggable Database” sin duda alguna provee aún mayor independencia a todas las “Pluggable Databases” al poder moverse en el tiempo utilizando tecnología Flashback sin impactar a ninguna de las demás “Pluggable Databases”. En este artículo se conoció los métodos para ejecutar “Flashback Pluggable Database” tanto en una configuración “Local Undo” como en una configuración “Shared Undo”, se vio que para “Shared Undo” Oracle se apoya en la creación de una instancia auxiliar, mientras que para “Local Undo” la operación flashback es exactamente igual a como se realizaba en versiones 10g y 11g. Se mostraron varios ejemplos utilizando diferentes formas de restauración, dejando así al lector una guía detallada y completa para poder utilizar y sacar provecho a estas funcionalidades.
Deiby Gómez es "Oracle ACE Director", "Oracle Certified Master 11g" y "Oracle Certified Master 12c". Ha sido conferencista en Oracle Open World en USA y en Brasil; en Collaborate, Las Vegas y OTN Tour en varios países de Latinoamérica. Ganador de "SELECT Journal Editor's Choice Award 2016". Es miembro de "Oraworld-Team", ha sido "Beta Tester" de la versión 12cR2. Deiby es el Presidente del Grupo de Usuarios Oracle de Guatemala (GOUG) y actualmente es Consultor de Bases de datos Oracle en Nuvola Consulting Group (www.nuvolacg.com). Twitter @hdeiby.
Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los productos Oracle.