opening ADP combo box causes high CPU utilization on SQL Server; query never completes

Hello all,
I'm using an Access 2000 (9.0.6926 SP-3) ADP as a front-end to a SQL Server
2000 (8.00.760 SP-3) database. SQL Server is running on a dedicated server.
There is a certain query, based on a view, that completes in about two
seconds via Query Analyzer. (It's a straightforward SELECT ... FROM
view_name WHERE ...; I'll spare you the code since the view does end up
hitting many tables, and I'm mostly curious whether this is a well-known bug
I wasn't able to find.) The query returns less than 300 rows.
We're using that query as the Row Source for a combo box in the ADP
front-end. When attempting to expand the combo box, the ADP seems to
freeze. CPU utilization for sqlservr.exe jumps to around 99. Firing up
Profiler beforehand and doing a trace on SQL Server shows a
SQL:BatchStarting and SQL:StmtStarting, with the TextData being the SELECT,
as I'd expect.
Eventually, if I kill the ADP (via task manager), the trace shows a
SQL:BatchCompleted with high numbers for CPU and Reads (unscientifically, it
seems that the longer I let the ADP run, the higher the numbers). There is,
of course, no SQL:StmtCompleted. I'm inclined to believe that, somehow, the
way that Access submits the query is different from Query Analyzer and is
causing SQL Server to go into an infinite loop of some kind.
I'm hoping this is a straightforward, known issue. I'd rather not open a
call with Microsoft; the beauracracy here with providing the up-front fee
(even if it is refunded) would make doing so very painful and difficult. I
can provide more back-end code, the execution plans, trace information,
etc., if anyone takes an interest. Thanks in advance for any help!
Regards,
Brian J. Parker
Systems Coordinator, Childhood Depression Research
Western Psychiatric Institute and Clinic, UPMC Health SystemA little follow-up on this problem:
The view on which the hanging SELECT is based includes a join between two
large tables; they were being joined on a shared derived (text) column
because the view writer didn't want to type out all the underlying integer
columns instead.
I re-wrote the view to use "real" columns and the problem vanishes (which
takes away some of the urgency). My original issue is, I think, still
valid-- a query that takes six seconds in Query Analyzer shouldn't run
indefinitely as the row source of a combo box-- but this may be a clue.
Regards,
Brian|||This would depend on how the data is retrieved for the combo box. Is it a bound control? That could be adding some overhead on the query being sent to SQL Server.|||"Doug Guerena" <anonymous@.discussions.microsoft.com> wrote in message
news:B676064D-81AB-43FB-AE1C-23EC93FCC069@.microsoft.com...
> This would depend on how the data is retrieved for the combo box. Is it a
bound control? That could be adding some overhead on the query being sent
to SQL Server.
No, it's not a bound control, but thanks for the suggestion.
If you're curious: the control provides a list of research study interviews
meeting certain criteria. Based on the user's selection, we launch a report
that provides some information related to that interview.
Regards,
Brian

opening ADP combo box causes high CPU utilization on SQL Server; query never completes

Hello all,
I'm using an Access 2000 (9.0.6926 SP-3) ADP as a front-end to a SQL Server
2000 (8.00.760 SP-3) database. SQL Server is running on a dedicated server.
There is a certain query, based on a view, that completes in about two
seconds via Query Analyzer. (It's a straightforward SELECT ... FROM
view_name WHERE ...; I'll spare you the code since the view does end up
hitting many tables, and I'm mostly curious whether this is a well-known bug
I wasn't able to find.) The query returns less than 300 rows.
We're using that query as the Row Source for a combo box in the ADP
front-end. When attempting to expand the combo box, the ADP seems to
freeze. CPU utilization for sqlservr.exe jumps to around 99. Firing up
Profiler beforehand and doing a trace on SQL Server shows a
SQL:BatchStarting and SQL:StmtStarting, with the TextData being the SELECT,
as I'd expect.
Eventually, if I kill the ADP (via task manager), the trace shows a
SQL:BatchCompleted with high numbers for CPU and Reads (unscientifically, it
seems that the longer I let the ADP run, the higher the numbers). There is,
of course, no SQL:StmtCompleted. I'm inclined to believe that, somehow, the
way that Access submits the query is different from Query Analyzer and is
causing SQL Server to go into an infinite loop of some kind.
I'm hoping this is a straightforward, known issue. I'd rather not open a
call with Microsoft; the beauracracy here with providing the up-front fee
(even if it is refunded) would make doing so very painful and difficult. I
can provide more back-end code, the execution plans, trace information,
etc., if anyone takes an interest. Thanks in advance for any help!
Regards,
Brian J. Parker
Systems Coordinator, Childhood Depression Research
Western Psychiatric Institute and Clinic, UPMC Health SystemA little follow-up on this problem:
The view on which the hanging SELECT is based includes a join between two
large tables; they were being joined on a shared derived (text) column
because the view writer didn't want to type out all the underlying integer
columns instead.
I re-wrote the view to use "real" columns and the problem vanishes (which
takes away some of the urgency). My original issue is, I think, still
valid-- a query that takes six seconds in Query Analyzer shouldn't run
indefinitely as the row source of a combo box-- but this may be a clue.
Regards,
Brian|||This would depend on how the data is retrieved for the combo box. Is it a b
ound control? That could be adding some overhead on the query being sent to
SQL Server.|||"Doug Guerena" <anonymous@.discussions.microsoft.com> wrote in message
news:B676064D-81AB-43FB-AE1C-23EC93FCC069@.microsoft.com...
> This would depend on how the data is retrieved for the combo box. Is it a
bound control? That could be adding some overhead on the query being sent
to SQL Server.
No, it's not a bound control, but thanks for the suggestion.
If you're curious: the control provides a list of research study interviews
meeting certain criteria. Based on the user's selection, we launch a report
that provides some information related to that interview.
Regards,
Brian

Only one CPU is used by the server

How can I utilize all four CPU′s by the SQL server?

Configuration:

HPDL385 2 x Intel Xenon 5160 3 GHz Dual Core, 4 GB Ram

Windows Server 2005

SQL Server 2005 Standard Edition

When running heavy SQL SP′s, the CPU load is only 25% nicely distributed over the four CPU′s as if only 1 CPU was present.

Is it the operating system that creates this problem or the SQL server?

How does the SQL server react if the license somehow is configured wrong - is this the problem?

Regards

Is because use a CPU per query.

How do you test? with a one query or several paralell queries?

Regards.|||

I test with two paralell queries.

When the second query is fired, the load remains the same.

|||

This is the normal behavoir, where SQL Server 2005 will try to spread the load evenly among the four processors. You can experiment by appending OPTION MAXDOP(1) to the end of a query, then running it in a query window in SSMS and turning on the graphical execution plan. Then appending OPTION MAXDOP(4) to the end of a query, then running it to see if the query uses parallism.

Quite often, for OLTP workloads, you will be better off with MAXDOP(1).

|||You could set the processor affinity so sql server uses only one cpu and watch what happens, then allow it to use more and see the difference.

http://msdn2.microsoft.com/en-us/library/ms187104.aspx

(i think multi cores are handled as physical cpu's but prob best to check it out)

aaron

only 1 out of 8 CPU maxed out

Hello
I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
running just fine but only one out of the 8 CPUs is running at 90%+
constantly. So avg is OK bit our alerting doesn't understand this.
Any way of determining what is running on that 1 CPU? This does not look
normal.
We dont have CPU affinitised and SQL Server is the only app on the box.
Are there some relevant perfmon counters I can check
tks
-- cranfield, DBA
This is not unusual. You have a SQL process that is not parallelizable.
Probably something with derived columns, cursors, or intense calculations.
Those are the "usual suspects" when it comes to single-threaded apps. SQL
runs processes across multiple processors where possible, but it is not
always possuble.
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
> Hello
> I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
> running just fine but only one out of the 8 CPUs is running at 90%+
> constantly. So avg is OK bit our alerting doesn't understand this.
> Any way of determining what is running on that 1 CPU? This does not look
> normal.
> We dont have CPU affinitised and SQL Server is the only app on the box.
> Are there some relevant perfmon counters I can check
> tks
> --
> -- cranfield, DBA
|||Thanks for the reply.
We have complete mirrored/parallel systems and on ServerB (which is
identical to the ServerA in question) we see similar CPU profile where 1 of
the CPUs spikes. Its not as pronounced as ServerA and load seems to be much
more evenly shared across the CPUs.
ServerA - CPU 0,1,2,3,4,5,7 - avg 5-10%; CPU6 - avg 90%
ServerB - CPU 0,1,2,3,4,5,7 - avg 10-30%; CPU6 - avg 60%
* exact same hardware
* exact same load (mostly continuous, batched, 1024 row bulk inserts)
*
I wonder what is causing the difference. Obviously I would prefer them to
use all CPUs.
-- cranfield, DBA
"Geoff N. Hiten" wrote:

> This is not unusual. You have a SQL process that is not parallelizable.
> Probably something with derived columns, cursors, or intense calculations.
> Those are the "usual suspects" when it comes to single-threaded apps. SQL
> runs processes across multiple processors where possible, but it is not
> always possuble.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
>
>
> "Cranfield" <alan_cranfield@.msn.co.za> wrote in message
> news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
>
|||If it's always the same CPU I'd be a bit suspicious. Check for an affinity
mask. What Sql Server product/licence are you using?
We get worse performance with parallel query. Although we have maxdup at 1
we still use all 8 cpus.
Regards
Paul Cahill
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:563A3C37-DDD5-4816-8898-C74966E33C00@.microsoft.com...[vbcol=seagreen]
> Thanks for the reply.
> We have complete mirrored/parallel systems and on ServerB (which is
> identical to the ServerA in question) we see similar CPU profile where 1
> of
> the CPUs spikes. Its not as pronounced as ServerA and load seems to be
> much
> more evenly shared across the CPUs.
> ServerA - CPU 0,1,2,3,4,5,7 - avg 5-10%; CPU6 - avg 90%
> ServerB - CPU 0,1,2,3,4,5,7 - avg 10-30%; CPU6 - avg 60%
> * exact same hardware
> * exact same load (mostly continuous, batched, 1024 row bulk inserts)
> *
> I wonder what is causing the difference. Obviously I would prefer them to
> use all CPUs.
> --
> -- cranfield, DBA
>
> "Geoff N. Hiten" wrote:
|||What version of SQL Server and Service pack? The way in which the
connections are tied to schedulers is different in both with 2000 having
more issues. How many concurrent connections do you have and what processors
are most of them on?
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
> Hello
> I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
> running just fine but only one out of the 8 CPUs is running at 90%+
> constantly. So avg is OK bit our alerting doesn't understand this.
> Any way of determining what is running on that 1 CPU? This does not look
> normal.
> We dont have CPU affinitised and SQL Server is the only app on the box.
> Are there some relevant perfmon counters I can check
> tks
> --
> -- cranfield, DBA
|||morning!
Both servers on SP2 + hotfix:
SQL Server 2005 - 9.00.3152.00 (Intel X86) Enterprise Edition on Windows NT
5.2 (Build 3790: Service Pack 2)
* sp_who2 shows 69 SPIDs (28 active)
How do I know which processers my connections are on?
tks
-- cranfield, DBA
"Andrew J. Kelly" wrote:

> What version of SQL Server and Service pack? The way in which the
> connections are tied to schedulers is different in both with 2000 having
> more issues. How many concurrent connections do you have and what processors
> are most of them on?
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Cranfield" <alan_cranfield@.msn.co.za> wrote in message
> news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
>

only 1 out of 8 CPU maxed out

Hello
I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
running just fine but only one out of the 8 CPUs is running at 90%+
constantly. So avg is OK bit our alerting doesn't understand this.
Any way of determining what is running on that 1 CPU? This does not look
normal.
We dont have CPU affinitised and SQL Server is the only app on the box.
Are there some relevant perfmon counters I can check
tks
--
-- cranfield, DBAThis is not unusual. You have a SQL process that is not parallelizable.
Probably something with derived columns, cursors, or intense calculations.
Those are the "usual suspects" when it comes to single-threaded apps. SQL
runs processes across multiple processors where possible, but it is not
always possuble.
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
> Hello
> I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
> running just fine but only one out of the 8 CPUs is running at 90%+
> constantly. So avg is OK bit our alerting doesn't understand this.
> Any way of determining what is running on that 1 CPU? This does not look
> normal.
> We dont have CPU affinitised and SQL Server is the only app on the box.
> Are there some relevant perfmon counters I can check
> tks
> --
> -- cranfield, DBA|||Thanks for the reply.
We have complete mirrored/parallel systems and on ServerB (which is
identical to the ServerA in question) we see similar CPU profile where 1 of
the CPUs spikes. Its not as pronounced as ServerA and load seems to be muc
h
more evenly shared across the CPUs.
ServerA - CPU 0,1,2,3,4,5,7 - avg 5-10%; CPU6 - avg 90%
ServerB - CPU 0,1,2,3,4,5,7 - avg 10-30%; CPU6 - avg 60%
* exact same hardware
* exact same load (mostly continuous, batched, 1024 row bulk inserts)
*
I wonder what is causing the difference. Obviously I would prefer them to
use all CPUs.
-- cranfield, DBA
"Geoff N. Hiten" wrote:

> This is not unusual. You have a SQL process that is not parallelizable.
> Probably something with derived columns, cursors, or intense calculations.
> Those are the "usual suspects" when it comes to single-threaded apps. SQL
> runs processes across multiple processors where possible, but it is not
> always possuble.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
>
>
> "Cranfield" <alan_cranfield@.msn.co.za> wrote in message
> news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
>|||If it's always the same CPU I'd be a bit suspicious. Check for an affinity
mask. What Sql Server product/licence are you using?
We get worse performance with parallel query. Although we have maxdup at 1
we still use all 8 cpus.
Regards
Paul Cahill
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:563A3C37-DDD5-4816-8898-C74966E33C00@.microsoft.com...[vbcol=seagreen]
> Thanks for the reply.
> We have complete mirrored/parallel systems and on ServerB (which is
> identical to the ServerA in question) we see similar CPU profile where 1
> of
> the CPUs spikes. Its not as pronounced as ServerA and load seems to be
> much
> more evenly shared across the CPUs.
> ServerA - CPU 0,1,2,3,4,5,7 - avg 5-10%; CPU6 - avg 90%
> ServerB - CPU 0,1,2,3,4,5,7 - avg 10-30%; CPU6 - avg 60%
> * exact same hardware
> * exact same load (mostly continuous, batched, 1024 row bulk inserts)
> *
> I wonder what is causing the difference. Obviously I would prefer them to
> use all CPUs.
> --
> -- cranfield, DBA
>
> "Geoff N. Hiten" wrote:
>|||What version of SQL Server and Service pack? The way in which the
connections are tied to schedulers is different in both with 2000 having
more issues. How many concurrent connections do you have and what processors
are most of them on?
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
> Hello
> I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
> running just fine but only one out of the 8 CPUs is running at 90%+
> constantly. So avg is OK bit our alerting doesn't understand this.
> Any way of determining what is running on that 1 CPU? This does not look
> normal.
> We dont have CPU affinitised and SQL Server is the only app on the box.
> Are there some relevant perfmon counters I can check
> tks
> --
> -- cranfield, DBA|||morning!
Both servers on SP2 + hotfix:
SQL Server 2005 - 9.00.3152.00 (Intel X86) Enterprise Edition on Windows NT
5.2 (Build 3790: Service Pack 2)
* sp_who2 shows 69 SPIDs (28 active)
How do I know which processers my connections are on?
tks
--
-- cranfield, DBA
"Andrew J. Kelly" wrote:

> What version of SQL Server and Service pack? The way in which the
> connections are tied to schedulers is different in both with 2000 having
> more issues. How many concurrent connections do you have and what processo
rs
> are most of them on?
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Cranfield" <alan_cranfield@.msn.co.za> wrote in message
> news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
>

only 1 out of 8 CPU maxed out

Hello
I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
running just fine but only one out of the 8 CPUs is running at 90%+
constantly. So avg is OK bit our alerting doesn't understand this.
Any way of determining what is running on that 1 CPU? This does not look
normal.
We dont have CPU affinitised and SQL Server is the only app on the box.
Are there some relevant perfmon counters I can check
tks
--
-- cranfield, DBAThis is not unusual. You have a SQL process that is not parallelizable.
Probably something with derived columns, cursors, or intense calculations.
Those are the "usual suspects" when it comes to single-threaded apps. SQL
runs processes across multiple processors where possible, but it is not
always possuble.
--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
> Hello
> I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
> running just fine but only one out of the 8 CPUs is running at 90%+
> constantly. So avg is OK bit our alerting doesn't understand this.
> Any way of determining what is running on that 1 CPU? This does not look
> normal.
> We dont have CPU affinitised and SQL Server is the only app on the box.
> Are there some relevant perfmon counters I can check
> tks
> --
> -- cranfield, DBA|||Thanks for the reply.
We have complete mirrored/parallel systems and on ServerB (which is
identical to the ServerA in question) we see similar CPU profile where 1 of
the CPUs spikes. Its not as pronounced as ServerA and load seems to be much
more evenly shared across the CPUs.
ServerA - CPU 0,1,2,3,4,5,7 - avg 5-10%; CPU6 - avg 90%
ServerB - CPU 0,1,2,3,4,5,7 - avg 10-30%; CPU6 - avg 60%
* exact same hardware
* exact same load (mostly continuous, batched, 1024 row bulk inserts)
*
I wonder what is causing the difference. Obviously I would prefer them to
use all CPUs.
--
-- cranfield, DBA
"Geoff N. Hiten" wrote:
> This is not unusual. You have a SQL process that is not parallelizable.
> Probably something with derived columns, cursors, or intense calculations.
> Those are the "usual suspects" when it comes to single-threaded apps. SQL
> runs processes across multiple processors where possible, but it is not
> always possuble.
> --
> Geoff N. Hiten
> Senior SQL Infrastructure Consultant
> Microsoft SQL Server MVP
>
>
> "Cranfield" <alan_cranfield@.msn.co.za> wrote in message
> news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
> > Hello
> >
> > I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
> > running just fine but only one out of the 8 CPUs is running at 90%+
> > constantly. So avg is OK bit our alerting doesn't understand this.
> >
> > Any way of determining what is running on that 1 CPU? This does not look
> > normal.
> >
> > We dont have CPU affinitised and SQL Server is the only app on the box.
> >
> > Are there some relevant perfmon counters I can check
> >
> > tks
> > --
> > -- cranfield, DBA
>|||If it's always the same CPU I'd be a bit suspicious. Check for an affinity
mask. What Sql Server product/licence are you using?
We get worse performance with parallel query. Although we have maxdup at 1
we still use all 8 cpus.
Regards
Paul Cahill
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:563A3C37-DDD5-4816-8898-C74966E33C00@.microsoft.com...
> Thanks for the reply.
> We have complete mirrored/parallel systems and on ServerB (which is
> identical to the ServerA in question) we see similar CPU profile where 1
> of
> the CPUs spikes. Its not as pronounced as ServerA and load seems to be
> much
> more evenly shared across the CPUs.
> ServerA - CPU 0,1,2,3,4,5,7 - avg 5-10%; CPU6 - avg 90%
> ServerB - CPU 0,1,2,3,4,5,7 - avg 10-30%; CPU6 - avg 60%
> * exact same hardware
> * exact same load (mostly continuous, batched, 1024 row bulk inserts)
> *
> I wonder what is causing the difference. Obviously I would prefer them to
> use all CPUs.
> --
> -- cranfield, DBA
>
> "Geoff N. Hiten" wrote:
>> This is not unusual. You have a SQL process that is not parallelizable.
>> Probably something with derived columns, cursors, or intense
>> calculations.
>> Those are the "usual suspects" when it comes to single-threaded apps.
>> SQL
>> runs processes across multiple processors where possible, but it is not
>> always possuble.
>> --
>> Geoff N. Hiten
>> Senior SQL Infrastructure Consultant
>> Microsoft SQL Server MVP
>>
>>
>> "Cranfield" <alan_cranfield@.msn.co.za> wrote in message
>> news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
>> > Hello
>> >
>> > I'm getting CPU alerts from one of our SQL servers. Problem is that SQL
>> > is
>> > running just fine but only one out of the 8 CPUs is running at 90%+
>> > constantly. So avg is OK bit our alerting doesn't understand this.
>> >
>> > Any way of determining what is running on that 1 CPU? This does not
>> > look
>> > normal.
>> >
>> > We dont have CPU affinitised and SQL Server is the only app on the box.
>> >
>> > Are there some relevant perfmon counters I can check
>> >
>> > tks
>> > --
>> > -- cranfield, DBA
>>|||What version of SQL Server and Service pack? The way in which the
connections are tied to schedulers is different in both with 2000 having
more issues. How many concurrent connections do you have and what processors
are most of them on?
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Cranfield" <alan_cranfield@.msn.co.za> wrote in message
news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
> Hello
> I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
> running just fine but only one out of the 8 CPUs is running at 90%+
> constantly. So avg is OK bit our alerting doesn't understand this.
> Any way of determining what is running on that 1 CPU? This does not look
> normal.
> We dont have CPU affinitised and SQL Server is the only app on the box.
> Are there some relevant perfmon counters I can check
> tks
> --
> -- cranfield, DBA|||morning!
Both servers on SP2 + hotfix:
SQL Server 2005 - 9.00.3152.00 (Intel X86) Enterprise Edition on Windows NT
5.2 (Build 3790: Service Pack 2)
* sp_who2 shows 69 SPIDs (28 active)
How do I know which processers my connections are on?
tks
--
-- cranfield, DBA
"Andrew J. Kelly" wrote:
> What version of SQL Server and Service pack? The way in which the
> connections are tied to schedulers is different in both with 2000 having
> more issues. How many concurrent connections do you have and what processors
> are most of them on?
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Cranfield" <alan_cranfield@.msn.co.za> wrote in message
> news:DA994330-99BA-4133-9739-02775C61ACEE@.microsoft.com...
> > Hello
> >
> > I'm getting CPU alerts from one of our SQL servers. Problem is that SQL is
> > running just fine but only one out of the 8 CPUs is running at 90%+
> > constantly. So avg is OK bit our alerting doesn't understand this.
> >
> > Any way of determining what is running on that 1 CPU? This does not look
> > normal.
> >
> > We dont have CPU affinitised and SQL Server is the only app on the box.
> >
> > Are there some relevant perfmon counters I can check
> >
> > tks
> > --
> > -- cranfield, DBA
>