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

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....

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

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...)

You can queue the requests by creating a table in wich your requests are saved and then, execute each command one at a time...

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