I have a table with a clustered primary key index with a 90% fillfactor and a second composite (two column) non-clustered index. The table has less than 300,000 rows. We have a separate archive table to keep the row count under 300,000. The table receives far more inserts and updates than reads. Performance monitor counters for the following are all well within accepted allowances: PhysicalDisk - %Disk Time - _Total PhysicalDisk - Current Disk Queue Length - _Total System - % Total Processor Time System - Processor Queue Length SQLServer: Access Methods - Page Splits/Sec SQLServer: Memory Manager - Target Server Memory SQLServer: Memory Manager - Total Server Memory SQLServer: Locks - Average Wait Time ms - _Total (always returns 0, never a lock) DBCC TraceOn(3605,1204,-1) - (no indication of dead locks) Daily, we delete from the table to an archive table, perform a transaction log backup, and then run a maintenance plan to shrink the database and reorganize the data and index pages. If we do not perform this daily routine, the application services communicating with the database time out at 30 seconds. As long as we perform this daily routine, in running a duration trace in Profiler, normal statement duration times for these inserts and updates are in the milliseconds. The 30 second command time out seems more than adequate. When we do not perform this daily routine we see the following in Profiler: 1. Only the inserts are failing (timing out at 30 seconds), but not all. A service that fails on an insert, can turn right around and perform a successful insert in milliseconds the next time around. The same service that timed out when inserting can turn right around and successfully perform an update in milliseconds. 2. Only inserts are failing (timing out). Updates do no fail. 3. There is no gradual buildup in duration time. Every duration is at milliseconds and then all of a sudden a service times out inserting at 30 seconds. 4. The rows size being inserted rarely exceeds 1MB and those that time out are often only several hundred bytes in size, if even that. 5. The data files are set to automatically grow at 10%. The data file is 6GB and does not show any growth or even near the threshold of growing when the inserts are timing out (remember that some inserts continue to succeed in milliseconds and all updates are succeeding in milliseconds). 6. The log files are set to automatically grow at 10%. The log file is 215MB and a transaction log backup is performed every 2 hours. Occasionally it does grow, but most of the time by the time the two hour backup comes around, it is around 50-60% used, or 40-50% free space (remember that some inserts continue to succeed in milliseconds and all updates are succeeding in milliseconds). With that lengthy background, do you have any insight on what may be at issue? When the timeouts occur we stop the application services, archive (delete some records from the table receiving the inserts), perform a transaction log backup, and then optimize by shrinking the database files and reorganize the data and index pages. Then we restart the application services and things proceed without any insert timeouts.