BTS fails after ontape Restore

Hi All, We just installed BTS on a Production server. We backed up the instance using ontape, and restored on a different machine. When we tried to use the BTS blade, it always returns Zero rows found. (select * from name where bts_contains(full_name,'TOM');) Trying the same query with LIKE returns hundreds of rows. On the Production server, the bts_contains query also returns hundreds of rows. Specifics: Server: SunOS gravity2 5.10 Generic_150400-20 sun4u sparc (uname -a) Informix: IBM Informix Dynamic Server Version 11.50.FC9 -- On-Line Blade: {fp_tcp} gravity2:/staff/dba> blademgr fp_tcp>list music DataBlade modules registered in database music: bts.2.00 fp_tcp> Index Creation: create index bts_name_full on name (full_name bts_varchar_ops) using bts (stopwords='(a,an,as,at,be,by,if,in,is,it,no,of,on,or,s,t,to)' ); Has anyone else had this problem with ontape Restores? At first I thought it might be due to the index rowids being in different places, but ontape is a binary restore, so all page layouts should be identical to Production. Thanks, Michael Hoffman

Michael: Early versions of the BTS would store indexes in the file system and not in the database. If you are using one of the these early versions, then you will have to manually have to move the in the indexes stored to the new computer as they will not be contained in the backup. Newer version of BTS store the indexes in smart blobspaces. John F. Miller III STSM, Lead Architect miller3@us.ibm.com 503-747-1366 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 03/06/2015 07:58:22 AM: > From: "MICHAEL HOFFMAN" <offdisc@gmail.com> > To: ids@iiug.org > Date: 03/06/2015 07:59 AM > Subject: BTS fails after ontape Restore [34793] > Sent by: ids-bounces@iiug.org > > Hi All, > We just installed BTS on a Production server. We backed up the instance using > ontape, and restored on a different machine. > When we tried to use the BTS blade, it always returns Zero rows found. > (select * from name where bts_contains(full_name,'TOM');) > Trying the same query with LIKE returns hundreds of rows. > On the Production server, the bts_contains query also returns hundreds of > rows. > > Specifics: > Server: SunOS gravity2 5.10 Generic_150400-20 sun4u sparc (uname -a) > Informix: IBM Informix Dynamic Server Version 11.50.FC9 -- On-Line > Blade: > > {fp_tcp} gravity2:/staff/dba> blademgr > > fp_tcp>list music > > DataBlade modules registered in database music: > > bts.2.00 > > fp_tcp> > Index Creation: create index bts_name_full > > on name (full_name bts_varchar_ops) using bts > > (stopwords='(a,an,as,at,be,by,if,in,is,it,no,of,on,or,s,t,to)' ); > > Has anyone else had this problem with ontape Restores? > > At first I thought it might be due to the index rowids being in different > places, but ontape is a binary restore, so all page layouts should be > identical to Production. > > Thanks, > Michael Hoffman > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hi John, Oh.... hmmm,.... this is BTS 2.0 on IFMX 11.5 using raw chunks for storage. How can I find where the BTS indexes are stored? I looked through the onconfig, but nothing obvious there. BTW, the query doesn't Fail with an error (would be expected if the index wasn't found); it runs very quickly and returns "No Rows Found" Thanks, Michael --------- "Sit Long, Talk Much, Laugh Often" -- anon "Shared Pain is lessened, Shared Joy is increased" --- Spider Robinson On Fri, Mar 6, 2015 at 10:39 AM, John Miller iii <miller3@us.ibm.com> wrote: Michael: Early versions of the BTS would store indexes in the file system and not in the database. If you are using one of the these early versions, then you will have to manually have to move the in the indexes stored to the new computer as they will not be contained in the backup. Newer version of BTS store the indexes in smart blobspaces. John F. Miller III STSM, Lead Architect miller3@us.ibm.com 503-747-1366 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 03/06/2015 07:58:22 AM: > From: "MICHAEL HOFFMAN" <offdisc@gmail.com> > To: ids@iiug.org > Date: 03/06/2015 07:59 AM > Subject: BTS fails after ontape Restore [34793] > Sent by: ids-bounces@iiug.org > > Hi All, > We just installed BTS on a Production server. We backed up the instance using > ontape, and restored on a different machine. > When we tried to use the BTS blade, it always returns Zero rows found. > (select * from name where bts_contains(full_name,'TOM');) > Trying the same query with LIKE returns hundreds of rows. > On the Production server, the bts_contains query also returns hundreds of > rows. > > Specifics: > Server: SunOS gravity2 5.10 Generic_150400-20 sun4u sparc (uname -a) > Informix: IBM Informix Dynamic Server Version 11.50.FC9 -- On-Line > Blade: > > {fp_tcp} gravity2:/staff/dba> blademgr > > fp_tcp>list music > > DataBlade modules registered in database music: > > bts.2.00 > > fp_tcp> > Index Creation: create index bts_name_full > > on name (full_name bts_varchar_ops) using bts > > (stopwords='(a,an,as,at,be,by,if,in,is,it,no,of,on,or,s,t,to)' ); > > Has anyone else had this problem with ontape Restores? > > At first I thought it might be due to the index rowids being in different > places, but ontape is a binary restore, so all page layouts should be > identical to Production. > > Thanks, > Michael Hoffman > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

One clarification for the Index Creation, we do specify the BTS smartspace: create index bts_name_full on name (full_name bts_varchar_ops) using bts (stopwords='(a,an,as,at,be,by,if,in,is,it,no,of,on,or,s,t,to)' ) in bts_sbspace; From Onconfig: SBSPACENAME bts_sbspace onstat -d:1163a2358 26 0x8001 62 1 2048 N S informi x bts_sbspace 1163a24f0 27 0xa001 63 1 2048 N U informi x bts_temp 1164be028 62 26 0 1000000 851068 932620 POS-- /dev/md/rdsk/d146 Metadata 67327 50099 67327 1164be218 63 27 0 1000000 917984 932620 POS-- /dev/md/rdsk/d147 Metadata 67327 50099 67327

Hi Michael, What are the arguments you used on the ontape backup and restore? Is the SBSPACENAME parameter set the same in the restored server as the backed up sever ? -- Mark. Mark Ashworth IBM Informix Extensibility Architect Office phone: +1 (905) 413-5033 Alternate: +1 (905) 697-8094 Email: ashworth@ca.ibm.com Check out my blog From: "MICHAEL HOFFMAN" <offdisc@gmail.com> To: ids@iiug.org Date: 03/06/2015 01:28 PM Subject: Re: BTS fails after ontape Restore [34796] Sent by: ids-bounces@iiug.org One clarification for the Index Creation, we do specify the BTS smartspace: create index bts_name_full on name (full_name bts_varchar_ops) using bts (stopwords='(a,an,as,at,be,by,if,in,is,it,no,of,on,or,s,t,to)' ) in bts_sbspace; >From Onconfig: SBSPACENAME bts_sbspace onstat -d:1163a2358 26 0x8001 62 1 2048 N S informi x bts_sbspace 1163a24f0 27 0xa001 63 1 2048 N U informi x bts_temp 1164be028 62 26 0 1000000 851068 932620 POS-- /dev/md/rdsk/d146 Metadata 67327 50099 67327 1164be218 63 27 0 1000000 917984 932620 POS-- /dev/md/rdsk/d147 Metadata 67327 50099 67327 ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Hi Mark, Backup is done by 'ontape -s -L 0' Restore was done with 'ontape -r' No extra special parameters. And as I was typing this email, I was collecting the appropriate BTS-related lines from the 4 onconfig's in play (we use a special 'backup' onconfig for ontape). Lo and behold, I found that the onconfig for Restore has a typo! One missing letter in the name of the SBSPACENAME parameter. I'm going to blow away the restore and try again. Thanks for the lead!!! Mike

Hi All, So, I re-ran the ontape restore (ontape -r) over the weekend. Restore completed successfully. However, the BTS index is still returning zero rows. I verified that the SBSPACENAME was the same on Production and Restore instances. Again, here is the Create Index script: create index bts_name_idx on name (full_name bts_varchar_ops) using bts (stopwords='(a,an,as,at,be,by,if,in,is,it,no,of,on,or,s,t,to)' ) in bts_sbspace; Any "select * from name where bts_contains(full_name, '[anystring]');" returns "No Rows Found" However, "select * from name where fill_name LIKE '[anystring]%'" works fine. Something is definitely messing up the index during the restore. The engine acts as if it is querying the index, though -- the query takes a couple seconds to complete. Any help would be greatly appreciated! Thanks, Michael Hoffman