Llevamos trabajando en mi empresa con firebird 6 meses con una nueva
aplicación de gestión y contabilidad.
El caso es que en nuestro primer cliente ya hemos tenido que montar un
proceso nocturno que realice
un backup ->restore de la base de datos, pues sino realizamos este proceso
al cabo de 1 semana
no se mueve ni el cursor de la aplicación, una ruina.

Alguien ve esto serio. Con SQL Server tambien haceis esto de limpiar la base
de datos.

Buscamos información de posibles configuraciones de la base de datos
(tamaños de pagina, caché, etc..)
y nadie nos resuelve problemas. Unos dicen que subamos el tamaño de pagina
otros que no. Esto es una mierda y creo que nadie tiene ni puta idea de
FireBird. Por lo menos en España.

Si alguien se sabe el "truco" ese truco que hace que vaya como una bestia
el servicio se le agradeceria.


Range Walker nosotros tenemos una Red Hat en un Biprocesador Fujitsu
nuevecito para 8 puestos
de trabajo. Funciona bien es un mounstro, pero claro cuando los 8 se ponen a
joder la marrana
se satura todo el sistema. Con Windows constatamos una perdida de velocidad
considerable.

Por otro lado hay que tener en cuenta el as consultas SQL todo el tema ese
de los PLANES.
A veces de tomar un PLAN a otro se te van varios minutos.

Eso es otra... el que me envie un PDF de como funcionan los PLANES de forma
extensa le doy un beso.
Gracias.

¿Estás seguro de tener creados todos los índices correctamente? (a partir de
1 Gb sí que es recomendable un backup/restore cada semana pero si no es tan
grande la BD yo creo que debieras encaminar las pesquisas por otro lado: los
indices pe)



Saludos

"R.B.N" <raulbou***ono.com> escribió en el mensaje
news:98pbc.2865$9c.188680***news.ono.com...
> Llevamos trabajando en mi empresa con firebird 6 meses con una nueva
> aplicación de gestión y contabilidad.
> El caso es que en nuestro primer cliente ya hemos tenido que montar un
> proceso nocturno que realice
> un backup ->restore de la base de datos, pues sino realizamos este proceso
> al cabo de 1 semana
> no se mueve ni el cursor de la aplicación, una ruina.
>
> Alguien ve esto serio. Con SQL Server tambien haceis esto de limpiar la
base
> de datos.
>
> Buscamos información de posibles configuraciones de la base de datos
> (tamaños de pagina, caché, etc..)
> y nadie nos resuelve problemas. Unos dicen que subamos el tamaño de
pagina
> otros que no. Esto es una mierda y creo que nadie tiene ni puta idea de
> FireBird. Por lo menos en España.
>
> Si alguien se sabe el "truco" ese truco que hace que vaya como una bestia
> el servicio se le agradeceria.
>
>
> Range Walker nosotros tenemos una Red Hat en un Biprocesador Fujitsu
> nuevecito para 8 puestos
> de trabajo. Funciona bien es un mounstro, pero claro cuando los 8 se ponen
a
> joder la marrana
> se satura todo el sistema. Con Windows constatamos una perdida de
velocidad
> considerable.
>
> Por otro lado hay que tener en cuenta el as consultas SQL todo el tema ese
> de los PLANES.
> A veces de tomar un PLAN a otro se te van varios minutos.
>
> Eso es otra... el que me envie un PDF de como funcionan los PLANES de
forma
> extensa le doy un beso.
> Gracias.
>
>
>
>
>
>
>
>

¿Estás seguro de tener creados todos los índices correctamente? (a partir de
1 Gb sí que es recomendable un backup/restore cada semana pero si no es tan
grande la BD yo creo que debieras encaminar las pesquisas por otro lado: los
indices pe)



Saludos

"R.B.N" <raulbou***ono.com> escribió en el mensaje
news:98pbc.2865$9c.188680***news.ono.com...
> Llevamos trabajando en mi empresa con firebird 6 meses con una nueva
> aplicación de gestión y contabilidad.
> El caso es que en nuestro primer cliente ya hemos tenido que montar un
> proceso nocturno que realice
> un backup ->restore de la base de datos, pues sino realizamos este proceso
> al cabo de 1 semana
> no se mueve ni el cursor de la aplicación, una ruina.
>
> Alguien ve esto serio. Con SQL Server tambien haceis esto de limpiar la
base
> de datos.
>
> Buscamos información de posibles configuraciones de la base de datos
> (tamaños de pagina, caché, etc..)
> y nadie nos resuelve problemas. Unos dicen que subamos el tamaño de
pagina
> otros que no. Esto es una mierda y creo que nadie tiene ni puta idea de
> FireBird. Por lo menos en España.
>
> Si alguien se sabe el "truco" ese truco que hace que vaya como una bestia
> el servicio se le agradeceria.
>
>
> Range Walker nosotros tenemos una Red Hat en un Biprocesador Fujitsu
> nuevecito para 8 puestos
> de trabajo. Funciona bien es un mounstro, pero claro cuando los 8 se ponen
a
> joder la marrana
> se satura todo el sistema. Con Windows constatamos una perdida de
velocidad
> considerable.
>
> Por otro lado hay que tener en cuenta el as consultas SQL todo el tema ese
> de los PLANES.
> A veces de tomar un PLAN a otro se te van varios minutos.
>
> Eso es otra... el que me envie un PDF de como funcionan los PLANES de
forma
> extensa le doy un beso.
> Gracias.
>
>
>
>
>
>
>
>

¿Estás seguro de tener creados todos los índices correctamente? (a partir de
1 Gb sí que es recomendable un backup/restore cada semana pero si no es tan
grande la BD yo creo que debieras encaminar las pesquisas por otro lado: los
indices pe)



Saludos

"R.B.N" <raulbou***ono.com> escribió en el mensaje
news:98pbc.2865$9c.188680***news.ono.com...
> Llevamos trabajando en mi empresa con firebird 6 meses con una nueva
> aplicación de gestión y contabilidad.
> El caso es que en nuestro primer cliente ya hemos tenido que montar un
> proceso nocturno que realice
> un backup ->restore de la base de datos, pues sino realizamos este proceso
> al cabo de 1 semana
> no se mueve ni el cursor de la aplicación, una ruina.
>
> Alguien ve esto serio. Con SQL Server tambien haceis esto de limpiar la
base
> de datos.
>
> Buscamos información de posibles configuraciones de la base de datos
> (tamaños de pagina, caché, etc..)
> y nadie nos resuelve problemas. Unos dicen que subamos el tamaño de
pagina
> otros que no. Esto es una mierda y creo que nadie tiene ni puta idea de
> FireBird. Por lo menos en España.
>
> Si alguien se sabe el "truco" ese truco que hace que vaya como una bestia
> el servicio se le agradeceria.
>
>
> Range Walker nosotros tenemos una Red Hat en un Biprocesador Fujitsu
> nuevecito para 8 puestos
> de trabajo. Funciona bien es un mounstro, pero claro cuando los 8 se ponen
a
> joder la marrana
> se satura todo el sistema. Con Windows constatamos una perdida de
velocidad
> considerable.
>
> Por otro lado hay que tener en cuenta el as consultas SQL todo el tema ese
> de los PLANES.
> A veces de tomar un PLAN a otro se te van varios minutos.
>
> Eso es otra... el que me envie un PDF de como funcionan los PLANES de
forma
> extensa le doy un beso.
> Gracias.
>
>
>
>
>
>
>
>

¿Estás seguro de tener creados todos los índices correctamente? (a partir de
1 Gb sí que es recomendable un backup/restore cada semana pero si no es tan
grande la BD yo creo que debieras encaminar las pesquisas por otro lado: los
indices pe)



Saludos

"R.B.N" <raulbou***ono.com> escribió en el mensaje
news:98pbc.2865$9c.188680***news.ono.com...
> Llevamos trabajando en mi empresa con firebird 6 meses con una nueva
> aplicación de gestión y contabilidad.
> El caso es que en nuestro primer cliente ya hemos tenido que montar un
> proceso nocturno que realice
> un backup ->restore de la base de datos, pues sino realizamos este proceso
> al cabo de 1 semana
> no se mueve ni el cursor de la aplicación, una ruina.
>
> Alguien ve esto serio. Con SQL Server tambien haceis esto de limpiar la
base
> de datos.
>
> Buscamos información de posibles configuraciones de la base de datos
> (tamaños de pagina, caché, etc..)
> y nadie nos resuelve problemas. Unos dicen que subamos el tamaño de
pagina
> otros que no. Esto es una mierda y creo que nadie tiene ni puta idea de
> FireBird. Por lo menos en España.
>
> Si alguien se sabe el "truco" ese truco que hace que vaya como una bestia
> el servicio se le agradeceria.
>
>
> Range Walker nosotros tenemos una Red Hat en un Biprocesador Fujitsu
> nuevecito para 8 puestos
> de trabajo. Funciona bien es un mounstro, pero claro cuando los 8 se ponen
a
> joder la marrana
> se satura todo el sistema. Con Windows constatamos una perdida de
velocidad
> considerable.
>
> Por otro lado hay que tener en cuenta el as consultas SQL todo el tema ese
> de los PLANES.
> A veces de tomar un PLAN a otro se te van varios minutos.
>
> Eso es otra... el que me envie un PDF de como funcionan los PLANES de
forma
> extensa le doy un beso.
> Gracias.
>
>
>
>
>
>
>
>

¿Estás seguro de tener creados todos los índices correctamente? (a partir de
1 Gb sí que es recomendable un backup/restore cada semana pero si no es tan
grande la BD yo creo que debieras encaminar las pesquisas por otro lado: los
indices pe)



Saludos

"R.B.N" <raulbou***ono.com> escribió en el mensaje
news:98pbc.2865$9c.188680***news.ono.com...
> Llevamos trabajando en mi empresa con firebird 6 meses con una nueva
> aplicación de gestión y contabilidad.
> El caso es que en nuestro primer cliente ya hemos tenido que montar un
> proceso nocturno que realice
> un backup ->restore de la base de datos, pues sino realizamos este proceso
> al cabo de 1 semana
> no se mueve ni el cursor de la aplicación, una ruina.
>
> Alguien ve esto serio. Con SQL Server tambien haceis esto de limpiar la
base
> de datos.
>
> Buscamos información de posibles configuraciones de la base de datos
> (tamaños de pagina, caché, etc..)
> y nadie nos resuelve problemas. Unos dicen que subamos el tamaño de
pagina
> otros que no. Esto es una mierda y creo que nadie tiene ni puta idea de
> FireBird. Por lo menos en España.
>
> Si alguien se sabe el "truco" ese truco que hace que vaya como una bestia
> el servicio se le agradeceria.
>
>
> Range Walker nosotros tenemos una Red Hat en un Biprocesador Fujitsu
> nuevecito para 8 puestos
> de trabajo. Funciona bien es un mounstro, pero claro cuando los 8 se ponen
a
> joder la marrana
> se satura todo el sistema. Con Windows constatamos una perdida de
velocidad
> considerable.
>
> Por otro lado hay que tener en cuenta el as consultas SQL todo el tema ese
> de los PLANES.
> A veces de tomar un PLAN a otro se te van varios minutos.
>
> Eso es otra... el que me envie un PDF de como funcionan los PLANES de
forma
> extensa le doy un beso.
> Gracias.
>
>
>
>
>
>
>
>

¿Estás seguro de tener creados todos los índices correctamente? (a partir de
1 Gb sí que es recomendable un backup/restore cada semana pero si no es tan
grande la BD yo creo que debieras encaminar las pesquisas por otro lado: los
indices pe)



Saludos

"R.B.N" <raulbou***ono.com> escribió en el mensaje
news:98pbc.2865$9c.188680***news.ono.com...
> Llevamos trabajando en mi empresa con firebird 6 meses con una nueva
> aplicación de gestión y contabilidad.
> El caso es que en nuestro primer cliente ya hemos tenido que montar un
> proceso nocturno que realice
> un backup ->restore de la base de datos, pues sino realizamos este proceso
> al cabo de 1 semana
> no se mueve ni el cursor de la aplicación, una ruina.
>
> Alguien ve esto serio. Con SQL Server tambien haceis esto de limpiar la
base
> de datos.
>
> Buscamos información de posibles configuraciones de la base de datos
> (tamaños de pagina, caché, etc..)
> y nadie nos resuelve problemas. Unos dicen que subamos el tamaño de
pagina
> otros que no. Esto es una mierda y creo que nadie tiene ni puta idea de
> FireBird. Por lo menos en España.
>
> Si alguien se sabe el "truco" ese truco que hace que vaya como una bestia
> el servicio se le agradeceria.
>
>
> Range Walker nosotros tenemos una Red Hat en un Biprocesador Fujitsu
> nuevecito para 8 puestos
> de trabajo. Funciona bien es un mounstro, pero claro cuando los 8 se ponen
a
> joder la marrana
> se satura todo el sistema. Con Windows constatamos una perdida de
velocidad
> considerable.
>
> Por otro lado hay que tener en cuenta el as consultas SQL todo el tema ese
> de los PLANES.
> A veces de tomar un PLAN a otro se te van varios minutos.
>
> Eso es otra... el que me envie un PDF de como funcionan los PLANES de
forma
> extensa le doy un beso.
> Gracias.
>
>
>
>
>
>
>
>

He usado Ib con bases de datos de 6Gb y el único problema que detecté es que
a partir de 2Gb y con IB 6.5 la base de datos desaparece de un día para otro
(particionar la base de datos de Gb en Gb para los que os halla pasado
esto).

Saludos

"Anticristo" <nouso***terra.es> escribió en el mensaje
news:c4llih$2jvck5$1***ID-210301.news.uni-berlin.de...
> ¿Estás seguro de tener creados todos los índices correctamente? (a partir
de
> 1 Gb sí que es recomendable un backup/restore cada semana pero si no es
tan
> grande la BD yo creo que debieras encaminar las pesquisas por otro lado:
los
> indices pe)

He usado Ib con bases de datos de 6Gb y el único problema que detecté es que
a partir de 2Gb y con IB 6.5 la base de datos desaparece de un día para otro
(particionar la base de datos de Gb en Gb para los que os halla pasado
esto).

Saludos

"Anticristo" <nouso***terra.es> escribió en el mensaje
news:c4llih$2jvck5$1***ID-210301.news.uni-berlin.de...
> ¿Estás seguro de tener creados todos los índices correctamente? (a partir
de
> 1 Gb sí que es recomendable un backup/restore cada semana pero si no es
tan
> grande la BD yo creo que debieras encaminar las pesquisas por otro lado:
los
> indices pe)

He usado Ib con bases de datos de 6Gb y el único problema que detecté es que
a partir de 2Gb y con IB 6.5 la base de datos desaparece de un día para otro
(particionar la base de datos de Gb en Gb para los que os halla pasado
esto).

Saludos

"Anticristo" <nouso***terra.es> escribió en el mensaje
news:c4llih$2jvck5$1***ID-210301.news.uni-berlin.de...
> ¿Estás seguro de tener creados todos los índices correctamente? (a partir
de
> 1 Gb sí que es recomendable un backup/restore cada semana pero si no es
tan
> grande la BD yo creo que debieras encaminar las pesquisas por otro lado:
los
> indices pe)