Do I really need Re-Build Index Task in SQL Server all the Time?
Do I really need Re-build Index Task


The answer to that is very much "it depends". If the data in your tables doesn't change much over time the definitely no, at least not often.


  or I need it only when the Fragmentation Level is above 30% ?


How much fragmentation you allow before a rebuild is an art rather than a science and may depend on your data patterns and performance metrics+targets, but there is definitely no need to rebuild a large index if there is only a very small amount of fragmentation so definitely check each index before rebuilding to see if it is worth the IO load.


  Do I need Re-Organize Index Task when I have Re-build Index Task ?


There is no point reorganising around the same time (either before or after) rebuilding. Reorganising is a less intensive operation then a full rebuild while having some but not all of the benefits. If you rebuild after reorganising then the reorg was wasted as the whole structure is thrown away, if you reorganise after then there is nothing for the process to really do so anything it tries to do is wasted effort.


  My Major concern is, we have the Databases in Full Backup Recovery Model and the T-Log Auto-Growth setting is in '%' .


I would generally recommend against % increments as they can produce large unneeded growth at times. Set the growth to a fixed size, reasonably large so it doesn't need to happen too often but not overly large. The values of "reasonably" and "overly" will change depending on your database.


  This is eating up all my T-log drive space


If altering your plans to rebuilt/reorg/nothing less aggressively (i.e. not rebuilding everything every time irrespective of current fragmentation) then perhaps you could spread the load over the week by working on a subset of your tables each day. This will make little difference if you DB has one huge structure and the rest of the data is in very small tables (an analytics setup with one huge results table and a series of small dimension tables perhaps) but could be beneficial otherwise. Try altering the current plan to be less aggressive first though, this will be simpler to implement and maintain, and there are many example scripts out there that you can take and tweak for your database's needs.