Czy włączenie automatycznego zmniejszania programu SQL Server jest bezpieczne?

Istnieje wiele opcji SQL Server, które można włączyć dla baz danych, a jedną z najbardziej niezrozumianych jest automatyczne zmniejszanie. Czy to jest bezpieczne? Jeśli nie, dlaczego nie?

(Początkowo zadałem zwykłe pytanie, ale potem znalazłem poprawną metodę - dzięki BrentO)

Nie, nigdy.

Spotkałem się z tym kilka razy na ServerFault i chcę dotrzeć do miłej szerokiej publiczności z kilkoma dobrymi radami. Jeśli ludzie patrzą na to z niechęcią, głosujcie, a chętnie to usunę.

Automatyczne zmniejszanie jest bardzo częstym ustawieniem bazy danych, które można włączyć. To wydaje się dobrym pomysłem - usuń dodatkowe miejsce z bazy danych. Istnieje wiele „mimowolnych DBA” (na przykład TFS, SharePoint, BizTalk lub zwykły stary SQL Server), którzy mogą nie wiedzieć, że automatyczne zmniejszanie jest zdecydowanie złe.

Podczas pracy w firmie Microsoft byłem właścicielem aparatu SQL Server Storage Engine i próbowałem usunąć funkcję automatycznego zmniejszania, ale musiałem pozostać w celu zachowania zgodności z poprzednimi wersjami.

Dlaczego automatyczne zmniejszanie jest tak złe?

Baza danych prawdopodobnie znów wzrośnie, więc po co ją zmniejszać?

1. Shrink-grow-shrink-grow powoduje fragmentację na poziomie systemu plików i zajmuje dużo zasobów.
2. Nie możesz kontrolować, kiedy to się uruchamia (nawet jeśli jest normalne)
3. Zużywa wiele zasobów. Przenoszenie stron w bazie danych wymaga procesora, wielu operacji we / wy i generuje wiele dzienników transakcji.
4. Oto prawdziwy kicker: zmniejszenie pliku danych (czy to automatycznie, czy nie) powoduje ogromne rozdrobnienie indeksu, co prowadzi do niskiej wydajności.

Niedawno napisałem post na blogu, który zawiera przykładowy skrypt SQL, który pokazuje problemy, które powoduje, i wyjaśnia bardziej szczegółowo. Zobacz Automatyczne zmniejszanie - wyłącz je! (brak reklam lub takich śmieci na moim blogu). Nie należy mylić tego ze zmniejszaniem pliku dziennika, który jest przydatny i potrzebny czasami.

Zrób więc sobie przysługę - sprawdź ustawienia bazy danych i wyłącz automatyczne zmniejszanie. Z tego samego powodu nie powinieneś również kurczyć się w planach konserwacji. Przekaż słowo swoim współpracownikom.

Edycja: Powinienem to dodać, przypominając drugą odpowiedź - powszechne jest błędne przekonanie, że przerwanie operacji zmniejszania może spowodować uszkodzenie. Nie, nie będzie. Kiedyś byłem właścicielem kodu skurczowego w SQL Server - wycofuje on bieżący ruch strony, który wykonuje, jeśli zostanie przerwany.

Mam nadzieję że to pomoże!

Oczywiście Paul ma rację.

Zobacz wszystkie bazy danych i ich ustawienia automatycznego nawiązywania połączenia. Jeśli masz dużo baz danych, jedna z nich się wkradnie.

sp_msforeachdb  @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')'

Czy to gdzieś w dmv ... Zastanawiam się.

To nie jest „niebezpieczne” - niczego nie uszkodzi.

Nie jest to jednak zalecane w środowiskach produkcyjnych, w których baza danych może zdecydować się na uruchomienie i przeprowadzenie kosztownej zmiany układu bezpośrednio przed nadejściem stosu żądań, co powoduje, że żądania te wymagają więcej czasu. O wiele lepiej jest korzystać z planowania operacji zmniejszania wraz z innymi operacjami konserwacji, takimi jak tworzenie kopii zapasowych (w rzeczywistości po wykonaniu kopii zapasowych - w ten sposób będzie więcej z dziennika transakcji). Lub po prostu wcale się nie kurczy, chyba że wystąpi problem ze wzrostem - zawsze możesz skonfigurować monitor, aby poinformować Cię, kiedy niewykorzystana przydzielona przestrzeń wzrośnie powyżej określonego współczynnika lub ustalonego rozmiaru.

IIRC opcja jest domyślnie wyłączona dla wszystkich baz danych we wszystkich edycjach MSSQL oprócz Express.

W witrynie TechNet dostępny jest oficjalny dokument wyjaśniający bardziej szczegółowo obsługę SQL.

http://technet.microsoft.com/en-us/library/cc262731.aspx

Widziałem serwer SQL z włączoną funkcją Autogrow i Autoshrink. Ten (stosunkowo mocny) serwer był strasznie wolny, ponieważ wszystko, co robił przez cały dzień, zmniejszało się i powiększało pliki bazy danych. Autoshrink może być użyteczny, ale polecam dwie rzeczy:

1. Domyślnie wyłącz Autoshrink.
2. Dokumentuj konfiguracje serwera, abyś wiedział, gdzie są włączone Autogrow i Autoshrink, a gdzie nie.

Jedyną sytuacją, w której zmuszono mnie do zmniejszenia bazy danych, było odświeżenie kopii na serwerze testowym z mniejszą ilością miejsca na dysku (niewystarczające do przechowywania produkcyjnej bazy danych).

Plik (-y) produkcyjnej bazy danych miał dużo wolnego miejsca, niestety musisz przywrócić bazę danych o tych samych rozmiarach plików, co kopia zapasowa. Więc nie miałem wyboru, musiałem zmniejszyć produkcję przed jej utworzeniem. (Zmniejszenie trwało wieki, zużyto dużo zasobów, a późniejszy wzrost dziennika transakcji był problematyczny).

Zobacz także samouczek wideo ....

Zobacz, jak Paul Randal pokazuje, jak zmniejszanie i automatyczne zmniejszanie może powodować poważne problemy z fragmentacją bazy danych http://wtv.watchtechvideos.com/topic194.html