Modificación de parámetros en una arquitectura 'Multitenant' en Oracle 12c

La arquitectura 'Multitenant', nueva en Oracle Database 12c permite crear y mantener multiples bases de datos denominadas 'PLUGGABLE' en un contenedor o 'CONTAINER'. Esta característica involucra muchas ventajas, una de las cuales es que reduce costos de administración.


Esta ventaja precisamente que motiva a explicar como funciona la modificación de parámetros de instancia en  una arquitectura de este tipo. 

Debemos considerar los siguientes puntos importantes antes de comenzar con la explicación:

  • En una arquitectura Multitenant existe una sola instancia por lo tanto existe un solo archivo de parámetros (PFILE o SPFILE).
  • Existen ciertos parámetros que pueden ser modificados a nivel de Pluggable Database, veremos cuales son mas adelante.
Para que el concepto sea entendido he trabajado con el siguiente escenario: una arquitectura Multitenant con dos bases de datos Pluggable: PDB1 y PDB2.

Parámetros modificables a nivel de PDB

Existen al rededor de 380 parámetros modificables en una base de datos Oracle 12c, para poder conocer el valor y nombre de cada uno podemos utilizar la vista V$SYSTEM_PARAMETER. Todos las columnas de esta vista pueden ser apreciadas en V$SYSTEM_PARAMETER.

Para efectos de este articulo nos vamos a enfocar en las columnas: 
  • NAME: nombre del parámetro.
  • VALUE: valor actual del parámetro.
  • ISPDB_MODIFIABLE: YES|NO indica si el parametro es modificable a nivel de pluggable database.
  • ISSYS_MODIFIABLE: YES|NO indica si el parámetros cobrara efecto solo después de reiniciar la instancia. 
  • CON_ID: Indica, para los parámetros que apliquen, para que pluggable database corresponde el cambio. Si el valor es de 0 el valor aplica para el contenedor (CDB).
Para saber, entonces, que parámetros pueden tomar efecto a nivel de pluggable database usamos la siguiente consulta:


SQL> select name,ispdb_modifiable,issys_modifiable from v$system_parameter
  2  where ispdb_modifiable='TRUE';

NAME        ISPDB_MODIFIABLE          ISSYS_MODIFIABLE
----------------------------- -------------------------- ------------------------------
sessions       TRUE     IMMEDIATE
timed_statistics      TRUE     IMMEDIATE
timed_os_statistics      TRUE     IMMEDIATE
resource_limit      TRUE     IMMEDIATE
nls_language      TRUE     FALSE
nls_territory      TRUE     FALSE
star_transformation_enabled       TRUE     IMMEDIATE
parallel_degree_policy       TRUE     IMMEDIATE
parallel_io_cap_enabled       TRUE     IMMEDIATE
optimizer_index_cost_adj       TRUE     IMMEDIATE
optimizer_index_caching       TRUE     IMMEDIATE
query_rewrite_enabled       TRUE     IMMEDIATE
query_rewrite_integrity       TRUE     IMMEDIATE
workarea_size_policy       TRUE     IMMEDIATE
optimizer_dynamic_sampling       TRUE     IMMEDIATE
statistics_level      TRUE     IMMEDIATE
cursor_bind_capture_destination               TRUE     IMMEDIATE
skip_unusable_indexes       TRUE     IMMEDIATE
optimizer_secure_view_merging               TRUE     IMMEDIATE
ddl_lock_timeout      TRUE     IMMEDIATE
deferred_segment_creation       TRUE     IMMEDIATE
optimizer_use_pending_statistics              TRUE     IMMEDIATE
...
185 rows selected.



Dependiendo del estado actual de la base de datos obtendrán un listado de los mismos o mas parámetros.

Modificando parámetros en una PDB

Para el siguiente ejemplo voy a utilizar de referencia el parámetro CURSOR_SHARING, utilizado para establecer el comportamiento del optimizador de consultas durante el parseo de sentencias SQL. Sus valores posibles son SIMILA | EXACT | FORCE. 

Valor inicial: solo existe un valor para el CDB y el mismo es heredado por todas las PDB's.

SQL> select name,value,con_id from v$system_parameter
  2  where name='cursor_sharing';

NAME       VALUE      CON_ID
------------------    ---------------------- ----------
cursor_sharing       EXACT      0

Modificando el parámetro en PDB1: 

SQL> alter session set container=pdb1;

Session altered.

SQL> alter system set cursor_sharing='FORCE' scope=memory;

System altered.

SQL> alter session set container=cdb$root;

Session altered.

Podeos ver que añade una nueva fila a la vista v$system_parameter con el valor actual e inmediato para PDB1 consecuencia de utilizar SCOPE=MEMORY.

SQL> select name,value,con_id from v$system_parameter
  2  where name='cursor_sharing';

NAME       VALUE      CON_ID
--------------------- ---------------------- ----------
cursor_sharing       EXACT      0
cursor_sharing       FORCE      3

Modificando el parámetro en PDB2:

SQL> alter session set container=pdb2;

Session altered.

SQL> alter system set cursor_sharing = 'FORCE' scope=spfile;

System altered.

SQL> alter session set container=cdb$root;

Session altered.

En este caso, el valor no se agrega a la vista debido al valor de SCOPE=SPFILE.

SQL> select name,value,con_id from v$system_parameter
  2  where name='cursor_sharing';

NAME       VALUE      CON_ID
--------------------- ---------------------- ----------
cursor_sharing       EXACT 0
cursor_sharing       FORCE 3

El valor tomara efecto hasta que se inicie nuevamente, ya sea la PDB2 o el CDB completo.

SQL> alter pluggable database pdb2 close;

Pluggable database altered.

SQL> alter pluggable database pdb2 open;

Pluggable database altered.

SQL> select name,value,con_id from v$system_parameter
  2  where name='cursor_sharing';

NAME       VALUE CON_ID
--------------------- ---------------------- ----------
cursor_sharing       EXACT 0
cursor_sharing       FORCE 3
cursor_sharing       FORCE 4 

De lo visto anteriormente podemos definir las siguientes reglas y comportamiento cuando modificamos parámetros en una base de datos pluggable:
  1. Si utilizamos SCOPE=MEMORY el cambio toma efecto inmediatamente solo para la PDB en la que estamos ubicados. El valor se pierde si:
    • Se reinicia la PDB
    • Se reinicia la CDB
    • Se establece el valor a nivel de CDB con valor de SCOPE=MEMORY o BOTH.
  2. Si utilizamos SCOPE=SPFILE el cambio toma efecto solo para la PDB y es efectivo hasta que se reinicie la PDB o se reinicie el contenedor completo.
  3. Si utilizamos SCOPE=BOTH el cambio toma efecto solo para la PDB y es inmediato ademas de prevalecer si hay un reinicio de PDB o de CDB.

Modificando parametros en una CDB


La modificación de parametros a nivel de Container ahora incluye una nueva sentencia, que permite aplicar el cambio efectuado -para los parámetros con ISPDB_MODIFIABLE=TRUE- a todas las PDB o solo al Contenedor.

La sentencia ALTER SYSTEM SET ahora agrega el parámetro CONTAINER que puede tomar valores ALL | CURRENT.

Cuando utilizamos CONTAINER=ALL, los parametros antes definidos para cada PDB son reemplazados por el valor establecido en la sentencia ALTER SYSTEM ejecutado en el CDB:

SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT

SQL> alter system set cursor_sharing='SIMILAR' container=all;

System altered.

SQL> select name,value,con_id from v$system_parameter
  2  where name='cursor_sharing';

NAME       VALUE        CON_ID
--------------------- ---------------------- ----------
cursor_sharing       SIMILAR 0

Cuando utilizamos CONTAINER = CURRENT solo el valor del CDB se modifica y los valores antes establecidos para cada PDB se conservan:

SQL> select name,value,con_id from v$system_parameter
  2  where name='cursor_sharing';

NAME       VALUE CON_ID
--------------------- ---------------------- ----------
cursor_sharing       SIMILAR 0
cursor_sharing       FORCE 3
cursor_sharing       FORCE         4

SQL> alter system set cursor_sharing='EXACT' container=current;

System altered.

SQL> select name,value,con_id from v$system_parameter
  2  where name='cursor_sharing';

NAME       VALUE CON_ID
--------------------- ---------------------- ----------
cursor_sharing       EXACT 0
cursor_sharing       FORCE 3
cursor_sharing       FORCE 4

Finalmente, para regresar los valores default de un parámetro a nivel de PDB y CDB utilizamos la misma instrucción que en versiones anteriores a 12c.

SQL> alter system reset cursor_sharing scope=spfile;

System altered.

SQL> select name,value,con_id from v$system_parameter
  2  where name='cursor_sharing';

NAME        VALUE      CON_ID
------------------    ---------------------- ----------
cursor_sharing        EXACT      0

Comments

Post a Comment

Popular posts from this blog

Cómo extraer Archive Logs desde un Backup Piece

RMAN no es de mis herramientas favoritas en Oracle, quizás porque cada vez que nos vemos las caras es porque ha ocurrido algún desastre. En esta ocasión necesitaba extraer Archive Logs para aplicarlos a una operación de RECOVER pero resulta que los archives estaban catalogados en una ubicación externa y fuera de mi alcance. Cuando al fin logre catalogar los archivos de backup que contenían los Archive Logs era necesario colocarlos en una ubicación local para poder aplicarlos. Así que veamos como extraer los archivos necesarios. Una vez catalogados los archivos de backup en nuestro repositorio de RMAN, podemos visualizar los Archives contenidos con el comando LIST BACKUP OF ARCHIVELOG ALL. RMAN> list backup of archivelog all; using target database control file instead of recovery catalog List of Backup Sets =================== BS Key  Size       Device Type Elapsed Time Completion Time ------- ---------- ...
Read more

Ejemplo práctico con SQL Tuning Advisor y SQL Access Advisor

Parte del perfil de un administrador de base de datos es el afinamiento de sentencias SQL, el afinamiento (o tuning) nos ayuda a mejorar el rendimiento de sentencias SQL dentro de nuestras bases de datos, mejorando: tiempos de respuesta de aplicaciones, tiempo de respuesta de procesos batch, consumo de recursos del sistema, escalabilidad de las aplicaciones. En Oracle, la ejecución de una sentencia SQL requiere tres fases: parseo, enlace y ejecución ( parse, bind and execute ). La parte de parseo es la que nos interesa para fines de este artículo. En esta, nuestro servidor interpreta lo que la sentencia significa y cuál es la mejor manera de ejecutarla. El parseo involucra interacción con el segmento de memoria SHARED POOL dentro de la instancia de la base de datos. Las estructuras del SHARED POOL convierten el SQL en algo ejecutable mediante un plan de ejecución. Plan de ejecución: es el resultado de la fase de parseo, indica la forma en cómo se va a acceder a los datos solici...
Read more

Tips para administración de memoria en una base de datos Oracle 11GR2

Image
Gestión de memoria en Oracle 11gR2 Constantemente recibo peticiones para establecer el tamaño ideal de memoria para una instancia de base de datos. Aunque el mejor consejo es manejar un estándar para toda las bases de datos, a veces el valor estándar no es suficiente o es demasiado, todo depende de los recursos con los que contemos y la funcionalidad que tendrá la base de datos. Aunque Oracle recomienda utilizar servidores dedicados para base de datos, en las organizaciones no siempre siguen ese consejo, esto sucede mucho en servidores de desarrollo, pruebas o QA, donde el servidor soporta: aplicación, base de datos, es repositorio de fuentes y hasta servidor ftp (he visto casos). La memoria es uno de los recursos mas valiosos de un servidor, pero, ¿por que rompernos la cabeza buscando un valor ideal para nuestros segmentos de memoria si Oracle puede hacerlo automáticamente y de forma eficiente? A continuación veremos algunos tips para administración eficiente de memoria...
Read more