Pérdida de conexión de todos los usuarios conectados a INTERBASE
 

Hola Foristas :

Este es un mail de ¡SOCORRO!.

Resulta, que cuando estamos trabajando normalmente contra la base de datos (Interbase 6.5), perdemos todos la conexión con la base de datos. Tenemos que volver a ejecutar el programa para seguir trabajando, el servidor sigue funcionando con normalidad.
El servidor es un Linux Red Hat 8.0, y en el fichero de registro de errores de Interbase, tengo lo siguiente (cada vez que perdemos la conexion) :

Server1 (Client) Tue Jun 10 12:02:39 2003
/opt/interbase/bin/ibguard: bin/ibserver terminated abnormally (-1)


Server1 (Client) Tue Jun 10 12:02:39 2003
/opt/interbase/bin/ibguard: guardian starting bin/ibserver


Server1 (Server) Tue Jun 10 12:02:39 2003
Server: setting SWEEP_QUANTUM to 10, USER_QUANTUM to 100 and SWEEP_YIELD
_TIME to 1 ms

De aquí, hemos deducido, que el servidor de interbase, al encontrar un error, se resetea, y por eso perdemos todos la conexión.


He mirado el manual, hemos verificado si hay algun ordenador con alguna tarjeta de red en mal estado (estan todas bien, incluida la del servidor). Nos hemos conectado por grupos, individualmente y por separado, descartando que sea un ordenador concreto. En pocas palabras, ya no sabemos que puede ser.

Creemos, que hay algo en el servidor que no está bien configurado, pero no sabemos que.

Si hay alguien que pueda ayudarnos, se lo agradeceremos muchísimo.

Gracias a todos.

Tiene toda la pinta de ser una consulta mal hecha la que te está dejando el servidor "tieso". Mira a ver si falla siempre al hacer una determinada tarea.... quizás eso te dé una pista

A mí me pasaba lo mismo, y tras muchas vueltas, descubrí que me ocurría al ejecutar una sentencia donde utilizaba una vista
cuya construcción era algo compleja, y además creo recordar que
a su vez hacía referencia a una tabla a la que también se hacía referencia en la orden inicial, creando algo de "recursividad".

Esta misma en ORACLE me funcionaba perfectamente , por lo que sé que la estructura estaba bien. Además Interbase no da ningún error, simplemente aborta.

La solución fue rehacer la sentencia utilizando UNION y partiendo la vista en dos mas sencillas, de manera que no hubiese un nivel demasiado profundo de sentencias SELECT.

Pero esto es normal, quien no ha tenido que rehacer sentencias SQL para que funcionen en uno u otro servidor, u optimizarlas cuando ha crecido la BD, etc..

Hola, como te han dicho los compañeros, el problema estará en alguna vista, o trigger.

Hace un mes mas o menos tuve el mismo problema y mes costo casi 2 dias dar con el problema. Te mando la url para que lo consultes.

Suerte.

http://www.clubdelphi.com/foros/show...=&threadid=870

Tras estar analizando la situación del problema, hemos llegado a la conclusión de que se resetea el servicio de interbase cuando estamos en fase de diseño (compilando procedimientos, triggers, creando campos, etc), ya que tenemos clientes que estan trabajando con la misma base de datos, y con un numero bastante importante de usuarios, y esto no les ocurre, salvo un dia que compilamos un procedimiento.

Si fuera alguna instrucción, o algún select algo complicado, ocurriria siempre que alguien lo ejecuta, pero no es así, sólo ocurre cuando alguien está en modo diseño.

Si alguien tiene alguna idea al respecto, le agradecería mucho su ayuda.


Gracias.

Después de muchas pruebas, después de tantas páginas consultadas en internet, después de muchas horas leyendo, buscando, reinstalando y sufriendo, el problema está localizado.

Interbase se reiniciaba por culpa de las UDF's instaladas.

Tan simple como comentar los triggers y stored procedures que hacian llamadas a las UDF's, y desinstalarlas, para no volver a producirse el reseteo del servidor.

Al instalarlas de nuevo, en menos de 5 minutos, el sistema, se reinicio de nuevo.

Supongo, que será alguna UDF que tendrá algún error, según he podido leer en páginas de borland y demás, puede que se produzca por utilizar asignaciones de memoria que no soportan el multithreading, aunque hasta el momento no lo he detectado.

Simplemente quería poner este comentario por si alguien mas tiene este mismo problema, a la vez, que agradecer al foro su colaboración.

Saludos, foristas.

ACK

Lamentablemente lei este hilo cuando ya has encontrado el problema, ya que si lo hubiera leido antes te hubiera aconsejado eso precisamente, yo tuve un error igual...

El asunto es que yo desarrolle unas udf personales, y funcionaban muy en Windows, cuando cambiamos a un servidor linux las udf las tuve que recompilar en kylix y aparentemente funcionaban bien, pero derepente se apagaba el servidor de interbase, como tu despues de dias y pruebas encontre que era una funcion que manejaba cadena de carateres y que no funcionaba bien en linux (ya que muchas cosas no las puedes manejar igual que windows), rehice la funcion, compile, y no volvio a dar problema.

Probablemente a mi me ocurra la mismo. No me he parado a repasar el código fuente de las udf's que desarrollé, ya que sólo las utilizo en un par de llamadas, y que he sustituido por código de base de datos, aunque, lo que antes era una línea ahora son bastantes mas. El motivo, es que me falta tiempo, pero, está en mi lista de tareas el repasarlas.

Si encontrara alguna cosa mas, lo publicaría en este foro, por si puede ayudar a alguien mas.

Gracias hecjona.

Saludos a todos.

ACK

Algunas cosas que cambie son:

en windows
Function NombreFuncion..... stdcall;
en Linux
Function NombreFuncion..... cdecl; export;


En windows manejaba variables string y despues las convertia a pchar en linux las cambien todas las variables a pchar.
Ej:
En Windows
Var sCadena : string;
sCadena := 'cadena';
............................
result := ib_util_malloc(10);
result := pchar(sCadena);
En Linux
Var sCadena : pchar;
sCadena := ib_util_malloc(10);
sCadena := 'cadena';
..............................
result := sCadena;

Una sugerecia que te hago es que pruebes las funciones en un programa de kylix para que veas si realmente la funcion esta haciendo lo que deberia de hacer. ;)