June 12, 2008 at 8:37 am
Not sure the use of a correlated subquery (a form of hidden RBAR) will speed anything up here... Maybe...
The real fact of the matter is the OP says it used to work just fine... and doesn't now... what could be the problem? Parallelism?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 12, 2008 at 10:13 am
Jeff Moden (6/12/2008)
Not sure the use of a correlated subquery (a form of hidden RBAR) will speed anything up here... Maybe...The real fact of the matter is the OP says it used to work just fine... and doesn't now... what could be the problem? Parallelism?
True enough Jeff. Looking back at the original post (and paraphrasing), the system is hanging and the factory floor can't work. The issue could be blocking. Pretty sure that the NOLOCK hint is ignored on the delete, and if the DELETE is going to delete 11,000,000 rows, I wouldn't be surprised if SQL puts a table lock on the table.
If it was working before but isn't now, the two things that come to my mind now would be data and disk fragmentation. The OP should check these out.
😎
June 12, 2008 at 10:28 am
Could it be a case of your disks filling up with the transaction log?
have you checked for free space?
June 12, 2008 at 2:14 pm
Lynn Pettis (6/12/2008)
Jeff Moden (6/12/2008)
Not sure the use of a correlated subquery (a form of hidden RBAR) will speed anything up here... Maybe...The real fact of the matter is the OP says it used to work just fine... and doesn't now... what could be the problem? Parallelism?
True enough Jeff. Looking back at the original post (and paraphrasing), the system is hanging and the factory floor can't work. The issue could be blocking. Pretty sure that the NOLOCK hint is ignored on the delete, and if the DELETE is going to delete 11,000,000 rows, I wouldn't be surprised if SQL puts a table lock on the table.
If it was working before but isn't now, the two things that come to my mind now would be data and disk fragmentation. The OP should check these out.
😎
Correct, WITH (NOLOCK) only affects SELECTs.
I just can believe the delete of 11 million rows didn't get caught blocking before. Somethings not quite right here. I think Lynn is on the right track... I've seen it where the undocumented ability to DELETE alias has bitten folks before. Gotta follow the rules and delete from a table name, instead.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 12, 2008 at 2:30 pm
Jeff Moden (6/12/2008)
Lynn Pettis (6/12/2008)
Jeff Moden (6/12/2008)
Not sure the use of a correlated subquery (a form of hidden RBAR) will speed anything up here... Maybe...The real fact of the matter is the OP says it used to work just fine... and doesn't now... what could be the problem? Parallelism?
True enough Jeff. Looking back at the original post (and paraphrasing), the system is hanging and the factory floor can't work. The issue could be blocking. Pretty sure that the NOLOCK hint is ignored on the delete, and if the DELETE is going to delete 11,000,000 rows, I wouldn't be surprised if SQL puts a table lock on the table.
If it was working before but isn't now, the two things that come to my mind now would be data and disk fragmentation. The OP should check these out.
😎
Correct, WITH (NOLOCK) only affects SELECTs.
I just can believe the delete of 11 million rows didn't get caught blocking before. Somethings not quite right here. I think Lynn is on the right track... I've seen it where the undocumented ability to DELETE alias has bitten folks before. Gotta follow the rules and delete from a table name, instead.
Sometimes there is no tracking in the amount of rows on tables and a sudden increase can be a "surprise" 😉
* Noel
June 12, 2008 at 2:35 pm
Jeff Moden (6/12/2008)
Lynn Pettis (6/12/2008)
Jeff Moden (6/12/2008)
Not sure the use of a correlated subquery (a form of hidden RBAR) will speed anything up here... Maybe...The real fact of the matter is the OP says it used to work just fine... and doesn't now... what could be the problem? Parallelism?
True enough Jeff. Looking back at the original post (and paraphrasing), the system is hanging and the factory floor can't work. The issue could be blocking. Pretty sure that the NOLOCK hint is ignored on the delete, and if the DELETE is going to delete 11,000,000 rows, I wouldn't be surprised if SQL puts a table lock on the table.
If it was working before but isn't now, the two things that come to my mind now would be data and disk fragmentation. The OP should check these out.
😎
Correct, WITH (NOLOCK) only affects SELECTs.
I just can believe the delete of 11 million rows didn't get caught blocking before. Somethings not quite right here. I think Lynn is on the right track... I've seen it where the undocumented ability to DELETE alias has bitten folks before. Gotta follow the rules and delete from a table name, instead.
Which track is right, the coding of the delete (I offered 2 solutions) or the fragmentation (disk and data)?
😎
June 12, 2008 at 2:44 pm
Makes me wonder if it wouldn't be easier to just to the select...INTO on stuff you want to keep, blow out the original table and reinsert the items to keep.....
I don't recall hearing how many rows would be left after this little adventure.....
Either way - deleting that much in one chunk is bound to jam things up a bit. Perhaps deleting in smaller chunks would help, too.
----------------------------------------------------------------------------------
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 12, 2008 at 2:52 pm
Matt Miller (6/12/2008)
Makes me wonder if it wouldn't be easier to just to the select...INTO on stuff you want to keep, blow out the original table and reinsert the items to keep.....I don't recall hearing how many rows would be left after this little adventure.....
Either way - deleting that much in one chunk is bound to jam things up a bit. Perhaps deleting in smaller chunks would help, too.
That is why I made the second code suggestion.
😎
June 12, 2008 at 2:54 pm
Lynn Pettis (6/12/2008)
Which track is right, the coding of the delete (I offered 2 solutions) or the fragmentation (disk and data)?
I was talking about the DELETE code... but, yes, I believe both tracks are correct and both need to be considered. It may also be that someone made the log smaller and they got bit by unexpected growth during the delete. That would certainly "Hang" the system until the growth completed and the delete completed.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 12, 2008 at 3:02 pm
Lynn Pettis (6/12/2008)
Matt Miller (6/12/2008)
Makes me wonder if it wouldn't be easier to just to the select...INTO on stuff you want to keep, blow out the original table and reinsert the items to keep.....I don't recall hearing how many rows would be left after this little adventure.....
Either way - deleting that much in one chunk is bound to jam things up a bit. Perhaps deleting in smaller chunks would help, too.
That is why I made the second code suggestion.
😎
yup - missed it! 😛
----------------------------------------------------------------------------------
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 12, 2008 at 3:13 pm
Unfortunately, it doesn't look like the OP has been on SSC since yesterday morning. Hope he checks this thread and let's us know what's happening.
😎
June 12, 2008 at 4:08 pm
Lynn Pettis (6/12/2008)
Unfortunately, it doesn't look like the OP has been on SSC since yesterday morning. Hope he checks this thread and let's us know what's happening.😎
I think that happens more that we like 😉
* Noel
Viewing 12 posts - 16 through 26 (of 26 total)
You must be logged in to reply to this topic. Login to reply