Gestión de parámetros en BBDD multitenant

A partir de la versión de BBDD 21c ya no habrá opción: la arquitectura de las BBDD deberá ser de tipo multitenant. Si bien es cierto que con la 19c podemos seguir usando la arquitectura no multitenant, lo mejor sería empezar a habituarnos a la nueva arquitectura si no lo hemos hecho aún. Al empezar a usar esta nueva arquitectura, que básicamente permite fusionar varias BBDD en una, empiezan a surgir dudas sobre su funcionamiento y una de las más comunes es la gestión de la parametrización.

 

En BBDD no multitenant los parámetros se leen de un fichero de texto llamado init<SID>.ora o de otro en formato binario llamado spfile<SID>.ora, teniendo preferencia este último en caso de disponer de ambos y no indicar específicamente cuál queremos usar al arrancar la instancia. El spfile es el recomendado y tiene la ventaja de permitir cambiar parámetros una vez arrancada la instancia para que estos persistan en siguientes reinicios. En el mundo multitenant podemos tener varias BBDD Pluggable dentro de una misma BBDD Contenedor. ¿Cómo se gestionan en este caso los parámetros? ¿Podemos tener diferentes parámetros para cada BBDD Pluggable?

 

En primer lugar hay que recordar que los parámetros de una BBDD definen su funcionamiento, permitiéndonos ajustarlo a nuestras necesidades. Podemos definir la memoria que le asignamos, el número máximo de procesos, el método para seleccionar los planes de ejecución, el formato en que nos mostrará fechas y números o activar/desactivar parches entre muchos otros. En la versión 19c tenemos más de 480 parámetros (o más de 5.400 si contamos los “ocultos”).

 

Hay parámetros que se definen al crear la BBDD y no se pueden cambiar, otros se pueden cambiar pero sólo siguiendo un procedimiento estricto y otros se pueden modificar de manera relativamente fácil cuando nos convenga. De la misma manera, hay parámetros que deben ser los mismos para toda la BBDD; otros, se pueden modificar a nivel de BBDD Pluggable o de instancia y, finalmente, hay parámetros que se pueden modificar a nivel de sesión. Algunos, para que surjan efecto, nos obligan a reiniciar la BBDD, la pluggable, la instancia o reconectar la sesión, mientras que otros tiene efecto inmediato.

 

Para la BBDD Contenedor todo es igual que para una BBDD no multitenant. Podemos tener el init<SID>.ora, el spfile<SID>.ora y los parámetros que indiquemos en ellos los va a usar durante el arranque para configurar la instancia y los heredarán por defecto las sesiones de usuario. Si usamos el fichero spfile para los parámetros, los cambios que hagamos podrán ser almacenados en él y persistirán entre reinicios de la BBDD Contenedor.

 

Hay que tener en cuenta que hay ciertos parámetros que tan solo se pueden definir a nivel de BBDD Contenedor y que las BBDD Pluggable conectadas a ella van a “heredar”, mientras que otros, en cambio, pueden ser modificados a nivel de cada una de las BBDD Pluggable que tengamos y, en consecuencia, podrán coincidir o no con los de la BBDD Contenedor.

 

Los parámetros específicos que queramos tener en las diferentes BBDD Pluggable no quedarán almacenados en ningún fichero como en el caso de la BBDD Contenedor, si no en la tabla SYS.PDB_SPFILE$ ubicada en el diccionario de la BBDD Contenedor. En esta tabla tendremos una fila por cada tripleta de “parámetro, valor del parámetro y UID de la BBDD Pluggable a que aplica” (también dispone de otros campos que indican por ejemplo si el parámetro es activo o se ha eliminado).

 

 

Las BBDD Pluggable tienen también en su parte del diccionario una tabla SYS.PDB_SPFILE$ que normalmente estará vacía. Sólo se llenará con sus parámetros específicos en el momento de hacer un “unplug” volviéndose a vaciar una vez hecho el “plug” en una nueva BBDD Contenedor. Esta tabla es tan sólo una copia de respaldo de los parámetros que se copian al fichero de “manifiesto” creado al hacer “unplug” de la BBDD Pluggable.

 

En caso que tengamos parámetros modificables por parte de una BBDD Pluggable definidos al mismo tiempo en el init<SID>.ora o el spfile<SID>.ora de la BBDD Contenedor y a nivel de BBDD Pluggable (dentro de la tabla SYS.PDB_SPFILE$), estos últimos tendrán preferencia sobre los primeros.

 

Los parámetros de BBDD e instancia se crean, modifican y resetean mediante el comando “ALTER SYSTEM”. Si lo hacemos conectados a la BBDD Contenedor los cambios sólo aplicarán a la propia BBDD Contenedor, se almacenarán/eliminarán del spfile si indicamos “scope=both” o “scope=spfile” y se heredarán por parte de las BBDD Pluggable que tenga esa BBDD Contenedor si estas no los tienen definidos específicamente.

 

Los parámetros que definamos estando conectados a una BBDD Pluggable sólo aplicarán a esa BBDD Pluggable y se almacenarán en la tabla SYS.PDB_SPFILE$ de la BBDD Contenedor. En caso de resetear algún parámetro este se marcará como eliminado en la tabla SYS.PDB_SPFILE$.

 

Para cambiar parámetros a nivel de sesión usaremos “ALTER SESSION”. En este caso no quedarán almacenados en ninguna parte y se perderán al desconectar.

 

Disponemos de algunas vistas que nos permiten revisar la parametrización de nuestras BBDD Contenedor y Pluggable:

 

La propia tabla SYS.PDB_SPFILE$, si estamos conectados a la BBDD Contenedor.

La vista dinámica V$SYSTEM_PARAMETERS, que nos muestra los parámetros activos a nivel de instancia y detalles de estos. Si estamos en la BBDD Contenedor vemos los parámetros de ella misma y de sus BBDD Pluggable.

La vista dinámica V$PARAMETER, con los parámetros activos a nivel de sesión y detalles de estos.

La visa V$SPPARAMETER, que nos muestra el contenido del spfile en la BBDD Contenedor o de los parámetros correspondientes de la tabla PDB_SPFILE$ en las BBDD Pluggable.

 

 

Pasemos a verlo con ejemplos:

 

Tenemos el parámetro optimizer_features_enable=19.1.0 definido en nuestro spfile. Este parámetro se puede modificar a nivel de BBDD Pluggable, instancia y sesión. Suponiendo que no lo hemos modificado en ningún otro sitio, este será el valor que veremos tanto a nivel de spfile, instancia y sesión en nuestra BBDD Contenedor y en sus BBDD Pluggable al arrancar.

 

Revisamos el valor dentro del spfile:

 

$ strings $ORACLE_HOME/dbs/spfileCDB2.ora  | grep optimizer_features_enable

*.optimizer_features_enable=’19.1.0′

 

Arrancamos la BBDD, nos conectamos y revisamos el valor presente en las diferentes vistas. El valor en el spfile se propaga a la instancia de la BBDD Contenedor y a la sesión a la que estamos conectados.

 

 

$ sqlplus / as sysdba

 

SQL*Plus: Release 19.0.0.0.0 – Production on Sun May 2 12:29:34 2021

Version 19.3.0.0.0

 

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

 

Connected to an idle instance.

 

SQL> startup

ORACLE instance started.

 

Total System Global Area 1577055368 bytes

Fixed Size                  9135240 bytes

Variable Size             385875968 bytes

Database Buffers         1174405120 bytes

Redo Buffers                7639040 bytes

Database mounted.

Database opened.

 

CDB$ROOT

v$spparameter: 19.1.0  Valido en: Todas

v$system_parameter: 19.1.0  Valido en: Contenedor

v$parameter: 19.1.0  Valido en: Sesion de CDB$ROOT

 

 

Saltamos a la BBDD Pluggable y vemos que no aparece el valor en la vista V$SPPARAMETER. Esto es a causa de que esa vista se basa en la PDB_SPFILE$ y actualmente en ella no tenemos ese parámetro definido. Sólo aparecería en caso que la BBDD Pluggable tuviera un valor específicamente definido para ella y actualmente no es el caso. La BBDD Pluggable “hereda” todos los valores de la Contenedor.

 

SQL> alter session set container=pdb1;

 

Session altered.

 

 

PDB1

v$spparameter:   Valido en:

v$system_parameter: 19.1.0  Valido en: Contenedor

v$parameter: 19.1.0  Valido en: Sesion de PDB1

 

 

Volvemos a la BBDD Contenedor y cambiamos el parámetro sólo a nivel de spfile, por tanto no se va a modificar ni en la instancia ni en la sesión (sólo lo haría en caso de reiniciar):

 

SQL> alter session set container=CDB$ROOT;

 

Session altered.

 

SQL> alter system set optimizer_features_enable=’18.1.0′ scope=spfile;

 

System altered.

 

 

CDB$ROOT

v$spparameter: 18.1.0  Valido en: Todas

v$system_parameter: 19.1.0  Valido en: Contenedor

v$parameter: 19.1.0  Valido en: Sesion de CDB$ROOT

 

Acto seguido lo modificamos en memoria de la instancia de la BBDD Contenedor y nos aparece también heredado en la sesión:

 

SQL> alter system set optimizer_features_enable=’18.1.0′ scope=memory;

 

System altered.

 

 

CDB$ROOT

v$spparameter: 18.1.0  Valido en: Todas

v$system_parameter: 18.1.0  Valido en: Contenedor

v$parameter: 18.1.0  Valido en: Sesion de CDB$ROOT

 

Finalmente probamos a cambiarlo a nivel de sesión:

 

SQL> alter session set optimizer_features_enable=’12.2.0.1′;

 

Session altered.

 

 

CDB$ROOT

v$spparameter: 18.1.0  Valido en: Todas

v$system_parameter: 18.1.0  Valido en: Contenedor

v$parameter: 12.2.0.1  Valido en: Sesion de CDB$ROOT

 

Y en la BBDD Pluggable, ¿Qué tenemos? A nivel de spfile nada, ya que la vista V$SPPARAMETER lee de la tabla interna PDB_SPFILE$ como ya hemos dicho. A nivel de instancia y sesión lo hereda de la BBDD Contenedor:

 

SQL> alter session set container=pdb1;

 

Session altered.

 

 

PDB1

v$spparameter:   Valido en:

v$system_parameter: 18.1.0  Valido en: Contenedor

v$parameter: 12.2.0.1  Valido en: Sesion de PDB1

 

Intentemos cambiar a nivel de instancia y sesión en la Puggable, ahora en la V$SPPARAMETER y en la instancia tenemos el valor que hemos asignado (al usar el scope=both) y en la sesión el valor específico que hemos definido a nivel de sesión:

 

SQL> alter system set optimizer_features_enable=’11.2.0.4′ scope=both;

 

System altered.

 

SQL> alter session set optimizer_features_enable=’10.2.0.5′;

 

Session altered.

 

 

PDB1

v$spparameter: 11.2.0.4  Valido en: Pluggable

v$system_parameter: 11.2.0.4  Valido en: pluggable

v$parameter: 10.2.0.5  Valido en: Sesion de PDB1

 

En caso de tener dos parámetros al mismo nivel el de la BBDD Pluggable sobrescribe el de la BBDD Contenedor. En este punto podemos ver que ha aparecido la fila en la tabla SYS.PDBSPFILE$:

 

 

Si volvemos a la BBDD Contenedor podemos ver que en el fichero spfile continuamos con el valor que hemos asignado al inicio de la prueba, que tenemos dos valores para la instancia (uno para la BBDD Contenedor y otro para la BBDD Pluggable) y que en el valor de la sesión se mantiene al que cambiamos dentro de la PDB (de hecho es lógico, hemos cambiado de contenedor pero no de sesión):

 

SQL> alter session set container=CDB$ROOT;

 

Session altered.

 

 

CDB$ROOT

v$spparameter: 18.1.0  Valido en: Todas

v$system_parameter: 18.1.0  Valido en: Contenedor

v$system_parameter: 11.2.0.4  Valido en: Pluggable

v$parameter: 10.2.0.5  Valido en: Sesion de CDB$ROOT

pdb_spfil$: ‘11.2.0.4’  Valido en: pdb1

 

Finalmente, si reconectamos la sesión, ¿Qué tendremos en la BBDD Contenedor y en la BBDD Pluggable?

En la BBDD Contenedor, como en la BBDD Pluggable, perdemos los cambios a nivel de sesión y los heredan de la instancia correspondiente:

 

SQL> connect / as sysdba

Connected.

 

CDB$ROOT

v$spparameter: 18.1.0  Valido en: Todas

v$system_parameter: 18.1.0  Valido en: Contenedor

v$system_parameter: 11.2.0.4  Valido en: Pluggable

v$parameter: 18.1.0  Valido en: Sesion de CDB$ROOT

pdb_spfil$: ‘11.2.0.4’  Valido en: pdb1

 

SQL> alter session set container=pdb1;

 

Session altered.

 

 

PDB1

v$spparameter: 11.2.0.4  Valido en: Pluggable

v$system_parameter: 11.2.0.4  Valido en: Pluggable

v$parameter: 11.2.0.4  Valido en: Sesion de PDB1

 

 

Ya para acabar, indicaros que la siguiente nota de Oracle support  explica los detalles de cómo funcionan los parámetros al trabajar en multitenant:

Initialization parameters in a Multitenant database – Facts and additional information (Doc ID 2101596.1).

Twitter
LinkedIn
Evolución, innovación y transformación
32 Service Expertise avalados por Oracle 
Nuestra propuesta de valor
Posts 100% Oracle
Sigue nuestro día a día