6.27. CONFIGURANDO SERVIDORES COMPARTIDOS 1

Ya sabemos que si la máquina donde tenemos la base de datos funciona bien, no tiene problemas de rendimiento, etc., bastaría con usar servidores dedicados. En cambio, si por las necesidades y las características de nuestra base de datos, de pronto la máquina va mal, o son insuficientes los recursos de CPU, memoria, etc., entonces sí que es muy recomendable usar servidores compartidos.

Los servidores compartidos o SHARED SERVERS, tienen un mejor rendimiento porque permiten tener conectados a más usuarios con los mismos recursos de CPU, memoria, etc. Pero a su vez, el administrador de la base de datos, debe encargarse de configurarlos. No es que sea algo muy complicado, pero sí es una tarea más de la que debe encargarse el dba.

Primero vamos a ver una serie de parámetros con los que vamos a trabajar en la configuración de este tipo de servidores.

• SHARED_SERVERS: Esto sería el número de servidores compartidos que serán lanzados en cuanto se arranca el sistema. Por ejemplo, si le damos valor CINCO, entonces vamos a tener siempre, desde que arranca la base de datos, al menos CINCO servidores compartidos.

• MAX_SHARED_SERVERS: define el define el número máximo de servidores compartidos que vamos a tener. Por ejemplo, si tenemos como mínimo CINCO, y aquí ponemos que vamos a tener DIEZ como máximo, lo que sucede es que, Oracle cuando arranca comienza con CINCO servidores, y si el sistema lo necesita va a ir creando hasta un máximo de DIEZ servidores; y también, cuando ya no los necesite los va a ir liberando, pero manteniendo un mínimo de CINCO servidores, que es el número del parámetro SHARED_SERVERS.

• SHARED_SERVERS_SESSIONS: es el total de shared servers user sessions que se pueden ejecutar de forma simultánea. O sea, la cantidad de sesiones compartidas que podemos tener ejecutándose de forma simultánea.

• DISPATCHERS: Que no es más que cómo vamos a configurar los procesos de DISPATCHERS que atienden peticiones del cliente, las envían a la cola de peticiones y luego la recuperan de la cola de respuestas.

• MAX_DISPATCHERS: Que es el número máximo de procesos de dispatchers que vamos a tener.

Para visualizar estos parámetros, debemos escribir la consulta:

• SHOW PARAMETER SHARED

Se nos muestran unos parámetros, y aquí tenemos SHARED SERVERS que tiene valor UNO, y MAX SHARED SERVERS que no tiene ningún valor definido. 

Pudiera crear alguna duda el hecho de que tengamos un servidor compartido en este punto, cuando aún no hemos configurado ninguno. Lo que pasa es que cuando instalamos el sqlplus, se crea automáticamente un servidor compartido que estará atendiendo las peticiones de esta aplicación cliente. Lo mismo sucedería si instaláramos el Enterprise Mannager. En fin, este servidor compartido, Oracle lo está utilizando exclusivamente para la conexión del sqlplus, esta conexión se denomina orclXDB, como vamos a ver en unos instantes.

Veamos ahora el status del listener que tenemos configurado en la base de datos, esto debemos hacerlo desde una terminal del Linux a la cual ya le hayamos indicado el entorno.

• lsnrctl status

Y podemos observar la configuración del Listener. Protocolo TCP, de tipo local, y estará escuchando por el puerto 1521. Y vemos además, que se ha creado un servicio, el orclXDB, que es precisamente el servicio que está utilizando ese SHARED SERVER. Hasta ahora no nos enterábamos de esto, porque lo ha hecho todo de forma automática, o sea, lo configura internamente Oracle, una vez que le dimos de alta al sqlplus. Esta es la razón por la cual, tenemos un SHARED SERVER.

En caso de no tener alguno de estos recursos clientes, como sqlplus o el Enterprise Mannager, no tendríamos SHARED SERVER alguno.

Otro de los parámetros que necesitamos son los dispatchers. Para visualizarnos, lo hacemos desde el sqlplus:

• SHOW PARAMETER DISPATCHERS

Y aquí tenemos la definición del protocolo que usa la conexión a los dispatchers y a través de qué servicio se conecta. Observemos que en servicio tenemos a orclXDB. Esto quiere decir, que cuando se hace una petición a desde una aplicación cliente, se conecta a este dispatcher usando el servicio orclXDB y a mediante el protocolo TCP. Entonces el dispatcher deja las peticiones en la cola de peticiones de la SGA y el SHARED SERVER, se encargará de gestionar esas peticiones y depositar la respuesta en la cola de respuestas. Por último, el dispatcher toma el resultado de esa petición de la cola de respuesta y la devuelve al cliente.

Es decir, que ya teníamos un SHARED SERVER configurado de forma automática, que se encarga de las peticiones hechas por la aplicación cliente a través de este dispatcher de aquí.

Si volvemos a donde mostramos el estado del listener, vemos que tenemos el servicio orclXDB. Entonces, todas las conexiones a través de este servicio se van a enrutar a este dispatcher que a la vez estará asociado al SHARED SERVER que vimos con anterioridad.