We have a database that has about 50 tables, each with approximately 800K
rows. These tables are imports of data from another system that are updated
daily. All the tables have the same column, Id, for a primary key. The table
s
are accessed via views that serve mainly to assign meaningful names to the
columns and to insulate the applications from changes to the underlying
tables. In other words, the views are not restricting the users to a subset
of the columns in the tables, nor are they doing multi-table joins, etc. Thi
s
database is accessed by many users using many different applications across
the enterprise.
We have an application that queries a 12-view subset of the views, allowing
the user to do ad-hoc what-if queries with an application that generates SQL
queries from the user requests. The queries are often very time consuming. W
e
are attempting to improve the performance of this application. One thing we
know is that due to the nature of this application, 25% of the rows in the
views will never be selected and the application has to include SQL to
explicitly exlude this 25% of the rows.
One thought is to eliminate the scanning of the 25% of the rows that the
application never uses. There appear to be two ways of doing this:
1) Create another database containing only the 10-table/view subset and to
eliminate the unwanted rows at import/update time.
2) Create another table/view in the existing database with the Ids of the
75% of the rows that are used by this application and have the application d
o
a join on this table for all the queries and eliminate the SQL designed to
weed out the 25% of the rows that are not used by the application.
Whatever we choose to do, we have to live within the constraint of our
current hardware, so if we choose to create a separate database it will have
to share the current hardware with the other applications.
Given that the processing required to either load the alternate database or
maintain the 75% table is not an issue, which choice is likely to give us th
e
best increase in performance for the application?
Thanks,
BobHi
If you are currently seeing conflict between the two types of usage then it
is probably a good idea to create a second database for this to work on.
There will be a latency in the data unless depending on how you implement th
e
propogation of data.
I think you should look at the index usage on the database first, before you
implement any complex task to reduce the data.
John
"Bob" wrote:
> We have a database that has about 50 tables, each with approximately 800K
> rows. These tables are imports of data from another system that are update
d
> daily. All the tables have the same column, Id, for a primary key. The tab
les
> are accessed via views that serve mainly to assign meaningful names to the
> columns and to insulate the applications from changes to the underlying
> tables. In other words, the views are not restricting the users to a subse
t
> of the columns in the tables, nor are they doing multi-table joins, etc. T
his
> database is accessed by many users using many different applications acros
s
> the enterprise.
> We have an application that queries a 12-view subset of the views, allowin
g
> the user to do ad-hoc what-if queries with an application that generates S
QL
> queries from the user requests. The queries are often very time consuming.
We
> are attempting to improve the performance of this application. One thing w
e
> know is that due to the nature of this application, 25% of the rows in the
> views will never be selected and the application has to include SQL to
> explicitly exlude this 25% of the rows.
> One thought is to eliminate the scanning of the 25% of the rows that the
> application never uses. There appear to be two ways of doing this:
> 1) Create another database containing only the 10-table/view subset and to
> eliminate the unwanted rows at import/update time.
> 2) Create another table/view in the existing database with the Ids of the
> 75% of the rows that are used by this application and have the application
do
> a join on this table for all the queries and eliminate the SQL designed to
> weed out the 25% of the rows that are not used by the application.
> Whatever we choose to do, we have to live within the constraint of our
> current hardware, so if we choose to create a separate database it will ha
ve
> to share the current hardware with the other applications.
> Given that the processing required to either load the alternate database o
r
> maintain the 75% table is not an issue, which choice is likely to give us
the
> best increase in performance for the application?
> Thanks,
> Bob
>|||John,
"John Bell" wrote:
> Hi
> If you are currently seeing conflict between the two types of usage then
it
> is probably a good idea to create a second database for this to work on.
> There will be a latency in the data unless depending on how you implement
the
> propogation of data.
>
It's not really a conflict. The 75% part of the data represents currently
active items while the other 25% is effectively history. Items move from
current to history and new items are added, on a daily basis as the result o
f
batch processing on another system. This also eliminates data latency as an
issue.
> I think you should look at the index usage on the database first, before y
ou
> implement any complex task to reduce the data.
>
The column that determines whether an item is current or history is already
indexed. In addition, all the other columns used by the queries are also
indexed as appropriate.
Bob|||Assuming all other factors (indexing, joins, etc.) remain the same, I would
not expect removing 25% of the rows to impact the total runtime of the
queries that much. If 75% of the rows could be archived elsewhere, then that
would be significant. Rather than guessing, there are methods to know for
sure where the bottleneck is:
Investigate to what extent your indexes may be fragmented and defragment if
needed.
http://www.microsoft.com/technet/pr...n/ss2kidbp.mspx
Use the Show Execution Plan feature in Query Analyzer to see exactly how the
query optimizer is using your indexes.
http://support.microsoft.com/defaul...;243589&sd=tech
SQL Server hardware configuration and monitoring memory usage, IO
performance, etc:
/url]
[url]http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx#EE
AA" target="_blank">http://www.microsoft.com/technet/pr...px#EE
AA
"Bob" <notrainsley@.worldsavings.com> wrote in message
news:B41801C0-B505-4A2C-9E3B-CF4D5E7C5C9A@.microsoft.com...
> We have a database that has about 50 tables, each with approximately 800K
> rows. These tables are imports of data from another system that are
> updated
> daily. All the tables have the same column, Id, for a primary key. The
> tables
> are accessed via views that serve mainly to assign meaningful names to the
> columns and to insulate the applications from changes to the underlying
> tables. In other words, the views are not restricting the users to a
> subset
> of the columns in the tables, nor are they doing multi-table joins, etc.
> This
> database is accessed by many users using many different applications
> across
> the enterprise.
> We have an application that queries a 12-view subset of the views,
> allowing
> the user to do ad-hoc what-if queries with an application that generates
> SQL
> queries from the user requests. The queries are often very time consuming.
> We
> are attempting to improve the performance of this application. One thing
> we
> know is that due to the nature of this application, 25% of the rows in the
> views will never be selected and the application has to include SQL to
> explicitly exlude this 25% of the rows.
> One thought is to eliminate the scanning of the 25% of the rows that the
> application never uses. There appear to be two ways of doing this:
> 1) Create another database containing only the 10-table/view subset and to
> eliminate the unwanted rows at import/update time.
> 2) Create another table/view in the existing database with the Ids of the
> 75% of the rows that are used by this application and have the application
> do
> a join on this table for all the queries and eliminate the SQL designed to
> weed out the 25% of the rows that are not used by the application.
> Whatever we choose to do, we have to live within the constraint of our
> current hardware, so if we choose to create a separate database it will
> have
> to share the current hardware with the other applications.
> Given that the processing required to either load the alternate database
> or
> maintain the 75% table is not an issue, which choice is likely to give us
> the
> best increase in performance for the application?
> Thanks,
> Bob
>|||Hi
JT gave you a link regarding the query plans. Just because your archive flag
is indexed does not necessarily mean it is used or if there is a better inde
x
configuration. With ad-hoc queries you may not get brilliant query plans all
of the time, but you may be able to produce an indexing strategy that gives
very good responses most of the time. It could be that with changed indexes
there is no need to separate the system. If the system is only updated by a
batch job, then you can use a strategy where you drop the indexes before
inserting the new data and re-creating the indexes after. If you don't drop
the indexes they should be rebuilt after the bulk load anyhow.
You may want to read some of the article on
http://www.sql-server-performance.c...performance.asp regarding how
to improve performance.
One thing that I don't think has been mentioned is that you may gain some
benefit from having indexed views.
John
"Bob" wrote:
> John,
> "John Bell" wrote:
>
> It's not really a conflict. The 75% part of the data represents currently
> active items while the other 25% is effectively history. Items move from
> current to history and new items are added, on a daily basis as the result
of
> batch processing on another system. This also eliminates data latency as a
n
> issue.
>
> The column that determines whether an item is current or history is alread
y
> indexed. In addition, all the other columns used by the queries are also
> indexed as appropriate.
> Bob
>|||JT and John,
Thanks for your replies. One of the problems I had was trying to actually
grab some of the generated queries to check out the execution plan in Query
Analyzer.
I got one of the DBAs to do a trace on the processing and we grabbed a few
of the generated queries. We discovered that there was a view someone had
written that wasn't part of the standard load and was doing massive amounts
of calculations.
I'm going to write a procedure that will use that view to create another
table loaded with the results of the calculations that will run as part of
the nightly load. The view will then simply be returning data instead of
calculating the values over and over. This will change a series of repetitiv
e
compute intensive calculations into a simple inner join on a primary key.
Thanks again for everyone's help.
Bob
Showing posts with label approximately. Show all posts
Showing posts with label approximately. Show all posts
Monday, March 26, 2012
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.
>
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.
>
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.
>
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.
>
Friday, March 9, 2012
Performance of stored procedure is improved after database is backed up and restored
I have a stored procedure that performs very poorly on SQL Server 2000 standard edition. It takes approximately 40 seconds to execute. In the course of troubleshooting the issue I backed up the database to disk and restored it to another SQLServer and the performance issue was resolved. On a hunch I went to the original server, backed up the database to disk, and then restored the database from the backup I just created and voila the problem was resolved. Why would this resolve the issue? I have another database with the same stored procedure with the same problem. I have tried the following on the stored procedure and all related tables with no success:
DBCC DBREINDEX
UPDATE STATISTICS
sp_recompile my_storedprocedure.
What is the restore doing to resolve the issue? What command can I run to resolve this. I have a feeling it is the query plan but wouldn't update statistics correct this?
Is it possible that the physical database files are getting fragmented?
The restore would then lay the files down contiguously, which would improve performance.
Other than that, the content of the database including statistics would be exactly the same after the restore as it was at the time of backup. SQL backup is a physical copy of every allocated byte in the database files.
Subscribe to:
Posts (Atom)