|
Y que se me suben hasta el cogote
La pesadilla de todo administrador de servidores de base de datos, me alcanzó hoy: "table xxx is marked as crashed" en un sistema basado en MySQL en producción, con 4 sucursales en linea y ninguna pudiendo hacer nada hasta que se resolviera el detalle. Ojo, el software MySQL corre en un servidor Dell dedicado, nada de pcs "habilitadas"
Afortunadamente el error se detectó y e bendito "repair table" arregló el asunto, no sin antes perder 11 registros que se identificaron y se recapturaron. Pero mientras...como decimos en México..."hasta azúcar me dió". Ahorita ya todo esta al 100% y pues mejor capturar 11 registros que restaurar el respaldo de ayer sobre todo por la cantidad de información que se mete, tengo tablas de casi 500 mil registros y la que se daño tiene 250 mil. A alguien le ha pasado algo similar? Yo uso MySQL desde siempre casi, y nunca me había dado problemas. Quienes usan FB que me pueden comentar, me intriga que problemas se presentan en esa BD pues trabaja muy distinto a MySQL en cuanto a organización de archivos se refiere. Saludos a todos y un largo fiuuuuu.... |
Cita:
Saludos Alfredo |
Nuestra aplicación tiene también cientos tablas (948 tablas, 1526 procedimientos y 2507 triggers, 315 vistas) en Firebird 1.5.
Las instalaciones llegan a bases de 4Gb aprox. Hace muchos años, cuando trabajábamos con Firebird 1.0 habíamos tenido algún problema, pero luego de actualizar nunca más. Incluso una vez cuando los electricistas cortaron la luz 3 o 4 veces en el día mientras todo el mundo (20 personas aprox.) estaba trabajando. Lo único que hubo que hacer es volver a encender el Linux y ya 'ta... |
Bueno, vuelvo a copiar lo que he comentado en otras ocasiones:
Cita:
Otra cosa no puedo decir porque es lo que he vivido. p.d.: por supuesto, hay muchas tablas que tienen decenas de millones de registros. Sin problemas. Edito: jacanche habla de una BD de 90 Gigas, tampoco está nada mal :) |
Pues yo hasta hace poco apostaba todas mis barajas por firebird, pero resulta que con un cliente en particular nos dio un error por demas rarisimo del cual despues de invertirle mucho tiempo no le hayamos y decidimos para este cliente trabajar con SQL 2008 server. El problema es que de la nada la base de datos empezaba a crecer desmesuradamente, ni siquiera proporcionalmete con el numero de operaciones sobre esta, asi podian ingresar 10 registros o 1 millon y esta crecia 100 veces o mas en tamaño.
Uds diran que es cuestion de transacciones pero les digo que el mismo sistema SIN NINGUNA DIFERENCIA corre con muchos clientes mas, con muchisimo mas trafico a la base, ademas de que ha sido checado con monitores de base de datos que me reportan que ninguna transaccion queda al aire, y nunca que me ha dado problemas. Afortunadamente nuestro sistema tiene la capacidad de poder correr para SQL Server, Firebird y en teoria para Oracle. La verdad es que seguimos saliendo por defecto con FB, pero nos queda esa espina de desconfianza. Edito: Se cambio de servidor, se creo la base de datos desde cero y nada que se corrigio para este cliente. |
Bueno, todos sabemos que frases como "todo está igual", "son sistemas idénticos", "nadie ha tocado nada", etc. es simplemente IMPOSIBLE :)
|
Cita:
Firebird es una excelente base de datos, tanto lo es para nosotros que nuestro sistema se instala con ella por defecto, pero no puedo decir desafortunadamente para mi al menos que es 100% confiabale (aunque dudo que haya alguna que lo pueda ser :rolleyes: ). Saludos |
Cita:
|
Cita:
Saludos. |
Hombre, de la nada no crece, yo quiero creer que las pruebas no se hicieron mirando la base de datos, sin nadie conectado, y ésta crecía y crecía como un globo. Eso sí sería preocupante. Supongo que habría gente conectada y trabajando sobre ella. Por lo tanto sí se estaba haciendo algo, aunque sea consultar.
Pero en fin, le salió barato al cliente, cambiar una libre y gratis por una de microsoft con las licencias de servidor, puestos, más la del windows server... para nada, por gusto :) |
Cita:
Con respecto al SQL Server olvide el "pequeño" detalle de que fue la version express, es decir, la gratutita. Saludos |
Bueno, esta conversación ya no sirve de nada porque se le cambió el sistema, pero en fin... si se crean registros de transacciones es porque se está haciendo algo, aunque sea consultas, pero eso no es malo, es así, no hay que preocuparse por ello. Sin en otro sitio no ocurría es simplemente porque hay menos consultas que involucren a muchos registros o cualquiera sabe cómo trabajan habitualmente. Pero, repito, es que eso no es nada malo, eso simplemente, es así.
Y luego, si se instaló la versión "express" de Microsfoft sql, que está limitada a unos pocos gigas, entonces la base de datos no era tan grande como para preocuparse por ella. Yo estaba pensando en decenas de gigas, como mínimo. Lo dicho, que se le cambió "por gusto", y aunque sea la "express", tiene que funcionar sobre windows, que ese sí paga licencia. Y su antivirus... y toda las "cositas" que requiere windows. |
Cita:
Aqui el punto era que cuando el garbage collector entraba a hacer su trabajo, dejaba la base de datos practicamente bloqueada, y te repito esto en cuestion de horas, claro que para mi cliente se tornó inoperante, y con esto te respondo que no fue por gusto ni mucho menos, y si tienes toda la razon cuando dices que deberia de ser una base de datos pequeña, dado su volumen de transacciones. Y Precisamente esto es para mi lo mas preocupante, que teniendo instalacion que superan por mucho, muchisimo a esta, se presenten estos problemas. Y como al final del día esto se trata de dinero, lo mejor para mi este caso fue cambiar el motor de base de datos, y santo remedio para mi cliente que hoy dia ya está feliz con su sistema. Pero me queda esta espina clavada de porque sucedio esto, en fin, no es para convencer sino para exponer la problematica que es real y reproducible con dicha base de datos. Saludos. |
Cita:
Saludos |
La arqutectura multi generacional. Firebird maneja varias versiones para un mismo registro al mismo tiempo, para que cada transacción tenga su propia versión, su propia "imagen" de la realidad. Así es posible, por ejemplo, poder leer siempre sin "molestar" a los que escriben. Y los que escriben no molestan a los que leen.
Ejemplo básico: alguien hace una actualización (update) de un registro y otra persona está leyéndolo (select), pues hasta que el que está actualizando no confirme los cambios (commit), el que está leyendo seguirá viendo lo que había hasta que el otro confirme. Es por lo que cada vez que se realiza cualquier acción sobre la base de datos, esta va creando registros "imágenes" de la "realidad" justo en ese momento, de esa forma no es necesario, por ejemplo, bloquear registros, ya que cada uno tiene una imagen del momento en que realiza cualquier acción. Existe un mecanismo que cada cierta cantidad de registros que ya no sirven se deshace de ellos, aunque es configurable para ponerlo a más o menos registros, incluso para deshabilitarlo y sólo se realizará cuando nosotros lo queramos. Por eso decía que no es ningún problema, simplemente funciona asi, y no importa que crezca la base de datos, toda la vida ha sido así, siempre ha funcionado así, es una de las características que tiene firebird, la MGA (multi generational architecture). Y que otros han copiado. |
Cita:
|
Exacto, se elimina automáticamente y el espacio desocupado se reutiliza para nuevos registros.
Cuando se hace backup/restore se eliminan también y no se restauran. Es configurable, por defecto "limpia" cada 20.000, pero puedes poner el valor que quieras, o deshabilitarlo y hacerlo cuando tú quieras. Para contestar a tu pregunta: no tienes que hacer nada, no hace falta un administrador que se preocupe de eso, es automático. Nunca jamás me he preocupado por ese asunto, ningún cliente se ha preocupado nunca por eso. Lo más que recuerdo es que alguien diga: Oye, que la base de datos crece mucho ¿Y cuánto mide ahora? Ocupa 0,7 Gb. ¿Y De cuánto es el disco? De 500 Gigas Bien, pues todavía puede crecer 700 veces ese tamaño ¿Entonces no me precoupo? Preocúpate de vender y ganar dinero para pagarme a mí :D |
Cita:
Hace algunos años, a un cliente le pasaba que su BD Firebird le crecía unas 10Mb cada vez que facturaba un albarán de venta... El sistema le permitía guardar una "fotocopia" de la factura en un campo blob de la BD según el diseño de la factura (hecho con QuickReport y editable con QRDesign), hasta aquí todo bien. El diseño muestra un campo blob para el logotipo de la empresa. Pero al hombre no se le ocurrió otra cosa que poner una imagen para el logo de su empresa que pesaba esos 10Mb, esa imágen era la que le hizo el diseñador del cartel que tenía en la fachada. Cuando le pregunté si no se le ocurrió reducirle el tamaño, me contestó: "Es que me dijisteis que podía ponerle cualquier imagen..." Con dos cojones!!! |
Pues imagina sólo 10 conexiones y unos simples "select" cada una... ya tiene más de 100 megas, sólo con eso :)
A mí también me ha pasado diversas veces, que para un simple logo ponen una imagen enorme de montones de megas. |
Cita:
// Saludos |
| La franja horaria es GMT +2. Ahora son las 00:26:00. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi