Tradueix

lunes, 8 de noviembre de 2010

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

lunes, 19 de julio de 2010

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...

Oracle Wars © 2008. Template by Dicas Blogger.

TOPO