6.1. ORACLE NET

CONFIGURACION Y ADMINISTRACION DE LA RED DE ORACLE.

Oracle Net es una tecnología que permite para la Arquitectura Oracle Cliente-Servidor. Es el mecanismo para establecer sesiones contra la instancia de la Base de Datos. Hay varias herramientas que pueden ser utilizadas para la creación y administrar Oracle Net. Aunque puede ser hecho con nada más que un Editor tal como Windows Notepad. Cualquiera que sea la herramienta utilizada, el resultado final es un conjunto de archivo que Controla un Proceso (El Database Listener), que lanza procesos de servidor es respuesta a solicitudes de conexión, y que define el medio por el cual un proceso de usuario localizará el Listener.

ORACLE NET Y EL PARADIGMA CLIENTE-SERVIDOR.

Hay muchas capas entre el Usuario y la Base de Datos. En el Entorno Oracle, ningún usuario nunca tiene acceso directo a la Base de Datos-ni el proceso que se ejecuta. La Arquitectura Cliente-Servidor garantiza que todo el acceso a datos es controlado por el Servidor.

Un usuario interactúa con un Proceso de Usuario: este es el software que (el/ella) se ejecuta en su terminal local. Por ejemplo, podría ser Microsoft Access plus, más un Driver ODBC en un PC Windows. Podría ser algo escrito en C y vinculado con la Oracle Call Interface(o OCI) Librerías. Podría ser incluso su viejo amigo SQL Plus. Sea lo que sea, el propósito del proceso de usuario es solicitar al usuario ingresar información que el proceso puede utilizar para generar sentencias SQL. En este caso de SQL Plus, el proceso simplemente espera a que escriba algo en un proceso de usuario más sofisticado que pintar una pantalla de entrada de datos apropiada, validará su entrada, y luego cuando usted de clic en botón enviar construirá la sentencia y la envía al proceso de servidor.

El proceso de servidor es un proceso que se ejecuta en el servidor de Base de Datos que ejecuta los SQL recibidos de los procesos de usuarios. Esta es la división básica de Cliente-Servidor: un Proceso de usuario generando SQL, un Proceso Servidor ejecutando estas. La ejecución de una sentencia SQl va atraves de cuatro etapas: Parse (Analiza), bind (enlaza), execute (ejecuta) y fecth (Obtención de información). En la Fase de Parse, su proceso servidor trabaja en lo que significa la sentencia realmente. y como ejecutarla mejor. El análisis implica la interacción con el Shared Pool de la instancia: La Estructura de memoria Shared pool son usadas para convertir el SQL es algo que si es realmente ejecutable. En la Fase Bind, cualquier variables es ampliada a valores literales, entonces la fase de ejecución requerirá mas uso de la SGA de la instancia y posiblemente de la Base de Datos. Durante la ejecución de una sentencia, los datos en el Database Buffer Cache serán leídos o actualizados y los cambios escritos en el redo log buffer, pero si los bloques importantes no estén en el Database Buffer Cache, sus procesos de servidor los leerá de los DataFiles. Este es el único punto en la ejecución de una declaración donde está implicada la Base de Datos sí mismo. Y finalmente, la fase de búsqueda del ciclo de ejecución es donde el proceso de servidor envía el conjunto de resultados generados por la ejecución de la declaración de nuevo al proceso de usuarios, que luego debe darle formato para su exhibición.

Oracle Net provee los mecanismos para poner en marcha un proceso de servidor para ejecutar el código en favor de un proceso de usuario. Esto establece una sesión. Entonces Oracle Net es responsable de mantener la sesión: La transmisión de SQL desde el proceso usuario a el proceso servidor, y trayendo resultados desde el proceso servidor de nuevo a el proceso de usuario.

Figura 6-1. Muestra los diferentes componentes de una sesión. Un usuario interactúa con un proceso usuario; un proceso de usuario interactúa con un proceso de servidor, vía Oracle Net; un proceso de servidor interactúa con la Instancia; y la Instancia, esto vía procesos Background, interactúa con la Base de Datos. Su división Cliente-Servidor es entre el Proceso de usuario genera SQL y el proceso de servidor que ejecuta esta. Esta división usualmente será tanto física como lógica: habrá una red de área local entre las maquinas que reciben los procesos de usuario y la maquina que recibe el lado de servidor. Pero esto es bastante posible que este vinculo de área extensa, o por el contrario para ejecutar los procesos de usuario en la maquina servidor. Oracle Net es responsable de establecer una sesión, y luego para la comunicación entre el proceso de usuario y el proceso de servidor. La Base de Datos es protegida de usuarios por varias capas de segregación.

UNA PALABRA SOBRE ORACLE NET Y PROTOCOLOS DE COMUNICACIÓN.

Oracle Net es un protocolo de Capas: Esto ejecuta en la parte superior de cualquier protocolo de comunicaciones es soportado por su Sistema Operativo. Históricamente, Sqlnet podría trabajar con todos los Protocolos populares (con la excepción de NetBIOS/NetBEUI, que tiene una funcionalidad muy limitada para ser usado para sistemas de bases de datos grandes, este no puede ser enrutado), pero en la versión 11g Oracle Network se limita a TCP, TCP con sockets seguros, Windows Named Pipes(0 NMP), y los nuevos Sockets Direct Protocol(o SDP) sobre las redes de alta velocidad de alta velocidad de Infiband. Esta reducción de la compatibilidad con protocolos se ajusta a los estándares del sector. Todos los Sistemas Operativos también tienen una comunicación entre procesos (o IPC) protocolo propietario para el sistema operativo – esto es también está disponible a la Red Oracle para las conexiones locales donde el proceso de usuario se encuentra en la misma máquina del servidor.

Estas capas de Oracle Net en la parte superior es provista por el sistema operativo da a Oracle Independencia de Plataforma. Usted, como DBA, no necesita saber nada acerca de la red subyacente, usted configura Oracle Net para usar cualquier protocolo ha sido configurado por los administradores de la Red. Usted no necesita preocuparse por lo que está sucediendo debajo. TCP es, para bien o para mal, sin duda el protocolo más popular del mundo, así que es el usado en los ejemplos siguientes. El uso de protocolo estándar de la industria significa que no hay necesidad de dependencia entre el Lado del Servidor y el lado del Cliente. No hay ninguna razón porque, por ejemplo, un cliente Windows no puede hablar con una Base de Datos sobre Unix. Como siempre que la plataforma pueda ofrecer una interfaz de capa TCP 4, luego Oracle Net pueda utilizarlo.

Con respecto a conformidad con el Open System Interconnection (o OSI) siete capas del modelo al que todos los proveedores de TI se suponen cumplir, Oracle Net mapea sobre las capas cinco, seis y siete: La sesión, presentación y aplicación. Los adaptadores de protocolo instalado con la instalación estándar de Oracle ofrecen el crossover a la capa cuatro, la capa de transporte, suministrado por el sistema operativo. Así la red de Oracle es responsable de establecer sesiones entre los sistemas de extremo una vez que el TCP (o cualquier otra cosa que usted está utilizando) ha establecido una conexión de la capa cuatro. Las funciones de capa de presentación son manejados por la Red de Oracle Dos tarea común (o TTC) capa. TCC es responsable de cualquier conversión necesaria cuando los datos se transfieren entre el proceso de usuario y el proceso del servidor, tales como cambios de juego de caracteres. A continuación, las funciones de capa de aplicación es el usuario y el servidor de procesos en sí mismos.

ESTABLECIENDO UNA SESION.

Cuando un usuario, através de su proceso de usuario, desea establecer una sesión en una instancia, se le emitirá un comando como este:

CONNECT SCOTT/TIGER@ORCL11G

Por supuesto, si está utilizando una interfaz de usuario correctamente escrito, no se escribe esas palabras, pero se le pedirá que introduzca los detalles en una pantalla de inicio de sesión - pero de un modo u otro ése es el comando que el proceso del usuario generará. Es ahora el momento de entrar en lo que realmente sucede cuando ese comando se procesa. En primer lugar, romper el comando en sus componentes. Hay un nombre de usuario de Base de Datos (“SCOTT”), seguido por un Password de base de Datos (“TIGER”), y los dos están separados por un “/” delimitador. Luego hay un símbolo “@”, seguido por una cadena de conexión, “ORCL11G”. El símbolo “@” es una indicación al proceso de usuario que una conexión de red es requerida. Si el “@” y la cadena de conexión son omitidos, entonces el proceso usuario asumirá que la instancia a la que desea conectarse esta ejecutándose en la maquina local, y siempre disponible el Protocolo IPC para ser utilizado. Si el “@” y una cadena de conexión son incluidos, entonces el Proceso usuario asumirá que usted solicita una conexión de red a una instancia en una maquina remota – aunque de hecho, usted podría estar rebotando en la tarjeta de red y regresando a la maquina en la que usted se registra.

CONECTANDOSE A UNA INSTANCIA LOCAL.

Incluso cuando usted se conecta a un instancia ejecutándose en su Maquina local, usted todavía utiliza Oracle Net. Todas las sesiones de Oracle utilizan un protocolo de red para implementar la separación de código de usuario del código de servidor, pero para una Conexión Local el protocolo es IPC: este es el protocolo provisto por tu sistema operativo que permitirá a los procesos comunicarse dentro de la maquina central. Este es el único tipo de conexión que no requiere un Database Listener; de hecho, conexiones locales no requieren ninguna configuración en absoluto. La única información necesaria es decir a su proceso de usuario que instancia usted quiere conectarse. Recuerde que puede hacer varias instancias ejecutándose en su máquina local. Usted da al proceso esta información atraves de una variable de entorno. Figura 6-2 muestra ejemplo de esto en Linux, Figura 6-3 es lo mismo en Windows.

Recuerde que la única diferencia entre plataformas es la sintaxis para ajustar variables de entorno.

RESOLUCION DE NOMBRES

Cuando se conecta mediante Oracle Net, la primera etapa es resolver exactamente qué es lo que quiere conectar. Este es el proceso de resolución de nombres. Si su declaración para conectarse incluye la cadena de conexión “@orcl11g,” Oracle Net ha de resolver que significa “orcl11g” Esto significa que la cadena que la cadena ha de ser resulta en ciertas piezas de información: el protocolo que desea utilizar (suponemos que es TCP), la dirección IP en el cual el Database Listener está ejecutando, el puerto que el Listener está monitoreando para peticiones de conexión entrante, y el nombre de la instancia (cuales no necesitan ser iguales que la secuencia de conexión) a la que desea conectar.

Hay variaciones: en cambio que una Dirección IP, la cadena de conexión puede incluir un Hostname, que luego consigue ser resuelto a una Dirección IP por un servidor DNS. En lugar de especificar una instancia por su nombre, la cadena de conexión puede incluir el nombre del Servicio, que (en un entorno RAC) puede estar conformado por una serie de instancia. En un entorno de instancia-única, los servicios pueden todavía ser utilizados-tal vez para ayudar en el seguimiento de la carga de trabajo impuesta a la Base de Datos por diferentes grupos de usuarios. Usted puede configurar un numero de maneras de resolución de cadenas de conexión a las direcciones y nombres de instancias, pero de una manera u otra el proceso de resolución de nombres da la información de su proceso de usuario como para ir a través de la red a un Listener de base de datos y solicitar una conexión a una instancia en particular.

LANZANDO UN PROCESO SERVIDOR.

El Database Listener, se ejecuta en la maquina servidor, utiliza uno o más protocolos para monitorear uno o varios puertos en una o varias interfaces de red para solicitudes de conexión entrantes. Usted puede complicar más la cuestión, ejecutando múltiples Listener en una Maquina. Y cualquier Listener puede aceptar solicitudes de conexión para una serie de instancias. Cuando se recibe una solicitud de conexión, el Listener debe primero validar si la instancia solicitada está disponible. Asumiendo que lo es, el Listener iniciará un nuevo proceso servidor para dar servicio al proceso usuario. Por lo tanto si usted tiene un millar de usuarios que se conectan concurrentemente a la instancia, este lanzará un millar de procesos servidor. Esto es conocido como la Arquitectura de Servidor Dedicado. Más adelante en este capítulo veremos la alternativa de Servidor Compartido. Donde cada proceso de usuario se da a un proceso servidor, dedicado a esta sesión.

En el entorno TCP, cada proceso servidor dedicado lanzado por un Listener adquiere un único numero de puerto TCP. Esto será asignado en tiempo de proceso de inicio por su algoritmo de trazado de puertos del sistema operativo. El número de puerto obtenido es devuelto al proceso usuario por el Listener (o en algunos Sistemas operativos el socket ya está abierto para el Listener se transfiere el nuevo número de puerto). Y el proceso usuario puede entonces comunicarse directamente con el proceso servidor. El Listener ha terminado su trabajo y espera a la siguiente solicitud de conexión.

EXAMEN

Si el Database Listener no está ejecutándose, ningún nuevo proceso servidor puede ser lanzado-pero esto no afectara a cualquier sesiones existente que ya han sido establecida.

CREANDO UN LISTENER.

Un Listener se define en un Archivo: el archivo listener.ora, cuya ubicación predeterminada esta en el directorio ORACLE_HOME/network/admin Como mínimo, el archivo listener.ora debe incluir una sección para un Listener, que dice su nombre y el protocolo y la dirección de escucha que utilice. Puede configurar varios Listener en un archivo, pero deben tener diferentes nombres y direcciones.

EN EL TRABAJO.

Usted puede ejecutar un Listener completamente en Dafault. Sin un archivo listener.ora en absoluto. Escuchara en cualquier dirección se resuelve el nombre de host de la maquina en el puerto 1521. No haga esto sería muy confuso. Siempre configure un archivo listener.ora. Para hacer de su entorno Oracle Net auto-documentable.

Al igual que con otros archivos utilizados para configurar Oracle Net, el archivo listener.ora puede ser muy exigente sobre los puntos aparentemente triviales de la sintaxis, tales como mayúsculas y minúsculas, espacios en blanco y abreviaciones. Por esta razón, muchos DBAs no le gusta editarlo a mano (aunque no hay razón para hacerlo). Oracle ofrece tres herramientas graficas para administrar Oracle Net: Enterprise Manager (Database Control o Grid Control), El Net Manager, y el Net Configuration Assistant. Las últimas dos herramientas están escritas en Java. Existe una considerable coincidencia entre la funcionalidad de estas herramientas, aunque hay algunas cosas que puede solo ser hechas en una u otra.

Este es un ejemplo de un archivo listener.ora:

LISTENER =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1)(PORT = 1521))

)

LIST2 =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT =1522))

(ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1.bplc.co.za)(PORT = 1522)))

)

La primera sección de este archive define un Listener llamado LISTENER, monitoreando el Hostname Local en el puerto por defecto, 1521. La segunda sección define otro Listener llamado LIST2. El Listener está monitoreando en el puerto 1522 en ambas direcciones Hostname y LoopBack. Para crear el Listener, no necesita hacer nada más que crear una entrada en el archivo listener.ora, e iniciarlo. En Windows el Listener se ejecutara como un Servicio Windows, pero no hay necesidad para crear el servicio explícitamente; se creara de forma implícita la primera vez que el Listener es iniciado. De entonces, si usted desea, este puede ser iniciado y parado como cualquier servicio Windows.

Figura 6-4 Muestra la vista del Net Manager’s del Listener LIST2, y la figura 6-5 muestra atreves el Net Configuration Assistant.

Tenga en cuenta que el Net Manager le permite configurar múltiples direcciones de escucha para un Listener. Mientras el Net Configuration Assistant no lo hace: solo puede ver una dirección del Hostname; no hay prompt para crear o ver cualquier otro.

REGISTRO DE BASE DE DATOS.

Un Listener es necesario para generar Procesos Servidor contra la instancia. Para hacer esto, necesita saber que instancias están disponibles en la computadora que se está ejecutando. Un Listener descubre las instancias por el proceso de “Registration - Registro”. Hay dos métodos para registrar una instancia con una Base de Datos: registro Estático y Dinámico. Para el registro Estático, Hard-Code una lista de Instancias en el archivo listener.ora. Registro Dinámico significa que la propia instancia, en tiempo de inicio, localiza un Listener y los registra.

EXAMEN

El Listener y la Instancia deben estar ejecutándose en la misma computadora, a menos este usando RAC. En un entorno RAC, cualquier Listener en cualquier computadora en el Clúster puede conectar a cualquier instancia en cualquier computadora.

REGISTRO ESTATICO.

Como regla general, registro dinámico es una mejor opción, pero hay circunstancias cuando usted recurrirá al registro estático, registro dinámico fue introducido con la versión 8i, pero si usted tiene viejas Bases de Datos que su Listener debe conectar a los usuarios, usted tendrá que registrarse estáticamente. Además, algunas aplicaciones pueden requerir de Registro Estático: típicamente herramientas de administración. Para registrar una instancia estáticamente, agregue una entrada apropiada al archivo listener.ora:

SID_LIST_LIST2 =

(SID_LIST =

(SID_DESC =

(ORACLE_HOME = /u01/oracle/app/product/11.1.0/db_1)

(SID_NAME = ocp11g)

)

)

Esta entrada configurará el Listener llamado LIST2 para aceptar solicitudes de conexión para una instancia llamada ocp11g. No dice si la instancia esta ejecutándose o incluso si existe. La directiva ORACLE_HOME solo es necesario si el Database Listener no está ejecutándose desde la misma Oracle Home como la instancia. Si este es el caso, entonces esta directiva permitirá al Listener encontrar el archivo ejecutable que deba ejecutar para iniciar un proceso servidor. Por lo general, esto solo es necesario si la configuración de un Listener para hacer conexiones a instancias de diferentes versiones, que están ejecutándose en diferentes Home`s.

REGISTRO DINAMICO DE INSTANCIAS.

Este es el método preferido por lo que una instancia se registrará con un Listener. Existe un parámetro de inicialización local_listener, que dice a la Instancia la dirección de Red que debe contactar para encontrar un Listener con el cual para registrarse. En el inicio de una instancia, el proceso PMON consumirá este parámetro para localizar un Listener, y se informará del nombre de la instancia y el nombre de los servicios que la instancia está ofreciendo. El nombre de la instancia se define por el parámetro Instance_name, y el parámetro Service_names habrá omitido este sufijo por el parámetro db_domain, que por defecto a null. Es posible crear e iniciar servicios adicionales en cualquier momento, ya sea cambiando el valor del parámetro Service_name (que puede ser una lista delimitadas por coma, si la instancia es la de ofrecer varios servicios) o mediante programación utilizando el paquete DBMS_SERVICE. Cualquier cambios a los servicios deben ser registrados con el Local Listener. Si esto no es hecho, el Listener no sabría qué servicios se están ofreciendo, y por lo tanto no será capaz de establecer sesiones con ellos. El proceso PMON se re registrara de vez en cuando de forma automática, pero en cualquier momento posterior al inicio de la instancia, puede obligar a la re registrar mediante la ejecución del comando.

SQL> alter system register;

EN EL TRABAJO

Usted necesitara registrar su instancia con el Listener con “alter System register” si usted ha reiniciado el Listener, o si usted reinicio la instancia de Base de Datos antes de iniciar el Listener.

Registro Dinámico es una mejor opción que el registro estático, ya que asegura que solo las instancias en ejecución y los servicios disponibles estén registrados en el Listener. Y también que no hay errores en los nombres de instancias y servicios. Es muy fácil hacer errores aquí, particularmente si usted está editando el archivo Listener.ora a mano. También, cuan la instancia se cierra. Quitara el registro del Listener automáticamente.

Desde la versión 9i en adelante, registro dinámico no requiere configuración en lo absoluto si su Listener esta ejecutándose en el puerto por default, 1521. Todas las instancias automáticamente buscaran a un Listener en el Host Local en ese puerto, y se registraran ellas misma sin encuentran uno. Sin embargo, si su Listener no está ejecutándose en el puerto por defecto en la dirección identificada por el Hostname, usted debe especificar donde el Listener es configurando el parámetro local_listener y registrando por ejemplo,

SQL> alter system set local_listener=list2;

SQL> alter system register;

En este ejemplo, el local_listener ha sido especificado por nombre. Este nombre necesita ser resuelto en una dirección para que la instancia encuentre el Listener y el registro en sí, como se describe en la siguiente sección. Una técnica alternativa es hard-code la dirección del Listener en el parámetro:

SQL> alter system set

local_listener='(address=(pro=tcp)(host=127.0.0.1)(port=1522))';

La sintaxis es perfectamente aceptable, pero el uso de un nombre que puede ser resuelto es buena práctica. Ya que coloca una capa de abstracción entre el nombre lógico y la dirección física. La abstracción significa que si la dirección de escucha tiene que cambiar, solo hay que cambiar en el servicio de resolución de nombres, en lugar de tener que cambiar en todos los casos que lo utiliza.

TECNICAS DE RESOLUCION DE NOMBRES

En el inicio de este capítulo, usted vio que para establecer una sesión contra una instancia, su proceso usuario debe emitir una cadena de conexión. Esa cadena resuelve la dirección del Listener y el nombre de una instancia o servicio. En la discusión del registro dinámicos de instancia. Usted vio otra vez el uso de un nombre lógico para un Listener, que necesita ser resuelto en una dirección de Red con el fin para que una instancia encuentre un Listener con quien registrarse. Oracle proporciona cuatro métodos de resolución de nombres: easy connect, Local Naming, Directory Naming, y External Naming. Es probablemente cierto decir que la mayoría de sitios Oracle utilizan el local naming, pero no hay duda que Directory Naming es el mejor método para instalaciones grandes y complejas.

EASY CONNECT

El método de resolución de nombres Easy Connect fue introducida con la versión 10g. Es muy fácil para usar-no requiere configuración en lo absoluto. Pero se limitado a un protocolo: TCP. Los otros métodos de resolución de nombres pueden utilizar cualquiera de los otros protocolos compatibles, tales como TCP con Sockets Secure, o Named Pipes. Otra limitación es que Easy Connect no puede utilizar con cualquiera de las capacidades más avanzadas de Oracle Net, tales como Balanceo de Carga o de conmutación por error de tiempo a través de rutas de red diferentes. Es justo decir que Easy Connect es un método como DBA encontrara muy práctico de utilizar, pero que no es un método de mucho uso para sus usuarios finales. Easy Connect esta activado por defecto. Usted lo invoca con una sintaxis tal como está como su cadena de conexión:

SQL> connect scott/tiger@jwlnx1.bplc.co.za:1522/ocp11g

En este ejemplo, SQL*PLUS utilizará TCP para ir al puerto 1522 de la dirección IP a la que el nombre de host se resuelve. Entonces si hay un Listener ejecutándose en ese puerto y dirección, le pedirá al Listener generar un proceso servidor contra una instancia que es forma parte del servicio llamado ocp10g, Easy Connect se puede hacer aun más fácil:

SQL> connect scott/tiger@jwlnx1.bplc.co.za

También trabajará, pero solo si el Listener está utilizando el Puerto 1521, y el nombre del servicio registrado con el Listener es jwlnx1.bplc.co.za, igual como el nombre de la computadora.

LOCAL NAMING

Con Local Naming el usuario el usuario proporciona un alias, conocido como Service Alias Oracle Net, para la cadena de conexión, y el Alias se resuelve mediante un Archivo Local en la Dirección de Red Completa (Protocolo-protocol, Dirección-address, puerto-port, y Service-service o nombre de instancia-instance name). El archivo local es el archivo tnsnames.ora, cual ha causado a DBAs mucha pena durante los años.

Considere este ejemplo de archivo tnsnames.ora:

ocp11g =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = jwlnx1.bplc.co.za)(PORT

= 1522))

)

(CONNECT_DATA =

(service_name = ocp11g)

)

)

test =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = serv2.bplc.co.za)(PORT

= 1521))

)

(CONNECT_DATA =

(sid = testdb)

)

)

Este archivo tnsnames.ora tiene dos alias de servicio Oracle Net definido dentro: ocp11g y test. Estos alias son lo que proporcionarán sus usuarios en sus declaraciones de conexión. La primera entrada, ocp11g, dice simplemente que cuando la cadena de conexión “@ocp11g” es emitida, su proceso de usuario debe utilizar el protocolo TCP para ir a la Maquina jwlnx1.co.za, en contacto con el puerto 1521, y pedir al Listener monitoree ese puerto para establecer una sesión contra la instancia con el nombre de servicio ocp11g. la segunda entrada, test, dirige a usuarios a un Listener sobre una Maquina diferente y pide una sesión en la instancia llamada testdb.

EN EL TRABAJO.

No es necesario que exista relación entre el alias, el nombre de servicio, y el nombre de instancia, pero por el bien de su cordura usted usualmente mantendrá el mismo.

Local Naming soporta todos los protocolos y todas las características avanzadas de Oracle Net, pero manteniendo los archivos tnsnames.ora en todos sus maquinas clientes puede ser una tarea extremadamente laboriosa. El archivo tnsnames.ora es también muy sensibles a las variaciones aparentemente triviales en el diseño. Utilizando las herramientas GUI ayudaran con tales problemas.

DIRECTORY NAMING Y EXTERNAL NAMING.

Directory Naming señala al usuario hacia un Servidor de Directorio LDAP para resolver los alias. LDAP es un estándar utilizado ampliamente que Oracle Corporation (y otros proveedores de software convencional) fomentan a organizaciones para adoptarlo. Para utilizar Directory Naming, usted debe primero instalar y configurar un Servidor de Directorio en algún lugar de su Red. Oracle proporciona un servidor LDAP (El Oracle Internet Directory) como parte de Oracle Application Server, pero usted no tiene que usar ese, si usted ya tiene un Microsoft Active Directory, eso será perfectamente adecuado. IBM y Novell también venden Servidores de Directorio conforme a la norma LDAP.

Como Local Naming, Directory Naming soporta todas las características de Oracle Net, pero a diferencia de Local Naming, utiliza un repositorio central, el Servidor de Directorio, para todos sus detalles de resolución de nombres. Esto es mucho más fácil para mantener que muchos archivos tnsnames.ora distribuidos atraves de su comunidad de usuarios.

External Naming es conceptualmente similar a Directory Naming, pero utiliza Servicios de Nombres de terceros tales como Suns Network Information Services (NIS+) o el Cell Directory Services (CDS) que son parte del Distributed Computing Environment (DCE).

EL LISTENER CONTROL UTILITY

Usted puede iniciar y detener los Listener atraves del Database Control, pero también hay una utilidad de línea de comandos lsnrctl (lsnrctl.exe sobre Windows). El comando lsnrctl puede ser ejecutado directamente desde un prompt de sistema operativo, o atraves de una simple interface. Para todos los comandos, usted debe especificar el nombre del Listener, si no es el nombre por default del Listener. Figura 6-6 y 6-7 muestra como comprobar el estatus de un Listener y para detener e iniciar, emitir los comando desde el prompt del sistema operativo o desde dentro de la interface de usuario.

Observe que el comando status siempre te dice la dirección sobre la que el Listener está aceptando solicitudes de conexión. El nombre y la ubicación del archivo Listener.ora que define el Listener, y el nombre y ubicación del archivo de log del Listener. También, en el Ejemplo mostrados en la figura, el Listener LIST2 “supports no services”. Esto es porque no hay servicios estáticamente registrados en el archivo Listener.ora para escucha. Y ninguna instancia tiene registro dinámico. La figura 6-8 utiliza el comando services para mostrar el estado de los Listener después de una instancia se ha registrado dinámicamente.

En la Figura 6-8, la salida del comando status dice que el Listener llamado LISTENER soporta tres servicios, todos disponibles con la instancia orcl11g:

- Servicio orcl11g.jwlnx1.bplc.co.za es el Servicio de Base de Datos Regular. El Listener puede lanzar sesiones de servidor dedicado contra la instancia. (no se ha lanzado todavía ninguna).

- Servicio orcl11gXDB.jwlnx1.bplc.co.za es el protocolo de servidor de Bases de Datos XML. Este permite a los usuarios conectarse a la Base de Datos con otros protocolos Oracle Net, tales como FTP y HTTP.

- Servicio orcl11g_XPT.jwlnx1.bplc.co.za tiene que ver con Data Guard.

Por default, una Instancia de Base de Datos 11g se registrara los servicios XDP y XPT, pero no pueden ser utilizado sin una considerable configuración adicional. El hecho que los se presentan como “Status Ready” indca que fueron registrados automáticamente por el proceso PMON: El Listener sabe que están listos por PMON dijeron que estaban. Si los servicios ha sido registrados estáticamente, serían marcados como “status unknown”, indicando que mientras están en el archivo Listener.ora pueden de hecho no trabajar.

Para ver todos los comandos de lsnrctl, utilice el comando HELP:

C:\>lsnrctl help

LSNRCTL for 32-bit Windows: Version 11.1.0.4.0 - Beta

on 26-NOV-2007 17:47:16

Copyright (c) 1991, 2006, Oracle. All rights reserved.

The following operations are available

An asterisk (*) denotes a modifier or extended command:

start stop status

services version reload

save_config trace change_password

quit exit set*

show*

En resumen, estos comandos son:

- START Inicia un Listener.

- STOP Detiene un Listener.

- STATUS Ve el status de un Listener.

- SERVICES Ve los servicios de un Listener está ofreciendo (información más completa que Status).

- VERSION Muestra la versión del Listener.

- RELOAD Obliga a un Listener a Leer nuevamente su entrada en Listener.ora.

- SAVE_CONFIG Escribe cualquier cambio realizado en línea al archivo Listener.ora.

- TRACE Habilita Tracing de la Actividad de un Listener.

- CHANGE_PASSWORD Establece un Password para la administración de un Listener.

- QUIT Sale de la Herramienta sin guardas cambios al archivo Listener.ora.

- EXIT Sale de la Herramienta y guarda cambios al archivo Listener.ora.

- SET Establece varias opciones, tales como Tracing y Timeouts.

- SHOW Muestra opciones que tiene que se han establecido para un Listener.

Tenga en cuenta que todos estos comandos debe ser calificados con el nombre de un Listener al que se debe aplicar el comando. Si un nombre no es proporcionado, el comando será ejecutado contra el Listener llamado LISTENER.

CONFIGURANDO SERVICE ALIASES.

Después de haber decidido que método de Resolución de Nombre a utilizar, su siguiente tarea es configurar los clientes para utilizarla. Usted puede hacer esto atraves del Database Control, pero desde el Database Control es un proceso del Lado del Servidor, usted puede solo utilizar para configurar clientes ejecutándose sobre el servidor de Base de Datos. Una alternativa es utilizar el Net Manager. Esta es una utiliza Java independiente, proporcionada con todos los productos cliente de Oracle.

Para lanzar el Net Manager, ejecute netmgr es un promp Unix, o sobre Windows lo encontrara en el menú inicio.

El árbol de Navegación de Net Manager tiene tres ramas. La rama Profile es utilizada para establecer opciones que pueden aplicarse a ambos lados, cliente y servidor de Oracle Net y puede ser utilizado para influenciar el comportamiento de todas la conexiones de Oracle Net. Aquí es donde, por ejemplo, puede configurar un Tracing detallado de las sesiones de Oracle Net. La Rama Service Naming es utilizado para configurar la resolución de nombre del lado del cliente, y la Rama Listeners es utilizado para configurar Database Listeners.

Cuando usted toma la rama Profile como es mostrado en la figura 6-9, usted de hecho está configurando un archivo llamado sqlnet.ora. Este archivo existe en su directorio ORACLE_HOME/network/admin. Es opcional, hay valores por default para cada directiva sqlnet.ora. Pero usted usualmente lo configurara únicamente para seleccionar el método de resolución de nombres.

En la rama Profile, verás todos los nombres de métodos disponibles, con tres (TNSNAMES, EZCONNECT y HOSTNAME) seleccionado por default,

Estos son Local Naming y Easy Connect y Host Naming. Los métodos externos son NIS y CDS. LDAP es Directory Naming. Host Naming es similar a Easy Connect y conservado por compatibilidad atrás.

Entonces usted necesita configurar los services aliases individuales de Oracle Net. Esto es hecho en la rama Service Naming, que en realidad crear o edita el archivo tnsnames.ora Local Naming que reside en su directorio ORACLE_HOME/network/admin. Si es bastante afortunado utilizar el Directory Naming, usted no necesita hacer esto; elija LDAP en el Profile como su método de nombramiento es suficiente.

Una típica entrada en el archivo tnsnames.ora debería ser.

OCP11G =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = jwacer.bplc.co.za)(PORT

= 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = ocp11g)

)

)

Esta entrada, si un usuario entra la cadena de conexión “ocp11g”, resolverá esta a un Listener ejecutándose sobre la dirección jwlnx1.bplc.co.za monitoreando el puerto 1521, y pide al Listener una sesión contra una instancia ofrece el servicio ocp11g, para conectarse con este, utilice.

sqlplus system/oracle@ocp11g

El equivalente con Easy Connect sería:

sqlplus system/manager@jwacer.bplc.co.uk:1521/ocp11g

Para probar la cadena de conexión, utilice la utilidad TNSPING. Esta aceptara una cadena de conexión, localiza los archivos Oracle Net, resuelve la cadena y envía un mensaje al Listener. Si el Listener está ejecutándose y sabe sobre el servicio solicitado, la prueba regresara con éxito, por ejemplo:

C:\> tnsping ocp11g

TNS Ping Utility for 32-bit Windows: Version 11.1.0.4.0 - Beta

on 27-NOV-2007 11

:49:55

Copyright (c) 1997, 2006, Oracle. All rights reserved.

Used parameter files:

D:\oracle\app\product\11.1.0\db_3\network\admin\sqlnet.ora

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)

(HOST = 127.0.0.1)(PORT = 2521))) (CONNECT_DATA = (SERVICE_NAME

= ocp11g)))

OK (40 msec)

Observe que la salida de TNSPING muestra el archive sqlnet.ora utilizado, el método de resolución de nombres utilizado, y luego de detalle de la dirección contactada. La herramienta no va más allá que la escucha, no comprueba si la instancia esta actualmente trabajando.

NOMBRES DE ARCHIVOS Y LA VARIABLE DE ENTORNO TNSADMIN.

Hay tres archivos críticos que participan en la configuración de Oracle Net:

- El Archivo Listener.ora es un archivo de lado del servidor que define los Database Listener. Incluye los protocolos, direcciones y puertos en los que va escuchar solicitudes de conexión entrantes, y (opcionalmente) una lista de código duro de las instancias contra las que lanzara sesiones.

- El archivo tnsnames.ora es un archivo del lado del cliente utilizado para resolución de nombres. Es utilizado por procesos de usuario para ubicar Database Listener. Puede también ser utilizado la instancia misma, para localizar un Listener con quien registrarse.

- El archivo sqlnet.ora es opcional y puede existir (posiblemente con diferentes configuraciones) en la lado del servidor, el lado del cliente o ambos. Contiene los ajustes que se aplican a todas las conexiones y Listeners, tales como reglas de seguridad y incripción.

Los tres archivos Oracle Net por default existen en el directorio ORACLE_HOME/network/admin. Es posible reubicarlos con una variable de entorno: TNSADMIN. Un importante uso de esto es sobre sistemas que tienen varios Oracle Home’s. Esta es una situación muy común. Una típica maquina Servidor Oracle tendrá por lo menos tres Homes: uno para el Agente Enterprise Manager Grid Control, uno para la Instancia de Base de Datos, y una para la instancia de Automatic Storage Management. Los equipos clientes bien pueden tener varios Oracle Homes también, tal vez uno por cada cliente 10g y 11g. Estableciendo la variable TNSADMIN para apuntar a un conjunto de archivos en uno de los directorios de Oracle Home (o incluso en un directorio diferente) significa que en lugar de tener que mantener múltiples conjunto de archivos, solo tiene que mantener un conjunto. Para establecer la variable en Windows, usted puede utilizar el comando SET para configurar una sesión,

set TNSADMIN=c:\oracle\net

Aun que por lo general será mejor establecerlo en el registro, como una llave de valor de string en la rama Oracle Home. En Linux y Unix, la sintaxis variara dependiendo del Shell, pero algo como esto suele ser:

set TNS_ADMIN=/u01/oracle/net; export TNS_ADMIN

Este commando puede ser colocado en el archive profile de cada usuario, o en el /etc/profile donde cada usuario lo recogerá.

DATABASE LINKS

Hasta el ahora, Oracle Net ha sido discutido en el contexto de un usuario conectándose a una Instancia de Base de Datos. Oracle Net puede también ser utilizado para comunicaciones entre Bases de Datos: una sesión de usuario contra una Base de Datos puede ejecutar declaraciones SQL contra otra Base de Datos. Esto se hace atreves de un Database Link. Existen varias opciones para crear Database Link, pero un ejemplo es:

create database link prodscott

connect to scott identified by tiger using 'prod';

Este define una Database Link desde la Base de Datos Actual a una Base de Datos remota identificada por la cadena de conexión PROD. Este Link existe en el esquema del usuario actual, y solo puede ser utilizado por el mismo. Cuando emita una declaración tal como:

select * from emp@prodscott;

su sesión lanzará una sesión contra la Base de Datos remota, iniciará una sesión transparentemente como usuario SCOTT, ejecutara la consulta allí. Los resultados será enviados de regreso a la Base de Datos Local y entonces se los regresará al usuario.

Cualquier declaración SQL puede ser ejecutada atraves de un Database Link, siempre que el esquema el cual el Database Link se conecta tenga permisos apropiados. Por ejemplo, considere este escenario:

Hay una Base de Datos de producción, identificada por la cadena de conexión PROD, que contiene un esquema SCOTT, con dos tablas: EMP y DEPT. Hay un Link a esta Base de Datos definido. Hay también una Base de Datos de Desarrollo, identificada por la cadena de conexión DEV, que contiene también el esquema SCOTT, estas conectado a una Base de Datos TEST, usted necesita actualiza el esquema de desarrollo con los Datos de producción.

Primero, defina un Database Link a la Base de Datos de Desarrollo:

create database link devscott

connect to scott identified by tiger using 'dev';

Luego actualice el esquema de desarrollo para que coincide con el esquema de producción:

truncate table emp@devscott;

truncate table dept@devscott;

insert into dept@devscott select * from dept@prodscott;

insert into emp@devscott select * from emp@prodscott;

commit;

Para comprobar si las filas han sido insertadas en el sistema de producción desde la última actualización de desarrollo y, si así, insertar entonces en Desarrollo, usted puede ejecutar esta declaración:

insert into emp@devscott

(select * from emp@prodscott minus select * from emp@devscott);

Si fuera necesario cambiar el nombre de un departamento, usted puede en ambas Bases de Datos concurrentemente:

update dept@prodscott set dname='SUPPORT' where deptid=40;

update dept@devscott set dname='SUPPORT' where deptid=40;

commit;

Cuando sea necesario, Oracle siempre implementará un commit de dos Fases para asegurar que una transacción (que es una transacción que afecta filas en más de una Base de Datos) distribuida es tratada como una transacción atómica. Los cambios deben ser exitosos en todas las Bases de Datos y ser roll back en toda las Bases de Datos. La consistencia también es mantenida atreves del entorno total.

DENTRO DEL EXAMEN

Oracle Net es configurado con un conjunto de archivos de texto: Listener.ora, sqlnet.ora (si utiliza local naming, como muchos sitios lo hacen) tnsnames.ora. pero hay valores por defecto para cada cosa: en el lado del servidor, el Listener, puede ejecutarse puramente en default, y por medio de Easy Connect, el lado cliente no necesitara ninguna configuración otra.

Herramientas proporcionadas para editar estos archivos son Net Manager, El Net Configuration Assistant, y Enterprise Manager. Experimente con los tres para familiarizarse con la navegación que les rodea y con lo que puede hacer. Y siempre compruebe el contenido de los archivos de texto para ganar una completa comprensión de lo que se ha hecho.

El entorno de servidor compartido es comúnmente utilizado, pero recuerde la alternativa de Servidor compartido.

EJERCICIO 6-1.

CONFIGURE ORACLE NET

En este ejercicio, creara un completo entorno de Oracle Net, utilizando herramientas graficas y de línea de comandos. Donde hay diferencias entre Windows y Linux, estos serán precisados.

1. Crear un directorio que se utilizará para los archivos de configuración de Oracle Net, y establecer la variable TNS_ADMIN para que apunte a esto. No importa dónde está el directorio, mientras el usuario tenga permiso para crear, leer y escribir.

Sobre Linux:

mkdir /u01/oracle/net

export TNS_ADMIN=/u01/oracle/net

Asegúrese que todo el trabajo de ahora en adelante se hace desde una sesión donde se ha establecido la variable.

Sobre Windows.

mkdir d:\oracle\net

Crear y establecer la llave TNS_ADMIN como una variable string en el registro en la rama Oracle Home, esta típicamente será:

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDb1g_home1

2. Comprobar quela variable ha sido leída por medio del comando TNSPING desde el prompt del sistema operativo.

tnsping orcl

Esta regresara un error “TNS-03505: Failed to resolve name” porque no hay ningún archivo en el directorio TNS_ADMIN. Sobre Windows, usted puede necesitar lanzar un nuevo prompt con el comando para recoger el nuevo TNS_ADMIN valor del registro.

3. Inicie el Net Manager. Sobre Linux, ejecute netmgr desde el prompt de sistema operativo; sobre Windows, láncelo desde el menú inicio. La barra de titulo de la ventana del Net Manager mostrará la unicacion de los archivos Oracle Net. Si este no es el nuevo directorio, entonces la variable TNS_ADMIN no ha sido establecida correctamente.

4. Crear un nuevo Listener: Expandir la Rama Local del árbol de navegación, acentuar Listeners, y dar clic al +.

5. Ingresar el nombre del Listener, NEWLIST, y dar clic OK.

6. Dar Clic en Agregar Direcciones.

7. Para Address 1, Elija TCP/IP como el protocolo e ingrese 127.0.0.1 como el Host, 2521 como el puerto. La Ilustración que sigue muestra el resultado.

8. Crear un nuevo nombre de servicio: Seleccionar Service Naming en el Árbol de navegación, y dar clic en el signo +.

9. Ingrese NEW como el nombre de Servicio Net, y clic en siguiente.

10. Seleccione TCP/IP como el protocolo, y clic en siguiente.

11. Ingresar 127.0.0.1 como el nombre de host y 2521 como el puerto y clic en siguiente.

12. Ingrese SERV1 como el nombre de Servicio, y clic siguiente.

13. Clic finalizar. Si usted trata de probar, fallara en este momento. La ilustración que sigue muestra los resultados.

14. Guardar la configuración mediante File y Save Network Configuration. Esto creara archivos Listener.ora y tnsnames.ora en el Directorio TNS_ADMIN.

15. Utilice un Editor para comprobar los dos archivos. Que se verá así:

LISTENER.ORA:

NEWLIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 2521))

)

TNSNAMES.ORA:

NEW =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT =

2521))

)

(CONNECT_DATA =

(SERVICE_NAME = SERV1)

)

)

16. Desde un prompt de sistema operativo, inicie el Listener con lsnrctl start newlist.

17. Desde un prompt de sistema operativo, compruebe la cadena de conexión con tnsping new.

18. Conéctese a su Base de Datos utilizando autentificación de sistema operativo, pasando por alto cualquier Listener, con sqlplus / as sysdba.

19. Establezca los parámetros service_names y local_listener para la instancia en ejecución (memoria solamente, no el archivo de parámetros) y registrar el nuevo nombre de servicio con el nuevo Listener:

alter system set service_names=serv1 scope=memory;

alter system set local_listener=new scope=memory;

alter system register;

20. Desde un prompt de sistema operativo, confirme que el nuevo servicio está registrado con el nuevo Listener con lsnrctl services newlist.

21. Confirme que el nuevo entorno de red es funcional por medio del Login sobre:

sqlplus system/oracle@new

22. Hay un ejercicio opcional 6-2sobre Servidor Compartido a venir. Si usted no se propone hacer eso, poner en orden su entorno ahora:

Reinicie la Base de Datos para regresar los parámetros cambiados en el Paso 19 a sus valores por default.

Detenga el Listener con lsnrctl stop newlist.

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