> > Hi
> > LI-V6.3.2.4731 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.
>
> Bogdan
>

The restore part of this equation has nothing to do with the lock conflict.
That's my point... Unless you are restoring over the top of an existing
database.
The restore operation is totally exclusive of any access to the database in
question.
Alan

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
performed

Bogdan

I would never perform restore over an active database (I'm too long in this
business :-))


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
22:52



[Non-text portions of this message have been removed]