• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 440
  • Last Modified:

SQL Server - How to tune insert/update/delete on very active Tables

Hi All,
I have some really active tables mainly with insert/update running against them.
There are lots of waits and as a result I often come across Deadlock. Once application hit deadlocks it often crashes some processes and I have to manually run those transactions. It's a pain.

How do I tune insert/update/delete so that these waits are gone for good.

Thanks
0
crazywolf2010
Asked:
crazywolf2010
1 Solution
 
LowfatspreadCommented:
so are your deadlocks in general caused by the applications waiting for resources across tables or within single tables?

userA    update TableA    wants to update tableB

userb    updated tableB  wants to update tableA

or

userA   update tableA row1   wants to update another tableA row2

userb   updated tableA row2  is still doing processing...


or is it normally more complex with with more than 2 users/connections involved?

in general
you may be able to change the clustering/partitioning  indexes to reduce contention if its page locks which are creating the problems...

you maybe able to influence the program design so that (in general) Table A is always updated before TableB

you may find that adding a logical deleted status column , instead of actually doing a DELETE (ie a delete becomes an UPDATE) will assist as DELETES are (usually) much more expensive than updates... (and run the physical delete in a batch period...)


the other standard TUNING mechanic apply ... ensure that the SQL actually needs to be performed... ensure that code delay between sql statements is minimised...
look to tune the actual statements usually involved...

e.g..

        update   row1

        select something
        insert something

         update row 2


ccould that be changed
   to
select something

update row1
 insert something
update row2

so that the lock for row1 is minimised....
0
 
crazywolf2010Author Commented:
Hi,
I think I forgot to add my attachment report for Tables. Could you have a look and comment how do I optimise these tables?
ActiveSQL.txt
0
 
LowfatspreadCommented:
its not clear what your report is actually showing...

the only comment i can make is that you appear to have 2 updates consecutively for the same table (and same basic row id...)

UPDATE NmsBroadLogRcp

could the updates  be combined into one statement and the actual
updated columns be specified by case statements in the set conditions...
*ie  move the selectivity from the where clause into case statement on the set condition

that could reduce the workload... (alternatively it could increase it if the set of rows affected significantly increases...)
0
Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

 
gpizzutoCommented:
You can queue the requests by creating a table in wich your requests are saved and then, execute each command one at a time...
0
 
ZberteocCommented:
How many indexes you have on that table. Keep in mind that every time you insert/update/delete all the indexes have to be updated which leads to a lot of extra work. I would recommend you to limit the indexes at a strict minimum.

Another thing is if you are running selects against that table you should use (nolock) hint:

select * from yourtable t (nolock)

or in inner join:

select
      *
from
      yourtable t (nolock)
      inner join anothertable a (nolock)
            on a.fk_col=t.pk_col
0
 
Scott PletcherSenior DBACommented:
By far the single best tuning is to get the correct clustered index; do that FIRST.

Then you can work on/worry about other things.

Based on the extremely limited number of queries posted so far, I'd suggest verifying that:
NmsBroadLogRcp is clustered on iBroadLogId


Btw, I'd avoid using any logical delete flags, as they usually destroy SELECT performance and aren't necessary for large DELETEs anyway, since SQL itself automatically defers those physical DELETEs until later.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now