Hello!
We have an application that stores online measurement data in a MSDE
database.
Some statistics: 20 x 1kb per minute.
We had no problems for several months at many locations.
On some of our systems we saw that the SQL Server took very much of the
memory and some of the customers complaint about this. So we limitted the
maximum server memory of SQL Server to half of the available RAM memory
(most of the machines had 1GB RAM).
After running the SQL Server then for a while we saw that the writing to the
database got slower and slower and in the end it took about 30 Seconds and
more for a single INSERT. After stopping and restarting the SQL Server
everything worked fine again.
The time for reading out of the database was never influenced.
Can anybody explain this to me?
Is there a way to avoid it?
I hope on many useful answers!
Thanks!
what is the sqlserver instance doing in 30 seconds? Is it waiting on IO? Or
blocked by something? select from sysprocesses as a start. There are some
good information on the web for analyzing blocking issues.
--
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
"Frank Esser" <Mistral@.nurfuerspam.de> wrote in message
news:OGWumWSgFHA.2700@.TK2MSFTNGP15.phx.gbl...
> Hello!
> We have an application that stores online measurement data in a MSDE
> database.
> Some statistics: 20 x 1kb per minute.
> We had no problems for several months at many locations.
> On some of our systems we saw that the SQL Server took very much of the
> memory and some of the customers complaint about this. So we limitted the
> maximum server memory of SQL Server to half of the available RAM memory
> (most of the machines had 1GB RAM).
> After running the SQL Server then for a while we saw that the writing to
the
> database got slower and slower and in the end it took about 30 Seconds and
> more for a single INSERT. After stopping and restarting the SQL Server
> everything worked fine again.
> The time for reading out of the database was never influenced.
> Can anybody explain this to me?
> Is there a way to avoid it?
> I hope on many useful answers!
> Thanks!
>
Showing posts with label statistics. Show all posts
Showing posts with label statistics. Show all posts
Wednesday, March 21, 2012
Performance collapse on writing to database
Hello!
We have an application that stores online measurement data in a MSDE
database.
Some statistics: 20 x 1kb per minute.
We had no problems for several months at many locations.
On some of our systems we saw that the SQL Server took very much of the
memory and some of the customers complaint about this. So we limitted the
maximum server memory of SQL Server to half of the available RAM memory
(most of the machines had 1GB RAM).
After running the SQL Server then for a while we saw that the writing to the
database got slower and slower and in the end it took about 30 Seconds and
more for a single INSERT. After stopping and restarting the SQL Server
everything worked fine again.
The time for reading out of the database was never influenced.
Can anybody explain this to me?
Is there a way to avoid it?
I hope on many useful answers!
Thanks!what is the sqlserver instance doing in 30 seconds? Is it waiting on IO? Or
blocked by something? select from sysprocesses as a start. There are some
good information on the web for analyzing blocking issues.
--
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
"Frank Esser" <Mistral@.nurfuerspam.de> wrote in message
news:OGWumWSgFHA.2700@.TK2MSFTNGP15.phx.gbl...
> Hello!
> We have an application that stores online measurement data in a MSDE
> database.
> Some statistics: 20 x 1kb per minute.
> We had no problems for several months at many locations.
> On some of our systems we saw that the SQL Server took very much of the
> memory and some of the customers complaint about this. So we limitted the
> maximum server memory of SQL Server to half of the available RAM memory
> (most of the machines had 1GB RAM).
> After running the SQL Server then for a while we saw that the writing to
the
> database got slower and slower and in the end it took about 30 Seconds and
> more for a single INSERT. After stopping and restarting the SQL Server
> everything worked fine again.
> The time for reading out of the database was never influenced.
> Can anybody explain this to me?
> Is there a way to avoid it?
> I hope on many useful answers!
> Thanks!
>sql
We have an application that stores online measurement data in a MSDE
database.
Some statistics: 20 x 1kb per minute.
We had no problems for several months at many locations.
On some of our systems we saw that the SQL Server took very much of the
memory and some of the customers complaint about this. So we limitted the
maximum server memory of SQL Server to half of the available RAM memory
(most of the machines had 1GB RAM).
After running the SQL Server then for a while we saw that the writing to the
database got slower and slower and in the end it took about 30 Seconds and
more for a single INSERT. After stopping and restarting the SQL Server
everything worked fine again.
The time for reading out of the database was never influenced.
Can anybody explain this to me?
Is there a way to avoid it?
I hope on many useful answers!
Thanks!what is the sqlserver instance doing in 30 seconds? Is it waiting on IO? Or
blocked by something? select from sysprocesses as a start. There are some
good information on the web for analyzing blocking issues.
--
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
"Frank Esser" <Mistral@.nurfuerspam.de> wrote in message
news:OGWumWSgFHA.2700@.TK2MSFTNGP15.phx.gbl...
> Hello!
> We have an application that stores online measurement data in a MSDE
> database.
> Some statistics: 20 x 1kb per minute.
> We had no problems for several months at many locations.
> On some of our systems we saw that the SQL Server took very much of the
> memory and some of the customers complaint about this. So we limitted the
> maximum server memory of SQL Server to half of the available RAM memory
> (most of the machines had 1GB RAM).
> After running the SQL Server then for a while we saw that the writing to
the
> database got slower and slower and in the end it took about 30 Seconds and
> more for a single INSERT. After stopping and restarting the SQL Server
> everything worked fine again.
> The time for reading out of the database was never influenced.
> Can anybody explain this to me?
> Is there a way to avoid it?
> I hope on many useful answers!
> Thanks!
>sql
Labels:
1kb,
application,
collapse,
database,
hellowe,
measurement,
microsoft,
msdedatabase,
mysql,
online,
oracle,
performance,
server,
sql,
statistics,
stores,
writing
Performance collapse on writing to database
Hello!
We have an application that stores online measurement data in a MSDE
database.
Some statistics: 20 x 1kb per minute.
We had no problems for several months at many locations.
On some of our systems we saw that the SQL Server took very much of the
memory and some of the customers complaint about this. So we limitted the
maximum server memory of SQL Server to half of the available RAM memory
(most of the machines had 1GB RAM).
After running the SQL Server then for a while we saw that the writing to the
database got slower and slower and in the end it took about 30 Seconds and
more for a single INSERT. After stopping and restarting the SQL Server
everything worked fine again.
The time for reading out of the database was never influenced.
Can anybody explain this to me?
Is there a way to avoid it?
I hope on many useful answers!
Thanks!what is the sqlserver instance doing in 30 seconds? Is it waiting on IO? Or
blocked by something? select from sysprocesses as a start. There are some
good information on the web for analyzing blocking issues.
--
--
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
"Frank Esser" <Mistral@.nurfuerspam.de> wrote in message
news:OGWumWSgFHA.2700@.TK2MSFTNGP15.phx.gbl...
> Hello!
> We have an application that stores online measurement data in a MSDE
> database.
> Some statistics: 20 x 1kb per minute.
> We had no problems for several months at many locations.
> On some of our systems we saw that the SQL Server took very much of the
> memory and some of the customers complaint about this. So we limitted the
> maximum server memory of SQL Server to half of the available RAM memory
> (most of the machines had 1GB RAM).
> After running the SQL Server then for a while we saw that the writing to
the
> database got slower and slower and in the end it took about 30 Seconds and
> more for a single INSERT. After stopping and restarting the SQL Server
> everything worked fine again.
> The time for reading out of the database was never influenced.
> Can anybody explain this to me?
> Is there a way to avoid it?
> I hope on many useful answers!
> Thanks!
>
We have an application that stores online measurement data in a MSDE
database.
Some statistics: 20 x 1kb per minute.
We had no problems for several months at many locations.
On some of our systems we saw that the SQL Server took very much of the
memory and some of the customers complaint about this. So we limitted the
maximum server memory of SQL Server to half of the available RAM memory
(most of the machines had 1GB RAM).
After running the SQL Server then for a while we saw that the writing to the
database got slower and slower and in the end it took about 30 Seconds and
more for a single INSERT. After stopping and restarting the SQL Server
everything worked fine again.
The time for reading out of the database was never influenced.
Can anybody explain this to me?
Is there a way to avoid it?
I hope on many useful answers!
Thanks!what is the sqlserver instance doing in 30 seconds? Is it waiting on IO? Or
blocked by something? select from sysprocesses as a start. There are some
good information on the web for analyzing blocking issues.
--
--
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
"Frank Esser" <Mistral@.nurfuerspam.de> wrote in message
news:OGWumWSgFHA.2700@.TK2MSFTNGP15.phx.gbl...
> Hello!
> We have an application that stores online measurement data in a MSDE
> database.
> Some statistics: 20 x 1kb per minute.
> We had no problems for several months at many locations.
> On some of our systems we saw that the SQL Server took very much of the
> memory and some of the customers complaint about this. So we limitted the
> maximum server memory of SQL Server to half of the available RAM memory
> (most of the machines had 1GB RAM).
> After running the SQL Server then for a while we saw that the writing to
the
> database got slower and slower and in the end it took about 30 Seconds and
> more for a single INSERT. After stopping and restarting the SQL Server
> everything worked fine again.
> The time for reading out of the database was never influenced.
> Can anybody explain this to me?
> Is there a way to avoid it?
> I hope on many useful answers!
> Thanks!
>
Labels:
1kb,
application,
collapse,
database,
measurement,
microsoft,
msde,
mysql,
online,
oracle,
performance,
server,
sql,
statistics,
stores,
writing
Saturday, February 25, 2012
Perfmon/Profiler confusion
I am trying to troubleshoot crazy values for SQL Statistics/SQL
Compilations/sec in Perfmon. So I started up the Profiler,removed all
the default events and added Stored Procedures/SP:Recompile event class.
I am seeing numbers like 20 SQL Compilations/sec average, however, the
Profiler only records a few over a 10 minute period. What am I missing
here? Could it be that SQL Server is not really doing recompilations,
but actual compilations (as if it sees the stored proc for the first
time)? Anyway, I am lost.
I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).
Hi Frank
These counters are measuring completely different things.
Although I don't know everything that is included in the Perfmon SQL
Statistics/SQL
Compilations/sec value, I know it is much more than just stored procedure
compilations.
Also, the SP:Recompile event in Profiler does not measure ALL
recompilations. It only counts those that occur after the procedure has
already started executing, and something in the proc forces SQL Server to
stop and compile the proc again. It does not count those cases where a proc
is recompiled before it even starts executing.
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Frank Rizzo" <none@.none.com> wrote in message
news:OiS5lc05GHA.2104@.TK2MSFTNGP06.phx.gbl...
>I am trying to troubleshoot crazy values for SQL Statistics/SQL
>Compilations/sec in Perfmon. So I started up the Profiler,removed all the
>default events and added Stored Procedures/SP:Recompile event class.
> I am seeing numbers like 20 SQL Compilations/sec average, however, the
> Profiler only records a few over a 10 minute period. What am I missing
> here? Could it be that SQL Server is not really doing recompilations, but
> actual compilations (as if it sees the stored proc for the first time)?
> Anyway, I am lost.
> I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).
|||Kalen Delaney wrote:
> Hi Frank
> These counters are measuring completely different things.
> Although I don't know everything that is included in the Perfmon SQL
> Statistics/SQL
> Compilations/sec value, I know it is much more than just stored procedure
> compilations.
I've looked around but I can't find a good definition of what SQL
Statistics/SQL Compilations/sec in PerfMon measures. Any idea of where
I can find it?
Also, is it generally a bad thing to have a high number (like 30-40) in
SQL Statistics/SQL Compilations/sec value?
Regards.
> Also, the SP:Recompile event in Profiler does not measure ALL
> recompilations. It only counts those that occur after the procedure has
> already started executing, and something in the proc forces SQL Server to
> stop and compile the proc again. It does not count those cases where a proc
> is recompiled before it even starts executing.
>
|||On Wed, 04 Oct 2006 10:15:53 -0700, Frank Rizzo <none@.none.com> wrote:
>Also, is it generally a bad thing to have a high number (like 30-40) in
>SQL Statistics/SQL Compilations/sec value?
Well they're not free.
J.
Compilations/sec in Perfmon. So I started up the Profiler,removed all
the default events and added Stored Procedures/SP:Recompile event class.
I am seeing numbers like 20 SQL Compilations/sec average, however, the
Profiler only records a few over a 10 minute period. What am I missing
here? Could it be that SQL Server is not really doing recompilations,
but actual compilations (as if it sees the stored proc for the first
time)? Anyway, I am lost.
I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).
Hi Frank
These counters are measuring completely different things.
Although I don't know everything that is included in the Perfmon SQL
Statistics/SQL
Compilations/sec value, I know it is much more than just stored procedure
compilations.
Also, the SP:Recompile event in Profiler does not measure ALL
recompilations. It only counts those that occur after the procedure has
already started executing, and something in the proc forces SQL Server to
stop and compile the proc again. It does not count those cases where a proc
is recompiled before it even starts executing.
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Frank Rizzo" <none@.none.com> wrote in message
news:OiS5lc05GHA.2104@.TK2MSFTNGP06.phx.gbl...
>I am trying to troubleshoot crazy values for SQL Statistics/SQL
>Compilations/sec in Perfmon. So I started up the Profiler,removed all the
>default events and added Stored Procedures/SP:Recompile event class.
> I am seeing numbers like 20 SQL Compilations/sec average, however, the
> Profiler only records a few over a 10 minute period. What am I missing
> here? Could it be that SQL Server is not really doing recompilations, but
> actual compilations (as if it sees the stored proc for the first time)?
> Anyway, I am lost.
> I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).
|||Kalen Delaney wrote:
> Hi Frank
> These counters are measuring completely different things.
> Although I don't know everything that is included in the Perfmon SQL
> Statistics/SQL
> Compilations/sec value, I know it is much more than just stored procedure
> compilations.
I've looked around but I can't find a good definition of what SQL
Statistics/SQL Compilations/sec in PerfMon measures. Any idea of where
I can find it?
Also, is it generally a bad thing to have a high number (like 30-40) in
SQL Statistics/SQL Compilations/sec value?
Regards.
> Also, the SP:Recompile event in Profiler does not measure ALL
> recompilations. It only counts those that occur after the procedure has
> already started executing, and something in the proc forces SQL Server to
> stop and compile the proc again. It does not count those cases where a proc
> is recompiled before it even starts executing.
>
|||On Wed, 04 Oct 2006 10:15:53 -0700, Frank Rizzo <none@.none.com> wrote:
>Also, is it generally a bad thing to have a high number (like 30-40) in
>SQL Statistics/SQL Compilations/sec value?
Well they're not free.
J.
Perfmon/Profiler confusion
I am trying to troubleshoot crazy values for SQL Statistics/SQL
Compilations/sec in Perfmon. So I started up the Profiler,removed all
the default events and added Stored Procedures/SP:Recompile event class.
I am seeing numbers like 20 SQL Compilations/sec average, however, the
Profiler only records a few over a 10 minute period. What am I missing
here? Could it be that SQL Server is not really doing recompilations,
but actual compilations (as if it sees the stored proc for the first
time)? Anyway, I am lost.
I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).Hi Frank
These counters are measuring completely different things.
Although I don't know everything that is included in the Perfmon SQL
Statistics/SQL
Compilations/sec value, I know it is much more than just stored procedure
compilations.
Also, the SP:Recompile event in Profiler does not measure ALL
recompilations. It only counts those that occur after the procedure has
already started executing, and something in the proc forces SQL Server to
stop and compile the proc again. It does not count those cases where a proc
is recompiled before it even starts executing.
--
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Frank Rizzo" <none@.none.com> wrote in message
news:OiS5lc05GHA.2104@.TK2MSFTNGP06.phx.gbl...
>I am trying to troubleshoot crazy values for SQL Statistics/SQL
>Compilations/sec in Perfmon. So I started up the Profiler,removed all the
>default events and added Stored Procedures/SP:Recompile event class.
> I am seeing numbers like 20 SQL Compilations/sec average, however, the
> Profiler only records a few over a 10 minute period. What am I missing
> here? Could it be that SQL Server is not really doing recompilations, but
> actual compilations (as if it sees the stored proc for the first time)?
> Anyway, I am lost.
> I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).|||Kalen Delaney wrote:
> Hi Frank
> These counters are measuring completely different things.
> Although I don't know everything that is included in the Perfmon SQL
> Statistics/SQL
> Compilations/sec value, I know it is much more than just stored procedure
> compilations.
I've looked around but I can't find a good definition of what SQL
Statistics/SQL Compilations/sec in PerfMon measures. Any idea of where
I can find it?
Also, is it generally a bad thing to have a high number (like 30-40) in
SQL Statistics/SQL Compilations/sec value?
Regards.
> Also, the SP:Recompile event in Profiler does not measure ALL
> recompilations. It only counts those that occur after the procedure has
> already started executing, and something in the proc forces SQL Server to
> stop and compile the proc again. It does not count those cases where a proc
> is recompiled before it even starts executing.
>|||On Wed, 04 Oct 2006 10:15:53 -0700, Frank Rizzo <none@.none.com> wrote:
>Also, is it generally a bad thing to have a high number (like 30-40) in
>SQL Statistics/SQL Compilations/sec value?
Well they're not free.
J.
Compilations/sec in Perfmon. So I started up the Profiler,removed all
the default events and added Stored Procedures/SP:Recompile event class.
I am seeing numbers like 20 SQL Compilations/sec average, however, the
Profiler only records a few over a 10 minute period. What am I missing
here? Could it be that SQL Server is not really doing recompilations,
but actual compilations (as if it sees the stored proc for the first
time)? Anyway, I am lost.
I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).Hi Frank
These counters are measuring completely different things.
Although I don't know everything that is included in the Perfmon SQL
Statistics/SQL
Compilations/sec value, I know it is much more than just stored procedure
compilations.
Also, the SP:Recompile event in Profiler does not measure ALL
recompilations. It only counts those that occur after the procedure has
already started executing, and something in the proc forces SQL Server to
stop and compile the proc again. It does not count those cases where a proc
is recompiled before it even starts executing.
--
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Frank Rizzo" <none@.none.com> wrote in message
news:OiS5lc05GHA.2104@.TK2MSFTNGP06.phx.gbl...
>I am trying to troubleshoot crazy values for SQL Statistics/SQL
>Compilations/sec in Perfmon. So I started up the Profiler,removed all the
>default events and added Stored Procedures/SP:Recompile event class.
> I am seeing numbers like 20 SQL Compilations/sec average, however, the
> Profiler only records a few over a 10 minute period. What am I missing
> here? Could it be that SQL Server is not really doing recompilations, but
> actual compilations (as if it sees the stored proc for the first time)?
> Anyway, I am lost.
> I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).|||Kalen Delaney wrote:
> Hi Frank
> These counters are measuring completely different things.
> Although I don't know everything that is included in the Perfmon SQL
> Statistics/SQL
> Compilations/sec value, I know it is much more than just stored procedure
> compilations.
I've looked around but I can't find a good definition of what SQL
Statistics/SQL Compilations/sec in PerfMon measures. Any idea of where
I can find it?
Also, is it generally a bad thing to have a high number (like 30-40) in
SQL Statistics/SQL Compilations/sec value?
Regards.
> Also, the SP:Recompile event in Profiler does not measure ALL
> recompilations. It only counts those that occur after the procedure has
> already started executing, and something in the proc forces SQL Server to
> stop and compile the proc again. It does not count those cases where a proc
> is recompiled before it even starts executing.
>|||On Wed, 04 Oct 2006 10:15:53 -0700, Frank Rizzo <none@.none.com> wrote:
>Also, is it generally a bad thing to have a high number (like 30-40) in
>SQL Statistics/SQL Compilations/sec value?
Well they're not free.
J.
Labels:
compilations,
confusion,
database,
default,
microsoft,
mysql,
oracle,
perfmon,
profiler,
sec,
server,
sql,
statistics,
troubleshoot,
values
Perfmon/Profiler confusion
I am trying to troubleshoot crazy values for SQL Statistics/SQL
Compilations/sec in Perfmon. So I started up the Profiler,removed all
the default events and added Stored Procedures/SP:Recompile event class.
I am seeing numbers like 20 SQL Compilations/sec average, however, the
Profiler only records a few over a 10 minute period. What am I missing
here? Could it be that SQL Server is not really doing recompilations,
but actual compilations (as if it sees the stored proc for the first
time)? Anyway, I am lost.
I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).Hi Frank
These counters are measuring completely different things.
Although I don't know everything that is included in the Perfmon SQL
Statistics/SQL
Compilations/sec value, I know it is much more than just stored procedure
compilations.
Also, the SP:Recompile event in Profiler does not measure ALL
recompilations. It only counts those that occur after the procedure has
already started executing, and something in the proc forces SQL Server to
stop and compile the proc again. It does not count those cases where a proc
is recompiled before it even starts executing.
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Frank Rizzo" <none@.none.com> wrote in message
news:OiS5lc05GHA.2104@.TK2MSFTNGP06.phx.gbl...
>I am trying to troubleshoot crazy values for SQL Statistics/SQL
>Compilations/sec in Perfmon. So I started up the Profiler,removed all the
>default events and added Stored Procedures/SP:Recompile event class.
> I am seeing numbers like 20 SQL Compilations/sec average, however, the
> Profiler only records a few over a 10 minute period. What am I missing
> here? Could it be that SQL Server is not really doing recompilations, but
> actual compilations (as if it sees the stored proc for the first time)?
> Anyway, I am lost.
> I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).|||Kalen Delaney wrote:
> Hi Frank
> These counters are measuring completely different things.
> Although I don't know everything that is included in the Perfmon SQL
> Statistics/SQL
> Compilations/sec value, I know it is much more than just stored procedure
> compilations.
I've looked around but I can't find a good definition of what SQL
Statistics/SQL Compilations/sec in PerfMon measures. Any idea of where
I can find it?
Also, is it generally a bad thing to have a high number (like 30-40) in
SQL Statistics/SQL Compilations/sec value?
Regards.
> Also, the SP:Recompile event in Profiler does not measure ALL
> recompilations. It only counts those that occur after the procedure has
> already started executing, and something in the proc forces SQL Server to
> stop and compile the proc again. It does not count those cases where a pro
c
> is recompiled before it even starts executing.
>|||On Wed, 04 Oct 2006 10:15:53 -0700, Frank Rizzo <none@.none.com> wrote:
>Also, is it generally a bad thing to have a high number (like 30-40) in
>SQL Statistics/SQL Compilations/sec value?
Well they're not free.
J.
Compilations/sec in Perfmon. So I started up the Profiler,removed all
the default events and added Stored Procedures/SP:Recompile event class.
I am seeing numbers like 20 SQL Compilations/sec average, however, the
Profiler only records a few over a 10 minute period. What am I missing
here? Could it be that SQL Server is not really doing recompilations,
but actual compilations (as if it sees the stored proc for the first
time)? Anyway, I am lost.
I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).Hi Frank
These counters are measuring completely different things.
Although I don't know everything that is included in the Perfmon SQL
Statistics/SQL
Compilations/sec value, I know it is much more than just stored procedure
compilations.
Also, the SP:Recompile event in Profiler does not measure ALL
recompilations. It only counts those that occur after the procedure has
already started executing, and something in the proc forces SQL Server to
stop and compile the proc again. It does not count those cases where a proc
is recompiled before it even starts executing.
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Frank Rizzo" <none@.none.com> wrote in message
news:OiS5lc05GHA.2104@.TK2MSFTNGP06.phx.gbl...
>I am trying to troubleshoot crazy values for SQL Statistics/SQL
>Compilations/sec in Perfmon. So I started up the Profiler,removed all the
>default events and added Stored Procedures/SP:Recompile event class.
> I am seeing numbers like 20 SQL Compilations/sec average, however, the
> Profiler only records a few over a 10 minute period. What am I missing
> here? Could it be that SQL Server is not really doing recompilations, but
> actual compilations (as if it sees the stored proc for the first time)?
> Anyway, I am lost.
> I am on SQL Server 2000 (v. 8.00.2039 - i think, sp4).|||Kalen Delaney wrote:
> Hi Frank
> These counters are measuring completely different things.
> Although I don't know everything that is included in the Perfmon SQL
> Statistics/SQL
> Compilations/sec value, I know it is much more than just stored procedure
> compilations.
I've looked around but I can't find a good definition of what SQL
Statistics/SQL Compilations/sec in PerfMon measures. Any idea of where
I can find it?
Also, is it generally a bad thing to have a high number (like 30-40) in
SQL Statistics/SQL Compilations/sec value?
Regards.
> Also, the SP:Recompile event in Profiler does not measure ALL
> recompilations. It only counts those that occur after the procedure has
> already started executing, and something in the proc forces SQL Server to
> stop and compile the proc again. It does not count those cases where a pro
c
> is recompiled before it even starts executing.
>|||On Wed, 04 Oct 2006 10:15:53 -0700, Frank Rizzo <none@.none.com> wrote:
>Also, is it generally a bad thing to have a high number (like 30-40) in
>SQL Statistics/SQL Compilations/sec value?
Well they're not free.
J.
Monday, February 20, 2012
Perf Mon
Hi,
SQL Server 2005 sp1
The object General Statistics: User Connections has a value of 1400
The object General Statistics:Logical Connections has avalue of 1000
Does anyone know why there is a differenece in the values?
Thanks,
YanHi
Is this applicable?
http://support.microsoft.com/kb/922118
John
"Yan" <yaniv.etrogi@.gmail.com> wrote in message
news:eLbfLtibIHA.4196@.TK2MSFTNGP04.phx.gbl...
> Hi,
> SQL Server 2005 sp1
>
> The object General Statistics: User Connections has a value of 1400
> The object General Statistics:Logical Connections has avalue of 1000
>
> Does anyone know why there is a differenece in the values?
>
> Thanks,
> Yan
>|||You may also want to check if this is occuring!
http://support.microsoft.com/kb/937745
John
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:eNN0sgybIHA.4652@.TK2MSFTNGP06.phx.gbl...
> Hi
> Is this applicable?
> http://support.microsoft.com/kb/922118
> John
>
> "Yan" <yaniv.etrogi@.gmail.com> wrote in message
> news:eLbfLtibIHA.4196@.TK2MSFTNGP04.phx.gbl...
>> Hi,
>> SQL Server 2005 sp1
>>
>> The object General Statistics: User Connections has a value of 1400
>> The object General Statistics:Logical Connections has avalue of 1000
>>
>> Does anyone know why there is a differenece in the values?
>>
>> Thanks,
>> Yan
>
SQL Server 2005 sp1
The object General Statistics: User Connections has a value of 1400
The object General Statistics:Logical Connections has avalue of 1000
Does anyone know why there is a differenece in the values?
Thanks,
YanHi
Is this applicable?
http://support.microsoft.com/kb/922118
John
"Yan" <yaniv.etrogi@.gmail.com> wrote in message
news:eLbfLtibIHA.4196@.TK2MSFTNGP04.phx.gbl...
> Hi,
> SQL Server 2005 sp1
>
> The object General Statistics: User Connections has a value of 1400
> The object General Statistics:Logical Connections has avalue of 1000
>
> Does anyone know why there is a differenece in the values?
>
> Thanks,
> Yan
>|||You may also want to check if this is occuring!
http://support.microsoft.com/kb/937745
John
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:eNN0sgybIHA.4652@.TK2MSFTNGP06.phx.gbl...
> Hi
> Is this applicable?
> http://support.microsoft.com/kb/922118
> John
>
> "Yan" <yaniv.etrogi@.gmail.com> wrote in message
> news:eLbfLtibIHA.4196@.TK2MSFTNGP04.phx.gbl...
>> Hi,
>> SQL Server 2005 sp1
>>
>> The object General Statistics: User Connections has a value of 1400
>> The object General Statistics:Logical Connections has avalue of 1000
>>
>> Does anyone know why there is a differenece in the values?
>>
>> Thanks,
>> Yan
>
Labels:
connections,
database,
microsoft,
mon,
mysql,
object,
oracle,
perf,
server,
sp1,
sql,
statistics,
statisticslogical,
user,
value
Perf Mon
Hi,
SQL Server 2005 sp1
The object General Statistics: User Connections has a value of 1400
The object General Statistics:Logical Connections has avalue of 1000
Does anyone know why there is a differenece in the values?
Thanks,
Yan
Hi
Is this applicable?
http://support.microsoft.com/kb/922118
John
"Yan" <yaniv.etrogi@.gmail.com> wrote in message
news:eLbfLtibIHA.4196@.TK2MSFTNGP04.phx.gbl...
> Hi,
> SQL Server 2005 sp1
>
> The object General Statistics: User Connections has a value of 1400
> The object General Statistics:Logical Connections has avalue of 1000
>
> Does anyone know why there is a differenece in the values?
>
> Thanks,
> Yan
>
|||You may also want to check if this is occuring!
http://support.microsoft.com/kb/937745
John
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:eNN0sgybIHA.4652@.TK2MSFTNGP06.phx.gbl...
> Hi
> Is this applicable?
> http://support.microsoft.com/kb/922118
> John
>
> "Yan" <yaniv.etrogi@.gmail.com> wrote in message
> news:eLbfLtibIHA.4196@.TK2MSFTNGP04.phx.gbl...
>
SQL Server 2005 sp1
The object General Statistics: User Connections has a value of 1400
The object General Statistics:Logical Connections has avalue of 1000
Does anyone know why there is a differenece in the values?
Thanks,
Yan
Hi
Is this applicable?
http://support.microsoft.com/kb/922118
John
"Yan" <yaniv.etrogi@.gmail.com> wrote in message
news:eLbfLtibIHA.4196@.TK2MSFTNGP04.phx.gbl...
> Hi,
> SQL Server 2005 sp1
>
> The object General Statistics: User Connections has a value of 1400
> The object General Statistics:Logical Connections has avalue of 1000
>
> Does anyone know why there is a differenece in the values?
>
> Thanks,
> Yan
>
|||You may also want to check if this is occuring!
http://support.microsoft.com/kb/937745
John
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:eNN0sgybIHA.4652@.TK2MSFTNGP06.phx.gbl...
> Hi
> Is this applicable?
> http://support.microsoft.com/kb/922118
> John
>
> "Yan" <yaniv.etrogi@.gmail.com> wrote in message
> news:eLbfLtibIHA.4196@.TK2MSFTNGP04.phx.gbl...
>
Subscribe to:
Posts (Atom)