I completely agree with you guys and did before I even posted. I was trying to gather as much technical detail as I can so that I am prepared to combat their recommendation.
GilaMonster (6/13/2011)
Regular rebuilds will sort out the partially empty pages problem (from deletes and inserts causing page splits). The shrink-reindex (grow) just wastes a hell of a lot of time and resources for no gain
allmhuran (6/13/2011)
Each operation essentially "undoes" the other in terms of logical fragmentation.Shrinking the database takes pages from the end first, and moves them to free space in the front. Rebuilding an index will try to lay out the pages on disk in order. Doing both sequentially is worse than just wasting time, because what you can end up with is underlying disk fragmentation.
I understand how it could be redundant to move a page up to the front with the shrink then turn around and move it with the rebuild. I guess I need to get more info from them on exactly how much data is being inserted and deleted from these tables. If it helps at all, this is Enterprise Vault and the DBs can range from 20 gig to 180 gig.
I dont see how you would get underlying disk fragmentation if you are not releasing any of the file free space back to the OS. I do understand that if the file were full and we were rebuilding large indexes while autogrowing 1MB at a time or we released all the free space and grew it again, we would be introducing physical fragmentation. In this case, there would be plenty of space in the data file. We also dont have any control over the physical disk fragmentation, i believe that is handled on the SAN by that group. We are pretty much presented a LUN and thats about as much say so as we have for disk. Could you please elaborate on that a little more where you could introduce physical fragmentation here.
Thanks