I have the following scenario: 2 SQL 2000 boxes (Enterprise Edition) - One is a production box. (Multiple applications access it.) - One is dedicated to a single application (except during a "download window"). During most of any given day, the "dedicated" server is accessed by a single application that makes one stored procedure call (through ODBC). This stored procedure needs to return in under 300MS ALWAYS. Normally (84.07% of the time), the stored procedure executes in less than 10MS. 99.89% of the time it executes in under 300MS. The times when it doesn't execute under 300MS, it executes in anywhere from 300MS-1600MS. These times coincide with the "download window" (not surprising). The "download" consists of an import process on the production box calling a remote procedure (that inserts one record) on the dedicated box. This "insert" procedure also USUALLY executes in under 10MS but spikes in the same pattern/dispersion as the stored procedure called through ODBC. So, during the "download window," I end up with ~99.9% of the stored procedure executions completing in under 300MS. I need to get this number closer to 100%. I have tracked every pattern I can think of, and I have noticed that the "burst" completion times are never isolated. They are always bunched in groups of 10-20 calls. The execution times seem to "burst" every 5-8 minutes. I don't believe there is any way to "prioritize" one stored procedure over another. I am out of ideas as to potential places I can look to figure out some way to improve the execution times of the delinquent stored procedures. The "dedicated" box is a quad processor with 4GIG of memory, so I don't believe this is a hardware or memory limitation. Other than the two processes I have described above, there is nothing running on the "dedicated" box during this time. SQL Server is the only software installed besides the operating system and (I think.) a backup software. Any ideas as to things to look into would be greatly, greatly appreciated.