Re: HDR unusable with 9.40

Could you let everyone know the bug number? "Ajay Gupta" <ajaykg68@yahoo.com> wrote in message news:26ad1e92.0408121748.c164043@posting.google.com... > Yes. This is a known bug and is fixed in later release of 9.40. > > -Ajay Gupta > > "Madison Pruet" <mpruet@comcast.net> wrote in message news:<uyOSc.292803$Oq2.232844@attbi_s52>... > > 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

Madison Pruet wrote: > Could you let everyone know the bug number? > > > "Ajay Gupta" <ajaykg68@yahoo.com> wrote in message > news:26ad1e92.0408121748.c164043@posting.google.com... > >>Yes. This is a known bug and is fixed in later release of 9.40. >> >>-Ajay Gupta >> Hello Ajay. I'm also interested in this. The description seems like a bug only corrected in late 7.31 versions, but if it's specific to 9.40 I'm very interested in this. Also if there is a tech support case it would be nice to know which is it. P.S.: could a bigger physical log improve the behavior? Kind regards, Fernando Nunes

The bug number for this problem is 167294. Yes. Increasing physical log is a workaround. Forcing a checkpoint on primary during index transfer can avoid this problem. -Ajay Gupta Fernando Nunes <spam@domus.online.pt> wrote in message news:<2o3iftF6hbpkU1@uni-berlin.de>... > Madison Pruet wrote: > > Could you let everyone know the bug number? > > > > > > "Ajay Gupta" <ajaykg68@yahoo.com> wrote in message > > news:26ad1e92.0408121748.c164043@posting.google.com... > > > >>Yes. This is a known bug and is fixed in later release of 9.40. > >> > >>-Ajay Gupta > >> > > Hello Ajay. > > I'm also interested in this. The description seems like a bug only > corrected in late 7.31 versions, but if it's specific to 9.40 I'm very > interested in this. > > Also if there is a tech support case it would be nice to know which is it. > > P.S.: could a bigger physical log improve the behavior? > > Kind regards, > > Fernando Nunes

Ajay Gupta wrote: > The bug number for this problem is 167294. > > Yes. Increasing physical log is a workaround. Forcing a checkpoint on > primary during index transfer can avoid this problem. > > -Ajay Gupta Thank you. Once again I appreciate your help. Kind regards.