Blog

Ola Hallengren: IndexOptimize

Procedura składowana IndexOptimize Poniżej za pomocą skryptu można wylistować wszystkie parametry procedury składowanej IndexOptimize. Na chwilę obecną można doliczyć się 35 parametrów, które można wykorzystać do konfiguracji procedury. W odpowiedzi dostajemy następującą listę: Poniżej opiszę większość parametrów. Pozwoli to na lepsze zrozumienie zasad działania procedury IndexOptymazie i stworzenie własnego rozwiązania. Istnieje możliwość zmiany wartości domyślnych dla każdego parametru wewnątrz procedury, ale nie jest to zalecane, ponieważ wpłynie to na każde wywołanie joba, który korzysta z tej procedury (np. IndexOptimize – USER_DATABASES). Powszechną Czytaj dalej…

Przez Dariusz Brejnak, temu

Kilka słów o skryptach utrzymaniowych Ola Hallengrena

Postanowiłem rozpocząć cykl kilku wpisów na temat skryptów utrzymaniowych stworzonych przez Ola Hallengrana. Od kilku lat używam je i stwierdzam, że z powodzeniem zastępują Maintenance Plany dostępne z poziomu SSMS. Ola Hallengren jest MVP Microsoft Data Platform mieszkającym w Szwecji. Opracował on najlepsze bezpłatne rozwiązanie do utrzymania i konserwacji dla SQL Server, które jest szeroko stosowane i akceptowane przez administratorów baz danych na całym świecie. Rozwiązanie opiera się na procedurach składowanych, które wykonują kopie zapasowe, sprawdzają integralność, utrzymują indeksy i statystyki we Czytaj dalej…

Przez Dariusz Brejnak, temu

Kto utworzył, skasował lub zmodyfikował obiekt bazy danych

Jak można się dowiedzieć kto utworzył, skasował czy zmodyfikował obiekt w bazie danych jeśli nie ma założonego audytu? Czy to sytuacja bez rozwiązania ? Jeśli z jakiegoś powodu zniknął nam indeks, tabela i chcemy znaleźć przyczynę możemy skorzystać z funkcji fn_trace_geteventinfo oraz z zapisów w tabeli sys.trace_events. To, że w SQL Server samodzielnie nie mamy włączonego śledzenia przy pomocy trace, nie oznacza, że silnik nie monitoruje podstawowych zdarzeń. Na stałe są monitorowane zdarzenia, które można wyświetlić za pomocą poniższego zapytania. W rezultacie Czytaj dalej…

Przez Dariusz Brejnak, temu

Jak użyć SET XACT_ABORT

SET XACT_ABORT określa, jaką akcję silnik SQL Server powinien wykonać po wystąpieniu błędów wykonań w ramach sesji. Domyślne ustawienie sesji to SET XACT_ABORT OFF, co wskazuje, że tylko instrukcja języka Transact-SQL, która zgłosiła błąd, jest wycofywana, a transakcja jest kontynuowana. W zależności od wagi błędu cała transakcja i/lub partia może zostać wycofana, nawet jeśli SET XACT_ABORT jest WYŁĄCZONE. Efektem ubocznym SET XACT_ABORT OFF jest to, że błąd anulowania/przekroczenia limitu czasu może pozostawić otwartą transakcję, więc to klient jest odpowiedzialny za oczyszczenie po Czytaj dalej…

Przez Dariusz Brejnak, temu

Nieudokumentowana funkcja %%lockres%%

Nieudokumentowana funkcja, nazywa się %%lockres%% i jest związana z implementacją blokowania SQL Server. Silnik bazy danych implementuje hierarchię blokowania i żąda blokad na poziomie tabeli, na poziomie strony i na poziomie rekordu. Gdy wymagana jest blokada na poziomie rekordu, SQL Server nie umieszcza blokady na samym rekordzie — SQL Server po prostu generuje wartość skrótu (hash), a wynikowa wartość jest ostatecznie zablokowana. Aby obliczyć tę wartość skrótu, SQL Server używa nieudokumentowanej funkcji %% lockres%% . Funkcję tę można również wywołać na poziomie Czytaj dalej…

Przez Dariusz Brejnak, temu

Dekodowanie Key i Page WaitResource dla zakleszczeń i blokad

W trakcie analizowania blokowań w SQL Server można często spotkać się z wpisami w XML: waitresource=“PAGE: 7:4:50256 ” lub waitresource=“KEY: 8:72046656561991169 (cd54f92b253d)” Co to oznacza ? Jak to przetłumaczyć ? Pokrótce blokada PAGE występuje na poziomie strony, a KEY na poziomie Klucza no ale po kolei. Page lock waits Jeśli mamy wpis waitresource=“ PAGE: 7:4:50256″ oznacza to, że zapytanie czekało na blokadę na poziomie strony. Silnik podaje nam po kolei PAGE: 7:4:50256 PAGE – blokada na poziomie strony 7 – jest to Czytaj dalej…

Przez Dariusz Brejnak, temu