der Neuaufbau der Indizes sowie der Statistiken ist ein Teil zur Optimierung der Datenbank damit der SQL-Server die Abfragen bestmöglich optimieren und ausführen kann.
Auf Details hier einzugehen würde am Thema vorbei führen.
Das könnte auch aus einem Werbeprospekt stammen, bis zu den Details. Die Details sind meistens spannend.
Man kann natürlich die halbe Nacht optimieren, aber wenn es den produktiven Betrieb beeinträchtigt, würde ich es nicht mehr "Optimierung" nennen.
Also konkret: Vielleicht sind ja die Indizes aus der laufenden Woche optimal genug, um den Job zu machen. Vielleicht reicht die Optimierung am WE vollkommen aus, oder sogar seltener.
Stichwort dazu wäre Indexfragmentierung, auch ein fragmentierter Index funktioniert noch, idR viel besser, als kein Index. Ich habe auch noch nie davon gehört, dass ein Optimizer nicht nur die Existenz oder Art eines Index in seine Query Optimierung einbezieht, sondern auch dessen Fragementierungsgrad.
Du kannst Dir also mal anschauen, wie fragmentiert irgendwelche Indizes überhaupt sind. Dann kannst Du überlegen, welche Fragementierung aktzeptabel ist. Und dann kannst Du sicher auch mal schauen, wann überhaupt Fragementierung entsteht. Grundannahme, vor allem dort, wo viel eingefügt UND gelöscht wird oder geändert (also bei Änderungen, die Non Key Fields betreffen und trotzdem einen Index haben).
Da Daten ja ziemlich heilig sind, werden sie selten gelöscht. Demnach könnte es viele Indizes geben, die überhaupt nicht oder selten optimiert werden müssen.
Die Frage nach der Version betraf die Möglichkeiten, überhaupt non blocking Verfahren einsetzen zu können, also den Fähigkeiten des Servers.
Ob MS SQL Server das überhaupt kann oder ab welcher Version müsstest Du prüfen.
Statistiken sind ein anderes Thema, müssen aber auch nicht täglich aktualisiert werden. Beispiel, eine Tabelle, auf der massiv Import Export Delete ausgeführt wird, kann sehr schwankende Bilder abgeben. Statistiken sollten das grobe Mengengerüst der DB wiedergeben.
Also Tipp
1: Optmiere nicht wild in der Gegend rum, sondern nur das Nötige
2: Das Gleiche gilt für Statistiken.
3: Suche Operationen, die massiv und unnötig Datenoperationen machen. Also Applikation oder Script Tuning.
4: Wähle die schonensten Formen von Index Rebuild, etc. ggF. kannst Du bei aktuellen Versionen ja sogar non blocking als Schalter wählen (was wahrscheinlich die Dauer negativ beeinflusst)
5: Schaue in Logs (Ereignisse) nach Meldungen wie z.B. Log Escalation. Findest Du sowas, versuche es zu vermeiden
6: Handarbeit
Handarbeit meint, selbst zu optimieren. Es gibt offenbar frei verfügbare Scripte von Leuten, die die gleichen Probleme mit MS SQL Server haben.
Zu 5. Das ist etwas, was man sowieso nicht haben will. MS macht es sich da einfach. Wenn die Ressourcen eng werden, kommt halt Log Escalation, ein Prozess hat die Locks und darf machen und der Rest schaut in die Röhre. Ob das bei Index Rebuild auch so gnadenlos durchgezogen wird, und was Ursache und Wirkung ist, keine Ahnung. Es betrifft auch die Frage, die schon gestellt wurde. Kann MS SQL das überhaupt non blocking.