blog

Las BBDD Stadard Edition (SE) nos pueden proporcionar la seguridad y robustez de una BBDD Oracle junto a un rendimiento elevado e incluso algo de alta disponibilidad, todo ello a un precio muy asequible. Pongamos por ejemplo un RAC de dos nodos, cada uno con centenares de GB de memoria y decenas de cores.

 

Aunque no todo son ventajas, ya que la SE no dispone de las funcionalidades avanzadas de la Enterprise Edition (EE) y este inconveniente, a medida que las BBDD crecen en tamaño y requerimientos, puede pasar de ser una “molestia asumible” a un “problema insalvable”. Dicho de otra manera, en ciertos entornos la SE no es una opción. Cuando hablo de funcionalidades avanzadas de EE no estoy pensando en las opciones “estrella” como son los packs de “Tuning” y “Diagnostic” sino en funcionalidades menos “glamurosas”, como el paralelismo, el “block change tracking” para backups incrementales o las reorganizaciones en caliente.

 

A esto se tiene que añadir que en las últimas versiones Oracle ha cambiado el licenciamiento de las SE, ahora llamadas Standard Edition 2 (SE2), limitándolas en funcionalidades y especialmente en rendimiento para mover a sus usuarios actuales y futuros hacia EE o la nube. Desde mi punto de vista, parte de esta “presión” no sólo consiste en las limitaciones sino también en la incertidumbre sobre el producto. Hemos visto cómo se han limitado el número de sockets, el de procesos concurrentes y eliminado la posibilidad de usar RAC. ¿Quién nos asegura que no se va a continuar por esa vía? ¿La arquitectura que hoy defines basándote en SE2 va a dejar de ser válida/soportada/legal mañana?

 

Finalmente, no podemos negar que la SE2 aporta nuevas funcionalidades en comparación con la SE, siendo la mas notable el “multitenant”, pero ¿vale la pena el cambio?

 

Para los que visto todo esto decidan seguir apostando por las versiones “Standard”, voy a intentar explicarles cómo “adaptarnos” reconvirtiendo un potente (y viejo) RAC 11gR2 SE a los nuevos tiempos. El planteamiento consistirá en partir de una instalación de BBDD RAC SE 11gR2 de dos nodos en el que se ejecutan una o varias BBDD y actualizarlo a la última versión “Long Term” la Oracle Database 19c SE2. Intentaremos mantener en parte la “alta disponibilidad” que teníamos con RAC y a ser posible ajustarnos a las licencias de que ya disponemos*.

 

• El primer paso consistirá en convertir las BBDD de RAC a mono instancia
• El segundo en actualizar el software de cluster de 11gR2 a 19c
• El tercero actualizar las BBDD a 19c y multitenant
• Y finalmente configuraremos un entorno Activo/Pasivo aprovechando el Clusterware Oracle

 

Por cierto, no está de más recordar que es necesario pasar nuestras licencias de SE a SE2 para poder usar las nuevas versiones de software.

 

*Descargo de responsabilidad:

Como siempre que se trata con tema de licenciamiento recordar que esto es solo un ejercicio didáctico y no tiene validez ni implicación legal alguna. En cualquier entorno real deberemos realizar una revisión de licenciamiento con nuestro partner Oracle de confianza y diseñar un plan de actualización ajustado a nuestras necesidades. Advertiros además que en este post “ni están todos los que son ni son todos los que están” la solución propuesta no es ni la única ni la mejor en todos los casos. Contactad con vuestro partner Oracle de confianza para realizar un plan de actualización ajustado a nuestras necesidades y entorno.

 

Convertir un RAC a monoinstancia

 

La opción de RAC se introdujo de manera gratuita y limitada para las BBDD SE en la versión 10g y desaparece en la 19c, por lo que tendremos que desmontar nuestro RAC. No hay otra opción si queremos pasar a 19c y continuar con SE2.

 

En una BBDD monoinstancia tenemos una sola instancia (conjunto de zonas de memoria y procesos ubicados en un servidor) que accede a los ficheros de datos. En una BBDD RAC podemos disponer de 1 a N instancias en diferentes servidores accediendo a los mismos ficheros y simulando ser una unidad ante los clientes que se conectan a ella.

 

La BBDD RAC necesita de una serie de parámetros y configuraciones que le permitan “organizarse” y realizar este acceso concurrente a los ficheros.

 

Para pasar de RAC a monoinstancia deberemos eliminar esos parámetros y estructuras “extra” que dejaran de ser útiles, de la misma manera tendremos que modificar la información que tiene el cluster en referencia a la BBDD para que tenga constancia de que ya solo se ejecuta en un nodo y finalmente deberemos cambiar los binarios con los que se ejecuta por unos que no disponga de la opción de RAC habilitada.

 

• Más información sobre Convertir un RAC a monoinstancia

Actualizar el clusterware a 19c

 

Para abordar este punto damos por hecho que nos encontramos en una versión de Sistema Operativo soportada por Grid Infrastructure 19c, caso contrario lo primero sería actualizar el sistema operativo (y quizás modernizar el hardware si se tercia). Supongamos tener un clusterware 11gR2 ejecutándose en dos nodos y una o varias BBDD monoinstancia 11gR2 que hace uso de este clusterware para acceder a los ficheros sobre ASM.

 

El clusterware 19c es compatible con la BBDD 11gR2 por lo que podremos seguir ejecutando las BBDD 11gR2 en él una vez actualizado. Notar que nos interesa mantener la configuración de cluster de dos nodos para poder montar con su ayuda el sistema de “Activo/Pasivo” en un paso posterior.

 

Otra opción, caso que queramos quedarnos con un solo servidor, seria desinstalar el clusterware 11gR2 (manteniendo los discos ASM de datos) y instalar un clusterware 19c de tipo “Oracle Grid Infrastructure for a Standalone Server” al que presentaríamos los discos de datos ya existentes.

 

Para realizar el upgrade, en primer lugar, deberemos verificar que la instalación de Clusterware 11gR2 y las BBDD 11gR2 disponen de todos los parches necesarios o aplicarlos caso que no sea así. Otro punto importante a revisar son los valores de “compatibilidad” tanto de las BBDD como de los diskgroups ASM. Es muy posible que tengamos que ajustarlos para permitir el upgrade a la nueva versión.

 

El clusterware 19c ya dispone de varios “Release Updates” que solucionan problemas de funcionamiento y seguridad, por lo que es muy recomendable actualizar al último disponible.  Actualmente es posible instalar la versión “base” de clusterware y el ultimo RU (e incluso parches sueltos) en un solo paso lo que nos ahorra tiempo y posibles problemas.

 

Así pues, instalaremos en un nuevo directorio los binarios de cluster 19c (junto con sus parches) y lanzaremos el script de upgrade que sustituirá los binarios del clusterware actual por los nuevos.

 

• Más información sobre Actualizar el clusterware a 19c

 

Actualizar las BBDD monoinstancia de 11gR2 a 19c

 

En este punto tenemos un clusterware 19c, parcheado con el ultimo Release Update y ejecutandose en este una o varias BBDD 11gR2. Vamos a hacer upgrade de estas BBDD a 19c, que como ya hemos comentado es la última “Long Term Support Release” disponible.

 

Recordad que cualquier actualización de una BBDD productiva se debe plantear y probar detenidamente antes de llevarse a cabo.

• ¿Las versiones de los clientes Oracle que usamos son compatibles con 19c?
• ¿Las aplicaciones están certificadas?
• ¿Se ha validado que no se producen cambios de comportamiento relevantes en las sentencias y procesos más críticos?

 

Los binarios de BBDD 19c, al igual que los de cluster 19c, disponen de varios Release Updates (RU) y deberemos usar el más reciente disponible, al igual que con el cluster es recomendable instalar la versión “base” junto con el último de esos parches en un solo paso.

Recodad que los binarios de BBDD incluyen una parte de binarios de cluster, en concreto los usados para gestionar la BBDD como un “recurso del cluster”. Si queremos tener todos los componentes de la BBDD parcheados correctamente deberemos aplicar también en el “home” de BBDD el RU aplicado anteriormente en los binarios de cluster.

 

Al realizar una instalación de una BBDD monoinstancia acabaremos con los binarios instalados y parcheados en un solo nodo, si nuestra idea es ejecutar BBDD en ambos nodos o configurar un Activo/Pasivo deberemos disponer de los binarios en ambos. A tal efecto podemos repetir toda la instalación en el segundo nodo o clonar el “home” de BBDD en la segunda máquina (lo que nos permite ahorrarnos algo de tiempo).

 

Una vez dispongamos de los binarios de BBDD deberemos “validar” que es posible hacer el upgrade. Oracle nos ofrece una herramienta llamada “Pre Upgrade Information Tool” que analiza las BBDD actuales y nos indica los pasos obligados y recomendados a realizar de manera previa y posterior al upgrade. El uso de esta herramienta es opcional, si bien altamente recomendable, para evitar posteriores problemas o un upgrade fallido.

 

Copiaremos los ficheros de init, spfile, sqlnet, password y similares que podamos tener en el “home” origen de BBDD al “home” destino y ya estaremos en condiciones de lanzar el script de upgrade, en este punto la BBDD va a dejar de estar disponible para los usuarios hasta la finalización del upgrade.

 

El script de upgrade puede llegar a tardar horas en función de la capacidad del servidor y de los componentes instalados en la BBDD. Tener las estadísticas de diccionario al día y eliminar previamente los componentes no necesarios puede ayudar a reducir el tiempo de parada.

 

Una vez realizado el upgrade de la BBDD podemos realizar algunas tareas post upgrade optativas como actualizar el timezone o pasar estadísticas y finalmente daremos por finalizado el upgrade.

 

En este punto ya tendríamos toda la plataforma en una configuración soportada, podríamos para en este punto o continuar convirtiendo nuestra BBDD monoinstancia “non-pdb” a una BBDD monoinstancia de tipo “pluggable”.

 

• Más información sobre Actualizar las BBDD monoinstancia de 11gR2 a 19c

Convertir la BBDD non-CBD a PDB

 

En el punto anterior dejamos la BBDD en un estado valido a nivel de soporte y configuración, pero sabiendo que las BBDD non-PDB (no pluggable) van a dejar de estar soportadas a partir de la versión 20c decidimos pasar nuestra BBDD a tecnología “pluggable”.

 

Con licencia Standard Edition podemos llegar a crear una BBDD contenedor y ubicar en ella hasta tres pluggable databases, el hecho de consolidar varias BBDD en una de sola nos facilita la gestión (un backup en lugar de tres, una gestión de auditoria en lugar de tres, una monitorización en lugar de tres, etc) pero en nuestro caso vamos a crear un contenedor para cada BBDD. La razón para hacer esto es tener flexibilidad al montar el Activo-Pasivo en un paso posterior.

 

En primer lugar creamos una BBDD de tipo contenedor sin PBD’s, en ella conectaremos nuestra BBDD recién migrada a 19c. Podemos usar el mismo asistente de creación de BBDD indicando que la BBDD a crear es una BBDD de tipo contenedor y que no queremos que se cree ninguna BBD plugabble durante el proceso.

 

Puntos importantes a tener en cuenta durante la creación de esta BBDD son los componentes que decidamos instalar en ella, así como el juego de caracteres. Para lo primero deberemos de instalar como mínimo todos los componentes que tengamos actualmente en la BBDD monoinstancia y para el juego de caracteres deberemos usar el mismo de la BBDD monoinstancia o el AL32UTF8 que permitiría conectar a ese contenedor una BBDD con cualquier otro tipo de juego de caracteres.

 

El siguiente paso sería generar un fichero de descripción de la BBDD monoinstnacia a conectar. Esto se realiza dejando la BBDD en modo solo lectura y usando el paquete DBMS_PDB.DESCRIBE, a partir de este punto dejaremos de dar servicio a los usuarios hasta que no finalice el proceso de conversión a PDB.

 

Con este fichero en primer lugar validaremos que es posible conectar la BBDD al contenedor y posteriormente la conectaremos. Al estar trabajando sobre los mismos discos ASM podemos optar por reutilizar los ficheros actuales de la BBDD, esto es, conectaremos al contenedor los ficheros actuales sin copiarlos ni reubicarlos.

 

La conexión es prácticamente inmediata y una vez hecha ya podremos ver, desde el contenedor, los ficheros propios y los de la BBDD conectada, pero esos ficheros siguen siendo los de una BBDD monoinstancia y deberemos convertirla a PDB.

 

Esto lo haremos ejecutando el script @$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql, este script puede tardar bastante en ejecutarse ya que va a recrear y/o recompilar todos los objetos de sistema que contiene la BBDD que acabamos de conectar.

 

Una vez finalizado ya podemos afirmar que disponemos de una BBDD pluggable que reside dentro de una BBDD contenedor y dar acceso a nuestros usuarios. Si se conectan mediante servicios no van a notar diferencia entre conectarse a la BBDD monoinstancia o a la pluggable.

 

A partir de este momento para arrancar nuestra BBDD pluggable deberemos arrancar el contenedor (o dejar el el software de cluster lo haga) y posteriormente entrar en la BBDD contedor y abrir la BBDD puggable. Esto, que puede representar un engorro, se puede solucionar “guardando el estado” de la pluggable, si guardamos su estado en modo “abierto” nos la encontraremos en ese estado cada vez que iniciemos la BBDD contenedor.

 

• Más información sobre Convertir la BBDD non-CBD a PDB 

 

Configurar “alta disponibilidad“ en nuestra BBDD SE2

 

A partir de la versión 19c RU4 es posible montar de manera “soportada” un cluster Activo/Pasivo con una BBDD SE2. Si disponemos de dos servidores (recordemos que veníamos de un RAC), podemos montar un “Activo – Pasivo” con nuestra BBDD contenedor o un “Activo – Pasivo cruzado” si disponemos de más de una BBDD.

 

Es tan simple como ajustar un par de parámetros de la BBDD y mediante un comando indicar al cluster que esta BBDD contenedor se puede ejecutar en más de un nodo.

 

Con esto ya podremos “mover” la BBDD de un nodo a otro bajo demanda o lo hará el cluster en nuestro nombre si el nodo en que se encuentra tiene problemas.

 

Si solo tenemos una BBDD o las tenemos todas ubicadas en un solo nodo es posible licenciar únicamente uno de los dos nodos del cluster (https://www.oracle.com/assets/data-recovery-licensing-070587.pdf) y usar las licencias liberadas del otro nodo para montar un entorno remoto de “Disaster Recovery” mediante la técnica de las “PDB’s refrescables”.

 

Solo añadir que el clusterware 19c tiene soporte para las BBDD 11gR2, de modo que podríamos mantener operativa alguna BBDD 11gR2 que no se puedan migrar a causa de aplicaciones “legacy”. Notar que no es recomendable, ya que estaremos en una configuración poco probada (Grid 19c+BBDD 11gR2), sin soporte en la parte de BBDD y con implicaciones a nivel de licencias por tener una 11gR2 SE en máquinas a las que aplicamos licencias SE2.

 

• Más información sobre Configurar “alta disponibilidad“ en nuestra BBDD SE2

Notas finales

 

Tener un entorno de BBDD soportado es muy importante, nos permite disponer de parches ante los nuevos problemas que se detecten, certificaciones con productos de terceros y en especial las correcciones de seguridad ante las vulnerabilidades que van apareciendo de manera continua.

 

No podemos quejarnos, la versión 11gR2 de la BBDD Oracle ha sido una de las más longevas en cuanto a soporte y remarcable por su estabilidad, la considero una de esas versiones “memorables” a la par que la 8.1.7 o la 9iR2.

 

En estos momentos ya nos encontramos fuera de soporte a no ser que hayamos contratado “Extended Support” o “Market Driven Support” y estos tampoco nos van a dar mucho margen más. La mayoría de aplicaciones que estemos ejecutando hoy en nuestras 11gR2 en sus siguientes versiones/actualizaciones posiblemente ya no la tengan como BBDD soportada. Las últimas versiones de sistemas operativos tampoco la tienen como soportada y nos encontramos desprotegidos ante las ultimas vulnerabilidades. En resumen: si no lo hemos hecho ya, ha llegado el momento de actualizar.

 

Con los pasos que os hemos descrito, u otros similares, podremos actualizar nuestros entornos a la nueva versión 19c, perdiendo por el camino el RAC y varios cores de potencia, pero ganando el uso (limitado) del  “Plan management – DBMS_SPM”, control sobre el IO de las BBDD o la posibilidad de montar una especie de “poor man standby” entre muchas otras nuevas funcionalidades.

 

Y lo que es más importante, disponiendo de nuevo de un entorno totalmente soportado durante los próximos años.