Re: HDR unusable with 9.40
A user on 9.40UC4 reported that creating several indexes on a large table in an HDR pair hung both primary and secondary in a checkpoint; the secondary repeatedly stalled while syncing the second index and effectively became unusable, and creating an index with the secondary down produced an "index will be unusable on secondary" message. A reply suggested the cause is the secondary's buffers all going dirty during the index transfer, with a workaround of increasing buffers on the secondary and forcing a checkpoint (onmode -c) between index creations; the warning only means the secondary copy is unusable, the primary index is fine. Another poster asked whether a bug was logged, but no confirmed fix or APAR is recorded in the thread.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
If you are transferring a big index to secondary, most of the buffers on
secondary are becoming dirty which may be source of the problem.
Workaround for above problem is to increase the buffers on secondary
and force a checkpoint (onmode -c) between two create index on primary.
Message 'index will be unusable on secondary' is just a warning.
If transfer of index from primary to secondary is aborted, you
get this message. Index on primary is fine and usable. A query
on secondary will not be able to use the index.
-Ajay Gupta
Alexey Sonkin <alexeis@grandvirtual.com> wrote in message news:<cfee79$18l$1@news.xmission.com>...
> Hi, everybody,
>
> I'm in a deep frustration about HDR quality and implementation in 9.40uc4
>
> In fact, 9.40 HDR is totally unusable: by creating a set of indexes over a
> big table,
> one can easily get primary into 'forever blocked in checkpoint' and
> make secondary completely unusable (should be restored from archive)
>
> I was trying to create a set of 10 indexes over a rather big table
> in ANSI database on primary in HDR-replicated pair.
> The first index in a set of 10 indexes was created successfully.
>
> Soon after the second index creation was started, the primary server
> became blocked in a checkpoint. For about a minute after that, the
> secondary was trying to write something to a disk, then became silent.
> Both servers were blocked in a checkpoint.
>
> After several hours, I've stopped secondary.
> Primary became operational immediately.
>
> After the secondary was started again, index synchronization
> (of both indexes) was started (with proper message in 'online.log')
> from scratch.
> The first index was synchronized successfully, then second index sync..
> and both server became blocked in checkpoint again.
>
> I repeated the experiment of starting/stopping secondary several times...
> And every time both servers were blocked at the synchronization
> of the second index.
>
> That's it. Secondary became totally unusable.
>
> I made an attempt to create index keeping secondary offline...
> One more interesting result: message appeared in 'online.log',
> indicating, that 'index will be unusable on secondary'.
> That is, 9.40, unlike 7.x and 9.21, doesn't allow to create
> indexes on primary with secondary offline.
>
> HDR is really, really bad in 9.40
>
> I'm going to file a level-1 bug to IBM/PA
>
> ------------------------------------------
> Alexey Sonkin
> Senior Database Administrator
> '
>
>
> sending to informix-list
Is there a known bug for this problem???
"Ajay Gupta" <ajaykg68@yahoo.com> wrote in message
news:26ad1e92.0408120908.57d4d1bb@posting.google.com...
> If you are transferring a big index to secondary, most of the buffers on
> secondary are becoming dirty which may be source of the problem.
>
> Workaround for above problem is to increase the buffers on secondary
> and force a checkpoint (onmode -c) between two create index on primary.
>
> Message 'index will be unusable on secondary' is just a warning.
> If transfer of index from primary to secondary is aborted, you
> get this message. Index on primary is fine and usable. A query
> on secondary will not be able to use the index.
>
> -Ajay Gupta
>
> Alexey Sonkin <alexeis@grandvirtual.com> wrote in message
news:<cfee79$18l$1@news.xmission.com>...
> > Hi, everybody,
> >
> > I'm in a deep frustration about HDR quality and implementation in
9.40uc4
> >
> > In fact, 9.40 HDR is totally unusable: by creating a set of indexes over
a
> > big table,
> > one can easily get primary into 'forever blocked in checkpoint' and
> > make secondary completely unusable (should be restored from archive)
> >
> > I was trying to create a set of 10 indexes over a rather big table
> > in ANSI database on primary in HDR-replicated pair.
> > The first index in a set of 10 indexes was created successfully.
> >
> > Soon after the second index creation was started, the primary server
> > became blocked in a checkpoint. For about a minute after that, the
> > secondary was trying to write something to a disk, then became silent.
> > Both servers were blocked in a checkpoint.
> >
> > After several hours, I've stopped secondary.
> > Primary became operational immediately.
> >
> > After the secondary was started again, index synchronization
> > (of both indexes) was started (with proper message in 'online.log')
> > from scratch.
> > The first index was synchronized successfully, then second index sync..
> > and both server became blocked in checkpoint again.
> >
> > I repeated the experiment of starting/stopping secondary several
times...
> > And every time both servers were blocked at the synchronization
> > of the second index.
> >
> > That's it. Secondary became totally unusable.
> >
> > I made an attempt to create index keeping secondary offline...
> > One more interesting result: message appeared in 'online.log',
> > indicating, that 'index will be unusable on secondary'.
> > That is, 9.40, unlike 7.x and 9.21, doesn't allow to create
> > indexes on primary with secondary offline.
> >
> > HDR is really, really bad in 9.40
> >
> > I'm going to file a level-1 bug to IBM/PA
> >
> > ------------------------------------------
> > Alexey Sonkin
> > Senior Database Administrator
> >
> >
> >
> > sending to informix-list