Oracle Processes (I) – Server Processes

Cada proceso Oracle ejecuta una tarea, para la cual ocupará un trozo de memoria interna (memoria PGA). Una instancia de Oracle tiene tres clases de procesos:

  • Server processes: estos procesos ejecutan tareas basadas en peticiones de clientes. Podemos clasificarlos en dedicated y shared servers. Estos son el tipo de procesos que veremos en esta entrada.
  • Background processes: se inician con la Base de Datos y ejecutan varias tareas de mantenimiento, como escrituras de bloques a disco, mantenimiento de online redo logs, …
  • Slave processes: similares a los background processes, ejecutan trabajo extra de cada background o server process.

Un proceso en sistemas como Windows donde Oracle se implementa con threads es equivalente a un thread. En sistemas operativos multiproceso como UNIX, el término proceso es totalmente apropiado.

Server Processes

Podemos tener las siguientes configuraciones:

  • Dedicated server: existe un proceso dedicado en el servidor para cada conexión. Hay una relación uno-a-uno entre una conexión a la base de datos y un proceso servidor o thread.
  • Shared server: Varias sesiones comparten un pool de procesos servidor. Las conexiones van a un dispatcher de la base de datos, no a un proceso de servidor dedicado creado para tú conexión.

Nota: Es importante distinguir entre una conexión y una sesión en Oracle. Una conexión es simplemente una ruta física entre un proceso cliente y una instancia de Oracle (por ejemplo conexión de red entre tú y la instancia). Una sesión es una entidad lógica en la base de datos, donde un proceso cliente puede ejecutar SQL y más. Varias sesiones independientes pueden ser asociadas con una conexión, y estas sesiones pueden existir independientemente de una conexión. Más adelante entraremos en detalle.

Dedicated Server Connections

Como comentamos anteriormente hay una relación uno-a-uno entre una conexión a la base de datos y un proceso servidor o thread. Si tienes 150 dedicated server connections en una máquina UNIX, habrá 150 procesos.

Description of Figure 4-1 follows

Shared Server Connections

En este tipo de arquitecturas la aplicación cliente conecta a el Oracle TNS listener y será redireccionado o manejado a un dispatcher, por lo cual no se puede usar shared server sin usar Oracle TNS listener. El dispatcher actúa de conductor entre la aplicación cliente y el shared server process.

Description of Figure 4-2 follows

Database Resident Connection Pooling (DRCP)

Este es un opcional y nuevo método de conectar a la base de datos y establecer una sesión (11g). Esta característica es útil en aplicaciones que no son desarrolladas como multithreaded (por ejemplo, aplicaciones PHP en un entorno de servidor Web Apache).

Para más información sobre este método de conexión se puede revisar el siguiente white paper de oracle:

http://www.oracle.com/technetwork/articles/oracledrcp11g-1-133381.pdf

Conexiones vs. Sesiones

Como comentamos anteriormente no es lo mismo una conexión que una sesión. Una conexión puede tener cero, una o más sesiones establecidas en ella. Cada sesión es separable e independiente, un commit en una sesión no afecta a otra sesión dentro de la misma conexión. Una sesión puede o no tener una conexión.

Vamos a ver un ejemplo dónde separamos conexiones y sesiones:

Como vemos en la imagen tenemos una sesión: una simple dedicated server-connection session. La columna PADDR es la dirección del proceso servidor.

Vemos que ahora tenemos dos sesiones que utilizan el mismo dedicated server process, ya que tienen el mismo PADDR. Una de las sesiones es la del AUTOTRACE, de hecho si ponemos off el AUTOTRACE veremos cómo cerrará su sesión. Por lo tanto hemos estado utilizando una conexión con dos sesiones.

Ahora vamos a ver una conexión sin ninguna sesión, para lo cual desconectamos del mismo SQL*Plus (Por lo tanto tenemos una conexión sin sesiones asociadas:)

Podemos ver que no tenemos sesiones, pero seguimos teniendo un proceso, una conexión física con el mismo PADDR:

¿Qué ocurriría si nosotros usamos shared server? Para ello debemos configurar shared server, esto lo podremos ver en otra entrada del blog, pero con shared server tanto el PADDR como el program cambiarían.

Dedicated Server vs. Shared Server vs. DRCP

Cuando usar Dedicated Server

Como vimos anteriormente es un mapeo uno-a-uno entre conexión cliente y proceso servidor. Es el único modo a considerar en entornos no-OLTP. Este modo es altamente recomendado si tienes recursos suficientes para servir el número de dedicated server processes.

Cuando usar Shared Server

Relación muchos-a-uno: muchos clientes a un shared server. En shared server se comparten recursos, con lo cual hay que tener especial cuidado de no monopolizar recursos por un largo periodo de tiempo. Los shared server son sólo apropiados para sistemas OLTP caracterizados por transacciones cortas y frecuentes.

Potenciales beneficios de shared server: reduce el número de procesos/threads del sistema operativo  reduce la memoria necesaria del sistema.

Conclusión: salvo que tu sistema esté sobrecargado o necesites utilizar shared server por alguna característica específica, la mejor opción será probablemente usar dedicated server.

Referencias: Expert Oracle Database Architecture (Thomas Kyte),Oracle® Database Administrator’s Guide 10g Release 2

3 Comments

Deja un comentario