"Jake Jessup" <watcherdude@hotmail.com> wrote in message news:<F26Cc.76408$EK5.32404@newssvr29.news.prodigy .com>...[color=blue]
> To
www.sysinternals.com and download two programs. One is called Filemon,
> the other is Regmon.
>
> I suspect Filemon will help you more.
>
> This will show you if there is any file or registry activity at all and if
> not, will likely reveal what file was running and causes the CPU to drop.
>
> I would also suggest taking an image of the production server, putting it on
> similar hardware and reinstalling your upgrade. Heck, you might even want to
> image it and do it on the same machine (after getting a proper backup AND
> the image file).
>
> Regmon is similar to filemon but may provide clues to what's going on as
> well.
>
> I hope this helps.
>
> "Patrick Moore" <patrick@wyrmhole.org> wrote in message
> news:4e024fd1.0406221655.7032c65f@posting.google.c om...[color=green]
> > We have a SQL 7.0 Standard Server running on a Windows 2000 Server
> > machine with 2 800mhz Pentium III with 2GB memory. Our front end is
> > Access 97 and 2000 with most ADO connections for the scripts but some
> > DAO for forms and reports. We recently "released" a new version of
> > the "database" that caused a catastrophic event to start happening
> > with our SQL server.
> >
> > Using PerfMon we monitored the CPU utilization on the server and
> > noticed that the CPU load would drop to 0 for approx 5-10 seconds and
> > then jump back up to our average 60-70% utilization. During this
> > drop, there is NO disk activity no new connections being made, etc.
> > We then took the process a step further and loaded a "stress" program
> > that put about 30% load on the server to start with. Then we
> > monitored each processes load. SQL Server process would drop to 0%
> > while the stress process continued at 30%.
> >
> > The problem is that the SQL does absolutely NOTHING for 5-10 seconds.
> > You cannot connect, any querys that are running stop, their is no disk
> > activity (logs, data drives), and you cannot even get sp_who2 to run
> > from Query Analyser. We thought maybe blocking (we have built an
> > "app" that monitors this), but we don't see any blocking before it
> > locks and nothing after it locks.
> >
> > Out of despiration we "rolled back" to our previous version to get
> > people working again. After business hours, we have tried to
> > duplicate the problem on machines (2 or 3 at a time) but cannot get it
> > to duplicate the problem.
> >
> > The only experience we had previous to this was using DNS to resolve
> > the server name which caused a problem EXTREMELY familar to this
> > problem. However, we have double checked every machine we have, and
> > none of them are using DNS to resolve.
> >
> > Any idea's would be most appreciated.
> >
> > Patrick Moore[/color][/color]
Without knowing too much about your system
I will highly recommend you run a trace/profiler
A poorly indexed and highly accessed table
has been known to bring things to a halt.
After you do that feed the index tuning
wizard with the trace file for a start
May be that will put out the heat
Vincento
