从具有约20个触发器的表中删除记录-SQL

Question

I want to delete a few thousand records using T-SQL from a huge table with 20 million records. This table has about 20 triggers depending on it and all referring to more or less similar huge table. Deletion is taking a long time even when I use the identity column values. How do I delete these records without disabling the triggers or having to disable minimum number of triggers? Please help.

Answer 1

I have worked a similar problem for deleting data. I had 360 million rows in a table. It had "A" delete trigger to enforce referential integrity. I was trying to delete about 60 million records. I could go two ways, disable the delete trigger or limit the number of deletes that I was trying to delete at one time. I had to limit my deletes to 10,000 records at a time. I think this had to do with not overloading the tranlog.

Answer 2

Try the following

add the following sps

Create PROCEDURE [dbo].[sysUserContextSet]  --#1

@user_name varchar(14),
@terminal varchar(10) = NULL
AS
SET NOCOUNT ON
SET ANSI_WARNINGS OFF

declare @context varbinary(128)

set @context = CONVERT(varbinary(128), isNull(@user_name,'') + SPACE(14 - len(isNull(@user_name,'')))+ isNull(@terminal, '') + space(10 - len(isNull(@terminal, ''))))
set context_info @context



Create PROCEDURE [dbo].[sysUserContextClear] --#2
AS
SET NOCOUNT ON
SET ANSI_WARNINGS OFF
DELETE FROM sysUserContext WITH (ROWLOCK) WHERE spid=@@SPID



    exec sysuserContextSet 'username'
    delete ...
    exec sysuserContextClear

Answer 3

To me it sounds like your issue is with the time it is taking to delete these rows.

I agree with Zane, the triggers are there for a reason and I would not disable them.

Are the triggers taking the time? Can you do anything to speed up the triggers?

What is the sql you are using to identify and delete the initial rows?

I ran into a similar issue with updates. I ended up doing the updates in batches. You could delete in batches

Answer 4

Those triggers are there for a reason. Disabling them is a poor idea.

What I would do is first look at the triggers to ensure they are operating in a set-based fashion (if you are going row by row in a trigger, then a few thousand records will take a long time no matter what.

Assuming your triggers are all correctly written, you may also have an issue with cascading deletes or FKs that require you to look for child records in many tables (We have one with over 100 FKs to check). In this case and if you can't speed up the triggers, then the best bet is to work in small batches in a loop. Commit the transactions for each round of the loop so the table is not locked up. Then if possible do the processing during off hours. The more FK tables affected the smaller the batch you need to process at a time.

Or you could design your database to do soft deletes (mark records as inactive and then crete a view that shows only the active records). This way you don't have to delete at all.