Showing posts with label activity. Show all posts
Showing posts with label activity. Show all posts

Friday, March 30, 2012

Performance tuning and measure on MSSQL 2000

Hi

I am trying to design an IO subsystem for my SQL Server and for that I
need to try and predict IO activity on each table in my MSSQL
Database. My idea is to move the hottest tables into special disk
subsystem away from the less hotter tables. So far I have gathered
that we have three tables more hot than the others but I have no
feeling on ratio on how hot each is and how much activity is on the
less hotter tables. I need to predict how many disks I should assign
to each subsystem and so far...
I haven't found a reasonable way to do this.

The only way I found to see read/writes and physical read/writes is on
filelevel. but I've also managed to do a trace in sqlprofiler to get
the logical read and writes per query but since my queries are often
joins I have no way of spliting that IO between the tables included in
the join and no idea on which hit the buffer pool and which didn'nt.
Is there maybe a counter or some way that I have not found?

Any input would be greatly appriciated.

best regards & thanks
Arni Snorriarnie@.gormur.com (Arni Snorri Eggertsson) wrote in message news:<c8d15bfa.0404280125.6f1dadcf@.posting.google.com>...
> Hi
> I am trying to design an IO subsystem for my SQL Server and for that I
> need to try and predict IO activity on each table in my MSSQL
> Database. My idea is to move the hottest tables into special disk
> subsystem away from the less hotter tables. So far I have gathered
> that we have three tables more hot than the others but I have no
> feeling on ratio on how hot each is and how much activity is on the
> less hotter tables. I need to predict how many disks I should assign
> to each subsystem and so far...
> I haven't found a reasonable way to do this.
> The only way I found to see read/writes and physical read/writes is on
> filelevel. but I've also managed to do a trace in sqlprofiler to get
> the logical read and writes per query but since my queries are often
> joins I have no way of spliting that IO between the tables included in
> the join and no idea on which hit the buffer pool and which didn'nt.
> Is there maybe a counter or some way that I have not found?
> Any input would be greatly appriciated.
> best regards & thanks
> Arni Snorri

I'm not sure if it's possible to do exactly what you want - MSSQL will
probably cache a lot of the data from the 'hot' tables anyway, so the
issue is not so much the physical disk access as how much RAM you
have, and how well MSSQL uses the cache. There are a lot of
performance monitor counters for buffer and cache management you can
use to look at this.

As for the disks, I would start by identifying how much space is
required on disk, then try to use lots of smaller disks instead of
fewer bigger ones for the 'hot' filegroups. Placing the transaction
logs on separate disks would also help, of course.

Simon|||"Arni Snorri Eggertsson" <arnie@.gormur.com> wrote in message
news:c8d15bfa.0404280125.6f1dadcf@.posting.google.c om...
> Hi
> I am trying to design an IO subsystem for my SQL Server and for that I
> need to try and predict IO activity on each table in my MSSQL
> Database. My idea is to move the hottest tables into special disk
> subsystem away from the less hotter tables. So far I have gathered
> that we have three tables more hot than the others but I have no
> feeling on ratio on how hot each is and how much activity is on the
> less hotter tables. I need to predict how many disks I should assign
> to each subsystem and so far...
> I haven't found a reasonable way to do this.

If you don't have it, get the Microsoft Press book on SQL Server Performance
tuning. Lots of good help here.

> The only way I found to see read/writes and physical read/writes is on
> filelevel. but I've also managed to do a trace in sqlprofiler to get
> the logical read and writes per query but since my queries are often
> joins I have no way of spliting that IO between the tables included in
> the join and no idea on which hit the buffer pool and which didn'nt.
> Is there maybe a counter or some way that I have not found?
> Any input would be greatly appriciated.
> best regards & thanks
> Arni Snorri

Tuesday, March 20, 2012

Performance problem, lots of disk activity, running out of memory

Fellas!!
This is a very complicated one and it took me a few days to figure out
exactly what's going on, but here's the final story:
I have a production environment running on .NET with a SQL Server
(2000, SP3). The SQL Server is on a dedicated Proliant computer with
2GB RAM (the actual SQLServer.exe process has dynamic memory
assignment and can reach up to 1.6GB RAM). Nothing else is running on
that specific computer.
Once the SQLServer is started, it hits 300MB RAM (the minimum that was
set in the configuration of the server - remember, it is dynamically
aquired).
Then there is a .NET program that requests just about all the data the
SQL Server contains (apart from a single table that contains roughly
1.6 million rows and another table that contains about 10000 rows
which are all of type IMAGE).
Once all the data is retrieved, the RAM is at about 400MB. From there
on, every update I make to the data on the server causes the RAM to go
up by a bit (that updates are done in a Transaction which of course is
committed at the end). It seems that BLOB updates are the major
problem in all of this. For some reason, uploading a blob of size 9MB
causes the RAM to go up by roughly 20MB and after commit it gose down
10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
process hits its upper limit (1.6GB) and at this point it starts
slowing down.
Some performance checks showed me the SQLServer has a lot of disk
activity, it seems it is reading and writing pages of data from/to the
HD all the time (which causes the queries to be much much much
slower).
We have a development environment running the exact same code (it is
the exact same in everything, except for the amount of data stored in
the DB). This does not happen there at all.
I have a few questions:
1. Why is the RAM going up after BLOB updates?
2. Why is the RAM going up at all?
3. How can I tell the DB which tables should remain in the RAM at all
time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
do the job.
It does not seem to have anything to do with the .NET code.
Thank you very much,
M Yamo.Mee
my 2 cents
1)
I you store image data , the actual data is not stored on the data
pages,instead it stores a 16 -byte pointer in the data row that indicates
where the actual data can be found.
2)
quote:

> We have a development environment running the exact same code (it is
> the exact same in everything, except for the amount of data stored in
> the DB). This does not happen there at all.

I think you have answered on your own question.
3)
DBCC PINTABLE is best used to keep small, frequently referenced tables in
memory. The pages for the small table are read into memory one time, then
all future references to their data do not require a disk read.
"Mee Yamo" <meeyamo@.hotmail.com> wrote in message
news:b5f0434e.0402010522.625a7a4d@.posting.google.com...
quote:

> Fellas!!
> This is a very complicated one and it took me a few days to figure out
> exactly what's going on, but here's the final story:
> I have a production environment running on .NET with a SQL Server
> (2000, SP3). The SQL Server is on a dedicated Proliant computer with
> 2GB RAM (the actual SQLServer.exe process has dynamic memory
> assignment and can reach up to 1.6GB RAM). Nothing else is running on
> that specific computer.
> Once the SQLServer is started, it hits 300MB RAM (the minimum that was
> set in the configuration of the server - remember, it is dynamically
> aquired).
> Then there is a .NET program that requests just about all the data the
> SQL Server contains (apart from a single table that contains roughly
> 1.6 million rows and another table that contains about 10000 rows
> which are all of type IMAGE).
> Once all the data is retrieved, the RAM is at about 400MB. From there
> on, every update I make to the data on the server causes the RAM to go
> up by a bit (that updates are done in a Transaction which of course is
> committed at the end). It seems that BLOB updates are the major
> problem in all of this. For some reason, uploading a blob of size 9MB
> causes the RAM to go up by roughly 20MB and after commit it gose down
> 10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
> process hits its upper limit (1.6GB) and at this point it starts
> slowing down.
> Some performance checks showed me the SQLServer has a lot of disk
> activity, it seems it is reading and writing pages of data from/to the
> HD all the time (which causes the queries to be much much much
> slower).
> We have a development environment running the exact same code (it is
> the exact same in everything, except for the amount of data stored in
> the DB). This does not happen there at all.
> I have a few questions:
> 1. Why is the RAM going up after BLOB updates?
> 2. Why is the RAM going up at all?
> 3. How can I tell the DB which tables should remain in the RAM at all
> time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
> do the job.
> It does not seem to have anything to do with the .NET code.
> Thank you very much,
> M Yamo.
|||Mee Yamo (meeyamo@.hotmail.com) writes:
quote:

> I have a production environment running on .NET with a SQL Server
> (2000, SP3). The SQL Server is on a dedicated Proliant computer with
> 2GB RAM (the actual SQLServer.exe process has dynamic memory
> assignment and can reach up to 1.6GB RAM). Nothing else is running on
> that specific computer.
> ...
> Once all the data is retrieved, the RAM is at about 400MB. From there
> on, every update I make to the data on the server causes the RAM to go
> up by a bit (that updates are done in a Transaction which of course is
> committed at the end). It seems that BLOB updates are the major
> problem in all of this. For some reason, uploading a blob of size 9MB
> causes the RAM to go up by roughly 20MB and after commit it gose down
> 10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
> process hits its upper limit (1.6GB) and at this point it starts
> slowing down.
>...
> I have a few questions:
> 1. Why is the RAM going up after BLOB updates?
> 2. Why is the RAM going up at all?
> 3. How can I tell the DB which tables should remain in the RAM at all
> time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
> do the job.

I guess since you post, you have a problem with your application. However,
your posting gives little information of what that problem might be.
The default behaviour of SQL Server is go grab as much as memory as
possible. The more data, SQL Server have in cache, the less it has to
read from disks. If there are competing applications on the machine,
this can be a problem if SQL Server does not yield memory fast enough.
But you say that this is dedicated to SQL Server, so if SQL Server gets
some more memory that is no cause for alarm.
DBCC PINTABLE is something you have little reason to play with. If you have
data that you access rarely, but when you access it, you need it quick,
then PINTABLE may be an option. For instance, the Managing Director wants a
report the first day of each months, and he cannot wait those two minutes
it would take to get the data from disk. But using DBCC PINTABLE is likely
to mean that you sacrifice overall performance.
quote:

> We have a development environment running the exact same code (it is
> the exact same in everything, except for the amount of data stored in
> the DB). This does not happen there at all.

The amount of data is surely the clue here. Assuming that you really
have performance problems, they are only likely to show when you have
a full-size database.
Since I don't know what your real problems are, it is diffiult to
give some relevant advice, but a good starting point is to review
indexing, if you have not done this already.
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Hi,
Thanks for trying to help.
Well the problem still goes on. The SQLServer process has hit its max
RAM allowance and started to slow down again (DISK ACTIVITY). I
restarted the SQLServer service and that solved it.
Why is it memory hogging? Every update seems to leave a residue on the
process's memory consumption.
Erland Sommarskog <sommar@.algonet.se> wrote in message news:<Xns9482AB02DAFF4Yazorman@.127.0.0.1>..
.
quote:

> Mee Yamo (meeyamo@.hotmail.com) writes:
> I guess since you post, you have a problem with your application. However,
> your posting gives little information of what that problem might be.
> The default behaviour of SQL Server is go grab as much as memory as
> possible. The more data, SQL Server have in cache, the less it has to
> read from disks. If there are competing applications on the machine,
> this can be a problem if SQL Server does not yield memory fast enough.
> But you say that this is dedicated to SQL Server, so if SQL Server gets
> some more memory that is no cause for alarm.
> DBCC PINTABLE is something you have little reason to play with. If you hav
e
> data that you access rarely, but when you access it, you need it quick,
> then PINTABLE may be an option. For instance, the Managing Director wants
a
> report the first day of each months, and he cannot wait those two minutes
> it would take to get the data from disk. But using DBCC PINTABLE is likel
y
> to mean that you sacrifice overall performance.
>
> The amount of data is surely the clue here. Assuming that you really
> have performance problems, they are only likely to show when you have
> a full-size database.
> Since I don't know what your real problems are, it is diffiult to
> give some relevant advice, but a good starting point is to review
> indexing, if you have not done this already.
|||Mee Yamo (meeyamo@.hotmail.com) writes:
quote:

> Well the problem still goes on. The SQLServer process has hit its max
> RAM allowance and started to slow down again (DISK ACTIVITY). I
> restarted the SQLServer service and that solved it.
> Why is it memory hogging? Every update seems to leave a residue on the
> process's memory consumption.

As I tried to explain, this by design. You should not worry about it.
If you have real performance problem with long response times etc, the
people in these newsgroups can assist, but you need to provide more
information.
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Performance problem, lots of disk activity, running out of memory

Fellas!!

This is a very complicated one and it took me a few days to figure out
exactly what's going on, but here's the final story:

I have a production environment running on .NET with a SQL Server
(2000, SP3). The SQL Server is on a dedicated Proliant computer with
2GB RAM (the actual SQLServer.exe process has dynamic memory
assignment and can reach up to 1.6GB RAM). Nothing else is running on
that specific computer.

Once the SQLServer is started, it hits 300MB RAM (the minimum that was
set in the configuration of the server - remember, it is dynamically
aquired).

Then there is a .NET program that requests just about all the data the
SQL Server contains (apart from a single table that contains roughly
1.6 million rows and another table that contains about 10000 rows
which are all of type IMAGE).

Once all the data is retrieved, the RAM is at about 400MB. From there
on, every update I make to the data on the server causes the RAM to go
up by a bit (that updates are done in a Transaction which of course is
committed at the end). It seems that BLOB updates are the major
problem in all of this. For some reason, uploading a blob of size 9MB
causes the RAM to go up by roughly 20MB and after commit it gose down
10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
process hits its upper limit (1.6GB) and at this point it starts
slowing down.

Some performance checks showed me the SQLServer has a lot of disk
activity, it seems it is reading and writing pages of data from/to the
HD all the time (which causes the queries to be much much much
slower).

We have a development environment running the exact same code (it is
the exact same in everything, except for the amount of data stored in
the DB). This does not happen there at all.

I have a few questions:
1. Why is the RAM going up after BLOB updates?
2. Why is the RAM going up at all?
3. How can I tell the DB which tables should remain in the RAM at all
time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
do the job.

It does not seem to have anything to do with the .NET code.

Thank you very much,

M Yamo.Mee
my 2 cents
1)
I you store image data , the actual data is not stored on the data
pages,instead it stores a 16 -byte pointer in the data row that indicates
where the actual data can be found.
2)
> We have a development environment running the exact same code (it is
> the exact same in everything, except for the amount of data stored in
> the DB). This does not happen there at all.
I think you have answered on your own question.
3)
DBCC PINTABLE is best used to keep small, frequently referenced tables in
memory. The pages for the small table are read into memory one time, then
all future references to their data do not require a disk read.

"Mee Yamo" <meeyamo@.hotmail.com> wrote in message
news:b5f0434e.0402010522.625a7a4d@.posting.google.c om...
> Fellas!!
> This is a very complicated one and it took me a few days to figure out
> exactly what's going on, but here's the final story:
> I have a production environment running on .NET with a SQL Server
> (2000, SP3). The SQL Server is on a dedicated Proliant computer with
> 2GB RAM (the actual SQLServer.exe process has dynamic memory
> assignment and can reach up to 1.6GB RAM). Nothing else is running on
> that specific computer.
> Once the SQLServer is started, it hits 300MB RAM (the minimum that was
> set in the configuration of the server - remember, it is dynamically
> aquired).
> Then there is a .NET program that requests just about all the data the
> SQL Server contains (apart from a single table that contains roughly
> 1.6 million rows and another table that contains about 10000 rows
> which are all of type IMAGE).
> Once all the data is retrieved, the RAM is at about 400MB. From there
> on, every update I make to the data on the server causes the RAM to go
> up by a bit (that updates are done in a Transaction which of course is
> committed at the end). It seems that BLOB updates are the major
> problem in all of this. For some reason, uploading a blob of size 9MB
> causes the RAM to go up by roughly 20MB and after commit it gose down
> 10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
> process hits its upper limit (1.6GB) and at this point it starts
> slowing down.
> Some performance checks showed me the SQLServer has a lot of disk
> activity, it seems it is reading and writing pages of data from/to the
> HD all the time (which causes the queries to be much much much
> slower).
> We have a development environment running the exact same code (it is
> the exact same in everything, except for the amount of data stored in
> the DB). This does not happen there at all.
> I have a few questions:
> 1. Why is the RAM going up after BLOB updates?
> 2. Why is the RAM going up at all?
> 3. How can I tell the DB which tables should remain in the RAM at all
> time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
> do the job.
> It does not seem to have anything to do with the .NET code.
> Thank you very much,
> M Yamo.|||Mee Yamo (meeyamo@.hotmail.com) writes:
> I have a production environment running on .NET with a SQL Server
> (2000, SP3). The SQL Server is on a dedicated Proliant computer with
> 2GB RAM (the actual SQLServer.exe process has dynamic memory
> assignment and can reach up to 1.6GB RAM). Nothing else is running on
> that specific computer.
> ...
> Once all the data is retrieved, the RAM is at about 400MB. From there
> on, every update I make to the data on the server causes the RAM to go
> up by a bit (that updates are done in a Transaction which of course is
> committed at the end). It seems that BLOB updates are the major
> problem in all of this. For some reason, uploading a blob of size 9MB
> causes the RAM to go up by roughly 20MB and after commit it gose down
> 10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
> process hits its upper limit (1.6GB) and at this point it starts
> slowing down.
>...
> I have a few questions:
> 1. Why is the RAM going up after BLOB updates?
> 2. Why is the RAM going up at all?
> 3. How can I tell the DB which tables should remain in the RAM at all
> time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
> do the job.

I guess since you post, you have a problem with your application. However,
your posting gives little information of what that problem might be.

The default behaviour of SQL Server is go grab as much as memory as
possible. The more data, SQL Server have in cache, the less it has to
read from disks. If there are competing applications on the machine,
this can be a problem if SQL Server does not yield memory fast enough.
But you say that this is dedicated to SQL Server, so if SQL Server gets
some more memory that is no cause for alarm.

DBCC PINTABLE is something you have little reason to play with. If you have
data that you access rarely, but when you access it, you need it quick,
then PINTABLE may be an option. For instance, the Managing Director wants a
report the first day of each months, and he cannot wait those two minutes
it would take to get the data from disk. But using DBCC PINTABLE is likely
to mean that you sacrifice overall performance.

> We have a development environment running the exact same code (it is
> the exact same in everything, except for the amount of data stored in
> the DB). This does not happen there at all.

The amount of data is surely the clue here. Assuming that you really
have performance problems, they are only likely to show when you have
a full-size database.

Since I don't know what your real problems are, it is diffiult to
give some relevant advice, but a good starting point is to review
indexing, if you have not done this already.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Hi,

Thanks for trying to help.

Well the problem still goes on. The SQLServer process has hit its max
RAM allowance and started to slow down again (DISK ACTIVITY). I
restarted the SQLServer service and that solved it.

Why is it memory hogging? Every update seems to leave a residue on the
process's memory consumption.

Erland Sommarskog <sommar@.algonet.se> wrote in message news:<Xns9482AB02DAFF4Yazorman@.127.0.0.1>...
> Mee Yamo (meeyamo@.hotmail.com) writes:
> > I have a production environment running on .NET with a SQL Server
> > (2000, SP3). The SQL Server is on a dedicated Proliant computer with
> > 2GB RAM (the actual SQLServer.exe process has dynamic memory
> > assignment and can reach up to 1.6GB RAM). Nothing else is running on
> > that specific computer.
> > ...
> > Once all the data is retrieved, the RAM is at about 400MB. From there
> > on, every update I make to the data on the server causes the RAM to go
> > up by a bit (that updates are done in a Transaction which of course is
> > committed at the end). It seems that BLOB updates are the major
> > problem in all of this. For some reason, uploading a blob of size 9MB
> > causes the RAM to go up by roughly 20MB and after commit it gose down
> > 10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
> > process hits its upper limit (1.6GB) and at this point it starts
> > slowing down.
> >...
> > I have a few questions:
> > 1. Why is the RAM going up after BLOB updates?
> > 2. Why is the RAM going up at all?
> > 3. How can I tell the DB which tables should remain in the RAM at all
> > time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
> > do the job.
> I guess since you post, you have a problem with your application. However,
> your posting gives little information of what that problem might be.
> The default behaviour of SQL Server is go grab as much as memory as
> possible. The more data, SQL Server have in cache, the less it has to
> read from disks. If there are competing applications on the machine,
> this can be a problem if SQL Server does not yield memory fast enough.
> But you say that this is dedicated to SQL Server, so if SQL Server gets
> some more memory that is no cause for alarm.
> DBCC PINTABLE is something you have little reason to play with. If you have
> data that you access rarely, but when you access it, you need it quick,
> then PINTABLE may be an option. For instance, the Managing Director wants a
> report the first day of each months, and he cannot wait those two minutes
> it would take to get the data from disk. But using DBCC PINTABLE is likely
> to mean that you sacrifice overall performance.
> > We have a development environment running the exact same code (it is
> > the exact same in everything, except for the amount of data stored in
> > the DB). This does not happen there at all.
> The amount of data is surely the clue here. Assuming that you really
> have performance problems, they are only likely to show when you have
> a full-size database.
> Since I don't know what your real problems are, it is diffiult to
> give some relevant advice, but a good starting point is to review
> indexing, if you have not done this already.|||Mee Yamo (meeyamo@.hotmail.com) writes:
> Well the problem still goes on. The SQLServer process has hit its max
> RAM allowance and started to slow down again (DISK ACTIVITY). I
> restarted the SQLServer service and that solved it.
> Why is it memory hogging? Every update seems to leave a residue on the
> process's memory consumption.

As I tried to explain, this by design. You should not worry about it.

If you have real performance problem with long response times etc, the
people in these newsgroups can assist, but you need to provide more
information.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Performance problem, lots of disk activity, running out of memory

Fellas!!
This is a very complicated one and it took me a few days to figure out
exactly what's going on, but here's the final story:
I have a production environment running on .NET with a SQL Server
(2000, SP3). The SQL Server is on a dedicated Proliant computer with
2GB RAM (the actual SQLServer.exe process has dynamic memory
assignment and can reach up to 1.6GB RAM). Nothing else is running on
that specific computer.
Once the SQLServer is started, it hits 300MB RAM (the minimum that was
set in the configuration of the server - remember, it is dynamically
aquired).
Then there is a .NET program that requests just about all the data the
SQL Server contains (apart from a single table that contains roughly
1.6 million rows and another table that contains about 10000 rows
which are all of type IMAGE).
Once all the data is retrieved, the RAM is at about 400MB. From there
on, every update I make to the data on the server causes the RAM to go
up by a bit (that updates are done in a Transaction which of course is
committed at the end). It seems that BLOB updates are the major
problem in all of this. For some reason, uploading a blob of size 9MB
causes the RAM to go up by roughly 20MB and after commit it gose down
10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
process hits its upper limit (1.6GB) and at this point it starts
slowing down.
Some performance checks showed me the SQLServer has a lot of disk
activity, it seems it is reading and writing pages of data from/to the
HD all the time (which causes the queries to be much much much
slower).
We have a development environment running the exact same code (it is
the exact same in everything, except for the amount of data stored in
the DB). This does not happen there at all.
I have a few questions:
1. Why is the RAM going up after BLOB updates?
2. Why is the RAM going up at all?
3. How can I tell the DB which tables should remain in the RAM at all
time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
do the job.
It does not seem to have anything to do with the .NET code.
Thank you very much,
M Yamo.Mee
my 2 cents
1)
I you store image data , the actual data is not stored on the data
pages,instead it stores a 16 -byte pointer in the data row that indicates
where the actual data can be found.
2)
> We have a development environment running the exact same code (it is
> the exact same in everything, except for the amount of data stored in
> the DB). This does not happen there at all.
I think you have answered on your own question.
3)
DBCC PINTABLE is best used to keep small, frequently referenced tables in
memory. The pages for the small table are read into memory one time, then
all future references to their data do not require a disk read.
"Mee Yamo" <meeyamo@.hotmail.com> wrote in message
news:b5f0434e.0402010522.625a7a4d@.posting.google.com...
> Fellas!!
> This is a very complicated one and it took me a few days to figure out
> exactly what's going on, but here's the final story:
> I have a production environment running on .NET with a SQL Server
> (2000, SP3). The SQL Server is on a dedicated Proliant computer with
> 2GB RAM (the actual SQLServer.exe process has dynamic memory
> assignment and can reach up to 1.6GB RAM). Nothing else is running on
> that specific computer.
> Once the SQLServer is started, it hits 300MB RAM (the minimum that was
> set in the configuration of the server - remember, it is dynamically
> aquired).
> Then there is a .NET program that requests just about all the data the
> SQL Server contains (apart from a single table that contains roughly
> 1.6 million rows and another table that contains about 10000 rows
> which are all of type IMAGE).
> Once all the data is retrieved, the RAM is at about 400MB. From there
> on, every update I make to the data on the server causes the RAM to go
> up by a bit (that updates are done in a Transaction which of course is
> committed at the end). It seems that BLOB updates are the major
> problem in all of this. For some reason, uploading a blob of size 9MB
> causes the RAM to go up by roughly 20MB and after commit it gose down
> 10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
> process hits its upper limit (1.6GB) and at this point it starts
> slowing down.
> Some performance checks showed me the SQLServer has a lot of disk
> activity, it seems it is reading and writing pages of data from/to the
> HD all the time (which causes the queries to be much much much
> slower).
> We have a development environment running the exact same code (it is
> the exact same in everything, except for the amount of data stored in
> the DB). This does not happen there at all.
> I have a few questions:
> 1. Why is the RAM going up after BLOB updates?
> 2. Why is the RAM going up at all?
> 3. How can I tell the DB which tables should remain in the RAM at all
> time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
> do the job.
> It does not seem to have anything to do with the .NET code.
> Thank you very much,
> M Yamo.|||Mee Yamo (meeyamo@.hotmail.com) writes:
> I have a production environment running on .NET with a SQL Server
> (2000, SP3). The SQL Server is on a dedicated Proliant computer with
> 2GB RAM (the actual SQLServer.exe process has dynamic memory
> assignment and can reach up to 1.6GB RAM). Nothing else is running on
> that specific computer.
> ...
> Once all the data is retrieved, the RAM is at about 400MB. From there
> on, every update I make to the data on the server causes the RAM to go
> up by a bit (that updates are done in a Transaction which of course is
> committed at the end). It seems that BLOB updates are the major
> problem in all of this. For some reason, uploading a blob of size 9MB
> causes the RAM to go up by roughly 20MB and after commit it gose down
> 10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
> process hits its upper limit (1.6GB) and at this point it starts
> slowing down.
>...
> I have a few questions:
> 1. Why is the RAM going up after BLOB updates?
> 2. Why is the RAM going up at all?
> 3. How can I tell the DB which tables should remain in the RAM at all
> time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
> do the job.
I guess since you post, you have a problem with your application. However,
your posting gives little information of what that problem might be.
The default behaviour of SQL Server is go grab as much as memory as
possible. The more data, SQL Server have in cache, the less it has to
read from disks. If there are competing applications on the machine,
this can be a problem if SQL Server does not yield memory fast enough.
But you say that this is dedicated to SQL Server, so if SQL Server gets
some more memory that is no cause for alarm.
DBCC PINTABLE is something you have little reason to play with. If you have
data that you access rarely, but when you access it, you need it quick,
then PINTABLE may be an option. For instance, the Managing Director wants a
report the first day of each months, and he cannot wait those two minutes
it would take to get the data from disk. But using DBCC PINTABLE is likely
to mean that you sacrifice overall performance.
> We have a development environment running the exact same code (it is
> the exact same in everything, except for the amount of data stored in
> the DB). This does not happen there at all.
The amount of data is surely the clue here. Assuming that you really
have performance problems, they are only likely to show when you have
a full-size database.
Since I don't know what your real problems are, it is diffiult to
give some relevant advice, but a good starting point is to review
indexing, if you have not done this already.
--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp|||Hi,
Thanks for trying to help.
Well the problem still goes on. The SQLServer process has hit its max
RAM allowance and started to slow down again (DISK ACTIVITY). I
restarted the SQLServer service and that solved it.
Why is it memory hogging? Every update seems to leave a residue on the
process's memory consumption.
Erland Sommarskog <sommar@.algonet.se> wrote in message news:<Xns9482AB02DAFF4Yazorman@.127.0.0.1>...
> Mee Yamo (meeyamo@.hotmail.com) writes:
> > I have a production environment running on .NET with a SQL Server
> > (2000, SP3). The SQL Server is on a dedicated Proliant computer with
> > 2GB RAM (the actual SQLServer.exe process has dynamic memory
> > assignment and can reach up to 1.6GB RAM). Nothing else is running on
> > that specific computer.
> > ...
> > Once all the data is retrieved, the RAM is at about 400MB. From there
> > on, every update I make to the data on the server causes the RAM to go
> > up by a bit (that updates are done in a Transaction which of course is
> > committed at the end). It seems that BLOB updates are the major
> > problem in all of this. For some reason, uploading a blob of size 9MB
> > causes the RAM to go up by roughly 20MB and after commit it gose down
> > 10MB (total gain of roughly 10MB RAM). Eventually the SQLServer
> > process hits its upper limit (1.6GB) and at this point it starts
> > slowing down.
> >...
> > I have a few questions:
> > 1. Why is the RAM going up after BLOB updates?
> > 2. Why is the RAM going up at all?
> > 3. How can I tell the DB which tables should remain in the RAM at all
> > time (never swapped back to the HD?) - DBCC PINTABLE does not seem to
> > do the job.
> I guess since you post, you have a problem with your application. However,
> your posting gives little information of what that problem might be.
> The default behaviour of SQL Server is go grab as much as memory as
> possible. The more data, SQL Server have in cache, the less it has to
> read from disks. If there are competing applications on the machine,
> this can be a problem if SQL Server does not yield memory fast enough.
> But you say that this is dedicated to SQL Server, so if SQL Server gets
> some more memory that is no cause for alarm.
> DBCC PINTABLE is something you have little reason to play with. If you have
> data that you access rarely, but when you access it, you need it quick,
> then PINTABLE may be an option. For instance, the Managing Director wants a
> report the first day of each months, and he cannot wait those two minutes
> it would take to get the data from disk. But using DBCC PINTABLE is likely
> to mean that you sacrifice overall performance.
> > We have a development environment running the exact same code (it is
> > the exact same in everything, except for the amount of data stored in
> > the DB). This does not happen there at all.
> The amount of data is surely the clue here. Assuming that you really
> have performance problems, they are only likely to show when you have
> a full-size database.
> Since I don't know what your real problems are, it is diffiult to
> give some relevant advice, but a good starting point is to review
> indexing, if you have not done this already.|||Mee Yamo (meeyamo@.hotmail.com) writes:
> Well the problem still goes on. The SQLServer process has hit its max
> RAM allowance and started to slow down again (DISK ACTIVITY). I
> restarted the SQLServer service and that solved it.
> Why is it memory hogging? Every update seems to leave a residue on the
> process's memory consumption.
As I tried to explain, this by design. You should not worry about it.
If you have real performance problem with long response times etc, the
people in these newsgroups can assist, but you need to provide more
information.
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

Saturday, February 25, 2012

Performance Monitoring?

My SQL Server 2000 system is pegged. Disk activity is maxed out and system is very unresponsive. Several people have database tasks running through this system and I'm pretty sure there is a single application that is the culprit and I'd like to identify which one.

Does anyone have any practical tips on using "Process Info" in Enterprise Manager? What units are CPU and Physical I/O displayed in? Why does the column sort on these fields not work as expected?

Do I just pick the process with the largest Physical I/O and assume that's the problem?Use profiler...but I'd look for a high cpu and no I/O

That would be a process stuck in a loop, or a very labor intensive in memory process (less likely)

Although I did build 1 like that once...extremeley quick compared to the I/O version...took 1/2 hour...22 hours with I/O...

Performance monitoring

Hi,
I'm using the counter log of Win 2003 to record the server activity (ex : %
processor time). This activity is stored in an SQL Server 2000 SP3a database
(named Performances). All data are stored in the table CounterData.
I tried to set a trigger on this table to copy inserted data to another
table (TB_LastCounters). This trigger does not work when data are
automatically inserted from the Win 2003 counter log. But, the trigger works
well when the data is inserted manually.
Could you explain me this behavior?
Here is a simplified example of my trigger :
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
VALUES (1, 'toto', 2)
END
Thanks a lot,
Eric.We need to see the real trigger and preferably an error message from SQL Server if you have such. My
guess is that the trigger doesn't handle multi-row modifications.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:67B984F3-DB2A-4F79-ABBC-67338F57F873@.microsoft.com...
> Hi,
> I'm using the counter log of Win 2003 to record the server activity (ex : %
> processor time). This activity is stored in an SQL Server 2000 SP3a database
> (named Performances). All data are stored in the table CounterData.
> I tried to set a trigger on this table to copy inserted data to another
> table (TB_LastCounters). This trigger does not work when data are
> automatically inserted from the Win 2003 counter log. But, the trigger works
> well when the data is inserted manually.
> Could you explain me this behavior?
> Here is a simplified example of my trigger :
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> VALUES (1, 'toto', 2)
> END
> Thanks a lot,
> Eric.|||Hi
You need to select from the Virtaul table called "Inserted" to get the rows
that were inserted by the statement.
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
SELECT INSERTED.CounterID, INSERTED.CounterDateTime, INSERTED.CounterValue
FROM INSERTED
END
--
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"itparis" wrote:
> Hi,
> I'm using the counter log of Win 2003 to record the server activity (ex : %
> processor time). This activity is stored in an SQL Server 2000 SP3a database
> (named Performances). All data are stored in the table CounterData.
> I tried to set a trigger on this table to copy inserted data to another
> table (TB_LastCounters). This trigger does not work when data are
> automatically inserted from the Win 2003 counter log. But, the trigger works
> well when the data is inserted manually.
> Could you explain me this behavior?
> Here is a simplified example of my trigger :
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> VALUES (1, 'toto', 2)
> END
> Thanks a lot,
> Eric.|||Thank you for your responses.
When Win 2003 counter log fills the CounterData table, the trigger does not
work but there are no errors.
Here is my real trigger :
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
CounterDate, CounterValue FROM INSERTED
END
This trigger works when I manually add data to CounterData table but does
not work when it is Win2003 counter log.
Thank you,
Eric.
"Mike Epprecht (SQL MVP)" a écrit :
> Hi
> You need to select from the Virtaul table called "Inserted" to get the rows
> that were inserted by the statement.
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> SELECT INSERTED.CounterID, INSERTED.CounterDateTime, INSERTED.CounterValue
> FROM INSERTED
> END
> --
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "itparis" wrote:
> > Hi,
> >
> > I'm using the counter log of Win 2003 to record the server activity (ex : %
> > processor time). This activity is stored in an SQL Server 2000 SP3a database
> > (named Performances). All data are stored in the table CounterData.
> >
> > I tried to set a trigger on this table to copy inserted data to another
> > table (TB_LastCounters). This trigger does not work when data are
> > automatically inserted from the Win 2003 counter log. But, the trigger works
> > well when the data is inserted manually.
> >
> > Could you explain me this behavior?
> >
> > Here is a simplified example of my trigger :
> >
> > CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> > FOR INSERT
> > AS
> > BEGIN
> > INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> > VALUES (1, 'toto', 2)
> > END
> >
> > Thanks a lot,
> >
> > Eric.|||Hi
If it does not work, then the odds are good that it is failing, and rolling
back the transaction too.
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
CounterDate, CounterValue FROM INSERTED
IF @.@.ERROR <> 0
PRINT 'Error Occurred'
END
END
Do an insert manually and see what happens.
--
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"itparis" wrote:
> Thank you for your responses.
> When Win 2003 counter log fills the CounterData table, the trigger does not
> work but there are no errors.
> Here is my real trigger :
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
> SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
> SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
> CounterDate, CounterValue FROM INSERTED
> END
> This trigger works when I manually add data to CounterData table but does
> not work when it is Win2003 counter log.
> Thank you,
> Eric.
> "Mike Epprecht (SQL MVP)" a écrit :
> > Hi
> >
> > You need to select from the Virtaul table called "Inserted" to get the rows
> > that were inserted by the statement.
> >
> > CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> > FOR INSERT
> > AS
> > BEGIN
> > INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> > SELECT INSERTED.CounterID, INSERTED.CounterDateTime, INSERTED.CounterValue
> > FROM INSERTED
> > END
> >
> > --
> > --
> > Mike Epprecht, Microsoft SQL Server MVP
> > Zurich, Switzerland
> >
> > MVP Program: http://www.microsoft.com/mvp
> >
> > Blog: http://www.msmvps.com/epprecht/
> >
> >
> >
> > "itparis" wrote:
> >
> > > Hi,
> > >
> > > I'm using the counter log of Win 2003 to record the server activity (ex : %
> > > processor time). This activity is stored in an SQL Server 2000 SP3a database
> > > (named Performances). All data are stored in the table CounterData.
> > >
> > > I tried to set a trigger on this table to copy inserted data to another
> > > table (TB_LastCounters). This trigger does not work when data are
> > > automatically inserted from the Win 2003 counter log. But, the trigger works
> > > well when the data is inserted manually.
> > >
> > > Could you explain me this behavior?
> > >
> > > Here is a simplified example of my trigger :
> > >
> > > CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> > > FOR INSERT
> > > AS
> > > BEGIN
> > > INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> > > VALUES (1, 'toto', 2)
> > > END
> > >
> > > Thanks a lot,
> > >
> > > Eric.|||Hi Mike,
I've written your trigger. I made your test but I don't know where I can see
the result of PRINT 'Error occured'. Can you tell me where I could see it?
Thanks,
Eric.
"Mike Epprecht (SQL MVP)" a écrit :
> Hi
> If it does not work, then the odds are good that it is failing, and rolling
> back the transaction too.
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
> SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
> SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
> CounterDate, CounterValue FROM INSERTED
> IF @.@.ERROR <> 0
> PRINT 'Error Occurred'
> END
> END
> Do an insert manually and see what happens.
> --
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "itparis" wrote:
> > Thank you for your responses.
> >
> > When Win 2003 counter log fills the CounterData table, the trigger does not
> > work but there are no errors.
> > Here is my real trigger :
> >
> > CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> > FOR INSERT
> > AS
> > BEGIN
> > INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> > SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
> > SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
> > SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
> > CounterDate, CounterValue FROM INSERTED
> > END
> >
> > This trigger works when I manually add data to CounterData table but does
> > not work when it is Win2003 counter log.
> >
> > Thank you,
> >
> > Eric.
> >
> > "Mike Epprecht (SQL MVP)" a écrit :
> >
> > > Hi
> > >
> > > You need to select from the Virtaul table called "Inserted" to get the rows
> > > that were inserted by the statement.
> > >
> > > CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> > > FOR INSERT
> > > AS
> > > BEGIN
> > > INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> > > SELECT INSERTED.CounterID, INSERTED.CounterDateTime, INSERTED.CounterValue
> > > FROM INSERTED
> > > END
> > >
> > > --
> > > --
> > > Mike Epprecht, Microsoft SQL Server MVP
> > > Zurich, Switzerland
> > >
> > > MVP Program: http://www.microsoft.com/mvp
> > >
> > > Blog: http://www.msmvps.com/epprecht/
> > >
> > >
> > >
> > > "itparis" wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm using the counter log of Win 2003 to record the server activity (ex : %
> > > > processor time). This activity is stored in an SQL Server 2000 SP3a database
> > > > (named Performances). All data are stored in the table CounterData.
> > > >
> > > > I tried to set a trigger on this table to copy inserted data to another
> > > > table (TB_LastCounters). This trigger does not work when data are
> > > > automatically inserted from the Win 2003 counter log. But, the trigger works
> > > > well when the data is inserted manually.
> > > >
> > > > Could you explain me this behavior?
> > > >
> > > > Here is a simplified example of my trigger :
> > > >
> > > > CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> > > > FOR INSERT
> > > > AS
> > > > BEGIN
> > > > INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> > > > VALUES (1, 'toto', 2)
> > > > END
> > > >
> > > > Thanks a lot,
> > > >
> > > > Eric.|||How does perfmon insert the data? Run a profiler trace to see whether perfmon does regular INSERTs
or uses some form of bulk loading API. Of the later, these API's can bypass triggers.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:81DAD60B-7D64-45AB-965E-31C58426AA6C@.microsoft.com...
> Hi Mike,
> I've written your trigger. I made your test but I don't know where I can see
> the result of PRINT 'Error occured'. Can you tell me where I could see it?
> Thanks,
> Eric.
> "Mike Epprecht (SQL MVP)" a écrit :
>> Hi
>> If it does not work, then the odds are good that it is failing, and rolling
>> back the transaction too.
>> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
>> FOR INSERT
>> AS
>> BEGIN
>> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
>> SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
>> SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
>> SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
>> CounterDate, CounterValue FROM INSERTED
>> IF @.@.ERROR <> 0
>> PRINT 'Error Occurred'
>> END
>> END
>> Do an insert manually and see what happens.
>> --
>> --
>> Mike Epprecht, Microsoft SQL Server MVP
>> Zurich, Switzerland
>> MVP Program: http://www.microsoft.com/mvp
>> Blog: http://www.msmvps.com/epprecht/
>>
>> "itparis" wrote:
>> > Thank you for your responses.
>> >
>> > When Win 2003 counter log fills the CounterData table, the trigger does not
>> > work but there are no errors.
>> > Here is my real trigger :
>> >
>> > CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
>> > FOR INSERT
>> > AS
>> > BEGIN
>> > INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
>> > SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
>> > SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
>> > SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
>> > CounterDate, CounterValue FROM INSERTED
>> > END
>> >
>> > This trigger works when I manually add data to CounterData table but does
>> > not work when it is Win2003 counter log.
>> >
>> > Thank you,
>> >
>> > Eric.
>> >
>> > "Mike Epprecht (SQL MVP)" a écrit :
>> >
>> > > Hi
>> > >
>> > > You need to select from the Virtaul table called "Inserted" to get the rows
>> > > that were inserted by the statement.
>> > >
>> > > CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
>> > > FOR INSERT
>> > > AS
>> > > BEGIN
>> > > INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
>> > > SELECT INSERTED.CounterID, INSERTED.CounterDateTime, INSERTED.CounterValue
>> > > FROM INSERTED
>> > > END
>> > >
>> > > --
>> > > --
>> > > Mike Epprecht, Microsoft SQL Server MVP
>> > > Zurich, Switzerland
>> > >
>> > > MVP Program: http://www.microsoft.com/mvp
>> > >
>> > > Blog: http://www.msmvps.com/epprecht/
>> > >
>> > >
>> > >
>> > > "itparis" wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > I'm using the counter log of Win 2003 to record the server activity (ex : %
>> > > > processor time). This activity is stored in an SQL Server 2000 SP3a database
>> > > > (named Performances). All data are stored in the table CounterData.
>> > > >
>> > > > I tried to set a trigger on this table to copy inserted data to another
>> > > > table (TB_LastCounters). This trigger does not work when data are
>> > > > automatically inserted from the Win 2003 counter log. But, the trigger works
>> > > > well when the data is inserted manually.
>> > > >
>> > > > Could you explain me this behavior?
>> > > >
>> > > > Here is a simplified example of my trigger :
>> > > >
>> > > > CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
>> > > > FOR INSERT
>> > > > AS
>> > > > BEGIN
>> > > > INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
>> > > > VALUES (1, 'toto', 2)
>> > > > END
>> > > >
>> > > > Thanks a lot,
>> > > >
>> > > > Eric.

Monday, February 20, 2012

Performance monitoring

Hi,
I'm using the counter log of Win 2003 to record the server activity (ex : %
processor time). This activity is stored in an SQL Server 2000 SP3a database
(named Performances). All data are stored in the table CounterData.
I tried to set a trigger on this table to copy inserted data to another
table (TB_LastCounters). This trigger does not work when data are
automatically inserted from the Win 2003 counter log. But, the trigger works
well when the data is inserted manually.
Could you explain me this behavior?
Here is a simplified example of my trigger :
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
VALUES (1, 'toto', 2)
END
Thanks a lot,
Eric.
We need to see the real trigger and preferably an error message from SQL Server if you have such. My
guess is that the trigger doesn't handle multi-row modifications.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:67B984F3-DB2A-4F79-ABBC-67338F57F873@.microsoft.com...
> Hi,
> I'm using the counter log of Win 2003 to record the server activity (ex : %
> processor time). This activity is stored in an SQL Server 2000 SP3a database
> (named Performances). All data are stored in the table CounterData.
> I tried to set a trigger on this table to copy inserted data to another
> table (TB_LastCounters). This trigger does not work when data are
> automatically inserted from the Win 2003 counter log. But, the trigger works
> well when the data is inserted manually.
> Could you explain me this behavior?
> Here is a simplified example of my trigger :
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> VALUES (1, 'toto', 2)
> END
> Thanks a lot,
> Eric.
|||Hi
You need to select from the Virtaul table called "Inserted" to get the rows
that were inserted by the statement.
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
SELECT INSERTED.CounterID, INSERTED.CounterDateTime, INSERTED.CounterValue
FROM INSERTED
END
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"itparis" wrote:

> Hi,
> I'm using the counter log of Win 2003 to record the server activity (ex : %
> processor time). This activity is stored in an SQL Server 2000 SP3a database
> (named Performances). All data are stored in the table CounterData.
> I tried to set a trigger on this table to copy inserted data to another
> table (TB_LastCounters). This trigger does not work when data are
> automatically inserted from the Win 2003 counter log. But, the trigger works
> well when the data is inserted manually.
> Could you explain me this behavior?
> Here is a simplified example of my trigger :
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> VALUES (1, 'toto', 2)
> END
> Thanks a lot,
> Eric.
|||Thank you for your responses.
When Win 2003 counter log fills the CounterData table, the trigger does not
work but there are no errors.
Here is my real trigger :
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
CounterDate, CounterValue FROM INSERTED
END
This trigger works when I manually add data to CounterData table but does
not work when it is Win2003 counter log.
Thank you,
Eric.
"Mike Epprecht (SQL MVP)" a écrit :
[vbcol=seagreen]
> Hi
> You need to select from the Virtaul table called "Inserted" to get the rows
> that were inserted by the statement.
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> SELECT INSERTED.CounterID, INSERTED.CounterDateTime, INSERTED.CounterValue
> FROM INSERTED
> END
> --
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "itparis" wrote:
|||Hi
If it does not work, then the odds are good that it is failing, and rolling
back the transaction too.
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
CounterDate, CounterValue FROM INSERTED
IF @.@.ERROR <> 0
PRINT 'Error Occurred'
END
END
Do an insert manually and see what happens.
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"itparis" wrote:
[vbcol=seagreen]
> Thank you for your responses.
> When Win 2003 counter log fills the CounterData table, the trigger does not
> work but there are no errors.
> Here is my real trigger :
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
> SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
> SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
> CounterDate, CounterValue FROM INSERTED
> END
> This trigger works when I manually add data to CounterData table but does
> not work when it is Win2003 counter log.
> Thank you,
> Eric.
> "Mike Epprecht (SQL MVP)" a écrit :
|||Hi Mike,
I've written your trigger. I made your test but I don't know where I can see
the result of PRINT 'Error occured'. Can you tell me where I could see it?
Thanks,
Eric.
"Mike Epprecht (SQL MVP)" a écrit :
[vbcol=seagreen]
> Hi
> If it does not work, then the odds are good that it is failing, and rolling
> back the transaction too.
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2) +
> SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
> SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
> CounterDate, CounterValue FROM INSERTED
> IF @.@.ERROR <> 0
> PRINT 'Error Occurred'
> END
> END
> Do an insert manually and see what happens.
> --
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "itparis" wrote:
|||How does perfmon insert the data? Run a profiler trace to see whether perfmon does regular INSERTs
or uses some form of bulk loading API. Of the later, these API's can bypass triggers.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:81DAD60B-7D64-45AB-965E-31C58426AA6C@.microsoft.com...[vbcol=seagreen]
> Hi Mike,
> I've written your trigger. I made your test but I don't know where I can see
> the result of PRINT 'Error occured'. Can you tell me where I could see it?
> Thanks,
> Eric.
> "Mike Epprecht (SQL MVP)" a écrit :

Performance monitoring

Hi,
I'm using the counter log of Win 2003 to record the server activity (ex : %
processor time). This activity is stored in an SQL Server 2000 SP3a database
(named Performances). All data are stored in the table CounterData.
I tried to set a trigger on this table to copy inserted data to another
table (TB_LastCounters). This trigger does not work when data are
automatically inserted from the Win 2003 counter log. But, the trigger works
well when the data is inserted manually.
Could you explain me this behavior?
Here is a simplified example of my trigger :
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
VALUES (1, 'toto', 2)
END
Thanks a lot,
Eric.We need to see the real trigger and preferably an error message from SQL Ser
ver if you have such. My
guess is that the trigger doesn't handle multi-row modifications.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:67B984F3-DB2A-4F79-ABBC-67338F57F873@.microsoft.com...
> Hi,
> I'm using the counter log of Win 2003 to record the server activity (ex :
%
> processor time). This activity is stored in an SQL Server 2000 SP3a databa
se
> (named Performances). All data are stored in the table CounterData.
> I tried to set a trigger on this table to copy inserted data to another
> table (TB_LastCounters). This trigger does not work when data are
> automatically inserted from the Win 2003 counter log. But, the trigger wor
ks
> well when the data is inserted manually.
> Could you explain me this behavior?
> Here is a simplified example of my trigger :
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> VALUES (1, 'toto', 2)
> END
> Thanks a lot,
> Eric.|||Hi
You need to select from the Virtaul table called "Inserted" to get the rows
that were inserted by the statement.
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
SELECT INSERTED.CounterID, INSERTED.CounterDateTime, INSERTED.CounterValue
FROM INSERTED
END
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"itparis" wrote:

> Hi,
> I'm using the counter log of Win 2003 to record the server activity (ex :
%
> processor time). This activity is stored in an SQL Server 2000 SP3a databa
se
> (named Performances). All data are stored in the table CounterData.
> I tried to set a trigger on this table to copy inserted data to another
> table (TB_LastCounters). This trigger does not work when data are
> automatically inserted from the Win 2003 counter log. But, the trigger wor
ks
> well when the data is inserted manually.
> Could you explain me this behavior?
> Here is a simplified example of my trigger :
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> VALUES (1, 'toto', 2)
> END
> Thanks a lot,
> Eric.|||Thank you for your responses.
When Win 2003 counter log fills the CounterData table, the trigger does not
work but there are no errors.
Here is my real trigger :
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2)
+
SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
CounterDate, CounterValue FROM INSERTED
END
This trigger works when I manually add data to CounterData table but does
not work when it is Win2003 counter log.
Thank you,
Eric.
"Mike Epprecht (SQL MVP)" a écrit :
[vbcol=seagreen]
> Hi
> You need to select from the Virtaul table called "Inserted" to get the row
s
> that were inserted by the statement.
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> SELECT INSERTED.CounterID, INSERTED.CounterDateTime, INSERTED.CounterValue
> FROM INSERTED
> END
> --
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "itparis" wrote:
>|||Hi
If it does not work, then the odds are good that it is failing, and rolling
back the transaction too.
CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
FOR INSERT
AS
BEGIN
INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2)
+
SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
CounterDate, CounterValue FROM INSERTED
IF @.@.ERROR <> 0
PRINT 'Error Occurred'
END
END
Do an insert manually and see what happens.
--
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"itparis" wrote:
[vbcol=seagreen]
> Thank you for your responses.
> When Win 2003 counter log fills the CounterData table, the trigger does no
t
> work but there are no errors.
> Here is my real trigger :
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2)
+
> SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
> SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
> CounterDate, CounterValue FROM INSERTED
> END
> This trigger works when I manually add data to CounterData table but does
> not work when it is Win2003 counter log.
> Thank you,
> Eric.
> "Mike Epprecht (SQL MVP)" a écrit :
>|||Hi Mike,
I've written your trigger. I made your test but I don't know where I can see
the result of PRINT 'Error occured'. Can you tell me where I could see it?
Thanks,
Eric.
"Mike Epprecht (SQL MVP)" a écrit :
[vbcol=seagreen]
> Hi
> If it does not work, then the odds are good that it is failing, and rollin
g
> back the transaction too.
> CREATE TRIGGER CopyInsertions ON [dbo].[CounterData]
> FOR INSERT
> AS
> BEGIN
> INSERT INTO TB_LastCounters (CounterID, CounterDateTime, CounterValue)
> SELECT CounterID, LEFT(CounterDateTime,4) + SUBSTRING(CounterDateTime,6,2)
+
> SUBSTRING(CounterDateTime,9,2) + SUBSTRING(CounterDateTime,12,2) +
> SUBSTRING(CounterDateTime,15,2) + SUBSTRING(CounterDateTime,18,2) As
> CounterDate, CounterValue FROM INSERTED
> IF @.@.ERROR <> 0
> PRINT 'Error Occurred'
> END
> END
> Do an insert manually and see what happens.
> --
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "itparis" wrote:
>|||How does perfmon insert the data? Run a profiler trace to see whether perfmo
n does regular INSERTs
or uses some form of bulk loading API. Of the later, these API's can bypass
triggers.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"itparis" <itparis@.discussions.microsoft.com> wrote in message
news:81DAD60B-7D64-45AB-965E-31C58426AA6C@.microsoft.com...[vbcol=seagreen]
> Hi Mike,
> I've written your trigger. I made your test but I don't know where I can s
ee
> the result of PRINT 'Error occured'. Can you tell me where I could see it?
> Thanks,
> Eric.
> "Mike Epprecht (SQL MVP)" a écrit :
>