2. Configurando Oracle Net Las redes informáticas evolucionaron desde terminales simples, pasando por arquitecturas cliente servidor y sistemas complejos. Las redes modernas se componen de muchas computadoras basadas en varios sistemas operativos utilizando una serie de protocolos de comunicación extendidos en un área geográfica diversa. A medida que la complejidad de las redes fue creciendo, las soluciones de aplicación lo hicieron de la misma manera. Las destrezas de un DBA para mantener las funcionalidades de una base de datos Oracle para brindar soporte tanto a redes simples como complejas es un requisito que cada vez se solicita con mayor necesidad. En este capítulo veremos las posibilidades con las que cuenta un administrador para las distintas posibilidades que ofrece Oracle Server.
2.1 Configuración Básica de Oracle Net del Lado del Servidor En la figura se presenta una clasificación de los contenidos tratados en esta subunidad, teniendo en cuenta, la relación de los mismos con el Material del Estudiante (kit). Esta clasificación sugiere diferentes momentos de lectura, estudio y revisión, entre los contenidos de este currículo y el Material del Estudiante (Kit). Según esta clasificación los contenidos pueden ser de: Lectura Previa: Se sugiere la lectura de estos contenidos antes de abordar los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Complementaria: Se sugiere la lectura de estos contenidos como complemento a los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Adicional: Se sugiere la lectura posterior de estos contenidos, como material adicional a los tratados en el Material del Estudiante (Kit). Prácticas : Actividades de laboratorios e interactivas incluidas como práctica adicional al Material del Estudiante (Kit).
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.1 Objetivos En este capítulo nos proponemos que conozacas la importancia de utilizar el servicio Listener al establecer una conexión del lado del servidor; y que sepas que, por lo tanto, una de las tareas de un DBA es la de configurar este servicio, como así también los componentes básicos que lo complementan. También esperamos que descubras de qué manera administrar los componentes de red de Oracle Server. Y por último, nos proponemos que logres descubrir cómo funciona la conectividad en un ambiente web, los posibles problemas que suelen ocurrir; y saber cómo solucionarlos.
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.2 Cuestionario de Iniciación Coloque el cursor sobre los botones numerados que aparecen a la izquierda para visualizar las preguntas de iniciación. Si desea, puede desplegar su respuesta.
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.3 El Listener El Listener de Oracle es el componente de red principal del lado del servidor. Éste nos habilita a establecer conexiones proveniente de los clientes. Podríamos pensar en el listener como una gran oreja que permanentemente está escuchando por conexiones entrantes, tal como se ve en la Figura. Una vez recibida una solicitud de conexión de un cliente, el listener tiene varias formas de responder a esto y va a depender por un lado de la forma en que el Listener esté configurado y de qué forma se está solicitando la conexión. Las maneras de procesar las conexiones entrantes son: Transferencia de la conexión Conexión Directa Conexión Redirigida En cuanto a la transferencia de conexión cabe aclarar que esta forma de conexión sólo es posible en un ambiente dedicado, ya que necesita de un proceso por cada conexión. Ésta se produce cuando el Listener recibe la conexión, entonces crea y hace la conexión con un proceso del servidor. De aquí en más la conexión queda establecida y el proceso del cliente se comunica directamente con el proceso del servidor. Gráficamente queda demostrado en la Figura.
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.4 Sesión Directa Continuando con los métodos de conexión de un cliente, nos encontramos con el método de Conexión Directa. En este caso, en vez de utilizar un proceso de servidor dedicado como en el método de la transferencia, utiliza un proceso intermedio, llamado distribuidor ó Dispatcher para recibir las conexiones entrantes. Entonces, en este modo, cuando el Listener recibe una conexión entrante, la transfiere al dispatcher y es éste quien se conecta con el proceso del servidor. La figura 1 demuestra este proceso de conexión.
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.5 Sesión Redirigida Cuando no se puede transferir la conexión al proceso de servidor ni a un distribuidor (dispatcher), ya sea porque el sistema operativo no lo soporta ó porque el Listener no se encuentra en el mismo equipo que el servidor, el Listener tiene la alternativa de utilizar el modo de redirección de la conexión, la cual se procesa de la siguiente manera: 1. El cliente conecta al Oracle Server luego de resolver su nombre de servicio (Service Name). 2. El Listener verifica los datos de conexión y si son correctos, crea un proceso dedicado para la comunicación, ó un proceso distribuidor (dispatcher). 3. Éste nuevo proceso selecciona un puerto disponible TCP/IP y se lo pasa al Listener. 4. El Listener le envía el puerto de conexión al clienteel cliente utiliza esta información para conectarse con el proceso creado por el Listener. 5. El proceso dedicado creado por el Listener recibe la solicitud de conexión del cliente y la acepta. Nota: Si tuviéramos un escenario distribuido, en el paso 2 no se crearía ningún proceso, ya que reutilizaría uno disponible. Adicionalmente, el proceso PMON le envía al Listener información sobre las conexiones actualmente establecidas
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.6 Registración de Servicios Estáticos (listener.ora) Teniendo en cuenta los diversos métodos de conexión, el DBA puede realizar la configuración que requiera, a través de una parametrización que puede definirse en el momento de la instalación, cuando se le pregunta si desea crear un Listener por defecto. Otra posibilidad de configuración es a través del utilitario Oracle Net Configuration Assistant. Utilizando cualquiera de los dos métodos mencionados para configurar el Listener, se crea un archivo con la parametrización definida llamado listener.ora. Este método de configuración es conocido como Registración del Servicio Estática. Este tipo de configuración es necesaria si desea conectar versiones de Oracle previas a Oracle 8i, utilizando Oracle Entreprise Manager. En la Figura podemos ver un ejemplo del archivo de configuración listener.ora.
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.7 Registración de Servicios Dinámicos (PMON) A demás de la registración del servicio estático, existe otro método de registración, llamado Registración del Servicio Dinámico, en donde no se requiere la utilización del archivo listener.ora. Ésta es una característica que le permite a una instancia Oracle 8i ó 9i poder registrarse a sí misma a un Listener de Oracle. En este caso, el encargado de registrar el servicio, es el Process Monitor (PMON). Este método se configura en el archivo de parámetros iniciales al momento de iniciar la instancia. Para poder utilizar este tipo de registración, hay que configurar los siguientes parámetros: SERVICE_NAMES: Especifica el ó los nombres de la base que se desea registrar INSTANCE_NAME: Especifica el nombre de la instancia. Por defecto, el proceso PMON se registra con su listener local, utilizando el puerto por defecto, que es el 1521. Se puede forzar al proceso PMON para que utilice otro tipo de conexión si se especifica el parámetro de inicialización LOCAL_LISTENER = alias; donde alias es un nombre que tiene que resolver, por algún método de nomenclatura, cómo ser tnsnames.ora.
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.8 Oracle 9i JVM Los servicios de Oracle Net se pueden configurar para responder a peticiones de la máquina virtual de java (Java Virtual Machine - JVM) sobre el protocolo TCP/IP. JVM corre sobre el Oracle Server, con lo que el proceso del usuario puede interactuar con la máquina java del servidor a través de http, ó del protocolo de Internet Inter-ORB Protocol (IIOP). La Figura 1 muestra los pasos para configurar éste tipo de Listener.
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.9 Utilidad LSNRCTL Una vez que tenemos creadas y configuradas las definiciones del Listener, como DBA, necesitamos iniciar el proceso del Listener para que los clientes puedan comenzar a conectarse a la base de datos. Para esto, existe una utilidad para la línea de comandos llamada lsnrctl. Cabe destacar que en instalaciones sobre Windows NT/2000, el proceso lsnrctl se ejecuta como un servicio, con lo cual facilita la administración del mismo. Existen varios comandos para trabajar con esta utilidad. Una vez ingresada a la utilidad, nos aparece un prompt (LSNRCTL>) para trabajar con las funciones que trae. En la Figura 1 se puede ver la forma de iniciar / detener este servicio. Adicionalmente podemos ver en la Figura 2 una serie de comandos adicionales que se pueden utilizar con esta utilidad.
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.10 Lectura Adicional: Posibles problemas de red En este apartado vamos a tratar los posibles problemas en la configuración de red del lado del servidor. A pesar de haber configurado correctamente el Listener, podríamos continuar con problemas de conexión, debido a los siguientes factores: El cliente, capa del medio ú Oracle Server no están configurados correctamente. El cliente no puede resolver el nombre del servidor Hay problemas con el protocolo de red o no está activo. Este tipo de errores puede diagnosticarse y corregirse rápidamente. Muchos de estos temas los vamos a tratar en el siguiente capítulo, donde veremos la configuración de Oracle Net del lado del cliente. Cuando estamos ante un error de conexión de un cliente, y es nuestra responsabilidad solucionar el problema, es necesario recaudar cierta información del problema para comenzar con el diagnóstico. La Figura demuestra qué datos son necesarios. Existe una utilidad que se utiliza como parte del diagnóstico de red del lado del cliente que se llama TNSPING, que tiene un funcionamiento similar a la utilidad PING del sistema operativo. Lo que hace es enviar una solicitud al Listener y chequear si responde con lo que se puede visualizar del estado y su disponibilidad. La Figura demuestra la utilización de este comando. Cabe destacar que para contar con esta utilidad, el cliente de Oracle es necesario que esté instalado en el cliente.
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.12 EI: Comandos LSNRCTL Identificar los comandos de la utilidad LSNRCTL según la descripción dada.
2.1 Configuración Básica de Oracle Net del Lado del Servidor 2.1.13 Síntesis En este capítulo tratamos los aspectos relevantes a la configuración del Listener, es decir, del servicio que nos provee Oracle para establecer conexiones desde los clientes. Para ello comentamos cómo trabaja el Listener, ya sea en forma directa ó redirigida. También vimos de que hay dos maneras de registrar el servicio de la base de datos en el Listener, utilizando una configuración estática ó dinámica. Esto va a depender de las necesidades y de la arquitectura en donde estemos trabajando. Finalmente tratamos la administración del servicio a través de la utilidad lsnrctl y vimos cómo iniciar y detener el Listener por defecto. Con respecto a las comunicaciones vía web, vimos de qué forma utilizar el Listener para este escenario. Adicionalmente hablamos de los posibles problemas a los que nos podemos enfrentar en la administración de las comunicaciones y de qué manera encararlas. Para ello se propuso un check list con posibles verificaciones y se comentó la utilidad TNSPING para la verificación del servicio de la base de datos.
2.2 Configuración Básica de Oracle Net del Lado del Cliente En la figura se presenta una clasificación de los contenidos tratados en esta subunidad, teniendo en cuenta, la relación de los mismos con el Material del Estudiante (kit). Esta clasificación sugiere diferentes momentos de lectura, estudio y revisión, entre los contenidos de este currículo y el Material del Estudiante (Kit). Según esta clasificación los contenidos pueden ser de: Lectura Previa: Se sugiere la lectura de estos contenidos antes de abordar los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Complementaria: Se sugiere la lectura de estos contenidos como complemento a los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Adicional: Se sugiere la lectura posterior de estos contenidos, como material adicional a los tratados en el Material del Estudiante (Kit). Prácticas : Actividades de laboratorios e interactivas incluidas como práctica adicional al Material del Estudiante (Kit).
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.1 Objetivos Una vez que la configuración de red del servidor está correctamente realizada, nos podremos focalizar en los clientes que utilizarán los servicios de base de datos de Oracle Server. En este capítulo analizaremos los elementos de configuración de red del cliente Oracle. Vamos a discutir los diferentes modelos de nomenclatura, particularmente los métodos Host y Local Naming utilizando Oracle Net. Finalmente vamos a ver posibles errores en la utilización de estos recursos y su solución. Cabe destacar que es importante conocer este lado de la arquitectura de red ya que la falta de esto nos limitaría en las variadas opciones de conexión al servidor. El DBA debe entender las necesidades del negocio asociadas a la conectividad y cómo responder ante ellas, ya sea para decidir la conectividad de los clientes, como la utilización de los recursos de red del lado del servidor (modo dedicado ó compartido).
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.2 Cuestionario de Iniciación Coloque el cursor sobre los botones numerados que aparecen a la izquierda para visualizar las preguntas de iniciación. Si desea, puede desplegar su respuesta.
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.3 Métodos de Nomenclatura En capítulos anteriores vimos las distintas opciones que tiene un cliente al momento de identificar un servidor para establecer una conexión. Estos métodos los podemos enumerar de la siguiente manera: Nomenclatura de Host Nomenclatura Local Nomenclatura de Directorio Oracle Names Nomenclatura Externa La utilización de alguno de estos métodos va a depender de la arquitectura de red en la que necesitemos trabajar, por ejemplo, trabajar con Nomenclatura de Host es ventajoso en ambientes de redes pequeñas con pocos servidores Oracle operando, ya que reduce el trabajo de configuración, teniendo en cuenta que hay que cumplir una serie de requisitos mínimos para poder utilizar esta configuración. Por otro lado tenemos el método de Nomenclatura Local, que es el más popular y utilizado. Este método requiere de un archivo de configuración local llamado tnsnames.ora y suele ser utilizado en corporaciones más grandes y en redes que suelen ser heterogéneas. En este capítulo vamos a tratar estos dos métodos de nomenclatura, desde su configuración hasta la solución de problemas (troubleshooting).
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.4 Nomenclatura de Host Focalizándonos en la Nomenclatura de Host, vimos que es útil en ambientes pequeños y de bajos recursos ligados a la parametrización. Pero también tenemos que tener en cuenta una serie de características mínimas para poder utilizar este método de nomenclatura: Tener instalado el cliente Oracle Net El protocolo de red debe ser TCP/IP No es posible utilizar algunas características avanzadas de Oracle, como ser el Oracle Connection Manager El cliente debe contar con un servidor de resolución de nombres (DNS) ó utilizar un archivo de HOSTS en forma local. El parámetro GLOBAL_DBNAME debe ser el mismo que el nombre del equipo servidor. Salvando los requisitos anteriores, procederemos con la configuración del lado del cliente, como se ve en la Figura, el mismo está basado en un archivo de parámetros llamado sqlnet.ora con el parámetro names.directory_path = (HOSTNAME) De esta manera se puede comprobar la fácil configuración de este método en el cliente. Del lado del servidor la configuración no es mucho más compleja, simplemente nos tenemos que asegurar que el Listener que se esté utilizando cumpla con las siguientes condiciones: El nombre del proceso Listener se debe llamar LISTENER El puerto debe estar configurado en su default (1521) Se debe especificar el parámetro GLOBAL_DBNAME en la parametrización inicial, para registrar el servicio automáticamente al arranque.
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.5 Nomenclatura Local El método de Nomenclatura Local ó comúnmente llamado método tns es el más utilizado y conocido de los métodos de nomenclatura. Recordemos también, que nos brinda una flexibilidad adicional con respecto al método de Host en cuanto a la resolución de nombres, como ser en una red multiprotocolo, por ejemplo. Este método utiliza un archivo adicional al sqlnet.ora que es el tnsnames.ora. La ubicación por defecto de estos archivos es %ORACLE_HOME%\network\admin.
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.6 TnsNames.ORA Enfocándonos en el archivo de parámetros tnsnames.ora, podemos establecer su configuración a través del Oracle Net Manager, en donde podemos ver la secuencia de creación de la Figura 1a la Figura 5. En la Figura 6 podremos observar el resultado del archivo de configuración, con lo que se puede contar con la alternativa de administrar su configuración con cualquier editor de texto del sistema operativo.
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.7 SqlNet.ORA Finalmente, para que el cliente utilice el método de nomenclatura local, necesita una configuración adicional en el archivo de parámetros sqlnet.ora, para definir si se desea utilizar este método de nomenclatura ó el método Host. Opcionalmente se puede llegar a definir un híbrido utilizando ambos métodos. En este caso, debemos configurar el parámetro names.directory_path = (TNSNAMES) Si deseamos utilizar ambos métodos, tendríamos que configurar: Names.directory_path = (HOSTNAME, TNSNAMES) En el ejemplo anterior, el orden de utilización es de izquierda a derecha, es decir, primero el cliente tratará de resolver por el método de Host, si no tiene éxito, tratará de resolver por el método local y si sigue sin tener éxito en la conexión, devolverá un error de conexión. En el tema siguiente veremos los errores comunes asociados a las comunicaciones en Oracle.
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.8 Errores Comunes de Conexión Al momento de establecer una conexión con un Oracle Server, nos podemos encontrar con una serie de problemas, que son identificados con un código de error devuelto por pantalla. Cuando nos enfrentamos a un problema de este tipo, necesitamos hacer una serie de chequeos para identificar el error: Puede el cliente contactar al servidor? Puede el cliente ver el proceso Listener? Verificar los archivos de configuración local sqlnet.ora Verificar los protocolos de comunicación instalados Hay un código de error identificado? Algunas posibles soluciones son: Verificar si se puede ver el proceso Listener utilizando la utilidad tnsping, como muestra la Figura 1. Controlar los parámetros names.directory_path, si está en HOSTNAME ó TNSNAMES ó ambos, para saber si se debe controlar la configuración del archivo tnsnames.ora La tabla de la Figura 2 muestra una verificación en función del código de error devuelto por Oracle.
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.9 Lectura Adicional: SQLNet.ora En los temas anteriores, vimos que para utilizar un método de resolución necesitamos una parametrización de la variable names.directory_path en el archivo sqlnet.ora. En este apartado vamos a ver qué otras opciones podemos configurar en este archivo. Uno de los parámetros que podemos usar es el names.default_domain, que especifica el dominio en donde el cliente usualmente resuelve los nombres de red. Cuando este parámetro se setea, el nombre de dominio es adjuntado automáticamente al nombre de servicio en una cadena de conexión. En la Figura 1 podemos ver como se define este parámetro.
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.11 EI: Comparación de la Nomenclatura Host y Local Definir los requerimientos necesarios para la utilización de la nomenclatura Local y Host.
2.2 Configuración Básica de Oracle Net del Lado del Cliente 2.2.12 Síntesis Los métodos de resolución de nombres disponibles para los clientes incluyen la resolución Host, Local, Oracle Names y Oracle Internet Directory. La resolución por Nombre de Host, que sólo puede ser utilizada sobre TCP/IP, es una configuración muy simple para la red Oracle. La nomenclatura Local es más popular y utiliza un archivo adicional de parametrización local llamado tnsnames.ora. Tanto el método de nomenclatura de Host y Local son configurados con la utilidad Oracle Net Manager. Es importante conocer los posibles errores y sus soluciones en torno a las conexiones de un cliente, como así también conocer la estructura que puede tener un archivo tnsnames.ora ó sqlnet.ora para llegar a identificar errores de sintaxis. En la Figura 2 podemos encontrar una serie de términos que nos tienen que ser familiares al término de este capítulo.
2.3 Configuración y Uso de Oracle en modo Compartido En la figura se presenta una clasificación de los contenidos tratados en esta subunidad, teniendo en cuenta, la relación de los mismos con el Material del Estudiante (kit). Esta clasificación sugiere diferentes momentos de lectura, estudio y revisión, entre los contenidos de este currículo y el Material del Estudiante (Kit). Según esta clasificación los contenidos pueden ser de: Lectura Previa: Se sugiere la lectura de estos contenidos antes de abordar los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Complementaria: Se sugiere la lectura de estos contenidos como complemento a los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Adicional: Se sugiere la lectura posterior de estos contenidos, como material adicional a los tratados en el Material del Estudiante (Kit). Prácticas : Actividades de laboratorios e interactivas incluidas como práctica adicional al Material del Estudiante (Kit).
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.1 Objetivos En este capítulo nos proponemos que llegue a identificar a los componentes de Oracle Server en modo compartido. También nos importa que sea capaz de describir la arquitectura y conozca la configuración, de Oracle Server en modo compartido. Y por último pretendemos que logre comprender la utilización de las vistas del diccionario de datos relacionados con Oracle Server en modo compartido.
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.2 Cuestionario de Iniciación Coloque el cursor sobre los botones numerados que aparecen a la izquierda para visualizar las preguntas de iniciación. Si desea, puede desplegar su respuesta
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.3 Oracle Server en Modo Dedicado A medida que una empresa crece, es visible que la tecnología que la acompaña también lo hace en función de las necesidades que se planteen. Esto se ve reflejado, desde el punto de vista de Oracle Server, en un crecimiento de sus recursos para abastecer a los servicios que brinda. Siguiendo con el paralelismo, podemos contar inicialmente con una configuración de Oracle orientada a negocios pequeños ó medianos, comúnmente llamada Servidor de Oracle Dedicado. Esta configuración lo que nos permite es una utilización de recursos dedicada a cada cliente que se conecte. Haciendo un poco de repaso, en el establecimiento de una conexión de un cliente que usa un proceso de usuario, el Listener crea un proceso de servidor para atender esa llamada, la cual va a durar lo que dure esa sesión. Una vez terminada se cierra tanto el proceso de usuario como su proceso servidor liberando los recursos en ambos lados. Esta tarea es realizada para cada nueva conexión atendida por el servicio de Listener. La Figura muestra este proceso, en una arquitectura dedicada, en donde se observa a cada proceso de usuario interactuar con un proceso de servidor. Cabe destacar que los procesos de servidor permanecen siempre activos mientras dure el proceso de usuario, o sea que si el cliente no efectúa ninguna operación por un largo tiempo, el proceso servidor tendrá los recursos reservados de todas maneras por más que no los use.
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.4 Oracle Server en Modo Compartido Como conclusión a la configuración dedicada, si por cada proceso usuario se crea un proceso servidor y ese proceso servidor asigna previamente por prealoca recursos de memoria, entonces va a llegar un momento en que lógicamente el servidor no tendrá más lugar en la memoria para seguir atendiendo conexiones entrantes, ya que no puede crear más procesos de servidor hasta que algún proceso usuario cierre su conexión. Si las exigencias del negocio incrementan drásticamente, podemos configurar Oracle Server en modo Compartido permitiéndole soportar numerosas conexiones concurrentes sin incrementar los recursos del servidor. Esto se logra compartiendo los procesos de servidor a grupos de clientes (procesos de usuario). Para lograr este cometido con éxito, Oracle Server se basa en distribuidores ó Dispatchers para resolver las solicitudes de los clientes administrando una mejora en el rendimiento. Por lo tanto, trabajar con este tipo de arquitectura es beneficioso no sólo en cuanto a la mayor cantidad de usuarios concurrentes que se puede lograr, sino que también realiza una mejor utilización del espacio de memoria ocupado y de cómo trabajan los procesos del servidor. Entonces, Por qué no utilizar siempre una configuración compartida? Para utilizar esta configuración, se deben tener en cuenta ciertos aspectos que se deberán dejar de lado, como por ejemplo la performance. Al utilizar procesos de servidor compartidos, no se va a lograr la misma disponibilidad para las solicitudes y por lo tanto, no se tendrá la misma velocidad de respuesta que en un ambiente dedicado. Otra contra es si tiene que atender muchas conexiones de mucho volumen de manejo, las cuales capturarían los procesos de servidor con su trabajo, haciendo tener un mal desempeño al servidor. Adicionalmente, hay algunas funciones que son inválidas en ente tipo de configuración, como ser STARTUP, SHUTDOWN y funciones de recuperación.
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.5 Comunicación con un Servidor Compartido Al momento de conectarnos a un servidor Oracle en modo compartido, es el Listener quien nos dará la dirección para conectar con un Distribuidor ó Dispatcher y procesar los requerimientos hasta que se termine el proceso del usuario y se cierre la comunicación con el dispatcher. Según la Figura 1, una vez establecida la conexión, se procede a trabajar con el servidor realizando las solicitudes de la siguiente manera: 1. Un proceso de usuario hace una consulta y se la envía a un dispatcher del servidor. 2. El dispatcher ubica la consulta en una cola de solicitudes en la SGA. 3. Alguno de los procesos del servidor ejecuta la consulta de la cola 4. La respuesta de la consulta la ubica en una cola de solicitudes resueltas del dispathcer, en la SGA 5. El Dispatcher captura la respuesta de la cola 6. La respuesta es enviada al proceso de usuario. Ocasionalmente podríamos llegar a necesitar conectarnos a un servidor compartido en forma dedicada, ya sea para realizar un trabajo tipo BATCH donde sabemos que el proceso de servidor va a estar dedicado a nuestras solicitudes, ó si nos tenemos que conectar como SYSDBA para algún trabajo de mantenimiento, como ser Startup, Shutdown ó trabajos de recuperación. Para ello, debemos configurar en el archivo de configuración de red tnsnames.ora la propiedad SERVER=DEDICATED, como se ve en la Figura 2.
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.6 Comportamiento de la Memoria Cuando un Oracle Server es configurado en modo Compartido, Oracle agrega dos nuevas estructuras de memoria a la SGA (System Global Area). Estas estructuras son llamadas Cola de Solicitudes y Cola de Respuestas. Sólo existe una Cola de Solicitudes para todos los distribuidores ó dispatchers, pero cada dispatcher sí tiene su propia Cola de Respuestas. Entonces, si se tienen cuatro dispatchers en la SGA va a existir una cola de solicitudes y cuatro colas de respuestas. Una Cola de Solicitudes es una estructura de memoria en la SGA donde los dispatchers ubican las solicitudes de los clientes. Entonces algún Proceso de Servidor tomará esta solicitud y la ejecutará, dejando el resultado en la Cola de Respuestas del dispathcer que lo solicitó. En un ambiente dedicado, cada proceso del servidor tiene un segmento de memoria propio llamado PGA (Program Global Area). La PGA es un área de memoria donde se mantiene la información de la sesión de cada cliente. Esta información incluye variables, información de cursores y un área de ordenamiento del cliente. En un ambiente compartido, esta información es movida de la PGA a la SGA, en una estructura especial de memoria llamada UGA (User Global Area). En versiones anteriores de Oracle la UGA se almacenaba en el Conjunto Compartido ó Shared Pool. A partir de Oracle 8, la UGA se almacena en el Conjunto Extendido ó Large Pool. Cada conexión servida por un dispatcher se vincula con la SGA formando un Circuito Virtual. El Proceso de Servidor utiliza el circuito virtual para enviar y recibir información del dispatcher que realizó cada solicitud. Las Figuras 1 y 2muestran la comparación del comportamiento de la SGA en un ambiente dedicado ó distribuido.
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.7 Configuración Para configurar un Oracle Server en modo Compartido, se requiere una parametrización adicional en el archivo de inicio, ya sea el PFILE ó el SPFILE. Estos parámetros identifican la cantidad de distribuidores ó dispatchers, la cantidad de procesos del servidor y el nombre de la base de datos que se quiere asociar con estos procesos. Dentro de los parámetros obligatorios, tenemos: DISPATCHERS: Como su nombre lo indica, este parámetro define la cantidad de procesos distribuidores que se utilizarán en la instancia, como así también el protocolo que utilizan. Adicionalmente se pueden adicionar dispatchers con el comando ALTER SYSTEM. En la Figura podemos ver una tabla con los parámetros que se pueden usar en la definición de este parámetro. Cabe destacar que sólo hace falta uno de los parámetros ADDRESS, PROTOCOL y DESCRIPTION para definir los dispatchers. SHARED_SERVERS: Especifica la cantidad de Procesos de Servidor que se deben crear al inicio de la instancia para procesar las solicitudes de los clientes. Al igual que el parámetro DISPATCHER, SHARED_SERVERS puede ser cambiado dinámicamente utilizando el comando ALTER SYSTEM. Al menos un Proceso de Servidor debe ser especificado para operar en este modo. Estos dos parámetros son necesarios para utilizar un Oracle Server en modo compartido. Para determinar aproximadamente la cantidad de dispatchers y procesos de servidor que se requieren inicialmente en una instancia, se debe conocer la cantidad de posibles conexiones por proceso usuario. Por ejemplo para 200 conexiones concurrentes balanceadas en 20 conexiones por dispatcher, requeriría 10 dispatchers: DISPATCHERS = (PRO=TCP)(DIS=10) Podemos valernos de la vista dinámica V$SESSIONS para obtener la cantidad de conexiones concurrentes en ese momento. De la misma manera, la cantidad de procesos de servidor también depende de la cantidad de conexiones contra el servidor, teniendo en cuenta el tipo de trabajo que realizarán. Por lo general un Proceso de Servidor puede atender entre 10 y 20 usuarios como valor por defecto. Adicionalmente contamos con el parámetro SHARED_SERVER_SESSIONS para definir el máximo de sesiones por instancia derivado de los parámetros CIRCUITS ó SESSIONS y por lo tanto no debería ser especificado manualmente ya que toma el valor menor de estos parámetros. Como podemos tener un control dinámico de estos parámetros, podemos contar con los parámetros MAX_DISPATCHERS y MAX_SHARED_SERVERS para limitar el crecimiento inadecuado peligrando la estabilidad de la instancia. Cabe destacar que estos dos parámetros NO se pueden modificar de manera dinámica, con lo que habría que reiniciar la instancia. Finalmente podemos definir el parámetro CIRCUIS, que maneja la cantidad total de circuitos virtuales permitidos para las conexiones entrantes y salientes. Éste es un parámetro estático y debería ser igual al valor del parámetro SESSIONS del (s)pfile, de lo contrario, se tiene que definir en 0.
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.8 Verificación de la Configuración Una vez que se completó la configuración en el (s)pfile, se debe reiniciar la instancia para que los nuevos parámetros cambien el comportamiento de la misma. Al reiniciar, se puede verificar la nueva parametrización a través de las vistas dinámicas de rendimiento (V$) para observar si se iniciaron los procesos de servidor y los distribuidores (dispatchers). Cuando una instancia configurada en modo compartido es iniciada, el PMON es el encargado de registrar los dispatchers en el Listener. Para verificar esto, podemos usar la utilidad lsnctl y el parámetro services, como se ve en la Figura, un ejemplo de un Listener con dos procesos dispatcher registrados. Adicionalmente podemos verificar las vistas del diccionario de datos que podemos consultar en relación a la configuración compartida, como se ve, en resumen, en la Figura. Entre ellas podemos encontrar la vista V$DISPATCHER para ver información de los dispatchers ejecutándose, la cantidad de conexiones establecidas y el total de conexiones de cada uno de ellos. La vista V$QUEUE contiene información sobre las colas de solicitudes y de respuestas. Este tipo de información es valiosa cuando se está tratando de determinar si se necesitan más procesos de servidor. V$CIRCUITS se utiliza para ver las conexiones compartidas realizadas por los dispatchers. Esta vista también verifica el balanceo del Listener. En cuanto a la vista V$SHARED_SERVER podemos decir que contiene información sobre los procesos de servidor que se encuentran ejecutándose en la instancia, incluyendo el estado de los mismos. Complementariamente a esta vista, podemos utilizar otra llamada V$SHARED_SERVER_MONITOR para hacer una afinación del servidor compartido. Esta vista incluye el número máximo de conexiones concurrentes desde que se inició la instancia y la cantidad total de procesos de servidor iniciados. Finalmente, la vista V$SESSION contiene información referida a los clientes, como ser si el cliente está utilizando una conexión compartida ó dedicada.
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.9 Lectura Adicional: El Rol del Listener en un ambiente compartido El Listener juega un papel importante en un ambiente compartido. Es el Listener el responsable de administrar a los clientes la dirección del dispatcher al que se deben conectar cuando solicitan una nueva conexión a un Oracle Server en modo compartido. El proceso en segundo plano PMON (Process Monitor) notifica al Listener la cantidad de dispatchers disponibles para conexiones entrantes. Esta información posibilita al Listener realizar el balanceo de la carga de conexiones de la siguiente manera: Cuando un Listener recibe una solicitud de conexión, éste mira la carga de conexión de cada dispatcher y redirige la conexión al dispatcher con menor carga de trabajo. Es por esto que el Listener se asegura la correcta distribución de las comunicaciones. Cuando un cliente concluye su comunicación, el Listener actualiza la información de las comunicaciones, como se puede ver en la Figura 1, los pasos en un proceso de conexión son: 1. El proceso dispatcher se inicia junto con el arranque de la instancia 2. Un cliente contacta al Oracle Server luego de resolver su nombre de servicio 3. El Listener redirige la conexión del cliente al dispatcher menos ocupado 4. El dispatcher procesa los requerimientos del cliente 5. El proceso PMON registra información sobre la conexión con el Listener
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.11 EI: Uso de memoria en modo dedicado y compartido Teniendo en cuenta el comportamiento de la SGA (System Global Area) en los ambientes compartidos, definir las estructuras de memoria que son incluidas al inicio de la instancia con dos distribuidores ó dispatchers:
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.12 EI: Uso de los parámetros para un servidor compartido Identificar las vistas dinámicas del diccionario de datos en función de su descripción.
2.3 Configuración y Uso de Oracle en modo Compartido 2.3.13 Síntesis El Modo Compartido es una configuración de Oracle Server que permite soportar grandes cantidades de conexiones sin la necesidad de recursos adicionales. Es importante entender la opción del modo compartido, ya que puede ayudar a reservar espacio de memoria inutilizado por procesos ociosos. En este tipo de configuración, las conexiones de usuario comparten procesos llamados distribuidores ó dispatchers. Los Dispatchers reemplazan al proceso de servidor dedicado en un ambiente dedicado. Oracle Server es configurado con una única cola de solicitudes en donde los dispatchers las ubican a medida que las reciben de los clientes y de donde los procesos de servidor las toman para procesarlas, dejando las solicitudes procesadas en la cola de respuestas del dispatcher que hizo la solicitud, devolviéndola al cliente. Tanto la cola de solicitudes como las de respuestas son estructuras de memoria albergadas en la SGA (System Global Area). Hay una serie de parámetros que se deben agregar en el (S)PFILE para la configuración del modo compartido. Adicionalmente se puede agregar más procesos de servidor y / o dispatchers dinámicamente una vez que la instancia fue iniciada. Hay una serie de vistas dinámicas de rendimiento (V$) para monitorear la configuración y el comportamiento de Oracle Server en Modo Compartido donde se puede ver información sobre los dispatchers, los proceso de servidor, los circuitos utilizados por los dispatchers o las sesiones establecidas. Estas vistas también se pueden utilizar para refinar el proceso del servidor obteniendo información sobre los tiempos de conexión, máximo de conexiones establecidas ó utilización de los dispatchers. Estos factores son los utilizados para saber si debemos agregar más cantidad de dispatchers para responder a las solicitudes de los clientes.