Uso de ediciones para actualizar la base de datos

Desde mi punto de vista, la funcionalidad Edition-Based Redefinition, cuya traducción directa sería "redefinición basada en ediciones", se trata de la característica más interesante de la release 2 de la base de datos Oracle 11g. En pocas palabras se trata de la posibilidad de actualizar nuestra aplicación PL/SQL sin tener que poner en modo restringido la base de datos, es decir, a partir de esta versión de la base de datos Oracle es posible realizar online la actualización de nuestra aplicación. Explicado de esta manera tan sencilla la mencionada funcionalidad suena como si se ratase de un juego de niños, pero en realidad es algo cuya verdadera dimensión resulta difícil de medir por sus enormes implicaciones.

Las versiones anteriores de la base de datos Oracle ya permitían realizar un gran número de operaciones online:

• Modificar la mayoría de los parámetros de la base de datos Oracle (sólo 90 de los 350 parámetros requieren reiniciar la base de datos).
• Aplicar patches a la base de datos utilizando Oracle Real Application Clusters.
• Reorganizar objetos de la base de datos en el espacio de almacenamiento.
• Crear índices (CREATE INDEX).
• Realizar actualizaciones de las base de datos Oracle de una release principal a otra release principal.

En conclusión, mientras la base de datos estaba online, podíamos realizar casi cualquier actualización, con excepción de operaciones del tipo recrear un procedimiento almacenado PL/SQL, cambiar un trigger PLSQL, actualizar permisos, o modificar una vista normal o una vista materializada. En pocas palabras, mientras los usuarios los estaban utilizando, no nos era posible actualizar los objetos que constituyen la base de nuestra aplicación.

Supongo que muchos DBAs habrán experimentado una enorme frustración cuando han intentado recrear un procedimiento PL/SQL para corregir algún tipo de problema, y no han podido hacerlo porque el procedimiento estaba siendo ejecutado por algún usuario del sistema. Obviamente, cuando se trata de un solo procedimiento PLSQL, el problema se solventa esperando a que el usuario lo deje de utilizar y el objeto se desbloquee, pero en la mayoría de los casos, los DBAs no tienen que reemplazar un solo procedimiento PL/SQL, sino un buen número de ellos, y muchos de estos procedimientos estarán relacionados con otros objetos de la base de datos Oracle. Por lo tanto, si un DBA debe actualizar varios procedimientos, paquetes, vistas y triggers PLSQL simultáneamente, y existen usuarios utilizando la aplicación, por un lado los usuarios bloquearan las transacciones iniciadas por el DBA y, por otro, el DBA estará bloqueando las operaciones de dichos usuarios. Esto supone que, para realizar este tipo de actualizaciones, el DBA necesitará poner en modo restringido la base de datos Oracle.

Todo esto terminó con la release 2 de la base de datos Oracle 11g y la funcionalidad Edition-Based Redefinition, que habilita a DBAs y usuarios para que accedan a distintas versiones de procedimientos, triggers, vistas, sinónimos y otros objetos de la base de datos almacenados bajo un mismo esquema, siendo ambas versiones totalmente independientes, de manera que coexisten en el sistema pero no interfieren entre ellas.

Esto es posible gracias a que la creación de objetos en la release 2 de la base de datos Oracle 11g introduce una tercera dimensión en la funcionalidad que permite resolver el nombre de los objetos, esta tercera dimensión es la edición de la base de datos que está utilizando nuestra sesión. Es decir, para referirnos a un objeto, aparte del dueño del mismo y su propio nombre, también se utiliza la edición de la sesión. Cuando un usuario crea una sesión en la release 2 de la base de datos Oracle 11g, dicha sesión tendrá asociado un atributo que identifica la edición de la sesión, edición que si no se cambia con el comando ALTER SESSION tomará el valor por defecto de la edición de la base de datos (normalmente el nombre de la edición por defecto es ora$base).

Todo esto posibilita que los DBAs puedan utilizar el comando SQL ALTER SESSION para cambiar la edición de la sesión que estén utilizando y, por ejemplo, utilizar una edición denominada "ver2", edición sobre la que podrán compilar todos los procedimientos PLSQL que quieran actualizar. Obviamente los cambios realizados sobre la edición "ver2" sólo serán visibles por las sesiones que utilicen dicha edición, y como dicha edición no es la edición por defecto, ningún usuario verá dichos cambios a menos que lo pida a través del comando ALTER SESSION.

Veamos a continuación como debería proceder un DBA para actualizar la aplicación sin afectar a los usuarios que la están utilizando.

CREATE EDITION ver2 AS CHILD OF ora$base;

ALTER SESSION SET EDITION = ver2;

Con el comando SQL CREATE EDITION hemos creado una nueva edición como hija de la edición de la base de datos por defecto. La edición ver2 es sólo una copia virtual de la base de datos, es decir, la base de datos no se copia físicamente sino que apunta a los objetos de la edición por defecto ora$base. Sólo se empezará a utilizar espacio de almacenamiento físico cuando se modifique algún objeto de la base de datos en el contexto de la edición ver2.

Con el comando SQL ALTER SESSION hemos indicado a la base de datos que los cambios que realicemos a continuación deben hacerse sobre la edición ver2. En este momento el DBA puede realizar la actualización de la aplicación modificando procedimientos, triggers, vistas, objetos, etcétera.

ALTER DATABASE DEFAULT EDITION = ver2;

Una vez completados los cambios, el DBA puede llevarlos a producción utilizando el comando SQL ALTER DATABASE, mediante el cual indicará que la versión por defecto de la base de datos es la ver2, de manera que el nuevo código se hace accesible a todos los usuarios de forma instantánea.