TNSNAMES y DBLINKS (Î)

El tema de la creación de un DATABASE LINK és una de esas tantas cosas que muchas veces configuramos sin saber siquiera que estamos haciendo, echando mano a la socorrida táctica del copy&paste.

Solo cuando falla alguna cosa nos damos cuenta de que necesitamos saber mas sobre el tema.

Un DATABASE LINK és un recurso de Oracle (muy preciado) que nos permite conectar bases de datos diferentes de forma sencilla.

Antes de entrar en la creación de un dblink propiamente dicho como objeto lógico de la bbdd intentaremos entender como funciona la comunicación del servidor Oracle.

Tendremos que prestar atención a los siguientes componentes:

• Tenemos una BBDD target a la cual queremos acceder. La llamaremos dbtarget.
• Tenemos una BBDD origen DESDE la cual queremos acceder a datos de la dbtarget. La llamaremos dborigen.
• El fichero tnsnames.ora en la bbdd origen. Contiene las direcciones de las bases de datos a la que podremos acceder.
• El fichero de configuración listener.ora i el proceso asociado lsnrtcl que escucha las peticiones de conexión procedentes de los clientes y gestiona el tráfico de estas peticiones.
• El DBLINK propiamente dicho. És un objeto a nivel lógico de la base de datos que podremos utilizar en nuestro código SQL para acceder a tablas de la otra bbdd y trabajar con ellas como si estuvieran en nuestra base de datos dborigen.
• El software SQL*Net y su fichero de configuración SQLnet.ora. Este software controla las comunicaciones de red del servidor Oracle y permite acceso remoto a los datos entre programas y la bbdd, o bien, entre varias bases de datos Oracle. Su configuración se guarda en el fichero de texto SQLNet.ora que se puede editar directamente o mediante un asistente gráfico.

Para el caso que nos ocupa podemos obviar el SQL*Net, pues entendemos que está previamente configurado y funcionando (si no fuera así no funcionaria el acceso a la bbdd por red y no estariamos intentando crear un dblink sino, a buen seguro tendriamos otras prioridades/urgencias). Tan solo mencionar que en SQLNet se define entre otras cosas, la forma en la que un cliente se comunicará con nuestra base de datos. 

Dos de estas posibles formas són:

• TNSNAMES: Mediante un fichero de configuración tnsnames.ora en el cliente.
• EZCONNECT: Conectando directamente con la base de datos Oracle mediante el protocolo TCP/IP. Esta forma elimina la necesidad de buscar nombres de servicios de red. Permite a los clientes conectarse solo con la IP, el puerto, el nombre del servicio, el usuario y el password. Todo ello en una url de este estilo:
  username/password@[//]host[:port][/service_name]
  Este modo nos permite, por ejemplo, configurar conexiones a la bbdd en nuestro SQLDeveloper en local o en nuestra aplicación Java.

Pues bien, en este fichero definimos cual de estas formas se permitiran y que prioridad buscará. Este és el parámetro:

NAMES.DIRECTORY_PATH = (TNSNAMES, EZCONNECT)

El metodo TNSNAMES o también llamado Local Naming Method requiere de un fichero de configuración tnsnames.ora que se aloja en:

• cualquier cliente que se comunique de esta forma con la bbdd.
• en el propio servidor de base de datos Oracle cuando este funcione como cliente (o sea siempre, si  queremos ejecutar un sqlplus en el propio servidor o queremos conectar este server Oracle con otro, via dblinks). Encontraremos este fichero alojado en la carpeta $ORACLE_HOME/network/admin.

Por ahora ya hay suficiente. En el próximo post entraremos en el fichero tnsnames.ora y veremos como se usa.

Hasta pronto.

Crear un usuari de consulta

El que en altres entorns podria resultar senzill, crear un usuari de consulta, en el mon d'Oracle no és obvi.
Per qué?

Doncs un usuari, no és només una connexió, si no que va lligat irremediablement a un esquema de la bbdd. Quan crees un usuari, crees per força un esquema associat, o sigui, un propietari d'una sèrie d'objectes que podrà crear (o no) aquest usuari.
Però molts cops el que volem és una entrada, una visió diferent a unes dades que ja existeixen, a uns objectes que són d'un altre propietari. I a més volem que la forma d'accés a aquests objectes sigui diferent de la que té el propietari, evidentment, si no ja ens valdria el usuari propietari. El cas més comú deu ser el desig de crear un usuari que només pugui consultar les dades d'un esquema però sense esborrar.
Una aproximació a aquest problema seria:

1. crear un esquema nou, per exemple UCONSULTA.
2. des de l'esquema on tenim les dades (p.ex: UPROPIETARI) donar accés de consulta a totes les taules: GRANT SELECT ON to UCONSULTA;
3. quan entrem amb el usuari UCONSULTA, podem fer select * from UPROPIETARI.

Això està be, però te alguns inconvenients:

• el que faci anar l'usuari UCONSULTA ha de saber a priori el nom de les taules que vol accedir, doncs veurà els noms enlloc.
• s'ha de fer el GRANT de tots els objectes un a un o fer un script que ho faci automàticament.

Per al primer inconvenient, la sol·lució (parcial) és, al crear l'usuari UCONSULTA, afegir el següent privilegi:

• GRANT SELECT ANY DICTIONARY TO UCONSULTA

Això permet a l'usuari UCONSULTA accedir al diccionari de dades, lo qual li permet veure els noms de les taules dels altres esquemes de la bbdd, però de tots, no només del que voliem. Ja deia que era una sol·lució parcial...

Per al segon inconvenient, una altra sol·lució (parcial) és, al crear l'usuari UCONSULTA, afegir el següent privilegi:

• GRANT SELECT ANY TABLE TO UCONSULTA

Això permet a l'usuari UCONSULTA veure el contingut de TOTES les taules de tots els esquemes de la BBDD. Si això no suposa cap problema doncs és una via possible. (Ja deia que era una sol·lució parcial).

No m'agrada cap de les sol·lucions, la veritat.

p.d.: no em faig responsable dels problemes de seguretat que es puguin causar.

Redo log (I)

Ya decía yo que me tocaba luchar en todas las batallas. Ahora el "enemigo" se llama Redo log. Ya dicen que para vencer a tu enemigo hay que entenderlo. Así que después de empaparme con la documentación online de Oracle voy a intentar escribirlo a mi manera para ver si lo recuerdo.
Todo ha empezado cuando la bbdd ha ralentizado su funcionamiento hasta límites sospechosos. He acudido al fichero que vive en /opt/app/oracle/admin//bdump/alert_.log y he visto el siguiente texto:

Thread 1 advanced to log sequence 19962
Current log# 11 seq# 19962 mem# 0: /opt/app/oracle/oradata//redo1.log
Thread 1 cannot allocate new log, sequence 19962
Checkpoint not complete

¿Que está pasando?
Algún problema con los redo log, eso seguro.

Los redo log son dos o más ficheros pre asignados que guardan los cambios que se van produciendo en la base de datos a medida que ocurren. Cada instancia de la base de datos tiene sus redo log para proteger la bbdd en caso de fallo de instancia.

¿Y porque aparece por aquí la palabra Thread?
En una configuración típica solo hay una instancia para una misma base de datos, pero en un entorno de cluster de Oracle, hay más de una instancia para una misma base de datos y cada instancia tiene su propio Thread de redo logs para evitar un atasco si usaran los mismos redo log.

¿Pero que contienen los ficheros redo log?
Los ficheros redo log contienen redo records (registro de redo) y así me quedo la mar de ancho (¿qué van a tener sino los ficheros sino registros?). Bueno, un redo record o redo entry (entrada de redo) a su vez contiene algo llamado change vector (vector de cambio) que es una descripción de un cambio hecho en un solo bloc de la bbdd. Estos registros contienen la información necesaria para reconstruir todos los cambios hechos en una bbdd incluido los segmentos de rollback.

¿Cual es el ciclo de vida de un redo log?
Como casi todo en este loco mundo de la informática empieza en la memoria. Las redo entries (entradas de redo) causadas por algún cambio en la bbdd originado por alguna sentencia SQL (INSERT, UPDATE, DELETE, CREATE, ALTER, o DROP) se generan en el espacio de memoria del usuario y procesos de Oracle las copian al redo log buffer del SGA. Las redo entries toman espacio secuencial del redo log buffer. Que por cierto, como casi todo en Oracle, el tamaño de este buffer se puede definir ajustando el parámetro de inicialización LOG_BUFFER. Es importante ajustar bien el tamaño de este buffer. A mayor tamaño se reducen las operaciones I/O aumentando el rendimiento.

Copiar a disco.
Cuando se produce un commit, es decir, se finaliza la transacción, el proceso de Oracle LGWR copia los redo records del redo log buffer, ojo, solo los correspondientes a la transacción que se ha cerrado, al fichero de redo log en el disco.
Sin embargo, no es necesario que esto suceda solo cuando se produzca un commit. También se realiza el proceso cuando:

• se ha llenado el buffer de redo log
• se ha hecho commit de otra transacción

En este caso se copia todo el contenido del buffer de redo log a disco, incluso aquellas entradas de las que aún no se ha realizado un commit. Estas entradas serán permanentes si se produce un commit en posterioridad.
Sigamos el curso normal. Acabamos de hacer un commit de una transacción. El proceso LGWR graba las redo entries en el fichero de redo log y le asigna un número llamado System Change Number (SCN) que identifica unequivocamente cada transacción dentro del fichero de redo log. Solo cuando absolutamente todas las entradas de redo log de la transacción están a salvo guardadas en nuestro fichero, es cuando se envía el aviso al usuario de que se ha realizado un commit con éxito.

Redo log en disco.

El redo log está compuesto por 2 ficheros como mínimo, pero pueden ser mas. ¿Porque 2? Porque se tiene que garantizar que mientras uno esté activo el otro pueda estar siendo archivado, o más bien al revés, garantizamos que mientras uno está siendo archivado (siempre y cuando estemos en modo ARCHIVELOG del cual ya hablaremos más tarde) haya otro como mínimo que esté activo.
El proceso LGWR guarda en los ficheros de redo log de un modo circular. Es decir, empieza por el primero y cuando este está lleno, continua por el siguiente disponible. En cuanto ha llenado el último disponible, vuelve a empezar por el primero y empieza el ciclo de nuevo.
El comportamiento cuando cambia de un fichero a otro varía en función de si tenemos activado o no el modo ARCHIVELOG. Si lo tenemos activado, al saltar a otro fichero, el que abandonamos se archiva en disco en un espacio habilitado a tal efecto.

(Continuará...)

links:
Managing Oracle redo logs
Oracle Concepts - Online redo log management
http://kerneltrap.org/node/14286
AskTom

TNS-01189: The listener could not authenticate the user

Problemes amb el Listener. Just acabat d'instal·lar Oracle 11g no podem connectar. Hi ha problemes amb el listener.
executem lsnrtcl.
A la linia de comanda executem status i ens respon:
TNS-01189: The listener could not authenticate the user
si l'intentem engegar amb start , ens respon que ja està engegat.
si l'intentem apagar ens respon insistentment:
TNS-01189: The listener could not authenticate the user
Algun problema amb l'autenticació? Mai hem ficat cap password per al listener...
Busquem a internet el famós error i ens trobem que no som els únics que l'han sorfert. Però les solucions no son gaire bones.
Alguns especulen amb la mala configuració de les variables d'entorn:
http://forums.oracle.com/forums/thread.jspa?threadID=369170
http://forums.oracle.com/forums/thread.jspa?threadID=1028651&tstart=135
Veiem que diu el manual:
http://www.error-code.org.uk/view.asp?e=oracle-tns-01189

Oracle Error :: TNS-01189

The listener could not authenticate the user

Cause

The user attempted to issue a privileged administrative command, but could not be successfully authenticated by the listener using the local OS authentication mechanism. This may occur due to one of the following reasons:
1. The user is running a version of LSNRCTL that is lower than the version of the listener.
descartat: acabo d'instal·lar oracle de zero, completament i amb una sola copia integra.

2. The user is attempting to administer the listener from a remote node.
descartat: L'executo des d'un terminal directe a la màquina via ssh , com sempre.

3. The listener could not obtain the system resources needed to perform the authentication.
descartat: Hi ha recursos suficients i tots els directoris tenen els permisos adequats.



4. The local network connection between the listener and LSNRCTL was terminated unexpectedly during authentication message exchange, such as if LSNRCTL program was suddenly aborted.
descartat: No s'ha produït tal incident.


5. The communication between the listener and LSNRCTL is being intercepted by a malicious user.
descartat: No existeix tal criatura. El sistema no està en producció ni connectat a l'exterior.



6. The software that the user is running is not following the authentication protocol, indicating a malicious user.
descartat: no comencem amb paranoies...

Action

Make sure that administrative commands are issued using the LSNRCTL tool that is of a version equal or greater than the version of the listener, and that the tool and the listener are running on the same node. You can issue the VERSION command to find out the version of the listener. If a malicious user is suspected, use the information provided in the listener log file to determine the source and nature of the requests. Enable listener tracing for more information. If the error persists, contact Oracle Support Services.
Confirmat: la versió és la mateixa.

Sembla un tema de seguretat amb el listener, però no hi he assignat cap password ni cap usuari i en les anteriors versions no ha calgut mai. Provo de treure o desactivar el sistema de password del listener. Res...
Es frustrant, no em deixa apagar el listener ni tampoc engegar-lo perquè ja esta engegat....
Desprès de dues reinstal·lacions d'Oracle per assegurar-nos i unes quantes hores gastades buscant a Google sense resultat, penso amb en el nom del host. I si...?
Efectivament, canvio el nom del host definit a listener.ora i al tnsnames.ora per la IP de la màquina i voilà!!!  Funciona!!!
Sembla que no podia resoldre el nom del host. Probablement s'ha d'afegir el nom en algún fitxer de configuració del sistema per a que el reconegui o algo similar, però de moment, amb la IP ja funciona.
Continuaré investigant...

Connectar ORACLE i SQL Server

Objectiu final: Accedir mitjançant un DBLINK d'Oracle a una altra bbdd SQLServer.

Material:

• Fedora Core 5 o superior
• Oracle 10g (10.2.0) per a Linux
• SQL Server 2000

Necessitarem:

• unixODBC
• FreeTDS

Instal·lar el unixODBC

1. Baixar el unixODBC d'aquesta adreça
2. copiar el fitxer unixODBC*.tar.gz a un directori de treball /home/oracle per exemple
   
3. # gunzip unixODBC*.tar.gz
4. # tar xvf unixODBC*.tar
5. # cd unixODBC*
   
6. # ./configure –prefix=/usr/local –enable-gui=no
7. # make
8. # make install

Instal·lar el driver FreeTDS

1. Baixar el driver de www.freetds.org. download
2. copiar el fitxer a un directori de treball
3. # tar -xvzf freetds-stable.tgz
4. # ./configure –with-tdsver=8.0 –with-unixODBC=/usr/local
5. # make
6. # make install

Configurar el TDS

1. Afegir al fitxer freetds.conf que es trobarà segurament a /usr/local/etc:

[test] --> nom de la connexió
host =
port = (1433 sòl ser el de SQL Server>
tds version = 8.0 (SQL Server 2000 és el 8.0 http://www.freetds.org/userguide/choosingtdsprotocol.htm)

Configurar el unixODBC

1. Obrir el fitxer obdcinst.ini que hauria d'estar a /usr/local/etc i modificar-lo:
   [TDS]
   Description = FreeTDS driver
   Driver = /usr/local/lib/libtdsodbc.so
   Setup = /usr/local/lib/libtdsodbc.so
   Trace = Yes
   TraceFile = /tmp/freetds.log
   FileUsage = 1
2. Obrir el fitxer odbc.ini que també hauria d'estar a /usr/local/etc i modificar-lo:
   [test]
   Driver = TDS
   Description = MS SQL Test
   Trace = Yes
   TraceFile = /tmp/mstest.log
   Servername = test
   Database =
   Port = 1433
   

Provar la connexió a la bbdd

1. Executar al shell la següent comanda:
   

   # isql -v   

2. +---------------------------------------+
   | Connected!                            |
   |                                       |
   | sql-statement                         |
   | help [tablename]                      |
   | quit                                  |
   |                                       |
   +---------------------------------------+
   SQL> select * from "sysObjects";
   Si això funciona vol dir que ens hem connectat correctament

Configurar Oracle per a connectar amb MS SQLServer

1. Crear un fitxer init.ora al directori $ORACLE_HOME/hs/admin on seria el nom de la connexió nova. Afegim en aquest fitxer les dades que apunten a la nostra connexió:
   
   • HS_FDS_CONNECT_INFO = el nom de la font de dades odbc (en el nostre cas test). Ha de coincidir amb el DSN
     
   • HS_FDS_SHAREABLE_NAME = el nom i la ruta del driver manager o driver
   • ODBCINI = el nom i ruta del fitxer de configuració del ODBC
     
   # This is a sample agent init file that contains the HS parameters that are
   # needed for an ODBC Agent.
   
   #
   # HS init parameters
   #
   HS_FDS_CONNECT_INFO = test
   HS_FDS_TRACE_LEVEL = 4
   HS_FDS_TRACE_FILE_NAME = /tmp/freetds.trc
   HS_FDS_SHAREABLE_NAME = /usr/local/lib/libodbc.so
   
   #
   # ODBC specific environment variables
   #
   set ODBCINI=/usr/local/etc/odbc.ini
   
   
   #
   # Environment variables required for the non-Oracle system
   #
   

Modificar el fitxer listener.ora

1. Afegir un listener al fitxer de configuració listener.ora que trobem al directori $ORACLE_HOME/network/admin:
   SID_LIST_test =
   (SID_LIST =
   (SID_DESC =
   (SID_NAME = test)
   (ORACLE_HOME =)
   (PROGRAM = hsodbc)
   (ENVS=LD_LIBRARY_PATH=/lib:)
   )
   )
   
   test =
   (DESCRIPTION_LIST =
   (DESCRIPTION =
   (ADDRESS_LIST =
   (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1522))
   )
   (ADDRESS_LIST =
   (ADDRESS=(PROTOCOL=ipc)(KEY=PNPKEY))
   )
   )
   )
   
2. Desprès de modificar el fitxer. Engenguem el nou listener amb la comanda:
   # lsnrctl start test

Modificar el tnsnames.ora

1. Afegir la entrada nova també al tnsnames.ora:
   test =
   (DESCRIPTION=
   (ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT=1522))
   (CONNECT_DATA=
   (SERVICE_NAME=test)
   )
   (HS=OK)
   )
   
2. Proveu la nova connexió amb la comanda:
   # tnsping test

Crear el nou database link

1. Connectar-se a Oracle amb un usuari
   # sqlplus system@
2. SQL> create database link sqlserverdb connect to user identified by password using 'test';
3. I per a comprovar que ha funcionat:
   SQL> select * from sysobjects@sqlserverdb;
4. Si la select retorna resultats és que ho hem fet correctament, evidentment.
   

startup automático de las bbdd de oracle

En Linux, una vez creado el proceso en /etc/init.d/ para encender el oracle automaticamente al reiniciar la màquina, no sus olvideis de modificar el fichero /etc/oratab. En el se encuentra una lista de las bbdd que tenemos en la máquina y si queremos que se enciendan o no automaticamente al reiniciar el sistema de la siguiente forma:

:/opt/app/oracle/product/10.2.0/db_1:Y
:/opt/app/oracle/product/10.2.0/db_1:N

Simplemente cambiando Y o N se monta la base de datos escogida al reiniciar Oracle.

ORA-12500

Las conexiones se estan multiplicando y el uso en general de la bbdd ha empezado a crecer. Empiezan a atacar la bbdd por todas partes. En algunos intentos de conexión ha aparecido el fastidioso error:

ORA-12500: TNS:listener failed to start a dedicated server process

En el sistema los procesos de oracle (ps -A) eran numerosos. Lo curioso és que al principio las conexiones desde SQLDeveloper funcionaban, en cambio las de un cliente desarrollado en NetBeans no. Desconozco la razón de esta discriminación.

Rastreando por internet he llegado a la web donde escribe este señor al que apodaré Boris Yelsin (que por cierto, se merece el cielo y mucho mas) y he comprobado el parámetro de procesos. Según el init.ora o segun el TOAD o segun el comando "show parameter process" tenia 150 procesos como máximo.

Despues he comprobado en el fichero /opt/u01/app/oracle/admin//bdump/alert_.log

para ver si hay algún error mas y he encontrado este:

kkjcre1p: unable to spawn jobq slave process

Buscando en internet al respecto como siempre llegamos al mismo sitio (Boris Yelsin otra vez): http://www.dba-oracle.com/t_kkjcre1p_unable_to_spawn.htm

Efectivamente parece que la máquina no tiene suficientes recursos. La cuestión és si el problema es de la RAM o bien de la limitación del parámetro de Oracle para generar mas procesos para cada nueva conexión. Según parece hay tres posibilidades:

1. El parámetro process es demasiado pequeño
2. La RAM de la máquina es demasiado limitada
3. El job_queue_processes es 0
   

Creo que de la RAM no es problema así que aumentaré el valor del parámetro. Para ello:

1. entrar en: sqlplus /nolog
2. connect sys as sysdba;
3. ALTER SYSTEM SET processes=500 SCOPE=SPFILE;
   (el valor inicial era 150. Scope=spfile hace que el cambio afecte al spfile, con lo que al arrancar la bbdd de nuevo tendria que canviarse. Ojo, NO afecta al pfile, o sea, al init.ora, con lo que si queremos cambiarlo en el init.ora hay que hacerlo en el fichero y convertir el init.ora en un spfile. Otro rato veremos como hacer esta operación)
4. shutdown immediate (hay que bajar la bbdd para que tenga efecto el cambio)
5. startup
6. show parameter process; --para comprobar que realmente ha cambiado.

La lucha sigue!!!