odd NETWORKIO lock problem after move to w2k3

I recently moved a hosted site to a new server, and now am getting NETWORKIO
locks, and am having a hard time resolving the issue.
The site is ASP/SQL Server 2000, with fairly low quality code. The ASP was
generated by Dreamweaver and in many cases copy/pasted from the web.
The site was originally running on a shared hosting web server, with its
database on a seperate shared hosting database server, both running w2k.
Due to the site's traffic, it was moved to a dedicated machine, with web and
database all running on the same w2k3 box, which is when the problem began.
The problem occurs when a particular insert is executed. That insert locks
the table, and then itself is blocked with a wait type of NETWORKIO. The
insert is a simple INSERT INTO (...) VALUES (...). This has a few triggers
to clean data, but nothing huge. The insert blocks many other processes
until ADODB times out, and then everything chugs along. This seems to be an
intermittent issue, sometimes easily reproducible, and other times working
very well. This problem began when the database was moved. ASP connects
using TCP to 127.0.0.1
My main question: Why is that insert getting blocked on NETWORKIO?
The old shared hosting server was a bit more powerful than the new dedicated
box, but would a better server solve deadlock issues?
I've loaded up the performance monitor, and the bandwidth available on
localhost gets pegged out occasionally, but not as frequently as we see this
problem.
I've been googling this problem for about a month and a half, any clues
would be greatly appreciated.try to do an
UPDATE STATISTICS
on the table for which the insert is causing the problem and see.
Hope this helps.|||
"Omnibuzz" wrote:

> try to do an
> UPDATE STATISTICS
> on the table for which the insert is causing the problem and see.
> Hope this helps.
That solved it briefly last w, but didn't fix it when it was reported
again today.
I've setup a maintanence plan to do this every sunday night, using a 10%
sample.
Do I need to use a bigger sample or something?|||"Ryan Davis" wrote:

> This problem began when the database was moved.
Do any other types of queries suffer the same problems, or only just the
inserts? When the database was moved, were the indexes rebuilt, or just plai
n
dropped? Is the log file on the same physical disk with the data files?|||Other queries seem fine, although I'm not sure how thoroughly my client has
tested their site, but there have been no other bug reports from their users
.
The indexes were rebuilt based on using the Index Tuning Wizard against a
trace of about an hours worth of site usage. The old indexes were dropped,
and the new ones put in place. A little later sp_updatestats was run, and
then the indexes really made a difference over the rest of the site.
The log and data files are on the same disk, which is a software RAID(1) dis
k.
"Mark Williams" wrote:

> "Ryan Davis" wrote:
>
> Do any other types of queries suffer the same problems, or only just the
> inserts? When the database was moved, were the indexes rebuilt, or just pl
ain
> dropped? Is the log file on the same physical disk with the data files?
>|||You can do a full scan (sampling 100%) for once and may be reduce the time
interval.
The way I see, sampling of 10 percent will give you the right picture only
for an equally distributed table with less insert operations.
Why don't you try to turn on the autostats for this particular table.
use SP_AUTOSTATS|||autostats are enabled for this table.
"Omnibuzz" wrote:

> You can do a full scan (sampling 100%) for once and may be reduce the time
> interval.
> The way I see, sampling of 10 percent will give you the right picture on
ly
> for an equally distributed table with less insert operations.
> Why don't you try to turn on the autostats for this particular table.
> use SP_AUTOSTATS|||then it might the fragmentation in the file system at the OS level :)|||autostats for that table are now disabled, and I'll run an UPDATE STATISTICS
on a schedule for that table.
One possibility is the index tuning wizard added 10 non-unique
non-clustered indexes, which should be slowing down INSERTs, but they work
consistently in other places in code, so I'm at a loss.
"Omnibuzz" wrote:

> then it might the fragmentation in the file system at the OS level :)
>|||Did you look at the fillfactor for the table and the indexes.
try DBCC showcontig and see the extent and logical framentation.
If its > 10 then do an index defrag.
And then see.