|Subject||RE: [firebird-support] Lock conflict|
> > HiThe restore part of this equation has nothing to do with the lock conflict.
> > LI-V220.127.116.1131 1.5 Classic, RedHat Enterprise, 9G database
> > In the evenings when gbak -g is running the clients are
> > encountering lock conflict on no wait transaction
> > Deadlock
> > Update conflicts with concurrent update
> > These errors began to occur two months ago, then we've
> > performed backup and restore - the problem went away.
> > After cca 2 months the problem reappired.
> > Any suggestions
> > Best regards
> > Bogdan Mugerli
> Ahh... Backup and restore? Can you clarify the restore thing? Alan
> There is nothing to clarify, simple backup and restore once
> per year to purify database.
That's my point... Unless you are restoring over the top of an existing
The restore operation is totally exclusive of any access to the database in
I will explain once again
Every day at 22:00 we perform gbak �b �g and restore to different database
Once per year we stop production and perform the same procedure as above.
Then we rename active (stopped) database to different name and rename
restored database to active database.
And start the production again.
I was just asking if possibility exists that backup (just �b) has influence
on currently active transactions
because lock conflicts begin to happen at exact time when backup is
I would never perform restore over an active database (I'm too long in this
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.15.24/1117 - Release Date: 7.11.2007
[Non-text portions of this message have been removed]