We've found that without doing update stats with full scan the query optimizer "mis-estimates" the number of records in the index -- poor execution plans. I can't do anything with the log or other backups other than suggest to the Systems team who manages Commvault. Native sql backups can't be run or we'll screw up the log chain Commvault establishes.

My maintenance runs on Saturday The log file is about 100GB and lately hasn't gotten over 50% full during maintenance, but that won't last -- we just added over 400k new records yesterday and will convert over a million new legacy records next weekend. The log drive is 170GB but I can easily ask for 3 times that. The real problem is how long maintenance takes. The next differential is 1am sunday morning followed by a systems maintenance window that I don't want to impact.

The update stats routine, like the reindex routine, uses it's own stored procedure which looks for indexes or stats needing updating, so neither just update everything. Right now we reorganize indexes with 10-30% fragmentation and rebuild if over 30.