Hi again, Sounds like a reasonable cause for the problem. So now is my question, what is the best way to upgrade. My current setup is as follows: I have two databases, one for raw data (RAW), and the second one for decoded data (MAIN). I need to keep the RAW db with as high availability as possible (or we will loose incoming data). For the MAIN db I have more slack regarding downtime (weekends/nights). They both have ODS version 11.2.
The best would be if I could upgrade to the latest version (2.5.4) of the server db without the need to do backup/restore as this takes a lot of time. Best regards Jardar 29. okt. 2015 00.00 skrev "setysvar setys...@gmail.com [firebird-support]" < firebird-support@yahoogroups.com>: > > > > Den 28.10.2015 20:56, skrev Jardar Maatje jardar.maa...@nds.nortek.no > [firebird-support]: > > Hi again > > A bit more details. I found the query the slows this down and it is a > query that includes blob data. If I adjust the query to cast the blob to > varchar first the query executes 30 timers faster. I will try to change my > queries to fix this. > > However I still wonder why this suddenly became a problem after restoring > the database. > > Best regards > > Jardar > > http://tracker.firebirdsql.org/browse/CORE-4601 is a report of a 60-time > improvement (from half a minute to half a second) with Firebird 2.5.2/2.5.3 > and Jaybird 2.2.5/2.1.6 when changing from blob to varchar, I guess this > could be the same problem as you observe. > > Could it be that your original database had never before been restored > with Firebird 2.5.1, but only with an older Firebird/InterBase version (or > never restored, but created with an older Firebird/InterBase version)? If > so, then you may have been protected against this particular bug (I'm just > guessing, I don't know if older versions have it or not), as well as the > bug (only existing in 2.5.1, 2.5.0 and 2.5.2 are OK) that I warned about > earlier today regarding indexes containing more than one field (which - I > think - can give you wrong results from some queries). > > Set > > >
