Thanks Art, that has helped to cure the problem, additional I found a small
number of table with page level locking, when these were changed to row
level in combination with use of the -w option the problem has disappeared.
"Art S. Kagel" <kagel@bloomberg.net> wrote in message
news:pan.2003.07.11.11.15.46.824654.15473@bloomberg.net...
> On Fri, 11 Jul 2003 04:12:59 -0400, Matt wrote:
>
> Try adding the '-w' option to the onchecks, it avoids the shared lock on
> sysindexes and also specify '-n' so it does not attempt to rebuild any
> damaged indexes, you can do that manually much more quickly after the run
> identifies the problems anyway.
>
> Art S. Kagel
>
> > Thanks Art, do you know any way around this ?
> >
> > "Art S. Kagel" <kagel@bloomberg.net> wrote in message
> > news:pan.2003.07.10.19.05.05.284450.15473@bloomberg.net...
> >> On Thu, 10 Jul 2003 10:10:18 -0400, Matt wrote:
> >>
> >> Adjacent key locks on systables indexes, likely.
> >>
> >> Art S. Kagel
> >>
> >> > Hi,
> >> >
> >> > In an attempt to get a full set on table level onchecks run in a
> >> > reasonable time (using -cdi options) I have split the job into three
> >> > parallel jobs each checking a distinct set of tables.
> >> >
> >> > I am getting locking problems, oncheck just reports a message like
> >> > 'could not obtain lock for <tablename>'
> >> >
> >> > Any ideas as to what might be causing this ?
> >> >
> >> > Thanks,
> >> > Matt