performance monitoring: memory

Showing posts with label memory. Show all posts

Friday, March 30, 2012

Performance turning

Is there a way we can identify most frequently hit tables in the database. We
would like to pin most frequently used tables in memory.
We have 6GB physical memory and like to allocate as 4-5 GB of memory to SQL
server.
Note: 4 or 5 of the tables have at least a million records.
Thanks in advance
Regards,
Amar
Amar
SQL Server Profiler is your tool.
"Amar" <Amar@.discussions.microsoft.com> wrote in message
news:08AF5B1E-3DE4-452B-8FF0-AF2C68EE4CDF@.microsoft.com...
> Is there a way we can identify most frequently hit tables in the database.
We
> would like to pin most frequently used tables in memory.
> We have 6GB physical memory and like to allocate as 4-5 GB of memory to
SQL
> server.
> Note: 4 or 5 of the tables have at least a million records.
> Thanks in advance
> Regards,
> Amar
|||Hi
Pinning very small tables can be argued for under extreme circumstances, but
tables with millions of rows, forget it. If you have queries that need to
process so many rows, you have a basic data architecture problem.
Pinning a table results in that memory not being available to other table
caches, so in effect, you might starve the cache and worsen performance.
SQL Server keeps track of how many times a page has been accessed, so it
will not discard heavily used pages.
Only after turning every query, and optimizing every index and table, should
you consider pinning tables. By then you would know what tables are problems.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Amar" wrote:

> Is there a way we can identify most frequently hit tables in the database. We
> would like to pin most frequently used tables in memory.
> We have 6GB physical memory and like to allocate as 4-5 GB of memory to SQL
> server.
> Note: 4 or 5 of the tables have at least a million records.
> Thanks in advance
> Regards,
> Amar
|||Hi Mike,
Thanks for your quick response. Couple of points I wanted to mention here
are we are using a product which is supplied by our supplier and hence
changing/tuning query needs to go through our QA/testing. We were looking at
this approach of pinning the table as a temporary fix while our supplier
works on tuning the queries. Would you think that is a good idea?
Other thing we noticed was our SQL is using only 1.7 GB of memory when we
have lot more unused memory. As you have said earlier we are noticing very
high cache hit at the same time we are also seeing very high disk read that
is 200M Bytes per sec.
We were looking for a quick fix as our users are finding it very difficult
to work with slow performing system which is affecting the business.
Thanks again for your help.
Regards,
Amar
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> Pinning very small tables can be argued for under extreme circumstances, but
> tables with millions of rows, forget it. If you have queries that need to
> process so many rows, you have a basic data architecture problem.
> Pinning a table results in that memory not being available to other table
> caches, so in effect, you might starve the cache and worsen performance.
> SQL Server keeps track of how many times a page has been accessed, so it
> will not discard heavily used pages.
> Only after turning every query, and optimizing every index and table, should
> you consider pinning tables. By then you would know what tables are problems.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "Amar" wrote:
|||Amar wrote:
> Hi Mike,
> Thanks for your quick response. Couple of points I wanted to mention
> here are we are using a product which is supplied by our supplier and
> hence changing/tuning query needs to go through our QA/testing. We
> were looking at this approach of pinning the table as a temporary fix
> while our supplier works on tuning the queries. Would you think that
> is a good idea?
> Other thing we noticed was our SQL is using only 1.7 GB of memory
> when we have lot more unused memory. As you have said earlier we are
> noticing very high cache hit at the same time we are also seeing very
> high disk read that is 200M Bytes per sec.
> We were looking for a quick fix as our users are finding it very
> difficult to work with slow performing system which is affecting the
> business.
>
As Mike said, you can pin very small tables if necessary, but you're not
likely to get much improved performance. If you pin the large tables
(the 4 or 5 with millions of rows), and those tables fill up available
SQL Server memory, you might find performance degraded as SQL Server has
to continually grab all other data from disk. You'd need to measure how
large the tables are and weight that against the size of the remaining
table and available memory.
What server version and edition and SQL edition are you using?
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Hi David,
Thanks for the response.
We are using SQL Enterprise edition and Windows 2003 Enterprise edition.
It is clustred sql with 2 nodes
Is there a way we can identify most frequently hit tables in the database?
"David Gugick" wrote:

> Amar wrote:
> As Mike said, you can pin very small tables if necessary, but you're not
> likely to get much improved performance. If you pin the large tables
> (the 4 or 5 with millions of rows), and those tables fill up available
> SQL Server memory, you might find performance degraded as SQL Server has
> to continually grab all other data from disk. You'd need to measure how
> large the tables are and weight that against the size of the remaining
> table and available memory.
> What server version and edition and SQL edition are you using?
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
|||Amar wrote:
> Hi David,
> Thanks for the response.
> We are using SQL Enterprise edition and Windows 2003 Enterprise
> edition. It is clustred sql with 2 nodes
> Is there a way we can identify most frequently hit tables in the
> database?
>
"Frequently hit" is a somewhat nebulous term. Those tables that are
accessed most frequently may not be best candidates for pinning if they
are always accessed in an index optimzed fashion. Proper indexing keeps
page reads to a minimum and keeps the data cache fresh with usable data.
Conversely, a table that is accessed infrequently, but is accessed by
table scan or clustered index scan operations, can cause the data cache
to get flushed of its good data and replaced with data that has no
business being there.
So my recommendation for a temporary fix is get SQL Server to use as
much memory as possible and at the same time start performance tuning
the database. I think you'll find that looking for candidates now for
pinning is a waste of time since it's going to be time consuming and
difficult to determine the benefits.
I realize you are looking for a quick, temporary fix to performance
issues, but these problems are almost always related to query and index
design. There is little in the way of quick fixes that can help, short
of adding/utilizing all available memory.
I'm not sure if it was you that started another thread on your memory
issues, but are you running AWE and SP4. If so, have you download the
latest SP4 AWE hotfix?
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Hi Mike and David,
Thanks a lot for quick response and all the suggestions.
Regards,
Amar
"David Gugick" wrote:

> Amar wrote:
> "Frequently hit" is a somewhat nebulous term. Those tables that are
> accessed most frequently may not be best candidates for pinning if they
> are always accessed in an index optimzed fashion. Proper indexing keeps
> page reads to a minimum and keeps the data cache fresh with usable data.
> Conversely, a table that is accessed infrequently, but is accessed by
> table scan or clustered index scan operations, can cause the data cache
> to get flushed of its good data and replaced with data that has no
> business being there.
> So my recommendation for a temporary fix is get SQL Server to use as
> much memory as possible and at the same time start performance tuning
> the database. I think you'll find that looking for candidates now for
> pinning is a waste of time since it's going to be time consuming and
> difficult to determine the benefits.
> I realize you are looking for a quick, temporary fix to performance
> issues, but these problems are almost always related to query and index
> design. There is little in the way of quick fixes that can help, short
> of adding/utilizing all available memory.
> I'm not sure if it was you that started another thread on your memory
> issues, but are you running AWE and SP4. If so, have you download the
> latest SP4 AWE hotfix?
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>

Performance turning

Is there a way we can identify most frequently hit tables in the database. We
would like to pin most frequently used tables in memory.
We have 6GB physical memory and like to allocate as 4-5 GB of memory to SQL
server.
Note: 4 or 5 of the tables have at least a million records.
Thanks in advance
Regards,
AmarAmar
SQL Server Profiler is your tool.
"Amar" <Amar@.discussions.microsoft.com> wrote in message
news:08AF5B1E-3DE4-452B-8FF0-AF2C68EE4CDF@.microsoft.com...
> Is there a way we can identify most frequently hit tables in the database.
We
> would like to pin most frequently used tables in memory.
> We have 6GB physical memory and like to allocate as 4-5 GB of memory to
SQL
> server.
> Note: 4 or 5 of the tables have at least a million records.
> Thanks in advance
> Regards,
> Amar|||Hi
Pinning very small tables can be argued for under extreme circumstances, but
tables with millions of rows, forget it. If you have queries that need to
process so many rows, you have a basic data architecture problem.
Pinning a table results in that memory not being available to other table
caches, so in effect, you might starve the cache and worsen performance.
SQL Server keeps track of how many times a page has been accessed, so it
will not discard heavily used pages.
Only after turning every query, and optimizing every index and table, should
you consider pinning tables. By then you would know what tables are problems.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Amar" wrote:
> Is there a way we can identify most frequently hit tables in the database. We
> would like to pin most frequently used tables in memory.
> We have 6GB physical memory and like to allocate as 4-5 GB of memory to SQL
> server.
> Note: 4 or 5 of the tables have at least a million records.
> Thanks in advance
> Regards,
> Amar|||Hi Mike,
Thanks for your quick response. Couple of points I wanted to mention here
are we are using a product which is supplied by our supplier and hence
changing/tuning query needs to go through our QA/testing. We were looking at
this approach of pinning the table as a temporary fix while our supplier
works on tuning the queries. Would you think that is a good idea?
Other thing we noticed was our SQL is using only 1.7 GB of memory when we
have lot more unused memory. As you have said earlier we are noticing very
high cache hit at the same time we are also seeing very high disk read that
is 200M Bytes per sec.
We were looking for a quick fix as our users are finding it very difficult
to work with slow performing system which is affecting the business.
Thanks again for your help.
Regards,
Amar
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> Pinning very small tables can be argued for under extreme circumstances, but
> tables with millions of rows, forget it. If you have queries that need to
> process so many rows, you have a basic data architecture problem.
> Pinning a table results in that memory not being available to other table
> caches, so in effect, you might starve the cache and worsen performance.
> SQL Server keeps track of how many times a page has been accessed, so it
> will not discard heavily used pages.
> Only after turning every query, and optimizing every index and table, should
> you consider pinning tables. By then you would know what tables are problems.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "Amar" wrote:
> > Is there a way we can identify most frequently hit tables in the database. We
> > would like to pin most frequently used tables in memory.
> > We have 6GB physical memory and like to allocate as 4-5 GB of memory to SQL
> > server.
> >
> > Note: 4 or 5 of the tables have at least a million records.
> >
> > Thanks in advance
> > Regards,
> > Amar|||Amar wrote:
> Hi Mike,
> Thanks for your quick response. Couple of points I wanted to mention
> here are we are using a product which is supplied by our supplier and
> hence changing/tuning query needs to go through our QA/testing. We
> were looking at this approach of pinning the table as a temporary fix
> while our supplier works on tuning the queries. Would you think that
> is a good idea?
> Other thing we noticed was our SQL is using only 1.7 GB of memory
> when we have lot more unused memory. As you have said earlier we are
> noticing very high cache hit at the same time we are also seeing very
> high disk read that is 200M Bytes per sec.
> We were looking for a quick fix as our users are finding it very
> difficult to work with slow performing system which is affecting the
> business.
>
As Mike said, you can pin very small tables if necessary, but you're not
likely to get much improved performance. If you pin the large tables
(the 4 or 5 with millions of rows), and those tables fill up available
SQL Server memory, you might find performance degraded as SQL Server has
to continually grab all other data from disk. You'd need to measure how
large the tables are and weight that against the size of the remaining
table and available memory.
What server version and edition and SQL edition are you using?
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Hi David,
Thanks for the response.
We are using SQL Enterprise edition and Windows 2003 Enterprise edition.
It is clustred sql with 2 nodes
Is there a way we can identify most frequently hit tables in the database?
"David Gugick" wrote:
> Amar wrote:
> > Hi Mike,
> > Thanks for your quick response. Couple of points I wanted to mention
> > here are we are using a product which is supplied by our supplier and
> > hence changing/tuning query needs to go through our QA/testing. We
> > were looking at this approach of pinning the table as a temporary fix
> > while our supplier works on tuning the queries. Would you think that
> > is a good idea?
> >
> > Other thing we noticed was our SQL is using only 1.7 GB of memory
> > when we have lot more unused memory. As you have said earlier we are
> > noticing very high cache hit at the same time we are also seeing very
> > high disk read that is 200M Bytes per sec.
> >
> > We were looking for a quick fix as our users are finding it very
> > difficult to work with slow performing system which is affecting the
> > business.
> >
> As Mike said, you can pin very small tables if necessary, but you're not
> likely to get much improved performance. If you pin the large tables
> (the 4 or 5 with millions of rows), and those tables fill up available
> SQL Server memory, you might find performance degraded as SQL Server has
> to continually grab all other data from disk. You'd need to measure how
> large the tables are and weight that against the size of the remaining
> table and available memory.
> What server version and edition and SQL edition are you using?
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>|||Amar wrote:
> Hi David,
> Thanks for the response.
> We are using SQL Enterprise edition and Windows 2003 Enterprise
> edition. It is clustred sql with 2 nodes
> Is there a way we can identify most frequently hit tables in the
> database?
>
"Frequently hit" is a somewhat nebulous term. Those tables that are
accessed most frequently may not be best candidates for pinning if they
are always accessed in an index optimzed fashion. Proper indexing keeps
page reads to a minimum and keeps the data cache fresh with usable data.
Conversely, a table that is accessed infrequently, but is accessed by
table scan or clustered index scan operations, can cause the data cache
to get flushed of its good data and replaced with data that has no
business being there.
So my recommendation for a temporary fix is get SQL Server to use as
much memory as possible and at the same time start performance tuning
the database. I think you'll find that looking for candidates now for
pinning is a waste of time since it's going to be time consuming and
difficult to determine the benefits.
I realize you are looking for a quick, temporary fix to performance
issues, but these problems are almost always related to query and index
design. There is little in the way of quick fixes that can help, short
of adding/utilizing all available memory.
I'm not sure if it was you that started another thread on your memory
issues, but are you running AWE and SP4. If so, have you download the
latest SP4 AWE hotfix?
--
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Hi Mike and David,
Thanks a lot for quick response and all the suggestions.
Regards,
Amar
"David Gugick" wrote:
> Amar wrote:
> > Hi David,
> > Thanks for the response.
> > We are using SQL Enterprise edition and Windows 2003 Enterprise
> > edition. It is clustred sql with 2 nodes
> > Is there a way we can identify most frequently hit tables in the
> > database?
> >
> "Frequently hit" is a somewhat nebulous term. Those tables that are
> accessed most frequently may not be best candidates for pinning if they
> are always accessed in an index optimzed fashion. Proper indexing keeps
> page reads to a minimum and keeps the data cache fresh with usable data.
> Conversely, a table that is accessed infrequently, but is accessed by
> table scan or clustered index scan operations, can cause the data cache
> to get flushed of its good data and replaced with data that has no
> business being there.
> So my recommendation for a temporary fix is get SQL Server to use as
> much memory as possible and at the same time start performance tuning
> the database. I think you'll find that looking for candidates now for
> pinning is a waste of time since it's going to be time consuming and
> difficult to determine the benefits.
> I realize you are looking for a quick, temporary fix to performance
> issues, but these problems are almost always related to query and index
> design. There is little in the way of quick fixes that can help, short
> of adding/utilizing all available memory.
> I'm not sure if it was you that started another thread on your memory
> issues, but are you running AWE and SP4. If so, have you download the
> latest SP4 AWE hotfix?
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>

Performance turning

Is there a way we can identify most frequently hit tables in the database. W
e
would like to pin most frequently used tables in memory.
We have 6GB physical memory and like to allocate as 4-5 GB of memory to SQL
server.
Note: 4 or 5 of the tables have at least a million records.
Thanks in advance
Regards,
AmarAmar
SQL Server Profiler is your tool.
"Amar" <Amar@.discussions.microsoft.com> wrote in message
news:08AF5B1E-3DE4-452B-8FF0-AF2C68EE4CDF@.microsoft.com...
> Is there a way we can identify most frequently hit tables in the database.
We
> would like to pin most frequently used tables in memory.
> We have 6GB physical memory and like to allocate as 4-5 GB of memory to
SQL
> server.
> Note: 4 or 5 of the tables have at least a million records.
> Thanks in advance
> Regards,
> Amar|||Hi
Pinning very small tables can be argued for under extreme circumstances, but
tables with millions of rows, forget it. If you have queries that need to
process so many rows, you have a basic data architecture problem.
Pinning a table results in that memory not being available to other table
caches, so in effect, you might starve the cache and worsen performance.
SQL Server keeps track of how many times a page has been accessed, so it
will not discard heavily used pages.
Only after turning every query, and optimizing every index and table, should
you consider pinning tables. By then you would know what tables are problems
.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Amar" wrote:

> Is there a way we can identify most frequently hit tables in the database.
We
> would like to pin most frequently used tables in memory.
> We have 6GB physical memory and like to allocate as 4-5 GB of memory to SQ
L
> server.
> Note: 4 or 5 of the tables have at least a million records.
> Thanks in advance
> Regards,
> Amar|||Hi Mike,
Thanks for your quick response. Couple of points I wanted to mention here
are we are using a product which is supplied by our supplier and hence
changing/tuning query needs to go through our QA/testing. We were looking at
this approach of pinning the table as a temporary fix while our supplier
works on tuning the queries. Would you think that is a good idea?
Other thing we noticed was our SQL is using only 1.7 GB of memory when we
have lot more unused memory. As you have said earlier we are noticing very
high cache hit at the same time we are also seeing very high disk read that
is 200M Bytes per sec.
We were looking for a quick fix as our users are finding it very difficult
to work with slow performing system which is affecting the business.
Thanks again for your help.
Regards,
Amar
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> Pinning very small tables can be argued for under extreme circumstances, b
ut
> tables with millions of rows, forget it. If you have queries that need to
> process so many rows, you have a basic data architecture problem.
> Pinning a table results in that memory not being available to other table
> caches, so in effect, you might starve the cache and worsen performance.
> SQL Server keeps track of how many times a page has been accessed, so it
> will not discard heavily used pages.
> Only after turning every query, and optimizing every index and table, shou
ld
> you consider pinning tables. By then you would know what tables are proble
ms.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "Amar" wrote:
>|||Amar wrote:
> Hi Mike,
> Thanks for your quick response. Couple of points I wanted to mention
> here are we are using a product which is supplied by our supplier and
> hence changing/tuning query needs to go through our QA/testing. We
> were looking at this approach of pinning the table as a temporary fix
> while our supplier works on tuning the queries. Would you think that
> is a good idea?
> Other thing we noticed was our SQL is using only 1.7 GB of memory
> when we have lot more unused memory. As you have said earlier we are
> noticing very high cache hit at the same time we are also seeing very
> high disk read that is 200M Bytes per sec.
> We were looking for a quick fix as our users are finding it very
> difficult to work with slow performing system which is affecting the
> business.
>
As Mike said, you can pin very small tables if necessary, but you're not
likely to get much improved performance. If you pin the large tables
(the 4 or 5 with millions of rows), and those tables fill up available
SQL Server memory, you might find performance degraded as SQL Server has
to continually grab all other data from disk. You'd need to measure how
large the tables are and weight that against the size of the remaining
table and available memory.
What server version and edition and SQL edition are you using?
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Hi David,
Thanks for the response.
We are using SQL Enterprise edition and Windows 2003 Enterprise edition.
It is clustred sql with 2 nodes
Is there a way we can identify most frequently hit tables in the database?
"David Gugick" wrote:

> Amar wrote:
> As Mike said, you can pin very small tables if necessary, but you're not
> likely to get much improved performance. If you pin the large tables
> (the 4 or 5 with millions of rows), and those tables fill up available
> SQL Server memory, you might find performance degraded as SQL Server has
> to continually grab all other data from disk. You'd need to measure how
> large the tables are and weight that against the size of the remaining
> table and available memory.
> What server version and edition and SQL edition are you using?
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>|||Amar wrote:
> Hi David,
> Thanks for the response.
> We are using SQL Enterprise edition and Windows 2003 Enterprise
> edition. It is clustred sql with 2 nodes
> Is there a way we can identify most frequently hit tables in the
> database?
>
"Frequently hit" is a somewhat nebulous term. Those tables that are
accessed most frequently may not be best candidates for pinning if they
are always accessed in an index optimzed fashion. Proper indexing keeps
page reads to a minimum and keeps the data cache fresh with usable data.
Conversely, a table that is accessed infrequently, but is accessed by
table scan or clustered index scan operations, can cause the data cache
to get flushed of its good data and replaced with data that has no
business being there.
So my recommendation for a temporary fix is get SQL Server to use as
much memory as possible and at the same time start performance tuning
the database. I think you'll find that looking for candidates now for
pinning is a waste of time since it's going to be time consuming and
difficult to determine the benefits.
I realize you are looking for a quick, temporary fix to performance
issues, but these problems are almost always related to query and index
design. There is little in the way of quick fixes that can help, short
of adding/utilizing all available memory.
I'm not sure if it was you that started another thread on your memory
issues, but are you running AWE and SP4. If so, have you download the
latest SP4 AWE hotfix?
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Hi Mike and David,
Thanks a lot for quick response and all the suggestions.
Regards,
Amar
"David Gugick" wrote:

> Amar wrote:
> "Frequently hit" is a somewhat nebulous term. Those tables that are
> accessed most frequently may not be best candidates for pinning if they
> are always accessed in an index optimzed fashion. Proper indexing keeps
> page reads to a minimum and keeps the data cache fresh with usable data.
> Conversely, a table that is accessed infrequently, but is accessed by
> table scan or clustered index scan operations, can cause the data cache
> to get flushed of its good data and replaced with data that has no
> business being there.
> So my recommendation for a temporary fix is get SQL Server to use as
> much memory as possible and at the same time start performance tuning
> the database. I think you'll find that looking for candidates now for
> pinning is a waste of time since it's going to be time consuming and
> difficult to determine the benefits.
> I realize you are looking for a quick, temporary fix to performance
> issues, but these problems are almost always related to query and index
> design. There is little in the way of quick fixes that can help, short
> of adding/utilizing all available memory.
> I'm not sure if it was you that started another thread on your memory
> issues, but are you running AWE and SP4. If so, have you download the
> latest SP4 AWE hotfix?
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>

Monday, March 26, 2012

Performance questions

We have a production database that sits on a 4 proc server with 4 GB of memory and SAN disk storage via fiber. There are some stored procedures that run and they take approximately 10 minutes to run. A developer has SQL Server installed on his local pc that has 1 2.5 GHz processor and 2 GB of memory and the stored procedures run in approximately 2 minutes. I have updated statistics and rebuilt indexes to no avail. He is questioning why it runs so much faster on his smaller pc compared to the production environment. I have monitored CPU, Memory, and Disk Queue Length and none of these performance counters look concerning to me while the stored procedures are running.

Can anyone out there give me some input on what I could check to figure out why we are experiencing this performance difference?

Thanks,

Corey

Do both databases have the same volume of data? You did not mention what speed and type of processors were in the server. If it is an older server, with say, 1GHz Pentium 3 based Xeon CPU's, you could easily see much slower query performance than on a developer's workstation, with a single faster CPU.

You should also look at the graphical execution plan for the query on the server, and see whether or not the plan is being parallelized or not. BTW, what version of SQL Server are you running?

|||

The data is the same between the two environments. His pc has a 2.5 GHz Intel processor and our server has 4 2.7 GHz Intel processors. We are running SQL Server 2000 SP3a. I will try to look at the queries but their are hundreds. Should the query plan be the same since I ran update statistics, rebuild indexes, and then the process so that I was comparing as each as close as possible.

|||

Just pick two or three commonly executed queries and run them in Query Analyzer with the graphical execution plan turned on and with SET STATISTICS IO on (just run that statement before you run the queries).

Do you see similar query plans and I/O statistics between the developer's workstation and your server?

Are we comparing a developer's workstation with no load with a production server with a full-work load?

If so, I would start looking at the production server to see if you see signs of CPU pressure, memory pressure, I/O bottlenecks, etc.

|||

I will try to get a couple of queries and compare them as suggested.

The developer's workstation has no load and the production server does have other work going on but this server does have plenty of resources left and it is a much larger box than the developer's workstation. I will go ahead and grab some perfmon counters to verify this too.

sql

Wednesday, March 21, 2012

Performance problems

Hi.
We have a system with approximately 1000 users running on a dual Pentium
with hyperthreading and 2Gb memory. The server is ultra fast and is
performing great - most of the time. The problem is that sometimes a query
that usually takes 2 seconds to run, suddenly will take 40 seconds or more.
It's like the system clutters up and everything becomes very slow.
We have been running a profiler on the system, and found several stored
procedures that needed optimizing and have done so - but we are still
experiencing the same problem. We have looked at sp_lock and found that most
of the time there are about 200 locks but suddenly the number of locks will
increase to as much as 200.000 mostly on one table and for one spid.
This leads us to believe that we have a query, an application or some other
unknown that prevents sql server from escalating a row level lock to table
level.
How do we find out if this is the case - is profiler the only way to go or
are we missing something here? Any ideas or similar experiences?
Your help will be greatly appreciated.When this happens, did you try running the query manually from Query
Analyzer and see if the execution plan is any different, compared to the one
when everything was okay? It could be that the statistics changed or not
up-to-date. Do you recall any data changes that correspond with the times of
bad performance?
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Thomas Jespersen" <tje@.nospam.mentum.dk> wrote in message
news:uLzi1GObFHA.464@.TK2MSFTNGP15.phx.gbl...
Hi.
We have a system with approximately 1000 users running on a dual Pentium
with hyperthreading and 2Gb memory. The server is ultra fast and is
performing great - most of the time. The problem is that sometimes a query
that usually takes 2 seconds to run, suddenly will take 40 seconds or more.
It's like the system clutters up and everything becomes very slow.
We have been running a profiler on the system, and found several stored
procedures that needed optimizing and have done so - but we are still
experiencing the same problem. We have looked at sp_lock and found that most
of the time there are about 200 locks but suddenly the number of locks will
increase to as much as 200.000 mostly on one table and for one spid.
This leads us to believe that we have a query, an application or some other
unknown that prevents sql server from escalating a row level lock to table
level.
How do we find out if this is the case - is profiler the only way to go or
are we missing something here? Any ideas or similar experiences?
Your help will be greatly appreciated.|||"Thomas Jespersen" <tje@.nospam.mentum.dk> wrote in message
news:uLzi1GObFHA.464@.TK2MSFTNGP15.phx.gbl...
> This leads us to believe that we have a query, an application or some
> other unknown that prevents sql server from escalating a row level lock to
> table level.
I had this ince, by a simple DTS table export, got _millions_ of locks.
Defragmented the database in question, and it helped, operation done exactly
the same way suddenly went without any problems.
Seems like some hard-to-reproduce SQL Server problem. I monitor the lock
count closely since then, and defragmenting is my first resort in such a
case, but it never happened again since then.
Hope it helps.
Regards
Wojtek|||Hi
Locks are managed by memory. Have you checked how much memory SQL Server
consumes?
Also make sure that you don't have along running transactions. Have you
checked that your tables have propely defined indexes and moreover an
optimizer is able to use them when it creates an execution plan.
Try to identify by DBCC INPUTBUFFER (spid) what query is running by this
spid.
"Thomas Jespersen" <tje@.nospam.mentum.dk> wrote in message
news:uLzi1GObFHA.464@.TK2MSFTNGP15.phx.gbl...
> Hi.
> We have a system with approximately 1000 users running on a dual Pentium
> with hyperthreading and 2Gb memory. The server is ultra fast and is
> performing great - most of the time. The problem is that sometimes a query
> that usually takes 2 seconds to run, suddenly will take 40 seconds or
more.
> It's like the system clutters up and everything becomes very slow.
> We have been running a profiler on the system, and found several stored
> procedures that needed optimizing and have done so - but we are still
> experiencing the same problem. We have looked at sp_lock and found that
most
> of the time there are about 200 locks but suddenly the number of locks
will
> increase to as much as 200.000 mostly on one table and for one spid.
> This leads us to believe that we have a query, an application or some
other
> unknown that prevents sql server from escalating a row level lock to table
> level.
> How do we find out if this is the case - is profiler the only way to go or
> are we missing something here? Any ideas or similar experiences?
> Your help will be greatly appreciated.
>

Performance problems

Hi.
We have a system with approximately 1000 users running on a dual Pentium
with hyperthreading and 2Gb memory. The server is ultra fast and is
performing great - most of the time. The problem is that sometimes a query
that usually takes 2 seconds to run, suddenly will take 40 seconds or more.
It's like the system clutters up and everything becomes very slow.
We have been running a profiler on the system, and found several stored
procedures that needed optimizing and have done so - but we are still
experiencing the same problem. We have looked at sp_lock and found that most
of the time there are about 200 locks but suddenly the number of locks will
increase to as much as 200.000 mostly on one table and for one spid.
This leads us to believe that we have a query, an application or some other
unknown that prevents sql server from escalating a row level lock to table
level.
How do we find out if this is the case - is profiler the only way to go or
are we missing something here? Any ideas or similar experiences?
Your help will be greatly appreciated.
When this happens, did you try running the query manually from Query
Analyzer and see if the execution plan is any different, compared to the one
when everything was okay? It could be that the statistics changed or not
up-to-date. Do you recall any data changes that correspond with the times of
bad performance?
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Thomas Jespersen" <tje@.nospam.mentum.dk> wrote in message
news:uLzi1GObFHA.464@.TK2MSFTNGP15.phx.gbl...
Hi.
We have a system with approximately 1000 users running on a dual Pentium
with hyperthreading and 2Gb memory. The server is ultra fast and is
performing great - most of the time. The problem is that sometimes a query
that usually takes 2 seconds to run, suddenly will take 40 seconds or more.
It's like the system clutters up and everything becomes very slow.
We have been running a profiler on the system, and found several stored
procedures that needed optimizing and have done so - but we are still
experiencing the same problem. We have looked at sp_lock and found that most
of the time there are about 200 locks but suddenly the number of locks will
increase to as much as 200.000 mostly on one table and for one spid.
This leads us to believe that we have a query, an application or some other
unknown that prevents sql server from escalating a row level lock to table
level.
How do we find out if this is the case - is profiler the only way to go or
are we missing something here? Any ideas or similar experiences?
Your help will be greatly appreciated.
|||"Thomas Jespersen" <tje@.nospam.mentum.dk> wrote in message
news:uLzi1GObFHA.464@.TK2MSFTNGP15.phx.gbl...
> This leads us to believe that we have a query, an application or some
> other unknown that prevents sql server from escalating a row level lock to
> table level.
I had this ince, by a simple DTS table export, got _millions_ of locks.
Defragmented the database in question, and it helped, operation done exactly
the same way suddenly went without any problems.
Seems like some hard-to-reproduce SQL Server problem. I monitor the lock
count closely since then, and defragmenting is my first resort in such a
case, but it never happened again since then.
Hope it helps.
Regards
Wojtek
|||Hi
Locks are managed by memory. Have you checked how much memory SQL Server
consumes?
Also make sure that you don't have along running transactions. Have you
checked that your tables have propely defined indexes and moreover an
optimizer is able to use them when it creates an execution plan.
Try to identify by DBCC INPUTBUFFER (spid) what query is running by this
spid.
"Thomas Jespersen" <tje@.nospam.mentum.dk> wrote in message
news:uLzi1GObFHA.464@.TK2MSFTNGP15.phx.gbl...
> Hi.
> We have a system with approximately 1000 users running on a dual Pentium
> with hyperthreading and 2Gb memory. The server is ultra fast and is
> performing great - most of the time. The problem is that sometimes a query
> that usually takes 2 seconds to run, suddenly will take 40 seconds or
more.
> It's like the system clutters up and everything becomes very slow.
> We have been running a profiler on the system, and found several stored
> procedures that needed optimizing and have done so - but we are still
> experiencing the same problem. We have looked at sp_lock and found that
most
> of the time there are about 200 locks but suddenly the number of locks
will
> increase to as much as 200.000 mostly on one table and for one spid.
> This leads us to believe that we have a query, an application or some
other
> unknown that prevents sql server from escalating a row level lock to table
> level.
> How do we find out if this is the case - is profiler the only way to go or
> are we missing something here? Any ideas or similar experiences?
> Your help will be greatly appreciated.
>

Performance problems

Tuesday, March 20, 2012

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

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

Performance problem but memory available...

Hi,
I've some performance problems on a server.
I monitor these statistics:
Pages/sec
page faults/sec
available MBytes
the result is strange during small activities on the server: (min, avg, max)
Pages/sec = 0, 30, 217
page faults/sec = 18, 350, 4000
available MBytes = 290Mb, 300,Mb 308Mb
My instance of SQL Server used 545Mb (700Mb in VM Size) and my server has
1280Mb installed.
Opening the property page of SQL server to manage the memory could take 2 to
3 minutes before I can see anything!!!
I've the same problem with some client applications, a simple query can take
a long time, and another time (5minutes) the same query takes only 5 seconds
after a reboot.
If I restart my server, then all works fine, but when my SQL Server instance
start to consume more memory, then the performance slow down. I don't
understand why, because I've some memory available.
What can I monitor to identify the problem?
Thanks for your guides.
Jrme.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09What is the processor utilization?... Sounds like you've got something
eating it all up!
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Jj" <willgart@._A_hAotmail_A_.com> wrote in message
news:utqpL3V9DHA.1636@.TK2MSFTNGP12.phx.gbl...
> Hi,
> I've some performance problems on a server.
> I monitor these statistics:
> Pages/sec
> page faults/sec
> available MBytes
> the result is strange during small activities on the server: (min, avg,
max)
> Pages/sec = 0, 30, 217
> page faults/sec = 18, 350, 4000
> available MBytes = 290Mb, 300,Mb 308Mb
> My instance of SQL Server used 545Mb (700Mb in VM Size) and my server has
> 1280Mb installed.
> Opening the property page of SQL server to manage the memory could take 2
to
> 3 minutes before I can see anything!!!
> I've the same problem with some client applications, a simple query can
take
> a long time, and another time (5minutes) the same query takes only 5
seconds
> after a reboot.
> If I restart my server, then all works fine, but when my SQL Server
instance
> start to consume more memory, then the performance slow down. I don't
> understand why, because I've some memory available.
> What can I monitor to identify the problem?
> Thanks for your guides.
> Jrme.
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09
>

Performance problem but memory available...

Hi,
I've some performance problems on a server.
I monitor these statistics:
Pages/sec
page faults/sec
available MBytes
the result is strange during small activities on the server: (min, avg, max)
Pages/sec = 0, 30, 217
page faults/sec = 18, 350, 4000
available MBytes = 290Mb, 300,Mb 308Mb
My instance of SQL Server used 545Mb (700Mb in VM Size) and my server has
1280Mb installed.
Opening the property page of SQL server to manage the memory could take 2 to
3 minutes before I can see anything!!!
I've the same problem with some client applications, a simple query can take
a long time, and another time (5minutes) the same query takes only 5 seconds
after a reboot.
If I restart my server, then all works fine, but when my SQL Server instance
start to consume more memory, then the performance slow down. I don't
understand why, because I've some memory available.
What can I monitor to identify the problem?
Thanks for your guides.
Jérôme.
--
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09What is the processor utilization?... Sounds like you've got something
eating it all up!
--
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Jéjé" <willgart@._A_hAotmail_A_.com> wrote in message
news:utqpL3V9DHA.1636@.TK2MSFTNGP12.phx.gbl...
> Hi,
> I've some performance problems on a server.
> I monitor these statistics:
> Pages/sec
> page faults/sec
> available MBytes
> the result is strange during small activities on the server: (min, avg,
max)
> Pages/sec = 0, 30, 217
> page faults/sec = 18, 350, 4000
> available MBytes = 290Mb, 300,Mb 308Mb
> My instance of SQL Server used 545Mb (700Mb in VM Size) and my server has
> 1280Mb installed.
> Opening the property page of SQL server to manage the memory could take 2
to
> 3 minutes before I can see anything!!!
> I've the same problem with some client applications, a simple query can
take
> a long time, and another time (5minutes) the same query takes only 5
seconds
> after a reboot.
> If I restart my server, then all works fine, but when my SQL Server
instance
> start to consume more memory, then the performance slow down. I don't
> understand why, because I've some memory available.
> What can I monitor to identify the problem?
> Thanks for your guides.
> Jérôme.
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.581 / Virus Database: 368 - Release Date: 2004-02-09
>

Monday, March 12, 2012

performance problem

Zarko
It seems that you need to add more memory.PLE counter shoud have a value
more than 300
"Zarko Jovanovic" <mind_lessIsHsAsTsEsSsPsAsMs@.inet.hr> wrote in message
news:fph6bc$806$3@.sunce.iskon.hr...
> sql server 2005 standrard, 4gGB ram, 4 processors, win 2003
> buffer cache hit ratio (BCHR) going from 97% down to 94%, page life
> expectancy (PLE) staying between 3 and 7!? sql memory default
> configuration (automanage), system free memory cca 1.7GB.
> q: how can PLE be so low and not bring down BCHR?
> q: looks like a memory pressure, but there's free memory?!!
> help apriciated
> tia
> Zarko
Zarko
Monitor your queries/locks/blocking. How much memory do you have in the
server?
"Zarko Jovanovic" <mind_lessIsHsAsTsEsSsPsAsMs@.inet.hr> wrote in message
news:fphaf8$806$6@.sunce.iskon.hr...[vbcol=seagreen]
> didi you notice : system free memory cca 1.7GB?!!
> Uri Dimant wrote:
|||Zarko, may I suggest that you bear in mind that people that answer these
forums are doing so on their OWN TIME and VOLUNTARILY. I strongly suggest
you cut them some slack or you will find that no one will answer your posts
and you will have lost a tremendous resource.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Zarko Jovanovic" <mind_lessIsHsAsTsEsSsPsAsMs@.inet.hr> wrote in message
news:fplu5a$ihc$1@.sunce.iskon.hr...[vbcol=seagreen]
> Uri, you DON'T READ! first line says: 4GB ram
> Uri Dimant wrote:

Performance on Windows 2003 Standard w/ SQL SERVER 2000 Enterprise

I have SQL SERVER 2K Enterprise SP4 installed on a Windows 2003 standard box
with 4G of memory and 2 XEON CPUs with hyperthreading. All the SQL SERVER
configuration is set to use all available resource on the box. But no matter
what we throw at it. It's using only 25% of CPU resource and the memory
usuage is never over 1.7G. The installation is definately Enterprise and not
standard. What am I missing?
Thanks!WD wrote:
> I have SQL SERVER 2K Enterprise SP4 installed on a Windows 2003 standard box
> with 4G of memory and 2 XEON CPUs with hyperthreading. All the SQL SERVER
> configuration is set to use all available resource on the box. But no matter
> what we throw at it. It's using only 25% of CPU resource and the memory
> usuage is never over 1.7G. The installation is definately Enterprise and not
> standard. What am I missing?
> Thanks!
The CPU utilization may mean nothing. Did you set the BOOT.INI switches
for the additional memory?
http://support.microsoft.com/kb/274750/
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Yes, I read the support article before, but because my installation is on a
windows 2003 server. The article indicates that it already supports up to 4
GB for Windows 2003 server and only need to modify the boot.ini to use more
than 4GB. Am I wrong in reading it that way. Thanks.
"Tracy McKibben" wrote:
> WD wrote:
> > I have SQL SERVER 2K Enterprise SP4 installed on a Windows 2003 standard box
> > with 4G of memory and 2 XEON CPUs with hyperthreading. All the SQL SERVER
> > configuration is set to use all available resource on the box. But no matter
> > what we throw at it. It's using only 25% of CPU resource and the memory
> > usuage is never over 1.7G. The installation is definately Enterprise and not
> > standard. What am I missing?
> >
> > Thanks!
> The CPU utilization may mean nothing. Did you set the BOOT.INI switches
> for the additional memory?
> http://support.microsoft.com/kb/274750/
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>

Friday, March 9, 2012

Performance on Windows 2003 Standard w/ SQL SERVER 2000 Enterprise

Wednesday, March 7, 2012

Performance of Hardware

Hey all,
I have 2 servers that I am interested in SQL Server 2000. One is a
single proc, Intel 2.53Ghz 533FSB with 1GB of dual-channel memory. This
server is running SBS2k3 running as a domain controller and Exchange. The
other is a dual proc AMD Athlon MP with 1500's in them. This server has
768MB and is running Windows 2003 Enterprise with RRAS acting as the gateway
to the internet, DNS, and DHCP. My question is which is the lesser evil? I
want to try out Microsoft CRM 1.2 and trying to balance out the workload.
Any help would be much appriciated.
MichaelMichael,
Some questions to point you down the right track:
What system has the better disc subsystem?
Check perfmon for current CPU loadings etc?
Mike John
"Michael Sainz" <mike@.twofatfrogs(remove).com> wrote in message =news:efCVtdA1DHA.1272@.TK2MSFTNGP12.phx.gbl...
> Hey all,
> I have 2 servers that I am interested in SQL Server 2000. One is a
> single proc, Intel 2.53Ghz 533FSB with 1GB of dual-channel memory. =This
> server is running SBS2k3 running as a domain controller and Exchange. =The
> other is a dual proc AMD Athlon MP with 1500's in them. This server =has
> 768MB and is running Windows 2003 Enterprise with RRAS acting as the =gateway
> to the internet, DNS, and DHCP. My question is which is the lesser =evil? I
> want to try out Microsoft CRM 1.2 and trying to balance out the =workload.
> Any help would be much appriciated.
> > Michael
> >|||John,
The Intel system (DC, Exchange2k3) has a single 80GB SATA Drive. The AMD
has dual 80GB in a mirrored array (hardware). In terms of performance and
load...there are only 3 clients ever connected so I dont think this is an
issue at all, but I just want to make sure and that is why i'm posting.
Thanks!
"Mike John" <Mike.John@.knowledgepool.spamtrap.com> wrote in message
news:ug7sctJ1DHA.3468@.TK2MSFTNGP11.phx.gbl...
Michael,
Some questions to point you down the right track:
What system has the better disc subsystem?
Check perfmon for current CPU loadings etc?
Mike John
"Michael Sainz" <mike@.twofatfrogs(remove).com> wrote in message
news:efCVtdA1DHA.1272@.TK2MSFTNGP12.phx.gbl...
> Hey all,
> I have 2 servers that I am interested in SQL Server 2000. One is a
> single proc, Intel 2.53Ghz 533FSB with 1GB of dual-channel memory. This
> server is running SBS2k3 running as a domain controller and Exchange. The
> other is a dual proc AMD Athlon MP with 1500's in them. This server has
> 768MB and is running Windows 2003 Enterprise with RRAS acting as the
gateway
> to the internet, DNS, and DHCP. My question is which is the lesser evil? I
> want to try out Microsoft CRM 1.2 and trying to balance out the workload.
> Any help would be much appriciated.
> Michael
>

Friday, March 30, 2012

Performance turning

Performance turning

Performance turning

Monday, March 26, 2012

Performance questions

Wednesday, March 21, 2012

Performance problems

Performance problems

Performance problems

Tuesday, March 20, 2012

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

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

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

Performance problem but memory available...

Performance problem but memory available...

Monday, March 12, 2012

performance problem

Performance on Windows 2003 Standard w/ SQL SERVER 2000 Enterprise

Friday, March 9, 2012

Performance on Windows 2003 Standard w/ SQL SERVER 2000 Enterprise

Wednesday, March 7, 2012

Performance of Hardware

performance monitoring

Blog Archive

About Me