6.2. ARQUITECTURA C/S

UTILIZAR LA ARQUITECTURA DE SERVIDOR COMPARTIDO ORACLE.

La arquitectura estándar de Servidor Dedicado requiere que el Database Listener debe generar un proceso servidor dedicado por cada conexión concurrente en la instancia. Estos procesos de servidor persistirán hasta que se termina la sesión. Sobre plataformas tipo Unix, los procesos servidor son realmente procesos de sistema operativo, sobre Windows, son hilos dentro de un proceso ORACLE.EXE. Esta arquitectura puede causar problemas con escala en algunas plataformas. Una alternativa es la Arquitectura de Servidor compartido, conocida como el Servidor Multiproceso (o MTS) en versiones pasadas.

LIMITACIONES DE LA ARQUITECTURA SERVIDOR DEDICADO.

Mientras más usuarios inician sesión a su instancia, muchos procesos servidor son iniciados. Esto no es un problema en cuanto a Oracle se refiere. El Database Listener puede lanzar muchos procesos como sean requeridos, aunque puede haber límites a la velocidad con lo que puede lanzarlos. Si usted tiene un gran número de solicitud de conexiones concurrentes, su Listener tendrá a encolarlos. Usted puede evitar esto por medio de la ejecución de múltiples Listener en diferentes puertos, y balancear la carga entre ellos. Entonces una vez que las sesiones son establecidas, no hay límite al número que PMON puede manejar. Pero su sistema operativo puede tener límites en el número de procesos que puede soportar, límites que ver con el cambio de contexto y de memoria.

Una computadora puede solo hacer uno cosa a la vez a menos que sea una maquina SMP, en cuyo caso cada CPU puede hacer solo una cosas a la vez. El sistema operativo simula procesamiento concurrente utilizando un algoritmo para compartir ciclos de CPU atraves de todos los procesos en ejecución actualmente. El algoritmo, a menudo referido conocido como corte de tiempo o algoritmo de tiempo compartido. El switch de tomar un proceso de la CPU para poner otro proceso sobre el CPU es llamado contexto switch (cambio de contexto). El cambio de contexto es muy costoso: el sistema operativo tiene que hacer mucho trabajo para restaurar el estado de cada procesos mientras trae al CPU y luego guardar el estado cuando es cambiado del CPU. A medida que mas usuario se conectan a la Instancia, el sistema operativo tiene que cambiar de contexto entre mas y mas procesos servidor. Dependiendo de su Sistema Operativo, esto puede causar una garve degradación en el rendimiento. Un sistema operativo mainframe decente puede cambiar de contexto entre decenas de miles de procesos sin problemas. Pero sistemas operativos nuevos tales como Unix o Windows pueden no ser buenos en ejecución de miles, o incluso solo cientos, de procesos concurrentes. El rendimiento se degrada dramáticamente, porque una proporción grande de la capacidad del procesamiento se toma con el manejo de cambios de contexto, dejando una relativa pequeña cantidad de capacidad de procesamiento disponible para hacer el trabajo real.

Puede también hacer problemas de memoria que ocurre mientras más sesiones son establecidas. Los procesos servidor actual ellos mismos no son un problema, porque todos los sistemas operativos modernos utilizan memoria compartida cuando el mismo procesos se carga más de una vez. Así que el lanzar a un millar de procesos servidor no debe tomar más memoria que lanzar uno. El problema viene con la Programa  Global Area o PGA. La PGA es un Block de memoria asociada a cada proceso servidor, para mantener el estado de la sesión y como un area de trabajo para operaciones tales como ordenar filas. Es evidente, la PGA no puede ser memoria compartida, contiene los datos únicos de cada sesión. Por ello, el sistema puede comenzar a cambiar a medida que más usuarios inician sesión: cada sesión se requiere su propia PGA.

Así, el entorno de Servidor Dedicado, el rendimiento puede degradarse si su sistema operativo tiene problemas de gestiones de un gran número de procesos concurrentes. Y el problema será exacerbado si su máquina servidor tiene memoria insuficiente. Tenga en cuenta que no importa realmente si las sesiones esta actualmente haciendo alguna cosa o no. Incluso si las sesiones están en espera, el sistema operativo debe todavía llevarlos dentro y fuera del CPU, y en la página, posiblemente, el PGA apropiadas en la memoria principal de los archivos de intercambio, de acuerdo con su tiempo de corte de algoritmo. Llega un punto cuando, no importa que usted haga en la forma de actualizar su hardware. El rendimiento inicia a degradarse debido a las ineficiencias del sistema operativo en la gestión de cambio de contexto y paginación. Estos no son problemas de Oracle, pero para superarlo Oracle Ofrece la opción de la Arquitectura de Servidor Compartido.

Esto permite un gran número de procesos de usuario a ser atendido por un número pequeño de procesos servidor compartido, por lo tanto reduce dramáticamente el número de procesos que el sistema operativo tiene que gestionar. Como beneficio, el uso de memoria puede también reducir.

Recuerde siempre que la necesidad de un servidor compartido es una plataforma mucho y específicos de la instalación. Algunos sistemas operativos casi nunca la necesita. Por ejemplo, un ordenador central-tiempo se puede compartir entre varios miles de procesos sin problemas-por lo general es más sencillo sistemas operativos como Windows o Unix que son más propensos a tener problemas.

LA ARQUITECURA DE SERVIDOR COMPARTIDO.

Un punto a enfatizar inmediatamente es que Servidor Compartido es implementado puramente sobre el lado del Servidor. Los procesos usuario y las aplicaciones software no tienen manera de saber que nada ha cambiado. Los procesos usuarios emiten una cadena de conexión que debe resolver a la dirección de un Listener y el nombre de un servicio (o de una instancia). A cambio, recibirá la dirección de un proceso del lado del servidor que se cree que es un servidor dedicado. Entonces procederá a enviar declaraciones SQL y recibirá de regreso un conjunto de resultados; por lo que el proceso usuario se refiere, absolutamente nada ha cambiado. Pero el lado del servidor es muy diferente.

Servidor compartido es implementado mediante procesos adicionales que son una parte de la instancia. Son procesos Background, lanzados en el inicio de la instancia. Estos son dos nuevos tipos de procesos: dispatchers (despachadores) y Shared servers (servidores compartido). Hay también algunas estructuras de colas de memoria extra dentro de la SGA, y el Database Listener modifica su comportamiento para el Servidor Compartido. Cuando una instancia que es configurada para servidor compartido se pone en marcha, en adición a los procesos background usuales uno o más procesos despachadores también inician. Los Despachadores, como cualquier otro proceso TCP, se ejecuta en un único puerto TCP asignado por su port mapper del sistema operativo: entra en contacto con el Listener y el registro con él, utilizando el parámetro local_listener (recuerde de la sección anterior “Database Registration”) para localizar el Listener. Uno o más procesos servidor compartido también inician. Estos son conceptualmente similares a los procesos normales de servidor dedicado, pero no son atados a una sesión. Ellos recibirán declaraciones SQL, analizaran (parse), ejecutar y generar un conjunto de resultado-pero no recibirán las declaraciones SQL directamente de un proceso usuario, leerán entonces desde una cola que será llenada con declaraciones de cualquier numero de procesos usuarios. Similarmente. Los servidores compartidos no buscan conjunto de resultado de regreso directamente aun procesos usuario-en cambio, ponen los conjuntos de resultados en una cola de respuesta.

La siguiente pregunta es, como hacen la declaración generadas por los usuarios adentrarse en la cola que es leído por los procesos servidor, y como los resultado consiguen traídos a los usuarios? Esto es donde los despachadores entran. Cuando un proceso usuario contacta un Listener, en lugar de lanzar un proceso servidor y conectar este al proceso usuario, el Listener pasa de regreso la dirección de un Despachador. Si solo hay un despachador, el Listener conectara a todos los procesos usuarios. Si hay múltiples despachadores, el Listener balanceara la carga de peticiones de conexiones entrantes atraves de ellos, pero el resultado final es que muchos procesos usuarios serán conectados a cada despachador. Cada proceso usuario estará balo la impresión que está hablando a un proceso servidor dedicado, pero no lo es: es compartir un despachador con muchos otros procesos usuarios. En el nivel de red, muchos procesos usuarios tendrán conexiones multiplexadas atraves del puerto utilizado por el despachador.

EXAMEN

Una conexión de sesión a un despachador persiste para la duración de la sesión, a diferencia la conexión a un Listener, que es transitorio.

Cuando un proceso usuario emite una declaración SQL, se envía al despachador. El despachador pone todas las declaraciones recibidas en una Cola. Esta cola es llamada common Queue, porque todos los despachadores la comparten. No importa el despachado que se conecte a un proceso usuario, todas las sentencias termina en la cola común.

EXAMEN

Hay una cola de entrada común compartida por todos los Despachadores, pero cada Despachador tiene su propia cola de respuesta.

Todos los procesos de servidor compartido monitorean la cola común, cuando una declaración llega a la cola común, el primer servidor compartido disponible, lo recoge. Entonces la ejecución procede atraves del ciclo habitual análisis-ligado-ejecución, pero cuando viene a la fase de fetch (buscar), es imposible para el servidor compartido traiga el conjunto de resultados de regreso al proceso usuario: no hay conexión entre el proceso usuario y el servidor compartido. Así que en lugar, el servidor compartido pone el conjunto de resultado en una cola de respuesta que es específica al despachador que recibió el trabajo, en primer lugar. Cada despachador monitorea su propia cola de respuestas, y cada vez que cualquier resultado se pone en este, el despachador los recogerá y los traerá de nuevo al proceso usuario que originalmente emitió la declaración.

Un resultado del mecanismo de despachadores y colas es que cualquier declaración de cualquier proceso usuario puede ser ejecutada por cualquier servidor compartido disponible. Esto plantea la pregunta de cómo el estado de una sesión puede ser mantenido. Serie bastante posible para un proceso usuario emita-publique (a issue), por ejemplo, SELECT FOR UPDATE, un DELETE, y un COMMIT. En una conexión normal de servidor dedicado, esto no es un problema porque la PGA (que está atado al proceso servidor que está administrando la sesión) almacena información acerca de lo que la sesión estaba haciendo, y por lo tanto el servidor dedicado sabrá que COMMIT y que bloqueos a liberar. La PGA para una sesión de servidor dedicado almacenara los datos de la sesión la sesión, el estado del cursor, su espacio de la clase (sort) y su espacio stack (pila). Pero en el Entorno de Servidor Compartido, cada declaración podría ser recogida de la cola común por un proceso de servidor compartido diferente, cual no tendrá idea cual es el estado de la transacción. Para solucionar este problema, una sesión de servidor compartido almacena la mayor parte de los datos de la sesión en la SGA, en lugar que en una PGA. Entonces cada vez que un servidor compartido recoge un trabajo de la cola común, irá a la SGA y conectarse a los bloques de memoria apropiados para buscar el estado de la sesión. La memoria utilizada en la SGA para cada sesión de servidor compartido es conocida como la User Global Area (UGA) e incluye todo lo que tendría que ser en una PGA con la excepción del espacio de pila de la sesión. Aquí es donde el ahorro de memoria viene. Oracle puede gestionar memoria en el Shared Pool mucho más eficiente que lo que puede en muchas PGA separadas.

La parte de la SGA utilizada para almacenamiento UGAs es el Large Pool. Este puede ser configurado manualmente con el parámetro large_pool_size, o puede ser gestionado automáticamente.

EXAMEN
En el servidor compartido, que estructura de memoria PGA no va en la SGA? El Stack Space.


CONFIGURANDO EL SERVIDOR COMPARTIDO

Siendo una capacidad del lado del servidor, no hay necesidad de configuración del cliente en todo perfectamente normal más allá de cliente de Oracle Net (archivos tnsname.ora y sqlnet.ora) como se detalla previamente. Sobre el lado del servidor, servidor compartido no es nada con la Base de Datos-solo la instancia. El Listener será configurado automáticamente por el Servidor Compartido atraves del registro dinámico de instancia. Sigue que el Servidor Compartido es configurado atraves de parámetros de instancia de inicialización. Hay un número de parámetros relevantes, pero dos son todos los que usualmente son necesarios: dispatchers and shared_servers.

El primer parámetro a considerar es Shared_servers. Este controla el número de servidores compartidos que serán iniciados en el inicio de la instancia. Servidor Compartido utiliza un mecanismo de cola-espera, pero lo ideal es que no debería haber cola-espera: debe siempre haber un proceso Servidor Listo y esperando por cada trabajo que se pone en la cola común mediante los despachadores. Por lo tanto, shared_servers debe ser establecido al número máximo de solicitudes concurrentes que usted espera. Pero si hay un repentino estallido de actividad, usted no tiene que preocuparse demasiado, porque Oracle lanzará servidores compartidos adicionales, hasta el valor especificado por max_shared_servers.

Por defecto, shared_servers es uno si se establece los despachadores. Si el parámetro max_shared_servers no es establecido, entonces el valor predeterminado es una-octava parte del parámetro processses.

El parámetro dispatchers controla cuantos procesos despachadores a lanzar en el inicio de la instancia y como se comportaran. Este es el único parámetro requerido. Hay muchas opciones para estos parámetros, pero por lo general dos serán suficientes: como el número para iniciar y que protocole se debe escuchar. Entre las opciones más avanzadas son las que permiten controlar el puerto y tarjeta de red en la que el despachador va a escuchar, y la dirección del Listener con la que se registro, pero usualmente dejar a su port mapper de su sistema operativo que asigne puertos. Y utilice el parámetro local_listener para controlar Listener que van a registrar. El parámetro max_dispatchers establece un límite máximo al número de despachadores que usted puede iniciar. Pero ha diferencia con Shared Server, Oracle no iniciará Dispatchers extras bajo demanda. Usted puede, sin embargo, lanzar despachadores adicionales en cualquier momento hasta ese límite.

Por ejemplo, para habilitar la arquitectura Shared Server, ajuste los dos parámetros críticos como sigue:

SQL> alter system set dispatchers='(dispatchers=2)(protocol=tcp)';
SQL> alter system set shared_servers=20;

Ajustar el Shared Server es vital. Debe haber siempre suficientes Servidores compartidos para quitar solicitudes de la cola común mientras llegan, y suficientes despachadores que puedan atender solicitudes entrantes a medida que llegan y regresar resultados a medida que se ponen en la cola de respuestas. El uso de memoria por sesiones de servidor compartido en la SGa debe ser monitoreado. Después de la conversión de servidor dedicado a un servidor compartido, el SGA tendrá que ser sustancialmente mayor.

CUANDO UTILIZAR SERVIDOR COMPARTIDO.

Usted no encontrara una gran cantidad de consejos en la documentación de oracle sobre cuando utilizar servidor compartido, o cuantos despachadores y servidores compartidos usted necesitara. El punto principal para aferrarse es que Servidor compartido es un servicio se utiliza se utiliza, ya que se ven obligados a no, algo se utiliza de forma automática. El punto principal para colgar sobre a es aquel servidor compartido es una facilidad la que usted usa porque le obligan a, no algo que usted usa automáticamente. Esto aumenta la escalabilidad, pero quizás a costo de reducir el rendimiento. Es muy posible que cualquier declaración tomara más tiempo para ejecutar en un entorno de servidor compartido que si se ejecuta en un servidor dedicado, porque tiene que ir a través de colas. Esto también puede tomar más recursos de CPU por la actividad de poner y quitar de la cola. Pero en general, la escalabilidad de su sistema incrementara dramáticamente. Incluso si cada solicitud es marginalmente más lenta, usted será capaz para llevar acabo muchas más solicitudes por segundo atraves de la instancia.

EN EL TRABAJO

A menudo se dice que usted debe pensar acerca del uso de Servidor Compartido cuando su número se de conexiones concurrentes se encuentra en unos pocos cientos. Si usted tiene menos que un centenar de conexiones concurrentes, es casi seguro que no lo necesita. Pero si usted tiene más que un millar, probablemente. El factor crítico es si el rendimiento del sistema operativo empieza degradarse.

Considere un entorno OLTP, tales como centenares de operadores telefónicos en un call center. Cada operador puede pasar uno o dos minutos por llamada, la recogida de los detalles de llamadas e ingresar dentro el proceso usuario. Entonces cuando hace clic en botón submit, el proceso usuario construye una declaración insert y lo envía al proceso servidor. El proceso servidor podría ir atraves de todo ciclo parse/bind/execute/fetch para la declaración justamente en pocos centésimos de segundo. Claramente, no importa que tan rápido el trabajo empleado, sus procesos de servidor están inactivos 99.9 % del tiempo. Pero el sistema operativo todavía tiene que cambiar todos los procesos dentro y fuera de la CPU, de acuerdo con su algoritmo de tiempo compartido. Por el contrario, considere un entorno Data Warehouse. Aquí, los usuarios envían consultas que pueden ejecutarse por un largo tiempo. Los lotes de cargas de datos serán igual de larga ejecución. Cada vez que uno de estos trabajos se presenta, el proceso servidor para esa sesión podría estar trabajando a toda máquina durante horas en una sola declaración.

Debe ser evidente que el Servidor Compartido es ideal para manejar muchas sesiones que hacen transacciones cortas, donde la mayor parte del trabajo está en el lado del cliente de la división cliente servidor. En estas circunstancias, un servidor compartido será capaz de dar servicio a decenas de sesiones. Pero para el trabajo de procesamiento por lotes, servidor dedicas es mucho mejor. Si usted envía un trabajo por lote grande atraves de una sesión de servidor compartido, va a trabajar. Pero se unirá uno de su pequeño pool de procesos de servidor compartido para la duración del trabajo, dejando a todos sus otros usuarios para competir por el resto de servidores compartidos. La cantidad de tráfico en la red implica carga en lotes de un proceso usuarios y en la recogida de conjunto de resultados grandes de regreso a los proceso usuarios causara la contención para los despachadores.

Una segunda clase de operaciones que se realizan mejor atraves de servidor dedicado es un Trabajo de Administración de Base de Datos. Creación de índices, operaciones de mantenimiento de tablas, y trabajos de respaldos y recuperación atraves de Recovery Manager desarrollado mejor atraves de un servidor dedicado. Y es lógicamente imposible emitir comandos startup o Shutdown atraves de un servidor compartido: el Servidor Compartido son parte de la instancia y por lo tanto no están disponibles en el momento de emitir un comando startup. Así que el administrador debe tener siempre una conexión de servidor dedicado.

EJERCICIO 6-2 (OPCIONAL)
CONFIGURAR UN ENTORNO DE SERVIDOR COMPARTIDO

En este ejercicio, que continua del paso 21 del ejercicio 6-1, usted configurara el Servidor Compartido y probar que está trabajando.

1. Establecer los parámetros dispatchers y Shared_servers y registrar con el Listener como sigue:
alter system set dispatchers='(pro=tcp)(dis=2)' scope=memory;
alter system set shared_servers=4 scope=memory;
alter system register;

1. Confirme que los despachadores y servidores compartidos han iniciado por medio de la consulta a la vista v$process. Buscar procesos llamados: S000, S001, S002, S003, D000, and D001

select program from v$process order by program;

2. Desde un prompt de sistema operativo, confirme que los despachadores están registrados con el Listener:

lsnrctl services newlist

3. Conectar atraves del Listener, y confirme que la conexión es atraves del mecanismo de servidor compartido:

connect system/oracle@new;
select d.name,s.name from v$dispatcher d,v$shared_server s,
v$circuit c
where d.paddr=c.dispatcher and s.paddr=c.server;

La consulta mostrara el despachador a cual su session esta conectada, y proceso servidor compartido que está ejecutando sus consultas.

4. Ordene el entorno, regresando a la configuración original:
alter system set local_listener='' scope=memory;
alter system set service_names='' scope=memory;
alter system set dispatchers='' scope=memory;
alter system set shared_servers=0 scope=memory;
alter system register;

Detenga el Listener desde un prompt de sistema operativo con lsnrctl stop newlist.

Desactivar la variable TNS_ADMIN: sobre Linux, Export TNS_ADMIN=’’ o sobre Windows, remover la llave de registro TNS_ADMIN.

RESUMEN DE CERTIFICACION

Oracle Net es el protocolo de Red de propiedad de Oracle Corporation, en la capa de encima de protocolos del estándar industrial. Cuando se utiliza la arquitectura de Servidor Dedicado, El DataBase Listener de Oracle Net genera un proceso servidor por cada sesión; cuando se utiliza la arquitectura Servidor Compartido; muchas sesiones compartirán un conjunto de procesos de servidor, por medio de despachadores el uso de colas para pasar las solicitudes y resultado y de los servidores.

Oracle Net puede ser configurado manualmente, editando archivos de texto, o por herramientas graficas. Shared Server es implementado puramente en el lado del servidor, por medio de la configuración de parámetros de instancia.

DOS-MINUTOS

Configurar y Gestionar la Red Oracle.

- Los archivos del Lado del Servidor son los archivos Listener.ora y (opcionalmente) sqlnet.ora.

- Los archivos del lado del cliente son los archivos tnsnames.ora y sqlnet.ora.

- Los archivos Oracle Net viven en ORACLE_HOME/network/admin, o en cualquier directorio la variable TNS_ADMIN indican.

- La resolución de nombres puede ser Local (con un archivo tnsnames.ora) o central (con un directorio LDAP).

- Easy Connect no necesita ninguna resolución de nombres.

- Un Listener puede escuchar para muchas Bases de Datos.

- Muchos Listener pueden conectarse a una Base de Datos.

- El registro de instancias con Listeners puede ser estático (mediante la codificación detallada en el archivo listener.ora) o dinámica (mediante el proceso PMON actualizando el Listener).

- Cada proceso de usuario tiene una conexión persistente a su proceso servidor.

Utilizar la Arquitectura de Servidor Compartido.

- Procesos Usuarios se conectan a despachadores, estas conexiones son persistentes.

- Todos los despachadores ubican peticiones en una cola común.

- Los procesos de servidor compartido quitan solicitudes de la cola común.

- Cada despachadores tienen su propia cola de respuesta.

- Los procesos de servidor compartido ponen resultados sobre la cola de respuesta del despachador apropiado.

- Los despachadores traen resultados de nuevo al proceso usuario apropiado.

- Servidor compartido es configurado con (como un mínimo) dos parámetros de instancia:

dispatchers y Shared_servers.