Archivo de la categoría: Parametrizacion

Nuevas funcionalidades 12c: PGA_AGGREGATE_LIMIT

Posted on por
Responder

Hoy vamos a ver una entrada sencilla sobre una nueva funcionalidad de la 12c , el parámetro PGA_AGGREGATE_LIMIT

Desde la versión 9i Oracle ha apostado por la gestión automática de la memoria, uno de los problemas que generaba Al motor la gestión total de la configuración del tamaño de la PGA y SGA es que el motor podía llegar a configuraciones donde el espacio asignado a la PGA fuese muy alto, repercutiendo sobre la SGA y produciendo un exceso de paginación en la base de datos.

Como han solucionado esto ?

Sencillamente han introducido un parámetro nuevo llamado PGA_AGGREGATE_LIMIT

Este nuevo parámetro va a ser un límite del tamaño total de las PGAs de la base de datos, al contrario de lo que ocurria con PGA_AGGREGATE_TARGET que actuaba como valor de referencia , el nuevo PGA_AGGREGATE_LIMIT actúa como límite , y no solo no dejará que este valor se sobrepase, sino que eliminará sesiones que estén usando mas memoria PGA con el nuevo error ora
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

¿Cual es el patrón que usa oracle para matar las sesiones

El proceso de background CKPT comprueba cada tres segundos si la cantidad de memoria usada excede el parámetro PGA_AGGREGATE_LIMIT, si este límite es excedido Oracle hará lo sigiuiente

  • Las llamadas de las sesiones que están consumiendo mas PGA son abortadas.(untunable PGA memory)
  • Si el tamaño de la PGA sigue por encima del límite, las sessiones y los procesos que mas PGA usan son terminados (untunable PGA memory)
  • Los procesos de SYS y background no se ven afectados por estas reglas

El motor notifica al cliente el problema con un ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT

¿Como se calcula el valor ?

EL PGA_AGGREGATE_LIMIT es un valor dinámico , por lo que puede modificarse en cualquier momento , su valor es calculado de manera automática en el arranque por el motor al mayor de estos tres valores

  • 2 GB
  • 200% of PGA_AGGREGATE_TARGET
  • PROCESSES ( valor del parámetros de incializacion) * 3 MB
  • Nunca excederá al 120% de la memoria física menos el total del tamaño la SGA .

¿Como lo deshabilito?

Si fijamos en el spfile el valor de esta variable a cero, la base de datos se comportará como lo hacía en la version 11g, y no eliminará las sesiones que sobrepasen este límite.
Esto podemos hacerlo con :

alter system set pga_aggregate_limit=0 scope=both;

Mas información en

Comments in spfile

Posted on por
Responder

Hola de nuevo !!

Hoy vamos a ver una funcionalidad muy simple y sencilla pero que nos ayudará a mantener nuestro sistema documentado , la opcion comment en el spfile
Hasta el momento, cuando queríamos dejar reflejado un comentario en uno de nuestros pfile simplemente teníamos que ponerlo comentado mediante el caracter #, pero
¿como lo hacemos con el spfile?

La respuesta es increíblemente sencilla


alter system set"_b_tree_bitmap_plans"=false comment='23-11-2016 por bug 8318459' SCOPE=SPFILE;

Parametrizacion del kernel en linux: swappiness

Posted on por

Hoy vamos a ver una parámetro poco documentado de la relaccion entre Linux y Oracle.
Cuando miramos las recomendaciones de Oracle para el kernel a la hora de instalarlo en un sistema operativo Linux nos encontramos con:
Configuring Kernel Parameters and Resource Limits

fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048586

Pero no hay ni rastro de este parámetro swappiness al que hago referencia. Si miramos en la wikipedia nos indica que :

Swappiness es una propiedad del Núcleo Linux que permite establecer un balance entre el uso del Espacio de intercambio (swap en inglés, por eso el nombre de la propiedad) y la Memoria de acceso aleatorio (RAM).
El swappiness puede tomar valores desde el 0 hasta el 100. Si se establece 0 el núcleo intentará no hacer intercambio, mientras que si se establece 100 el sistema intentará mantener la Memoria de acceso aleatorio lo más libre posible haciendo intercambio.

Este valor está configurado por defecto en las distribuciones Linux a 60 ,y como os decía no encontramos apenas referencias a el en la documentación de Oracle.Pero ¿que significa este valor del swappines a 60?

Significa que, cuando lleguemos al uso de ese 60% de memoria el proceso kswapd se lanzará a hacer su trabajo, haciendo que el rendimiento de nuestra base de datos caíga en picado por el uso de recursos del sistema del proceso kswapd.

¿Que hacer si esto ocurre?

La solucion pasa por modificar este parámetro para que el kswapd no empiece hasta un 10% de memoria libre.

echo vm.swappiness=10 >> /etc/sysctl.conf
sysctl -p

Como os comentaba, esta opcion del kernel de linux está muy poco documentada por parte de Oracle, yo solamente he encontrado referencias a ella en:

Parámetro compatible en las bases de datos

Posted on por

Hoy vamos a ver uno de los parámetros mas sencillos que hay pero que puede provocarnos algún que otro quebradero de cabeza. El parámetro «compatible»

Uno de los parámetros del init.ora de nuestras bases de datos es el de la compatibilidad.
Este parámetro afecta al funcionamiento interno de la base de datos afectando no solamente al modo de trabajo del optimizador sino también pudiendo afectar a la manera en la que Oracle maneja físicamente algunas estructuras de datos.

¿Cual es la principal consecuencia de esto?
Que NO es posible la vuelta atrás.
Desde Oracle 9i , la versión de base de datos está compuesta por 5 dígitos cuyo significado es:
Opciones del número

En nuestro afán de tener la base de datos al último nivel de funcionalidad podemos tender a subir siempre el nivel de compatibilidad al máximo.
Esta costumbre no solo la desaconsejamos aquí, sino que es una de los advices que dan desde Oracle «Use only the first 3 digits for the compatible parameter unless there would be some very specific instructions to do otherwise.».

La razón es que, como comentábamos al principio, el parámetro compatible no es algo que pueda deshacerse ya que afecta a la estructura física de la base de datos con lo que, en caso de tener que hacer marcha atrás hacia una versión compatible inferior deberá de hacerse un downgrade completo de la base de datos.

Para mas información, como siempre en soporte de Oracle:

  • About Oracle Database Release Numbers
  • Note 733987.1 How To Change The COMPATIBLE Parameter And What Is The Significance? (Doc ID 733987.1)
  • Note 1563364.1 What is the Relationship between the COMPATIBLE Initialization Parameter and the Optimizer (Doc ID 1563364.1)
  • Note 1458741.1 COMPATIBLE Parameter – Explanation, Usage and Advise (Doc ID 1458741.1)