June 11, 2008 at 2:50 am
I wrote query to delete some records in one of the table in my database.
I set up job to run this query.
The query is as below:
DELETE I
FROM tbItem I (nolock)
INNER JOIN tbProductionOrder PO (nolock)
ON I.POID = PO.POID
WHERE PODescription LIKE '%00000%'
This job has ran successfully in the past, but now it start hanging my system to extent that they cannot work in the factory, what are the possible causes?
June 11, 2008 at 2:56 am
how many rows is that delete likely to affect?
What indexes do you have on the 2 tables?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 11, 2008 at 3:06 am
Not sure on the validity of (nolock) on a table where you are deleting data?
That aside, you mentioned this has worked in the past, but not so well now.
What you don't state is other contributing factors like
* Volume of data involve on both the related tables
* Is there an RI link and has that any supportive indexing to help the query.
* What sort of number of deletes are you expecting, ie When originally run a few rows to be deleted would not have the same impact as say several thousand.
As with a lot of the forum items on this site (I know because I have asked questions as well), it works a lot better if you can give as much relevant details on the issue as possible.
Cheers.
June 11, 2008 at 3:15 am
DELETE I
FROM tbItem I (nolock)
INNER JOIN tbProductionOrder PO (nolock)
ON I.POID = PO.POID
WHERE PODescription LIKE '%00000%'
This will delete about 11000000 records
Once again this has been successfully severally
June 11, 2008 at 5:00 am
Index definitions?
Has the total number of rows in the table changed since this worked properly?
Are your indexes fragmented? Are the statistics out of date?
I'm not asking just to be a pain. I'm asking because I want as clear a picture of the problem as possible.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 11, 2008 at 5:06 am
UDBNT (6/11/2008)
Not sure on the validity of (nolock) on a table where you are deleting data?
The hint will be ignored. Deletes have to lock exclusivly, lock hints or no lock hints.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 11, 2008 at 5:18 am
Fair enough, it was just that I seem to remember some reference to (nolock) dealing with potentially non-commited data and the obvious impacts of that might not be that desirable.
Seems like we are both asking for more detail/history from the originator.
Delete of 11 million rows doesn't sound like a daily task to me, but I might be wrong!!
June 11, 2008 at 7:31 am
The 11 Million is a standard number so it does not vary
I also run DBCC DBREINDEX on the table earlier
So question of defragmentation should not come up
June 11, 2008 at 1:23 pm
It would be helpful if you mention the index structure on both the tables involved in delete operation.
Manu
June 11, 2008 at 1:42 pm
I'd write it more like this:
DELETE FROM
dbo.tbItem
FROM
dbo.tbItem I
INNER JOIN dbo.tbProductionOrder PO
ON (I.POID = PO.POID)
WHERE
PO.PODescription LIKE '%00000%'
You could also encolse this is a while loop and delete records in smaller batches.
declare @recordstodelete int,
@recordsdeleted int;
set @recordstodelete = 5000;
while (@recordsdeleted is null)
or (@recordsdeleted <> 0)
begin -- while
DELETE TOP (@recordstodelete) FROM
dbo.tbItem
FROM
dbo.tbItem I
INNER JOIN dbo.tbProductionOrder PO
ON (I.POID = PO.POID)
WHERE
PO.PODescription LIKE '%00000%'
set @recordsdeleted = @@rowcount
-- BACKUP LOG ... -- a transaction log backup could be coded here to manage t-log size
end -- while
😎
June 11, 2008 at 2:23 pm
Also, your WHERE clause of PO.PODescription LIKE '%00000%' will normally produce a table scan. It's a bit hard to say for sure though as you have not posted an execution plan or your index structure as requested by the other posters.
June 11, 2008 at 2:50 pm
John Rowan (6/11/2008)
Also, your WHERE clause of PO.PODescription LIKE '%00000%' will normally produce a table scan. It's a bit hard to say for sure though as you have not posted an execution plan or your index structure as requested by the other posters.
Agreed, although I can't think of how that wouldn't cause a table scan, thanks to the leading %. That kind of forces a table scan (or a clustered index scan), since there's no decent way to use an index to seek those out.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 11, 2008 at 3:08 pm
Matt Miller (6/11/2008)
John Rowan (6/11/2008)
Also, your WHERE clause of PO.PODescription LIKE '%00000%' will normally produce a table scan. It's a bit hard to say for sure though as you have not posted an execution plan or your index structure as requested by the other posters.Agreed, although I can't think of how that wouldn't cause a table scan, thanks to the leading %. That kind of forces a table scan (or a clustered index scan), since there's no decent way to use an index to seek those out.
I also agree, but we have to go with what the OP provided. There is one thing, and unfortunately I don't have time to try and find it, I thought I had read in "Inside Microsoft SQL Server 2005 T-SQL Querying" that SQL Server 2005 had some improvements in its statitistics that improved query performance with leading wildcard characters in the LIKE clause. When I have some free time (what ever that is) I will see if I can find it again.
😎
June 11, 2008 at 3:10 pm
June 12, 2008 at 5:05 am
Try this...
DELETE FROM tbItem l (nolock)
Where exists(Select p.POID From tbProductionOrder p (nolock) where l.POID = p.POID AND PODescription LIKE '%00000%')
Viewing 15 posts - 1 through 15 (of 26 total)
You must be logged in to reply to this topic. Login to reply