W lutym napisałem post na blogu o automatycznej korekcie planu w SQL Server, a w tym poście chcę opowiedzieć o automatycznym zarządzaniu indeksami, drugim składniku funkcji automatycznego dostrajania. Automatyczne zarządzanie indeksami jest dostępne tylko w Azure SQL Database i nie jest obecnie objęte planem, który ma być dostępny w następnej wersji lokalnego programu SQL Server. Ta opcja jest włączona niezależnie od Automatycznej korekty planu i jak sama nazwa wskazuje, będzie zarządzać indeksami w Twojej bazie danych. W szczególności może tworzyć brakujące indeksy i usuwać indeksy, które nie są używane, a także te, które są duplikatami. Przyjrzyjmy się, jak to się dzieje.
Pod osłonami
Automatyczne zarządzanie indeksami przy podejmowaniu decyzji opiera się na danych. W celu potencjalnego tworzenia indeksu wykorzystuje informacje o brakującym indeksie DMV i śledzi go w czasie oraz łączy te dane z modelem wewnętrznym w celu określenia korzyści z indeksu. Używa również Query Store do określenia, czy indeks zapewnia korzyści, więc musi być włączony dla bazy danych, tak jak w przypadku automatycznej korekty planu. W zakresie zrzucania indeksów wykorzystywane są dane z wykorzystania indeksu DMV (sys.dm_db_index_usage_stats) oraz metadane indeksu (np. liczba kolumn, typy danych kolumn).
Włączanie automatycznego zarządzania indeksami
Jak wspomniano, dla bazy danych musi być włączony zapis zapytań. Można to zrobić w SSMS, za pomocą T-SQL i REST API dla Azure SQL Database. Pamiętaj, że magazyn zapytań jest domyślnie włączony dla baz danych na platformie Azure i działa od IV kw. 2016 r.
USE [master]; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE (OPERATION_MODE = READ_WRITE); GO
Po włączeniu magazynu zapytań możesz użyć interfejsu API Azure Portal, T-SQL lub EST, aby włączyć automatyczne zarządzanie indeksami w bazie danych SQL Azure (C# i PowerShell są w przygotowaniu).
ALTER DATABASE [WWI_PS] SET AUTOMATIC_TUNING (CREATE_INDEX = ON, DROP_INDEX = ON); GO
Automatyczne zarządzanie indeksami będzie domyślnie włączone dla nowych baz danych na platformie Azure (https://azure.microsoft.com/en-us/blog/automatic-tuning-will-be-a-new-default/) w najbliższej przyszłości. Począwszy od stycznia 2018 r. firma Microsoft rozpoczęła wdrażanie, aby włączyć automatyczne dostrajanie dla baz danych SQL Azure, które nie zostały jeszcze włączone, z powiadomieniami wysyłanymi do administratorów, aby w razie potrzeby można było wyłączyć tę opcję. Ten proces trwa kilka miesięcy, więc jeśli nie otrzymałeś jeszcze powiadomienia, nie panikuj!
Jak to działa
W przypadku tworzenia indeksu istnieje obecnie okno kroczące trwające siedem (7) dni*, w którym dane są śledzone, a model potrzebuje co najmniej dziewięciu (9) godzin* danych, aby zarekomendować indeks, wraz z z 12 godzinami* danych w magazynie zapytań, które będą używane jako linia bazowa. Jeśli zostanie ustalone, że indeks przyniesie znaczące korzyści, SQL Server utworzy indeks.
*Te wartości mogą się zmienić w przyszłości, w miarę rozwoju modelu.
Uwaga:obecnie model łączy rekomendacje. Oznacza to, że jeśli dla tabeli zalecanych jest wiele indeksów, ale można utworzyć jeden indeks obejmujący wszystkie opcje, można obecnie utworzyć ten jeden indeks. Jednak model nie jest obecnie wystarczająco inteligentny, aby połączyć zalecany indeks z już istniejącym.
Po utworzeniu indeksu SQL Server weryfikuje, czy zapewnia on korzyści, używając Query Store (dlatego musi być włączony dla bazy danych). Monitoruje wydajność każdego zapytania korzystającego z nowego indeksu i porównuje procesor zapytania przed dodaniem indeksu oraz podczas korzystania z indeksu. Jeśli w wyniku indeksu nastąpi regresja wydajności zapytania, indeks zostanie odwrócony (usunięty). SQL Server monitoruje wydajność zapytań przez maksymalnie trzy (3) dni lub do momentu przeanalizowania 100% odpowiedniego obciążenia. Po tym okresie, jeśli indeks nie wykaże żadnych oznak regresji, nie będzie ponownie sprawdzał jego wyników.
Zrozum, że jeśli automatyczne zarządzanie indeksami utworzy indeks, a dwa miesiące później zmieni się obciążenie pracą i skorzysta na tym samym indeksie utworzonym wcześniej, ale z jedną dodatkową kolumną, wówczas SQL Server utworzy obecnie nowy indeks. Obecnie nie ma logiki zmiany istniejącego automatycznie utworzonego indeksu, ale ta funkcja jest na planie działania funkcji.
Jeśli chodzi o usuwanie indeksów, jeśli indeks nie ma wyszukiwań ani skanów przez 90 dni, ale ma koszty utrzymania (co oznacza, że są wstawiane, aktualizowane lub usuwane), zostanie usunięty. Zduplikowane indeksy również zostaną usunięte, zakładając, że są one dokładnym duplikatem (a schemat jest używany do określenia, czy indeksy są dokładnie takie same). Jeśli istnieją zduplikowane indeksy pod względem kolumn kluczowych i kolumn uwzględnionych (jeśli dotyczy), ale co najmniej jeden z nich ma filtr, to nie są one naprawdę zduplikowane i żadne indeksy nie zostaną usunięte.
Dla porównania, w Azure SQL Database jest dwa razy więcej zaleceń DROP INDEX niż zaleceń CREATE INDEX.
Po włączeniu opcji DROP INDEX SQL Server usunie indeksy utworzone przez użytkownika. Po włączeniu opcji CREATE INDEX SQL Server ma możliwość automatycznego tworzenia indeksów, a także może usuwać te indeksy (ale nie usuwa indeksów utworzonych przez użytkownika). Na koniec indeksy są tworzone i usuwane w okresach obciążenia poza szczytem, określonym przez jednostkę DTU. Jeśli obciążenie przekracza 80% DTU, program SQL Server będzie czekał z utworzeniem lub usunięciem indeksu do momentu zmniejszenia obciążenia systemu.
Czy naprawdę pozwolę, aby SQL Server przejął kontrolę?
Może. Moje zalecenie dotyczące tej funkcji początkowo wymaga podejścia „zaufaj, ale weryfikuj”.
Podobnie jak w przypadku automatycznej korekty planów, automatyczne zarządzanie indeksami zostało opracowane przy użyciu znacznej ilości danych przechwyconych z prawie dwóch milionów baz danych Azure SQL Database. Funkcja automatycznego zarządzania indeksami jest dostępna w Azure SQL Database od pierwszego kwartału 2016 r. w ramach usługi Index Advisor.
Algorytmy używane przez tę funkcję ewoluowały i ewoluują w czasie, ponieważ korzysta z niej coraz więcej baz danych, a coraz więcej danych jest przechwytywanych i analizowanych. Jednak obecnie istnieją pewne ograniczenia.
- Zalecenia dotyczące indeksów nie są oceniane w odniesieniu do istniejących indeksów, dlatego konsolidacja indeksów między nowymi i istniejącymi indeksami nie jest obecnie dostępna.
- Jeśli indeks przyniósłby korzyści dla SELECT, narzut związany z modyfikacjami spowodowanymi INSERT, UPDATE i DELETE nie jest znany przed utworzeniem. SQL Server monitoruje to obciążenie podczas procesu weryfikacji, po zaimplementowaniu indeksu.
Są zalety automatycznego zarządzania indeksami, o których warto wspomnieć:
- Dla każdego, kto musi zarządzać bazą danych SQL Server, ale nie jest administratorem baz danych, zalecenia dotyczące indeksów mogą być niezwykle pomocne.
- Zalecenia dotyczące indeksów są przechwytywane w DMV sys.dm_db_tuning_recommendations, nawet jeśli opcje indeksu CREATE i DROP nie są włączone. Dlatego jeśli nie masz pewności, jakie zmiany może wprowadzić program SQL Server, możesz przejrzeć, co jest przechwycone w DMV, a następnie podjąć decyzję o ręcznym wdrożeniu zalecenia.
Uwaga:W przypadku ręcznego wdrożenia zalecenia SQL Server nie przeprowadza żadnej weryfikacji. Jeśli zaimplementujesz rekomendację przez Portal (przy użyciu przycisku Apply) lub REST API, to zostanie ona wykonana tak, jakby była to akcja automatyczna i zostanie przeprowadzona walidacja (a indeks może zostać automatycznie odwrócony w przypadku regresji).
- Funkcja nadal się poprawia. Jak powiedziałem wcześniej, Microsoft nie próbuje kodować administratorów baz danych ani programistów bez pracy, ale stara się zająć nisko wiszący owoc, aby mieć więcej czasu na zadania i projekty, których nie można inteligentnie zautomatyzować.
Podsumowanie
Jeśli nie jesteś gotowy, by oddać wodze w zarządzaniu indeksami, rozumiem. Ale jeśli masz co najmniej bazę danych SQL Azure, powinieneś regularnie sprawdzać DMV sys.dm_db_tuning_recommendations, aby zobaczyć, co jest zalecane przez program SQL Server, i porównać to z danymi, które Ty lub narzędzie do monitorowania innej firmy może przechwytywać na temat użycia indeksu. W końcu, kiedy ostatni raz wykonałeś pełny i dokładny przegląd swoich indeksów, aby zrozumieć, czego brakuje, co jest naprawdę używane, a co po prostu generuje narzut w bazie danych?
