HOLA A TODOS QUISIERA PREGUNTARLES SI HAY ALGUN PROBLEMA A PASAR DE FIREBIRD 1.5 A 2.5, PRA TRABAJAR ESA BASE DE DATOS EN DELPHI 7
FIREBIRD 2.5
Started by
FELIX
, Jul 13 2011 01:32 PM
7 replies to this topic
#2
enecumene
-
- Administrador
-
- 7419 posts
Webmaster
- LocationRepública Dominicana
#3
FELIX
-
- Miembros
-
- 123 posts
Advanced Member
Posted 13 July 2011 - 03:43 PM
saludo nuevamente tengo una nuevoa duda, como mejoro el rendimiento de de mi base de datos migrandola a firebird 2.5.
#4
enecumene
-
- Administrador
-
- 7419 posts
Webmaster
- LocationRepública Dominicana
Posted 13 July 2011 - 03:45 PM
El rendimiento de la BD depende mucho de como la tengas estructurada, aunque ya al migrar la diferencia es notable.
Saludos.
Saludos.
#5
enecumene
-
- Administrador
-
- 7419 posts
Webmaster
- LocationRepública Dominicana
Posted 13 July 2011 - 03:52 PM
Por favor, no repitas el tema, ya habias escrito la duda aquí, por tal motivo he eliminado el nuevo tema, por favor continúa aquí.
Saludos.
Saludos.
#6
FELIX
-
- Miembros
-
- 123 posts
Advanced Member
Posted 13 July 2011 - 03:53 PM
enecumene te agradezco tu tiempo, me ayudas muchisimo
#7
Delphius
-
- Administrador
-
- 6295 posts
Advanced Member
- LocationArgentina
Posted 13 July 2011 - 06:42 PM
Hola FELIX,
No deberías tener mayores problemas.
Cuanto mucho algún pequeño inconveniente, totalmente solucionable, en alguna que otra instrucción SQL. Hay cosas que en Firebird 1.5 es más permisible que en la 2.5 ya que ha ido madurando en el criterio y el soporte al estándar SQL.
Quizá alguna que otra UDF que utilices provoque alguno que otro error, aunque nada serio.
No te sabría decir mucho, yo no hice el paso aún a 2.5 (ni siquiera a 2.1); al igual que tu estoy con 1.5
Saludos,
No deberías tener mayores problemas.
Cuanto mucho algún pequeño inconveniente, totalmente solucionable, en alguna que otra instrucción SQL. Hay cosas que en Firebird 1.5 es más permisible que en la 2.5 ya que ha ido madurando en el criterio y el soporte al estándar SQL.
Quizá alguna que otra UDF que utilices provoque alguno que otro error, aunque nada serio.
No te sabría decir mucho, yo no hice el paso aún a 2.5 (ni siquiera a 2.1); al igual que tu estoy con 1.5
Saludos,
#8
Sergio
-
- Moderadores
-
- 1092 posts
Advanced Member
- LocationMurcia, España
Posted 14 July 2011 - 04:44 AM
Mi mayor problema fue el uso de acentos y eñes en los comentarios de los procedures, triggers, etc., no tuve mas remedio que hacer una lista con toda la serie de updates a aplicar a la BD para eliminarlos, aplicar ese parche a las bases de datos de mis clientes, y entonces ya se podain actualizar a FB V2.5 sin problemas. Si no lo hacian, las copias de seguridad no les funcionaban.
En teoria existe un nuevo switch en el gbak.exe para arreglar todas estas cosillas en los metadatas mientras se hace un ciclo de backup/restore, pero a mi no me funciono en absoluto, asi que tuve que hacerme esa lista de "cosas con acentos" (haces un backup/restore, te da error en un trigger, pues lo añades a tu lista de cambios a la base de datos, la aplicas a los datos, y sigues hasta que ya no da mas errores y el backup/restore termina felizmente).
Aparte de esto, pues las tipicas sentencias que antes funcionaban aunque no fuesen muy correctas, que ahora si ve ambiguedad te da un error y listo, pero a cambio ganas velocidad y tranquilidad de espiritu.
Respecto a ganar velocidad, lo mas importante es un diseño correcto de la base de datos (evitar que en el plan de la consulta se usen indices "naturales", es decir, sin indices), y aparte de eso, sanear la base de datos (un ciclo de backup/restore y usar el nuevo ficheor en lugar dle antiguo) gana mucho en ficheros muy "usados" (peor mucho mucho), configurar FireBird para que use para los temporales un segundo disco duro fisico (o un disco RAM aun mejor) tambien da beneficios, y tambien cambiar la configuracion de firebird para que use mas RAM de cache que las miseras 8MB de fabrica.
En la empresa hicimos un pequeño tuto al respecto para nuestros clientes, son 3 puntos (no habla de diseñar bien la BD porque eso no es cosa suya): Elegir un PC servidor (povco importante realmente pero nos llaman mucho por eso), configurar bien FireBird, y sanear la base de datos.
http://www.hcsoft.ne...r&hoja=accesobd
En teoria existe un nuevo switch en el gbak.exe para arreglar todas estas cosillas en los metadatas mientras se hace un ciclo de backup/restore, pero a mi no me funciono en absoluto, asi que tuve que hacerme esa lista de "cosas con acentos" (haces un backup/restore, te da error en un trigger, pues lo añades a tu lista de cambios a la base de datos, la aplicas a los datos, y sigues hasta que ya no da mas errores y el backup/restore termina felizmente).
Aparte de esto, pues las tipicas sentencias que antes funcionaban aunque no fuesen muy correctas, que ahora si ve ambiguedad te da un error y listo, pero a cambio ganas velocidad y tranquilidad de espiritu.
Respecto a ganar velocidad, lo mas importante es un diseño correcto de la base de datos (evitar que en el plan de la consulta se usen indices "naturales", es decir, sin indices), y aparte de eso, sanear la base de datos (un ciclo de backup/restore y usar el nuevo ficheor en lugar dle antiguo) gana mucho en ficheros muy "usados" (peor mucho mucho), configurar FireBird para que use para los temporales un segundo disco duro fisico (o un disco RAM aun mejor) tambien da beneficios, y tambien cambiar la configuracion de firebird para que use mas RAM de cache que las miseras 8MB de fabrica.
En la empresa hicimos un pequeño tuto al respecto para nuestros clientes, son 3 puntos (no habla de diseñar bien la BD porque eso no es cosa suya): Elegir un PC servidor (povco importante realmente pero nos llaman mucho por eso), configurar bien FireBird, y sanear la base de datos.
http://www.hcsoft.ne...r&hoja=accesobd
