Re: BTS index on HDR Secondary usable?

On Thu, Oct 16, 2008 at 3:23 PM, Nilesh Ozarkar <nilesho@us.ibm.com> wrote: > >> Re: BTS index on HDR Secondary usable? >> >> Jim Tranny >> >> to: >> >> informix-list >> >> 10/16/2008 12:53 PM >> >> Sent by: >> >> informix-list-bounces@iiug.org >> >> On Thu, Oct 16, 2008 at 12:14 PM, Jim Tranny <jimtranny@gmail.com> wrote: >> > On Thu, Oct 16, 2008 at 11:58 AM, TBP <theBP@usenet-news.net> wrote: >> >> Jim Tranny wrote: >> >>> Has anyone else seen this? We're using IDS 11.50.FC2 (Linux). I >> >>> created a BTS (Basic Text Search) index on the HDR primary, expecting >> >>> to see it being created on the HDR secondary as well but the index did >> >>> not get created. I can see that the index 'should' have been created >> >>> since running dbschema on the secondary shows the index but when I try >> >>> to use the index I get: (BTS92) - bts error - CLucene index does not >> >>> exist. >> >>> >> >>> I have tried setting LOG_INDEX_BUILDS to 0 or 1 but that didn't help. >> >>> Does anyone have any ideas on how to get a BTS index working on the >> >>> secondary? >> >>> >> >>> Thanks. >> >> >> >> As the extspace is external to the engine, is it "in-sync" on the >> secondary machine as regards the primary?? >> >> >> >> I think you may need to : >> >> >> >> Shut the engine down (or stop all insert activity) >> >> Copy across the extspace >> >> Start the engine >> >> >> >> Do you still get the error? >> >> _______________________________________________ >> > >> > >> > Yes, that does work. But what will happen if there are changes to the >> > indexed column? I doubt that the index on the secondary will get >> > updated. I'll give it a shot to see what happens with the updates. >> > >> > When LOG_INDEX_BUILDS is set to 0 I can see that the build command is >> > being sent to the secondary: >> > 11:24:59 DR: Receiving index mydb:"auser".atable#idx_bts : Started >> > 11:24:59 DR: Receiving index mydb:"auser".atable#idx_bts : Completed.>> > >> > I find it strange that it's not issuing the build commands to the >> > datablade. >> > >> >> So I've tried it and as expected the secondary's copy of the extspace >> didn't get updated when updates are made to the indexed column and >> thus the BTS index on the secondary is now out of sync. >> >> So are we seeing a bug here or is this expected behaviour? We can use > > Expected behavior as external spaces are not replicated via HDR. > But you can still use it on primary instance if you want. > >> a BTS index on a secondary (so long as we copy over the extspace), but >> it won't get created or updated automatically. >> _______________________________________________ >> Informix-list mailing list >> Informix-list@iiug.org >> http://www.iiug.org/mailman/listinfo/informix-list > Yes I realize that, I wasn't expecting that the extspace was to be replicated, but rather I thought the 'create index' stmt, would be sent as is to the secondary and that the secondary internally would run the same bts index creation commands. After all, that's what happens with regular indexes when LOG_INDEX_BUILDS=0; no? Then it would be just a matter of sending the BTS update commands to the secondary so that they can be replayed whenever the column is updated.

Jim Tranny wrote: > On Thu, Oct 16, 2008 at 3:23 PM, Nilesh Ozarkar <nilesho@us.ibm.com> wrote: >>> Re: BTS index on HDR Secondary usable? >>> >>> Jim Tranny >>> >>> to: >>> >>> informix-list >>> >>> 10/16/2008 12:53 PM >>> >>> Sent by: >>> >>> informix-list-bounces@iiug.org >>> >>> On Thu, Oct 16, 2008 at 12:14 PM, Jim Tranny <jimtranny@gmail.com> wrote: >>>> On Thu, Oct 16, 2008 at 11:58 AM, TBP <theBP@usenet-news.net> wrote: >>>>> Jim Tranny wrote: >>>>>> Has anyone else seen this? We're using IDS 11.50.FC2 (Linux). I >>>>>> created a BTS (Basic Text Search) index on the HDR primary, expecting >>>>>> to see it being created on the HDR secondary as well but the index did >>>>>> not get created. I can see that the index 'should' have been created >>>>>> since running dbschema on the secondary shows the index but when I try >>>>>> to use the index I get: (BTS92) - bts error - CLucene index does not >>>>>> exist. >>>>>> >>>>>> I have tried setting LOG_INDEX_BUILDS to 0 or 1 but that didn't help. >>>>>> Does anyone have any ideas on how to get a BTS index working on the >>>>>> secondary? >>>>>> >>>>>> Thanks. >>>>> As the extspace is external to the engine, is it "in-sync" on the >>> secondary machine as regards the primary?? >>>>> I think you may need to : >>>>> >>>>> Shut the engine down (or stop all insert activity) >>>>> Copy across the extspace >>>>> Start the engine >>>>> >>>>> Do you still get the error? >>>>> _______________________________________________ >>>> >>>> Yes, that does work. But what will happen if there are changes to the >>>> indexed column? I doubt that the index on the secondary will get >>>> updated. I'll give it a shot to see what happens with the updates. >>>> >>>> When LOG_INDEX_BUILDS is set to 0 I can see that the build command is >>>> being sent to the secondary: >>>> 11:24:59 DR: Receiving index mydb:"auser".atable#idx_bts : Started >>>> 11:24:59 DR: Receiving index mydb:"auser".atable#idx_bts : Completed.>>>> >>>> I find it strange that it's not issuing the build commands to the >>>> datablade. >>>> >>> So I've tried it and as expected the secondary's copy of the extspace >>> didn't get updated when updates are made to the indexed column and >>> thus the BTS index on the secondary is now out of sync. >>> >>> So are we seeing a bug here or is this expected behaviour? We can use >> Expected behavior as external spaces are not replicated via HDR. >> But you can still use it on primary instance if you want. >> >>> a BTS index on a secondary (so long as we copy over the extspace), but >>> it won't get created or updated automatically. >>> _______________________________________________ >>> Informix-list mailing list >>> Informix-list@iiug.org >>> http://www.iiug.org/mailman/listinfo/informix-list > > Yes I realize that, I wasn't expecting that the extspace was to be > replicated, but rather I thought the 'create index' stmt, would be > sent as is to the secondary and that the secondary internally would > run the same bts index creation commands. After all, that's what > happens with regular indexes when LOG_INDEX_BUILDS=0; no? Then it > would be just a matter of sending the BTS update commands to the > secondary so that they can be replayed whenever the column is updated. No. The index pages are always sent to the secondary. If LOG_INDEX_BUILD=1 then they are sent inside the logical logs, if it's 0 then they're sent in "out of band"... If the index was built by the secondary you'd end up with different space allocations which can't happen... (and it would be a waste of resources, since the index already exists). Crazy and unsupported idea... if you have the extspace remotely mounted as read only, will it work? Notice the unsupported part!!! Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...