Witam,

odnośnie Pana pierwszego postu, to polecam wpis Paula Randalla odnośnie operacji SHRINK. To jest generalnie bardzo mocno niezalecane.

Odbudowywanie Indeksów zależy od czasu, jaki mamy w nocy do dyspozycji; jeżeli jest go wystarczająco dużo, przebudowujemy indeksy, jeżeli nie, to musimy wybrać indeksy do przebudowania.

Kilka uwag do powyższego planu i wskazówek :

1. Shrink with TRUNCATEONLY (tak jak w Twoim planie) nie jest wielką tragedią. Prawdziwy disaster stałby się, gdybyś użył tej procedury bez żadnej opcji lub z WITH NOTRUNCATE. Wtedy dochodzi do tej potężnej defragmentacji, o której wspomina Maciej, przytaczając post Paul Randalla (tam jest właśnie przykład samego SHRINK czyli najpierw NOTRUNCATE  a potem TRUNCATEONLY). Dzieje się tak dlatego, że algorytm NOTRUNCATE jest banalnie prosty - weź ostatnią stronę z pliku i wsadź ją w pierwszą wolną dziurę od początku... i tak w kółko aż obszar będzie spójny. W skrajnym przypadku doprowadzi to do 100% fragmentacji indeksu. U Ciebie tak się nie stanie, bo TRUNCATEONLY obcina tylko wolne miejsce i zwraca je do OS... co nie zmienia faktu, że nie jestem zwolennikiem obcinania (tym bardziej regularnego). Tak czy siak - SHRINK tylko w skrajnych, uzasadnionych przypadkach. :)

2. Zastanów się nad sensownością wykonywania tych operacji o 3:00 po full backup (który jest o 0:00). Jeśli baza walnie o 11-tej, to będziesz musiał odtworzyć wszystko z F-backupu, potem sprawdzić spójność, defragmentować indeksy etc. - bez sensu. Zazwycza lepiej te operacje (CHECK DB zwłaszcza) przed backupem bo po co Ci backup z błędami / pofragmentowanymi indeksami etc.  Chyba, że problem jest z oknem serwisowym.... wtedy trzeba kombinować.

3. Puchnięcie kopii różnicowej - bo jak wykonujesz po FULL Backup, rebuild indeksów to znacząco obciążasz log transakcyjny. DIFF zawiera wszystkie zmiany, więc również zmiany alokacji na stronach indeksu. Jest to kolejny powód, aby Full Backup robić po czynnościach utrzymaniowych. :)

4. Czy robić codziennie pełen Maintenance Plan? Tu musisz sam znaleźć odpowiedź - jak długo się on wykonuje. Jeśli ten czas jest akceptowalny np. 1h i mieści się w oknie serwisowym, to nie widzę powodów, aby go nie robić - same plusy. Jeśli się nie mieści, to może tylko defragmentować część indeksów (najważniejszych), update statstyk z próbkowaniem etc.

5. Aktualizacja statystyk jest bardzo wskazana. Bez aktualnych statystyk nigdy nie ma mowy o optymalnym planie wykonania (przypomnę, że auto update dopiero po 20% zmian!!! To mega dużo). SQL Server, jak i inne silniki, oparty jest o optymalizator kosztowy, który bez drogowskazu, jakimi są stats, nie jest w stanie wyliczyć WŁAŚCIWIE kosztu - i w ten sposób rodzą się duże rozbieżności pomiędzy ESTIMATED i ACTUAL rows i inne kłamstwa w planach wykonania. Jeśli czas Cię nie ogranicza - to oczywiście robić!

Pozdrowienia!