malcolmbegg
asked on
Ultra-Slow DELETE
Hi there,
I have a table (MyTable) with the following structure:
dataCol1 int,
dataCol2 int,
dataCol3 tinyint,
datacol4 float
dataCol1 and dataCol2 together are the primary key, no other indices are defined on the table.
dataCol1 is a foreign key to another table, dataCol2 is a foreign key to a different table.
There are approx 18000 rows in this table.
The database in total is a little under 1Gb, but SQL Server should be able to cope with that OK. There were also no active connections to the DB when I ran the command.
I am running the command DELETE FROM MyTable WHERE dataCol2 = x. In my case, there should never really be more than 70 being deleted at any one time.
When there are 70 rows to be deleted, this command (run in Query Analyzer) takes approx. 43 seconds to complete. That's almost 0.6 seconds per row!! How can this be, and how can I improve the performance so that it works in a (much) more reasonable time scale?
Thanks,
Malcie.
I have a table (MyTable) with the following structure:
dataCol1 int,
dataCol2 int,
dataCol3 tinyint,
datacol4 float
dataCol1 and dataCol2 together are the primary key, no other indices are defined on the table.
dataCol1 is a foreign key to another table, dataCol2 is a foreign key to a different table.
There are approx 18000 rows in this table.
The database in total is a little under 1Gb, but SQL Server should be able to cope with that OK. There were also no active connections to the DB when I ran the command.
I am running the command DELETE FROM MyTable WHERE dataCol2 = x. In my case, there should never really be more than 70 being deleted at any one time.
When there are 70 rows to be deleted, this command (run in Query Analyzer) takes approx. 43 seconds to complete. That's almost 0.6 seconds per row!! How can this be, and how can I improve the performance so that it works in a (much) more reasonable time scale?
Thanks,
Malcie.
william_jwd
You can improve the query performance by indexing the column in the where clause (dataCol2). I dont think that there is any problem with your query...
when did you last time did indexes maintenances like reindex (see DBCC INDEXDEFRAG or\and DBCC DBREINDEX); update statistics (see sp_updatestats)?
BTW: could be not so bad to create nonclustered index on column dataCol2
Do you have any triggers on the table?
Are there any referential integrity constraints to other tables?
Is your DB reasonably defragmented?
mono
Are there any referential integrity constraints to other tables?
Is your DB reasonably defragmented?
mono
What does the query plan show?
Have you run this with profiler on to see what's really happening?
How fast would a select with the same criteria be?
Have you run this with profiler on to see what's really happening?
How fast would a select with the same criteria be?
ASKER
Thank you all for your help so far.
william_jwd: I tried setting up a non-clustered index on dataCol2 - this had no real effect.
monosodiumg: There are no triggers defined on the table. The foreign key relationships I mentioned previously are enforced as relationships within the DB. How can I tell if the DB is defragmented? If it isn't how do I sort it out?
ChrisFretwell: Query Execution Plan shows the following (in as much detail as I can squeeze in!):
DELETE (0%) <-- Assert (0%) <-- Nested Loops (0%) <-- Clustered Index Delete (70%)
^
|
Row Count Spool (0%) <-- Index Scan (30%)
The Clustered Index Delete is taking up the majority of the time (obviously), but should it? Does this plan look right?
A SELECT using the same criteria is pretty fast (almost instantaneous).
Malcie.
william_jwd: I tried setting up a non-clustered index on dataCol2 - this had no real effect.
monosodiumg: There are no triggers defined on the table. The foreign key relationships I mentioned previously are enforced as relationships within the DB. How can I tell if the DB is defragmented? If it isn't how do I sort it out?
ChrisFretwell: Query Execution Plan shows the following (in as much detail as I can squeeze in!):
DELETE (0%) <-- Assert (0%) <-- Nested Loops (0%) <-- Clustered Index Delete (70%)
^
|
Row Count Spool (0%) <-- Index Scan (30%)
The Clustered Index Delete is taking up the majority of the time (obviously), but should it? Does this plan look right?
A SELECT using the same criteria is pretty fast (almost instantaneous).
Malcie.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Spot-on LordSilk, there was one foreign key to this table (which I hadn't noticed), referencing a fairly big table (approx. 400000 records). I indexed the foreign keys and hey presto, it now deletes virtually instantly.
Many thanks, and thanks also to all others who contributed - especially monosodiumg. I realise now you were going along the right tracks with your comment, but I only noticed after LordSilk's solution.
Malcie.
Many thanks, and thanks also to all others who contributed - especially monosodiumg. I realise now you were going along the right tracks with your comment, but I only noticed after LordSilk's solution.
Malcie.