> > > 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

Answer: no
It's a read operation only

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