I've read this has to do with IO conflicts, but does it really matter?
I have a problem with a table with two text columns- it's only 80,000
rows but about 6 gb of text- the full text population takes forever
(+3 days) and it's still going on. Also, the server's full text
queries are really slow. Mssearch is consuming about 700mb of memory
and consistently around 60% cpu. The machine is a dual xeon 3.0mb
with 2GB of ram, sql server 2k sp3. I can't stop the population, and
more importantly the catalog statistics haven't changed for about 6
hours. Something is wrong and I can't figure out what... Anybody have
ideas?

Mike,
No, something is not wrong... Unless of course, you've reviewed the server's
Application event log for "Microsoft Search" or MssCi source event (warnings
or errors). Unfortunately, SQL Server 2000 FTS is slow for many reasons,
writing to the same disk array as the database mdf or ldf files are on, are
just one of the issue. Memory availability & resource_usage level being the
others as well as the language of the text and most importantly, the total
number of rows in the FT-enable table...

What type of population (Full, Incremental or "change tracking" with "update
index in background) do you have currently running? Also, is the "6 gb of
text", pure text, i.e., not MS Word documents stored in an IMAGE column?
What is the language of the text? Do you currently have the FT Catalog on
the same disk array as the database mdf or ldf files? What is the disk array
type - RAID5 or RAID10 or ?

Regards,
John



[quoted text, click to view]

I looked at the event logs, and nothing funny came up. The language has
been set to default (english), the total number of rows is 80,000, it's
straight text (in a text field, not ntext). I have other databases on
the server which are fine doing a full population, but this is the
largest (by about twice as much). The FT catalog is on the same disk
array, and it's a six disk SCSI Raid 5.

What should I be looking for under memory availability and
resource_usage?

*** Sent via Devdex http://www.devdex.com ***

Thanks, Michael,
Yes, in your case the FT Catalogs should be on a separate disk and if you
monitor the disk i/o Perfmon counters, I suspect that you will see disk i/o
(read vs. write) contention. Of course, I'm assuming that when you say "The
FT catalog is on the same disk array", that you mean that the FT Catalog
folder is on the same disk array as your database files on this server.
Correct?

Additionally, having the FT Catalog on a RAID5 disk array can also be a
performance penalty and my recommendation is for you to stop the FT
Population on this server, set the "Microsoft Search" service to manual and
re-boot the server. Then we can manually de-reference the FT Catalog from
the system tables and registry and then delete the physical FT Catalog, then
reboot the server again and you should then be able to re-create this FT
Catalog on its own Disk array (RAID0 or RAID10 recommended), separate from
the database files.

Regards,
John



[quoted text, click to view]