| Subject | RE: [firebird-support] Advise Please |
|---|---|
| Author | Svein Erling Tysvær |
| Post date | 2011-05-31T06:56:59Z |
On 2011.05.31 12:54 AM, munster77054 wrote:
My hunch is that your slowdown is due to what you describe as 'process'. Just reading from a file and inserting into a database that is not currently in use by anyone isn't likely to show that much of a slowdown, but if 'process' includes selects, updates and/or deletes, then it might be due to the plan for one or more of these selects/updates/deletes having changed. Plans change due to changes in the data making Firebird believe a different strategy for accessing those data would be benefitial, but sometimes Firebird can guess very wrong and action must be taken one way or the other. Updating statistics is one (likely temporal) option, modifying the SQL to prevent certain plans for being options is another (more permanent) solution.
Of course, check what Paul wrote, that is a common reason for databases to slow down over time when one or more programs doesn't take proper care of transactions and the database is in use. If you hold the only connection to the database, then this ought not to be the reason.
HTH,
Set
> Now here is the situation. In 2008, using the FB, when I processed theLuckily, you're wrong. Firebird doesn't automatically upgrade databases when you change from one Firebird version to the next. It will work with the database in the version it was created with, so you should be able to e.g. access a Fb 1.5 database with any Firebird version >= Fb 1.5. To upgrade the database, do a backup/restore. One reason to upgrade, would be that you get access to new features, e.g. I don't think you can use EXECUTE BLOCK or CTEs on a Firebird 1.5 database even though you're using a Firebird 2.5 server.
> file, it went fast, and was able to process 3000+ records in about 20
> seconds... it was reading a flat file, parsing it, and putting it into
> the database.
>
> I tried it earlier today, with the same DB from 2008, and it only
> processed about 50 records in the same time that in 2008 it took to
> process 3000+ records, and later, it slowed down even more. I rebuilt
> the database/tables, and tried it again, and the 20 seconds came back.
> Can anyone tell me why? It is my understanding, that when I opened the
> old database with FB 2.1.3.18185, it was suppose to convert it to the
> current format. Any ideas?
My hunch is that your slowdown is due to what you describe as 'process'. Just reading from a file and inserting into a database that is not currently in use by anyone isn't likely to show that much of a slowdown, but if 'process' includes selects, updates and/or deletes, then it might be due to the plan for one or more of these selects/updates/deletes having changed. Plans change due to changes in the data making Firebird believe a different strategy for accessing those data would be benefitial, but sometimes Firebird can guess very wrong and action must be taken one way or the other. Updating statistics is one (likely temporal) option, modifying the SQL to prevent certain plans for being options is another (more permanent) solution.
Of course, check what Paul wrote, that is a common reason for databases to slow down over time when one or more programs doesn't take proper care of transactions and the database is in use. If you hold the only connection to the database, then this ought not to be the reason.
HTH,
Set