|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Wednesday, May 01, 2013 11:07 AM
Points: 39,
Visits: 221
|
|
GilaMonster (10/31/2012)
Andrew Diniz (10/31/2012)
After all, it is possible to observe 'Halloween Protection' in DELETE and INSERT plans too  No, the Halloween problem is exclusively for updates. You can't insert or delete a row multiple times, you can an update and that's the problem. You may see spools in insert or delete plans, but they are not there for halloween protection.
I beg to differ. Consider a DELETE statement of the form:
DELETE TABLE_NAME WHERE COL < CONST
as opposed to
DELETE TABLE_NAME WHERE COL < (SELECT AVG(COL) FROM TABLE_NAME)
You'll see a spool in the second DELETE, and that spool is essential to protecting against deleting more rows than expected due to the fact that the AVG changes as a result of rows already deleted. Basically, the DELETE condition depends on data in the table, and the condition changes as rows are deleted. Conceptually this is exactly the same as Halloween Protection for UPDATES.
Consider another example:
DELETE TABLE_NAME WHERE COL1 NOT IN (SELECT COL2 FROM TABLE_NAME)
using data
COL1 COL2 1 2 2 3 3 4
By deleting the row where COL1=2, we now have COL1=2 also unexpectedly matching the filter. Similarly deleting COL1=2 could result in COL1=3 being deleted. Without Halloween Protection, the DELETE statement empties the table.
So although Halloween Protection typically applies to UPDATE, it can apply to DELETE; and similar cases can be found for INSERT.
|
|
|
|
|
SSC Eights!
      
Group: General Forum Members
Last Login: Tuesday, June 04, 2013 8:50 AM
Points: 862,
Visits: 1,440
|
|
Thank you for this question. I knew the answer from the top of my head because I've read about it not so long ago. Excellent opportunity for this question to come up!
Best regards,
Andre Guerreiro Neto
Database Analyst http://www.softplan.com.br MCITPx1/MCTSx2
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Today @ 8:26 AM
Points: 3,164,
Visits: 4,344
|
|
Good question, thanks Steve. Actually encountered this very issue while repairing a "broken" cobol program on the mainframe a few years ago, where the developer changed the ordinal positions of the columns in the data set (by adding a column in ordinal position 1, which shifted all the other columns on) but did not change the variables in the cursor accordingly (using select * to populate the variables, of course) - really played havoc with the customer limits every time one was changed...
____________________________________________ Space, the final frontier? not any more... All limits henceforth are self-imposed. “libera tute vulgaris ex”
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Wednesday, June 12, 2013 5:11 AM
Points: 1,168,
Visits: 1,470
|
|
Nakul Vachhrajani (10/31/2012) Very nice question! With a little thought, I was certain about the answer. While this was the first time I heard about "halloween protection", the chain of thought I used was Halloween = ghosts & goblins. Ghosts = phantom. We all know about "phantom updates" and hence the answer had to be what it is.
I had the same thought, figuring it had something to do with ghosts. That was the only Halloween related term that seemed to be related to databases. Well, zombie might be too, but that only relates to DBA's that have been working too long without sleep.
Please don't go. The drones need you. They look up to you.
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Today @ 3:19 AM
Points: 194,
Visits: 248
|
|
GilaMonster (10/31/2012)
Andrew Diniz (10/31/2012)
After all, it is possible to observe 'Halloween Protection' in DELETE and INSERT plans too  No, the Halloween problem is exclusively for updates. You can't insert or delete a row multiple times, you can an update and that's the problem. You may see spools in insert or delete plans, but they are not there for halloween protection.
Ok. Thanks for clarifying.
The scenarios I alluded to (and illustrated by craig 81366 above) seem to be resolved in a similar fashion to 'Halloween Protection'.
I assume, then, that the QO's introduction of blocking operators in INSERT and DELETE statements to address similarly undesirable effects was already in place when the 'Halloween bug' was discovered. Is this why 'Halloween Protection' relates to UPDATE statements only?
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Thursday, June 13, 2013 8:50 PM
Points: 3,208,
Visits: 4,178
|
|
craig 81366 (10/31/2012)
GilaMonster (10/31/2012)
You can't insert or delete a row multiple times
I beg to differ ... that spool is essential to protecting against deleting more rows than expected "Delete a row multiple times" and "Delete more rows than expected" – there is a big difference, I believe.
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Wednesday, June 12, 2013 3:30 AM
Points: 113,
Visits: 102
|
|
vk-kirov (10/31/2012)
craig 81366 (10/31/2012)
GilaMonster (10/31/2012)
You can't insert or delete a row multiple times
I beg to differ ... that spool is essential to protecting against deleting more rows than expected "Delete a row multiple times" and "Delete more rows than expected" – there is a big difference, I believe.
Yeah, it is all about using the exact SAME row more than once... If you INSERT the 'same' row more than once, it becomes 2 different rows in the database. If you DELETE the 'same' row more than once, you are essentially only deleting it once... Once the row is deleted, it is deleted
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Today @ 10:48 AM
Points: 10,990,
Visits: 10,578
|
|
GilaMonster (10/31/2012)
Andrew Diniz (10/31/2012)
After all, it is possible to observe 'Halloween Protection' in DELETE and INSERT plans too  No, the Halloween problem is exclusively for updates. You can't insert or delete a row multiple times, you can an update and that's the problem. You may see spools in insert or delete plans, but they are not there for halloween protection. This is a common misconception. Internally, all data-changing operations are referred to as updates. This includes insert, delete, update, and merge. Confusing for SQL people perhaps, but that's the way it is. This usage in Ian's post seems to have misled Steve today because Halloween Protection is most definitely required (and a strategy computed) for update plans (I/U/D/M) in general, not just updates. There were several bugs (in SQL Server 7/2000 I think) that related to incorrect HP for inserts and deletes with self-joins, for example.
Craig Freedman states this explicitly at the end of the following entry:
http://blogs.msdn.com/b/craigfr/archive/2008/02/27/halloween-protection.aspx
edit: Adding KB http://support.microsoft.com/kb/810026
Paul White SQL Server MVP SQLblog.com @SQL_Kiwi
|
|
|
|
|
Say Hey Kid
      
Group: General Forum Members
Last Login: 2 days ago @ 6:18 AM
Points: 691,
Visits: 1,104
|
|
| Thanks for the great question. Had to do a little reading to get the answer.
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Wednesday, May 01, 2013 11:07 AM
Points: 39,
Visits: 221
|
|
vk-kirov (10/31/2012)
craig 81366 (10/31/2012)
GilaMonster (10/31/2012)
You can't insert or delete a row multiple times
I beg to differ ... that spool is essential to protecting against deleting more rows than expected "Delete a row multiple times" and "Delete more rows than expected" – there is a big difference, I believe. It seems to me that you're quibbling about how a questionable statement by GilaMonster differs from mine. Perhaps take a look at the very last sentence of Craig Freedman's (not me) blog post: http://blogs.msdn.com/b/craigfr/archive/2008/02/27/halloween-protection.aspx He says he's been working for the SQL Server team for quite a few years, so probably can be considered authoritative on the matter. 
Edit: To clarify... it's not the statement "cannot delete a row multiple times" that I consider questionable. (Obviously ) It's questionable to use that as the explanation why DELETE's don't apply to the Halloween Problem.
|
|
|
|