It should work. 200,000 inserts per day works out to be about 417 inserts per minute if you distribute these updates over a 8 hour period.
I did some testing on a IDE Raid controller - adaptec 1200 with 4 drives and placed my catalog on this. I believe I got a 10% increase in performance while indexing.
Placing my database on a Raid 5 drive (adaptec 2000s) I got a 23% increase in performance in conjunction with the IDE raid controller.
"Phil Sherrod" wrote:
>
> On 14-Jun-2004, "Hilary Cotter" <hilaryk@att.net> wrote:
>
> > An incremental population is very similar to a full population. In both of
> > them all rows are extracted. In a full population all rows are indexed, in
> > an incremental population all the rows are extrated and then MSSearch does
> > some analysis to find out which rows are changed, inserted or deleted. So
> > if
> > a large number of rows are changed you are better off using a full
> > population.
> >
> > Microsoft recommends you use change tracking to get around the poor
> > performance of both full and incremental indexing.
>
> Excuse me for butting into this thread, but we are experiencing a similar
> problem with the incremental indexing. In our case, our database currently
> has 3.2 million rows, but we expect it to grow to about 6 million rows. We
> are adding about 200,000 rows per day, and once we reach full size we will
> add and delete 200+ k rows/day.
>
> Currently, the "incremental" index build takes over 8 hours, and it is
> getting slower each day. Do you think change tracking would be suitable for
> our situation with 200+ k insertions and deletions per day?
>
> Currently we have two 7200 RPM IDE disks in a RAID 0 array. Do you think a
> caching RAID controller would significantly improve performance? How about
> switching to SCSI?
>
> Thank you for your help.
>
> --
> Phil Sherrod
> (phil.sherrod 'at' sandh.com)
>
http://www.dtreg.com (decision tree modeling)
>
http://www.nlreg.com (nonlinear regression)
