January 1, 2014 at 10:10 pm
Comments posted to this topic are about the item Dropping indexes
January 1, 2014 at 10:12 pm
Good Question..
January 2, 2014 at 3:33 am
PRR.DB (1/1/2014)
Good Question..
+1
🙂
January 2, 2014 at 4:02 am
Good One!
---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."
January 2, 2014 at 6:26 am
Really good question. Had to think about that one for a second :-D. Of course, I was thinking more into your question like "what if there are relational keys associated or referencing foreign keys?" which of course would throw errors.
Again, thanks.
January 2, 2014 at 6:35 am
Good one, thank you for the post. 🙂
(even though, I got it right with inconsistent thought on this "This may take significant time on large tables." and was wondering if the DB is online and users connected to it via application and the application performance would reduce in that particular time frame - and then thought; wait - why would they drop index on the main DB, such activity is done on mainly DWH in the maintenance window with very less users connected and the impact would be very less... and then thought may be this was the case of 2008 R2 and below and may be 2012 and 14 have bettered in this area.... well!!!)
ww; Raghu
--
The first and the hardest SQL statement I have wrote- "select * from customers" - and I was happy and felt smart.
January 2, 2014 at 7:28 am
Got it wrong as I was using http://technet.microsoft.com/en-us/library/ms176118.aspx as a reference and it says, in part:
If a clustered index is dropped by using MOVE TO, any nonclustered indexes on the base table are rebuilt, but they remain in their original filegroups or partition schemes. If the base table is moved to a different filegroup or partition scheme, the nonclustered indexes are not moved to coincide with the new location of the base table (heap). Therefore, even if the nonclustered indexes were previously aligned with the clustered index, they might no longer be aligned with the heap.
which would appear to contradict the given answer.
What am I missing here?
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
January 2, 2014 at 7:41 am
Thomas Abraham (1/2/2014)
Got it wrong as I was using http://technet.microsoft.com/en-us/library/ms176118.aspx as a reference and it says, in part:If a clustered index is dropped by using MOVE TO, any nonclustered indexes on the base table are rebuilt, but they remain in their original filegroups or partition schemes. If the base table is moved to a different filegroup or partition scheme, the nonclustered indexes are not moved to coincide with the new location of the base table (heap). Therefore, even if the nonclustered indexes were previously aligned with the clustered index, they might no longer be aligned with the heap.
which would appear to contradict the given answer.
What am I missing here?
non-clustered indexes also contain the clustered index column(s) to identify the location of the actual rows to retrieve data from. If the clustered index is dropped then the non-clustered indexes have to be rebuilt to remove the clustered index and replace it with row ID information
---------------------------------------------------------------------
January 2, 2014 at 7:48 am
george sibbald (1/2/2014)
Thomas Abraham (1/2/2014)
Got it wrong as I was using http://technet.microsoft.com/en-us/library/ms176118.aspx as a reference and it says, in part:If a clustered index is dropped by using MOVE TO, any nonclustered indexes on the base table are rebuilt, but they remain in their original filegroups or partition schemes. If the base table is moved to a different filegroup or partition scheme, the nonclustered indexes are not moved to coincide with the new location of the base table (heap). Therefore, even if the nonclustered indexes were previously aligned with the clustered index, they might no longer be aligned with the heap.
which would appear to contradict the given answer.
What am I missing here?
non-clustered indexes also contain the clustered index column(s) to identify the location of the actual rows to retrieve data from. If the clustered index is dropped then the non-clustered indexes have to be rebuilt to remove the clustered index and replace it with row ID information
I understand that part. However, the reference seemed to imply that the non-clustered indexes had to be MANUALLY rebuilt, IF the table was moved to a different filegroup or partition scheme.
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
January 2, 2014 at 8:13 am
January 2, 2014 at 8:21 am
george sibbald (1/2/2014)
I would read that If as an 'as well'. This is because the clustered index is still being dropped, but the data is moved at the same time, but is now a heap.Best details on when non-clustered indexes get rebuilt here[/url]
Thanks. That cleared it up for me.
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
January 2, 2014 at 11:55 am
Nice question. Bizarre choice of reference for the explanation, though - [http://technet.microsoft.com/en-us/library/ms186342.aspx has nothing to do with dropping indexes - it's abouy creating clustered indexes.
Tom
January 2, 2014 at 12:44 pm
Nice question, thanks.
January 3, 2014 at 2:41 am
A big Thank you to all for your comments and wish you all a very happy new year...
January 3, 2014 at 11:13 am
Simple, but sent me to check BOL, anyway. Thanks, Jagadish!
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply