 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
SQL Server Forum / Other Technologies / Full-Text Search / October 2004After switch to "Change tracking", full-text index repopulate in f
Hi, I have a table setup running full-text index in sql server 2000. After finishing 12 hrs long of initial full population, I immediately turned on the "change tracking, update index in background". The full text index population restart all over again even though there is no data change after that initial full population. Could someone shed some light on this? thanks, -Leon This is a known problem. I reported it to Microsoft I believe 3 years ago. > Hi, > [quoted text clipped - 10 lines] > > -Leon Do you know any fix or work around of that since our production server cannot have 20+ hours to rebuild this index twice. Is that help if I add timestamp column, or not at all? thanks, -Leon > This is a known problem. I reported it to Microsoft I believe 3 years ago. > [quoted text clipped - 12 lines] > > > > -Leon The timestamp column is irrelevant. I am unaware of any work around. I suggest you call up PSS on this one. > Do you know any fix or work around of that since our production server > cannot [quoted text clipped - 24 lines] >> > >> > -Leon Leon Lee, This is actually not a known problem, but is in fact by design, although I would say that is it a DOC bug as this behavior is not documented in Books Online. A fix or additional workaround is not necessary as this will only occur once while the MSSearch service re-sync's the table data with the FT Catalog even though it as already done a Full Population. Basically, it is un-documented that if you set "Change Tracking" with "Update Index in Background" that setting this option on an un-populated FT Catalog will automatically run a Full Population. If this option is set on a populated FT Catalog, then depending upon if a timestamp column is present in the FT-enable table, either a Full Population or Incremental Population (if timestamp present) to re-sync the FT Catalog with the FT-enable table. You can certainly add a timestamp column at a later time, when you have a need to drop the existing FT Catalog, or when you need to perform other table maintenance, but it is not necessary at this time as the re-sync will only be done once. Regards, John > Do you know any fix or work around of that since our production server cannot > have 20+ hours to rebuild this index twice. Is that help if I add timestamp [quoted text clipped - 20 lines] > > > > > > -Leon Thanks for your prompt reply. So, no matter if we run full population or not, FT catalog repopulation will kick off after I turned on the "change tracking " option. Is that better if I just set to "Change Tracking" with "Update Index in Background" for the unpopulated FT catalog without doing the full population at first place? In that way, one population is needed, right? -Leon > Leon Lee, > This is actually not a known problem, but is in fact by design, although I [quoted text clipped - 46 lines] > > > > > > > > -Leon That is correct, you will always get the full scan even if you do a full population before enabling change tracking with update index in background. Your best bet is not to do the full population. > Thanks for your prompt reply. So, no matter if we run full population or > not, [quoted text clipped - 68 lines] >> > > > >> > > > -Leon You're welcome, Leon, Yes, you are correct. It is better to just set "Change Tracking" with "Update Index in Background" and let it kick off the FT Population. If it is un-populated a Full Population will be executed, if it is populated and a timestamp column is present, then an Incremental Population will be executed, otherwise a Full Population will be executed! Regards, John > Thanks for your prompt reply. So, no matter if we run full population or not, > FT catalog repopulation will kick off after I turned on the "change tracking [quoted text clipped - 54 lines] > > > > > > > > > > -Leon |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.