August 10, 2006 at 8:59 am
Any suggestions and/or supporting documentation for best practices on where to locate the full text catalog files. Especially as related to other data, log, and tempdb files?
My searching is coming up empty.
Thanks in advance.
Terry
August 14, 2006 at 8:00 am
This was removed by the editor as SPAM
October 31, 2007 at 2:44 pm
In our production envirionment we have 3 catalogs taking nearly 20GB space. We did not experiment with performance in terms of it's location but keeping them on the same drive as the database data file is working well for us. Perhaps, it is not noticeable because these are high end SAN drives.
But if you think about the whole FTS process logically, I'd think that having the full text index (basically the catalog) on the same drive as the base tables/views makes the best sense because usually more data is written to the tables (and then the index) than it is read from from by few users on the UI. So, from an overall system performance point of view keeping them on the same drive is better. From a pure querying the index/catalog point of view it may makes little sense to justify puting the catalog in it's own drive because the whole idea of having an index on a table/view is that it's fast by nature. Any additional gain in speed from disk seperation is probably marginal/negligible/unnoticeable at best.
Amar
Amar
October 31, 2007 at 2:48 pm
Thanks Amar
October 31, 2007 at 3:19 pm
I would tend to disagree with Amar. Right now, we have about 5000 Terabytes (5 petabytes, if you wish) of databases with about 30% being FT Catalogs in a mixed 2000/2005 environment. There are several reasons that you may want to place the catalogs on their own separate drives, if you have the luxury. I would also say it depends on the volume of FT data that's indexed vs. normal data, and how often the FT data needs to be indexed.
That being said, I would say here are the things you could consider doing:
1) Separate volume for log files
2) Separate volume for tempdb
3) Separate volume for FT Data
4) Separate volume for FT Indexes
This is for FT heavy searches, of course. Also, keep in mind that FT indexes are large, so you want good I/O throughput. If a FT index gets corrupt in SQL 2000 (it can happen a lot), the speed at which it is rebuilt and how much it affects other systems depends a good deal on separation from other logical volumes. If you can, post more info on the scale (GB) and how you plan to use the FT indexes, so we can give you better info. One size does not fit all.
Thanks,
Eric
October 31, 2007 at 3:30 pm
Thank you Eric and Amar.
I'm not sure you noticed, but my original post was from 08/06. We deployed with the FT indexes on the data drive, and for our usage it has been fine (at least no complaints). Its no where near the size of your environment Eric, with the indexes totaling 1.2GB on @30GB of data.
Thanks again.
October 31, 2007 at 3:54 pm
Sorry, the post from Amar made the thread active again on the main site. I hope all is going well nonetheless. And just for good measure:
This thread is dead! No more posts please!
Eric
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply