Well, the explorer copy is the typical copy paste or drag and drop - either
way. It is first exported locally as a flat file, then copied via SMB. For
some reason, which I suspect is due to SQL server parametrization, simple DTS
copies using OLE DB are much slower.

This needs a little more description: A recent test involved a WinXP box
with SQL Server. Both hosts have the same version of SQL Server and dont
appear to have errors in event viewer. The test DTS copies a 129MB table
using OLE DB and it is transferred from a newly created database from the
problem server to a newly created database on the XP box, just in case
there's database mis-parametrizations. The DTS copy transfer speed is up to
10x faster copying from the XP machine to the problem server. However, the
DTS copy is not as fast as a simple explorer file copy of the same table as a
text file.
At no point is there a disc queue problem or space limitation on either
host. CPU and memory utilization is fine, yet the network bandwidth isnt
being used with DTS. There's a bottleneck on the problem SQL server host and
it doesnt seem to be disc, memory cpu or network hardware (changed cables and
switches).

What can be causing the slowdown in SQL server? Consistently up to 10x
slower importing to the problem win2k host, than exporting from it. Have
tried exporting and importing with different hosts, and this one has the
problem with transfer speed. The DTSs are executed locally from each host,
no remote execution.

A security patch maybe? Running out of ideas here.

[quoted text, click to view]