open source sql server project(s)

Where could some one find sql server open source project? Source Forge
projects for sql servers are very front end intensive. Are there any open
source sql server projects that would involve lots of database/server side
work that some one could participate in?
TIA..Hi
You should ask people from Microsoft.
BTW , did you mean open source like MySQL provided?
"sqlster" <trisha@.nospam.nospam> wrote in message
news:0AF98BC0-786A-46E4-B676-86A8B04B8ACA@.microsoft.com...
> Where could some one find sql server open source project? Source Forge
> projects for sql servers are very front end intensive. Are there any open
> source sql server projects that would involve lots of database/server side
> work that some one could participate in?
> TIA..|||By open source, I mean sourcforge.net type of projects. Some one comes up
with an idea and a project, posts the requirements, and volunteers around th
e
world work on the modules independently. This helps in "hands on" experience
.
"Uri Dimant" wrote:

> Hi
> You should ask people from Microsoft.
> BTW , did you mean open source like MySQL provided?
> "sqlster" <trisha@.nospam.nospam> wrote in message
> news:0AF98BC0-786A-46E4-B676-86A8B04B8ACA@.microsoft.com...
>
>|||Hi
> By open source, I mean sourcforge.net type of projects.
Does it relate somehow to SQL Server ?
"sqlster" <trisha@.nospam.nospam> wrote in message
news:46A40D79-2B1E-41B1-A994-BE3BCE496790@.microsoft.com...
> By open source, I mean sourcforge.net type of projects. Some one comes up
> with an idea and a project, posts the requirements, and volunteers around
> the
> world work on the modules independently. This helps in "hands on"
> experience.
> "Uri Dimant" wrote:
>

Only see groups in Enterprise Manager

I have to export the servers registered in Enterprise Manager and import the
servers into another 30 machines. I exported the registry of
HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL
Server\80\Tools\SQLEW\Registered Servers X
but when I import it, I only see the groups. Tried install and uninstall
enterprise manager but not helping.
thanks, larryYou may have to do it manually, and if so, the approach you're taking may
not be practical.
You could run profiler while setting up a registration, and see if it would
be possible to replicate the code that EM uses for the wizard and make it
programmable. I'm not sure if that will give you everything you need, since
some things might happen outside of the visibility of profiler.
I believe I read once that the sqldiag utility (located in the BINN folder)
will export registrations, but unless there's some undocumented argument I
haven't tried, I can only get it to store aliases (not registrations).
Do all 30 servers really need registrations to every single server? Are
they all round robin, so when you connect to manage all of them, you could
be on any node?
If not, you might consider reserving one or two "control" servers for
management, and not expecting to manage any server from any server.
If the servers just need to see each other (e.g. for queries) then it might
be better to just create aliases (if they're not DNS'able) and linked
servers (which are programmable) on all of the servers.
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"LarryLiMCDBA" <larryliwork@.hotmail.com> wrote in message
news:OAm0Xqt1DHA.2972@.TK2MSFTNGP09.phx.gbl...
> I have to export the servers registered in Enterprise Manager and import
the
> servers into another 30 machines. I exported the registry of
> HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL
> Server\80\Tools\SQLEW\Registered Servers X
> but when I import it, I only see the groups. Tried install and uninstall
> enterprise manager but not helping.
> thanks, larry
>|||By the way, registrations are user-based. Are you logging into the
destination machine with the same user as the source machine? It might be
that user-specific information is encoded in the data stored in those
registry values... so if you connect to Enterprise Manager as a different
user, or with SQL Server authentication, you might not see those
registrations.
Look in the registry of the destination machine and see which user your
registrations appear under. If the .reg file ran without error, they're
probably there somewhere.
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"LarryLiMCDBA" <larryliwork@.hotmail.com> wrote in message
news:OAm0Xqt1DHA.2972@.TK2MSFTNGP09.phx.gbl...
> I have to export the servers registered in Enterprise Manager and import
the
> servers into another 30 machines. I exported the registry of
> HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL
> Server\80\Tools\SQLEW\Registered Servers X
> but when I import it, I only see the groups. Tried install and uninstall
> enterprise manager but not helping.
> thanks, larry
>|||I tried both HKEY local machine and HKEY current user but couldn't make it
work. I was able to import the alias though and SQL Query Analyzer actually
works. I guess there is a encryption process somewhere for the registered
servers in EM.
tks, larry
"Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
news:%2300Ai9u1DHA.2328@.TK2MSFTNGP10.phx.gbl...
> By the way, registrations are user-based. Are you logging into the
> destination machine with the same user as the source machine? It might be
> that user-specific information is encoded in the data stored in those
> registry values... so if you connect to Enterprise Manager as a different
> user, or with SQL Server authentication, you might not see those
> registrations.
> Look in the registry of the destination machine and see which user your
> registrations appear under. If the .reg file ran without error, they're
> probably there somewhere.
> --
> Aaron Bertrand
> SQL Server MVP
> http://www.aspfaq.com/
>
>
> "LarryLiMCDBA" <larryliwork@.hotmail.com> wrote in message
> news:OAm0Xqt1DHA.2972@.TK2MSFTNGP09.phx.gbl...
> > I have to export the servers registered in Enterprise Manager and import
> the
> > servers into another 30 machines. I exported the registry of
> > HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL
> > Server\80\Tools\SQLEW\Registered Servers X
> >
> > but when I import it, I only see the groups. Tried install and
uninstall
> > enterprise manager but not helping.
> >
> > thanks, larry
> >
> >
>

Only see groups in Enterprise Manager

I have to export the servers registered in Enterprise Manager and import the
servers into another 30 machines. I exported the registry of
HKEY_CURRENT_USER\Software\Microsoft\Mic
rosoft SQL
Server\80\Tools\SQLEW\Registered Servers X
but when I import it, I only see the groups. Tried install and uninstall
enterprise manager but not helping.
thanks, larryYou may have to do it manually, and if so, the approach you're taking may
not be practical.
You could run profiler while setting up a registration, and see if it would
be possible to replicate the code that EM uses for the wizard and make it
programmable. I'm not sure if that will give you everything you need, since
some things might happen outside of the visibility of profiler.
I believe I read once that the sqldiag utility (located in the BINN folder)
will export registrations, but unless there's some undocumented argument I
haven't tried, I can only get it to store aliases (not registrations).
Do all 30 servers really need registrations to every single server? Are
they all round robin, so when you connect to manage all of them, you could
be on any node?
If not, you might consider reserving one or two "control" servers for
management, and not expecting to manage any server from any server.
If the servers just need to see each other (e.g. for queries) then it might
be better to just create aliases (if they're not DNS'able) and linked
servers (which are programmable) on all of the servers.
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"LarryLiMCDBA" <larryliwork@.hotmail.com> wrote in message
news:OAm0Xqt1DHA.2972@.TK2MSFTNGP09.phx.gbl...

quote:

---

> I have to export the servers registered in Enterprise Manager and import

---

the

quote:

---

> servers into another 30 machines. I exported the registry of
> HKEY_CURRENT_USER\Software\Microsoft\Mic
rosoft SQL
> Server\80\Tools\SQLEW\Registered Servers X
> but when I import it, I only see the groups. Tried install and uninstall
> enterprise manager but not helping.
> thanks, larry
>

---

|||By the way, registrations are user-based. Are you logging into the
destination machine with the same user as the source machine? It might be
that user-specific information is encoded in the data stored in those
registry values... so if you connect to Enterprise Manager as a different
user, or with SQL Server authentication, you might not see those
registrations.
Look in the registry of the destination machine and see which user your
registrations appear under. If the .reg file ran without error, they're
probably there somewhere.
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"LarryLiMCDBA" <larryliwork@.hotmail.com> wrote in message
news:OAm0Xqt1DHA.2972@.TK2MSFTNGP09.phx.gbl...

quote:

---

> I have to export the servers registered in Enterprise Manager and import

---

the

quote:

---

> servers into another 30 machines. I exported the registry of
> HKEY_CURRENT_USER\Software\Microsoft\Mic
rosoft SQL
> Server\80\Tools\SQLEW\Registered Servers X
> but when I import it, I only see the groups. Tried install and uninstall
> enterprise manager but not helping.
> thanks, larry
>

---

|||I tried both HKEY local machine and HKEY current user but couldn't make it
work. I was able to import the alias though and SQL Query Analyzer actually
works. I guess there is a encryption process somewhere for the registered
servers in EM.
tks, larry
"Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
news:%2300Ai9u1DHA.2328@.TK2MSFTNGP10.phx.gbl...

quote:

---

> By the way, registrations are user-based. Are you logging into the
> destination machine with the same user as the source machine? It might be
> that user-specific information is encoded in the data stored in those
> registry values... so if you connect to Enterprise Manager as a different
> user, or with SQL Server authentication, you might not see those
> registrations.
> Look in the registry of the destination machine and see which user your
> registrations appear under. If the .reg file ran without error, they're
> probably there somewhere.
> --
> Aaron Bertrand
> SQL Server MVP
> http://www.aspfaq.com/
>
>
> "LarryLiMCDBA" <larryliwork@.hotmail.com> wrote in message
> news:OAm0Xqt1DHA.2972@.TK2MSFTNGP09.phx.gbl...
> the
uninstall[QUOTE]
>

---

Only one row returned from linked server while using INTO clause

Hello,
We have encountered the following behaviour / problem:
There are two SQL 2000 Servers: Local Server (LOCAL) and Linked Server
(LINKED).
On the local server we run the following query:
SELECT * FROM LINKED.MyDatabase.dbo.MyTable
WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
ColumnA is varchar(3), ColumnB is varchar(4)
The query returns approx. 800 rows - that's correct.
However, if we run the same query using the INTO clause:
SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
the message is
(1 row(s) affected)
and there is only one row in #MyTemp table, what is obviously wrong.
What might be the problem?
Investigating the problem further we've found out that the problematic is
WHERE clause for ColumnB - if we rewrite it as follows:
SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
WHERE ColumnA = 'XXX' AND ColumnB LIKE 'YYYY%'
the query returns the correct number of rows.
But the ColumnB is varchar (4), so the clause ColumnB LIKE 'YYYY%' doesn't
make much sense to me - but it works!
Would anybody be so kind to explain that behaviour?
Best regards,
Andrew
Just a guess, but ensure the collation compatibility settings for the linked
server are correct and the settings for things like Ansi Null, etc match...
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Andrew Drake" <andrewdrake@.hotmail.com> wrote in message
news:eO5X4eQkFHA.3316@.TK2MSFTNGP14.phx.gbl...
> Hello,
> We have encountered the following behaviour / problem:
> There are two SQL 2000 Servers: Local Server (LOCAL) and Linked Server
> (LINKED).
> On the local server we run the following query:
> SELECT * FROM LINKED.MyDatabase.dbo.MyTable
> WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
> ColumnA is varchar(3), ColumnB is varchar(4)
> The query returns approx. 800 rows - that's correct.
> However, if we run the same query using the INTO clause:
> SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
> WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
> the message is
> (1 row(s) affected)
> and there is only one row in #MyTemp table, what is obviously wrong.
> What might be the problem?
>
> Investigating the problem further we've found out that the problematic is
> WHERE clause for ColumnB - if we rewrite it as follows:
> SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
> WHERE ColumnA = 'XXX' AND ColumnB LIKE 'YYYY%'
> the query returns the correct number of rows.
> But the ColumnB is varchar (4), so the clause ColumnB LIKE 'YYYY%' doesn't
> make much sense to me - but it works!
> Would anybody be so kind to explain that behaviour?
> Best regards,
> Andrew
>
>

Only one row returned from linked server while using INTO clause

Hello,
We have encountered the following behaviour / problem:
There are two SQL 2000 Servers: Local Server (LOCAL) and Linked Server
(LINKED).
On the local server we run the following query:
SELECT * FROM LINKED.MyDatabase.dbo.MyTable
WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
ColumnA is varchar(3), ColumnB is varchar(4)
The query returns approx. 800 rows - that's correct.
However, if we run the same query using the INTO clause:
SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
the message is
(1 row(s) affected)
and there is only one row in #MyTemp table, what is obviously wrong.
What might be the problem?
Investigating the problem further we've found out that the problematic is
WHERE clause for ColumnB - if we rewrite it as follows:
SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
WHERE ColumnA = 'XXX' AND ColumnB LIKE 'YYYY%'
the query returns the correct number of rows.
But the ColumnB is varchar (4), so the clause ColumnB LIKE 'YYYY%' doesn't
make much sense to me - but it works!
Would anybody be so kind to explain that behaviour?
Best regards,
AndrewJust a guess, but ensure the collation compatibility settings for the linked
server are correct and the settings for things like Ansi Null, etc match...
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Andrew Drake" <andrewdrake@.hotmail.com> wrote in message
news:eO5X4eQkFHA.3316@.TK2MSFTNGP14.phx.gbl...
> Hello,
> We have encountered the following behaviour / problem:
> There are two SQL 2000 Servers: Local Server (LOCAL) and Linked Server
> (LINKED).
> On the local server we run the following query:
> SELECT * FROM LINKED.MyDatabase.dbo.MyTable
> WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
> ColumnA is varchar(3), ColumnB is varchar(4)
> The query returns approx. 800 rows - that's correct.
> However, if we run the same query using the INTO clause:
> SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
> WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
> the message is
> (1 row(s) affected)
> and there is only one row in #MyTemp table, what is obviously wrong.
> What might be the problem?
>
> Investigating the problem further we've found out that the problematic is
> WHERE clause for ColumnB - if we rewrite it as follows:
> SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
> WHERE ColumnA = 'XXX' AND ColumnB LIKE 'YYYY%'
> the query returns the correct number of rows.
> But the ColumnB is varchar (4), so the clause ColumnB LIKE 'YYYY%' doesn't
> make much sense to me - but it works!
> Would anybody be so kind to explain that behaviour?
> Best regards,
> Andrew
>
>

Only one row returned from linked server while using INTO clause

Hello,
We have encountered the following behaviour / problem:
There are two SQL 2000 Servers: Local Server (LOCAL) and Linked Server
(LINKED).
On the local server we run the following query:
SELECT * FROM LINKED.MyDatabase.dbo.MyTable
WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
ColumnA is varchar(3), ColumnB is varchar(4)
The query returns approx. 800 rows - that's correct.
However, if we run the same query using the INTO clause:
SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
the message is
(1 row(s) affected)
and there is only one row in #MyTemp table, what is obviously wrong.
What might be the problem?
Investigating the problem further we've found out that the problematic is
WHERE clause for ColumnB - if we rewrite it as follows:
SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
WHERE ColumnA = 'XXX' AND ColumnB LIKE 'YYYY%'
the query returns the correct number of rows.
But the ColumnB is varchar (4), so the clause ColumnB LIKE 'YYYY%' doesn't
make much sense to me - but it works!
Would anybody be so kind to explain that behaviour?
Best regards,
AndrewJust a guess, but ensure the collation compatibility settings for the linked
server are correct and the settings for things like Ansi Null, etc match...
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Andrew Drake" <andrewdrake@.hotmail.com> wrote in message
news:eO5X4eQkFHA.3316@.TK2MSFTNGP14.phx.gbl...
> Hello,
> We have encountered the following behaviour / problem:
> There are two SQL 2000 Servers: Local Server (LOCAL) and Linked Server
> (LINKED).
> On the local server we run the following query:
> SELECT * FROM LINKED.MyDatabase.dbo.MyTable
> WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
> ColumnA is varchar(3), ColumnB is varchar(4)
> The query returns approx. 800 rows - that's correct.
> However, if we run the same query using the INTO clause:
> SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
> WHERE ColumnA = 'XXX' AND ColumnB = 'YYYY'
> the message is
> (1 row(s) affected)
> and there is only one row in #MyTemp table, what is obviously wrong.
> What might be the problem?
>
> Investigating the problem further we've found out that the problematic is
> WHERE clause for ColumnB - if we rewrite it as follows:
> SELECT * INTO #MyTemp FROM LINKED.MyDatabase.dbo.MyTable
> WHERE ColumnA = 'XXX' AND ColumnB LIKE 'YYYY%'
> the query returns the correct number of rows.
> But the ColumnB is varchar (4), so the clause ColumnB LIKE 'YYYY%' doesn't
> make much sense to me - but it works!
> Would anybody be so kind to explain that behaviour?
> Best regards,
> Andrew
>
>

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
>