Subject | Re: Clear database cache? |
---|---|
Author | Adam |
Post date | 2008-02-01T01:12:49Z |
--- In firebird-support@yahoogroups.com, "Matthew Metlis"
<mmetlis@...> wrote:
be touched during the restore and your application behaves itself.
Are you 100% sure that the data in question had been committed at the
time the backup was initiated? Firebird backups are hot backups,
meaning that you can continue using the database while the backup is
taking place. But anything added/updated/deleted that has not been
committed before the moment in time the backup starts will not be
included in the backup.
So lets be clear, if you add a new record at 9am, but do not commit
its transaction until 12pm, the backup taken at 11am will *NOT*
contain the new record.
In terms of a database cache, it does not quite work the way you are
expecting. There is a forced writes setting on each database you will
want to set to true (if you care about the data inside ;) ). This is
the default setting for new databases in Firebird, but databases
created in ancient history may have defaulted false.
See notes on gfix (or any admin tool) to change setting.
There is also possibly some caching done by your Java layer that you
may need to flush but that would be better asked on another list
(possibly firebird-java).
Adam
<mmetlis@...> wrote:
>This is all OK, as long as you understand that the database must not
> Ann,
>
> Thanks for the response. Replacing the data file through the
> application is something that has to be done. The application is
> deployed to non-technical users on systems to which I do not have
> access most of the time. Each application uses its own database
> resident on its own system, so I do not have access to the databases
> either. Frequent (every 5 minutes) automated backups along with the
> option to restore the data from a backup are a requirement of the
> system - and a non-technical user has to be able to perform that
> restoration.
>
> When the application does a restore, it does first block the user from
> making any data changes (or doing anything besides watching a progress
> bar, really), closes its connections to the database, does the restore
> of the data file, opens new connections, and then lets the user resume
> work. There also can only be one application open for a single
> database. So there is nothing the user can do during the restore
> process that would be lost. We do emphasize to the users that if they
> restore a backup, they will lost whatever data has been entered since
> that backup.
be touched during the restore and your application behaves itself.
>Matthew,
> Still, though, after doing that process, there seem to be issues when
> entering new data.
Are you 100% sure that the data in question had been committed at the
time the backup was initiated? Firebird backups are hot backups,
meaning that you can continue using the database while the backup is
taking place. But anything added/updated/deleted that has not been
committed before the moment in time the backup starts will not be
included in the backup.
So lets be clear, if you add a new record at 9am, but do not commit
its transaction until 12pm, the backup taken at 11am will *NOT*
contain the new record.
In terms of a database cache, it does not quite work the way you are
expecting. There is a forced writes setting on each database you will
want to set to true (if you care about the data inside ;) ). This is
the default setting for new databases in Firebird, but databases
created in ancient history may have defaulted false.
See notes on gfix (or any admin tool) to change setting.
There is also possibly some caching done by your Java layer that you
may need to flush but that would be better asked on another list
(possibly firebird-java).
Adam