Oracle Database 12.2: Shared Undo y Local Undo

Por Deiby Gómez
Publicado en Enero 2017

Introducción:

Cuando Oracle 12c fue publicada en el año 2013 fueron muchísimas nuevas características las que fueron introducidas, pero además una nueva e interesante arquitectura: La Arquitectura Multitenant.

Cuando hablamos de arquitectura Multitenant estamos hablando de Container Database (CDB), Pluggable Database (PDB) y PDB$SEED la cual es una Pluggable Database especial y que es creada de facto.

Esta arquitectura se puede describir en la siguiente imagen:

En esa imagen se puede notar muchas cosas importantes. En primer lugar se ve que la arquitectura Multitenant está conformada por la Instancia de base de datos, un Contenedor llamado “root”, una Pluggable Database llamada “Seed” y luego varias Pluggable Databases. Pero lo más importante de todo esto, son los archivos que tiene el “Root Container”. Se ve claramente que tanto el “Root Container” como todas las Pluggable Databases poseen su propio Tablespace SYSTEM y SYSAUX. Se ve también que los “Control Files” y los “Redo Logs” pertenecen al “Root Container” y que por lo tanto, estos archivos son “compartidos” (Shared, en ingles) con todas las Pluggable Databases para que puedan hacer uso de ellos. En otras palabras, todas las Pluggable Databases leen/escriben a los “Control Files” y “Redo Logs” pero estos archivos son adueñados por el “Root Container”, de tal manera que si desconectamos una Pluggable Database, esta solamente se llevará sus propios archivos como por ejemplo los “Datafiles” de los Tablespace SYSTEM y SYSAUX, y los “Datafiles” en donde se guarda los datos del negocio. Es importante notar que crear un Tablespace temporal en una Pluggable Database es opcional, si no se tiene, dicha Pluggable Database utilizará el Tablespace temporal que posee el “Root Container”. Pero lo más importante de todo esto y es el tema que trata este artículo es el Tablespace “Undo”. Tal como se ve en la imagen anterior, el Tablespace “Undo” es adueñado por el “Root Container”, pero es compartido con todas las Pluggable Databases para que pueda ser utilizado. Ninguna Pluggable Database tiene un propio Tablespace Undo.

¿Qué es el Tablespace Undo y para qué sirve?

Los Datos Undo son muy importantes dentro de una Base de Datos Oracle. Estos datos son almacenados en extensiones de Oracle dentro de Segmentos de tipo “Undo” en un Tablespace que se dedica completamente a almacenar datos “Undo”, es por eso que frecuentemente a este Tablespace se le llama “Undo Tablespace”, aunque puede tener cualquier nombre. Los datos Undo son frecuentemente utilizados para deshacer transacciones (Rollback), para recuperar una transacción que se terminó abruptamente (con Kill – 9, ALTER SYSTEM KILL IMMEDIATE, etc), para realizar una recuperación de una Instancia, para realizar recuperación hasta un punto en el tiempo, para realizar lecturas consistentes, para resolver problemas lógicos y para las operaciones “Flashback” que fueron introducidas en la versión 10g. Los datos “Undo” son igual de importantes que los datos “Redo”, ambos se complementan. Mientras Undo deshace (Undo) el otro rehace (Redo).

Un vistazo a la configuración Undo en Oracle Database 12cR1:

Tal como se ha visto hasta el momento, en la versión 12cR1, el Tablespace Undo era compartido por todas las “Pluggable Databases”. Dicho Undo Tablespace pertenecía al “CDB$ROOT”. Una de las desventajas de tener esta configuración es que no es posible realizar “Flashback Database” a nivel de “Pluggable Database”. Cuando se requería regresar en el tiempo, el “Flashback Database” era aplicado al “Container Database” en su totalidad, impactando todas las “Pluggable Databases” que existen dentro de él. Otra desventaja es que para clonar una “Pluggable Database” se tenia que poner dicha “Pluggable Database” en modo “read only” para garantizar la consistencia de la información que estaba siendo clonada. Finalmente al tener un solo “Undo Tablespace”, esto se convertía en un punto de falla. Si algo dañaba ese único “Undo Tablespace” todas las “Pluggable Databases” eran impactadas.

Oracle Database 12cR2 y su nueva característica “Local Undo”

Iniciando con Oracle Database 12.2.0.1.0 existen dos tipos de configuraciones de Undo: El “Shared Undo” y el “Local Undo”. El “Shared Undo” no es más que la misma configuración que se tenía en 12cR1 en una arquitectura Multitenant, pero “Local Undo” es una configuración nueva. Básicamente se trata de que cada una de las Pluggable Databases tenga su propio Tablespace Undo tal como se ve en la siguiente imagen:

Esto habilita las soluciones de los problemas que se tuvieron en 12cR1. Si un “Container Database” utiliza “Local Undo” entonces ya es posible realizar “Flashback Pluggable Database”, que no es más que un “Flashback Database” pero a nivel de “Pluggable Database”, de ahí su nombre. Así también clonaciones totalmente online (Hot Cloning) de las “Pluggable Databases”, aunque la “Pluggable Database” clonada esté remota, en otro “Container Database”, ya sea on-premise o en la nube pública de Oracle. La configuración “Local Undo” le da aún más independencia a cada una de las Pluggable Databases. Lo bueno de todo esto es que el tipo de configuración Undo no es una decisión de una sola vez, como la decisión de utilizar “non-CDB” o “CDB”. La configuración de Undo puede ser cambiada en cualquier momento, tanto de “Shared Undo” a “Local Undo” o viceversa. Sin embargo, hay que notar que para cambiar la configuración se necesita “Downtime” (reiniciar la base de datos). “Local Undo” es la configuración recomendada por Oracle, incluso en la nube pública de Oracle, todos los “Container Databases” son creados utilizando la configuración “Local Undo” de facto.

NOTA: Los siguientes ejemplos fueron realizados sobre una versión “Oracle Database 12.2.0.1.0 Enterprise Edition Extreme Performance 64bit”, en la nube de Oracle.

Crear una base de datos configurada con Local Undo:

Para crear un “Container Database” es necesario que el parámetro “enable_pluggable_database” tenga el valor de “true” tal como se muestra a continuación: