Jakie są zalety i wady skryptów Oli w porównaniu do korzystania z planu konserwacji?

9

Czy pomożesz mi zrozumieć zalety i wady korzystania z rozwiązania Oli w stosunku do planu konserwacji? Przygotowałem prezentację opartą na SQL Pass ( http://www.pass.org/DownloadFile.aspx?File=ebae1b31 ), którą przedstawię.

Przygotowuję również kilka scenariuszy, których nie rozwiązuje adres rozwiązania Ola i plan konserwacji. Czy możecie mi pomóc wyjaśnić to bardziej technicznie?

Nawiasem mówiąc, zarządzamy prawie 150+ serwerami (mix 2008/2012/2014/2016) z rozwiązaniem Oli na co najmniej 75% z nich. Podobał mi się ten artykuł Brenta Ozara. Ale w jednym komentarzu Brent zalecił użycie rozwiązania opartego na skryptach dla liczby serwerów, które mamy. https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/

sql-server ola-hallengren

— Poklepać
źródło

Czy mówimy o kopiach zapasowych, utrzymywaniu indeksów / statystyk, sprawdzaniu korupcji czy o wszystkich wyżej wymienionych?

— nkdbajoe

Wszyscy. Cały skrypt rozwiązania serwisowego autorstwa Oli. Rozwiązałem problemy z niepotrzebnymi odbudowaniami indeksu i aktualizacjami statystyk w planie konserwacji za pomocą skryptów Oli. Chciałem tylko trochę więcej amunicji technicznej od innych DBA. Dziękuję Ci.

— Pat

2

Osobiście uważam, że najlepszym rozwiązaniem jest rozwiązanie spełniające wymagania biznesowe i zdolność do rozwiązania go w przypadku wystąpienia błędu. Rozwiązanie Oli nie jest ogólnie złe, ale nadal wolę własne, dostosowane do mojego środowiska. Na przykład do konserwacji indeksu chcę mieć równoległe wykonywanie, aby zaoszczędzić czas. Rozwiązanie Oli nie działa tutaj. Chcę mieć przyrostową aktualizację statystyk, rozwiązanie Oli też tutaj nie działa.

— jyao

Czy masz jakieś dane wskazujące, że są one lepsze, czy po prostu korzystasz z tego, co uważasz za lepsze? Najlepszym sposobem rozwiązania tego problemu jest zdobycie danych o wydajności, aby pokazać, dlaczego metoda jest lepsza

— Joe W

W przypadku utrzymania indeksu wielokrotnie czynnikiem ograniczającym jest SAN i podsystem pamięci. W zależności od konfiguracji SAN możesz nie zauważyć żadnej poprawy w równoległych przebudowach.

— Alen

13

Mam napisane

Plany konserwacji nie są złe, ale gdy środowisko rośnie, ograniczona elastyczność i funkcjonalność zapewniane przez plany konserwacji nie będą wystarczające.

Aby dodać więcej,

Rozwiązanie konserwacyjne Oli jest powszechnie akceptowane w społeczności i dużych organizacjach .
Jego otwarte źródła i problemy mogą być podnoszone na github / problemy z prawdopodobieństwem szybkiego naprawienia.
Jest elastyczny i skalowalny (nawet jeśli chcesz wdrożyć go na setkach serwerów, po prostu użyj Install-DbaMaintenanceSolution z dbatools).
Microsoft zajął prawie dekadę, aby naprawić GUI planu konserwacji, który sam był błędny :-)
ma obszerną dokumentację i często zadawane pytania oraz jest stale aktualizowana, aby pomieścić nowsze wersje serwerów SQL.
w wersji zapoznawczej możesz nawet tworzyć kopie zapasowe równolegle.
w przypadku rozwiązania do obsługi indeksu można nawet wyregulować czas procesu, np. jeśli trwa on dłużej niż X, przerwij go.

— Kin Shah
źródło

5

Jedną z głównych zalet rozwiązania opartego na skryptach jest łatwość wdrożenia - coś, co jest wyraźnie istotne w twoim przypadku, ponieważ masz ponad 150 serwerów. Próba wprowadzenia kilku planów konserwacji (tj. Co najmniej 2, jednego dla baz danych systemu i jednego dla baz danych użytkowników) na 150 serwerach byłaby koszmarem. Utrzymanie ich raz na miejscu jest tak samo kłopotliwe.

Z czasem rozwiązanie oparte na skryptach jest znacznie łatwiejsze do wdrożenia i utrzymania. Skrypty Oli są dość kompleksowe i zaspokajają większość potrzeb. Stanowią świetny punkt wyjścia dla każdej organizacji, aby następnie dostosować ją do własnych unikalnych wymagań.

W naszym przypadku mamy około 40 instancji SQL w naszym środowisku DEV i używamy zmodyfikowanych skryptów Ola z funkcją wielu połączeń SSMS, aby móc wprowadzać zmiany w systemie konserwacji we wszystkich 40 instancjach za pomocą jednego kliknięcia. Wszelkie specjalne przypadki są obsługiwane przez nasze modyfikacje.

— Mikrofon
źródło

3

Nie jestem w 100% pewien jego skryptów, ale skrypty niestandardowe są znacznie lepsze niż plany konserwacji. Wbudowane plany odbudują każdy indeks w tabeli bez względu na to, jak mało fragmentacji. Jeśli masz Always On, stworzy się burza.

Skrypty niestandardowe możesz odbudować o ponad 20% lub o dowolnym progu. Mniej przebudowywanych jednocześnie indeksów. Mniej zawsze włączonych danych do wysłania do pomocniczych. Szybsza przebudowa, ponieważ przebudowujesz mniej indeksów. Wymagane krótsze okno konserwacji.

Ostatnim razem, gdy korzystałem z planów konserwacji, miałem tabelę wierszy o wartości 300 milionów, a funkcja Always On byłaby o kilka godzin za każdym razem, gdy rozpoczynane były odbudowy indeksu i problemy z przepełnieniem dziennika transakcji. Wróciłem do skryptów i wszystko zniknęło.

— Alen
źródło

1

Oryginalnie napisałem swój własny dla SQL 2005 około 2007 roku. Użyłem tego, co książki on-line miał jako bazę, i trochę go zmieniłem. Wtedy wydawało się, że większość ludzi korzysta z planów, a teraz wydaje się, że się odwróciło. I zanim zacząłem robić rzeczy DBA, poprzedni DBA przede mną miał niestandardowe skrypty dla SQL 2000. Jedyną rzeczą, którą inaczej zrobiłem, było przebudowanie wszystkiego. Szybsza była odbudowa o ponad 20% lub 30% niż reorganizacja. Do tworzenia kopii zapasowych zawsze korzystaliśmy z produktów innych firm

— Alen

1

Oprócz powyższego moim ulubionym powodem jest możliwość automatycznego przełączania rodzaju kopii zapasowej, aby nowa baza danych miała pełną kopię zapasową przy pierwszym uruchomieniu zadania tworzenia kopii zapasowej dziennika zamiast oczekiwania na uruchomienie następnego pełnego zadania tworzenia kopii zapasowej.

— SQLDBAWithABeard
źródło

0

Plany konserwacji będą wystarczające przez większość czasu. Skrypty Oli Hallengren będą w większości przypadków w porządku.

W bardzo rzadkich przypadkach może być konieczne wyhodowanie własnego.

Jak powiedział Jyao, wszystko sprowadza się do najwygodniejszej pracy. Jeśli twój współpracownik najlepiej czuje się w planach konserwacji, po co skręcać majtki?

Jeśli zajmuje się bazami danych od ponad 20 lat, napisał już własne skrypty serwisowe. Mniej więcej w tym czasie, gdy uczysz się prowadzić, pewnie pojawił się młody punk w spodenkach cargo i fliplopsach, który wyglądał jak: „hej, stary drodzy, plany konserwacji są lepsze - i ściągnij spodnie, wyglądasz absurdalnie! „.

Potem prawdopodobnie miała miejsce 4-letnia bitwa, w której zarozumiały młodzieniec wdrożył plan konserwacji, kiedy tylko mógł. Teraz ten drugi młody punk z chudymi jeansami i dziwaczną muszką każe mu wrócić do scenariuszy. Wystarczy, aby twoje włosy stały się siwe.

Trzy rzeczy do rozważenia:

Czy te przykłady wyższości Hallengrenite faktycznie dotyczą twojego środowiska?

Czy to sprawi ci prawdziwy problem, jeśli użyje planów konserwacji?

Jeśli przekonasz go do korzystania ze skryptów Hallengrena i pojawi się problem, czy będzie w stanie rozwiązać go samodzielnie, czy będzie musiał do ciebie zadzwonić?

— James
źródło

Odpowiedz na dwa pierwsze pytania Tak. Widzieliśmy już problemy z planami konserwacji i rozwiązałem je za pomocą rozwiązania Oli. Na serwerze produkcyjnym było również zadanie dziennika zmniejszania (??), które natychmiast wyłączyłem. Trzecie pytanie, nie wiem. Nie jestem pewien, czy będzie w stanie rozwiązać problemy stworzone przez sam Plan konserwacji. Kiedy zapytałem go na wypadek, gdybyśmy mieli z tym problemy, co powinniśmy zrobić? Jego odpowiedzią było wezwanie pomocy technicznej Microsoft. (??)

— Pat

@Pat, ahh, brzmi jakby osiągnął swój limit zgodnie z Zasadą Piotra. Ostrożnie staraj się, aby był lepszy - raczej nie doceni pomocy.

— James