An extraordinarily large table (which I'll abbreviate "xlt" for convenience) can indeed cause unusual issues.
If you use tempdb, it needs (lots of) extra disk space, which basically can't be freed while SQL is running.
If you don't use tempdb, you might not have any good choice except to test for avail. space and explicitly grow the db file(s) containing the xlt before doing the rebuild if necessary. You'll want to make sure IFI is set on for that if at all possible (hopefully it's already on all the time anyway).
But then it will be extremely difficult to shrink the db to regain any of that disk space either, as that can fragment that xlt you just rebuilt.
Ouch! The disk space is basically gone either way
Given that, I prefer to increase tempdb to the point where it can handle the xlt rebuild. That way, if any new xlt(s) are ever added, the tempdb space handles rebuilding any of them (you just can't rebuild more than one of the xlt's at the same time). And the rebuild results are often better, resulting in a less fragmented xlt, which was the point of the rebuild in the first place.
SQL DBA,SQL Server MVP(07, 08, 09)[size=2]Prosecutor James Blackburn, in closing argument in the Fatal Vision murders trial: If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them.[/size]