| Termin | Definicja |
|---|---|
| Query Store a migracja | Query Store po migracji bazy warto wyczyścić, by uniknąć porównywania planów sprzed i po zmianie środowiska. Dlaczego migracja zmienia wartość danych w Query StoreQuery Store to funkcja Microsoft SQL Server zapisująca informacje o zapytaniach, planach wykonania oraz statystykach czasu wykonywania. Dane te są przechowywane razem z bazą danych, dlatego mogą zostać przeniesione podczas odtworzenia kopii zapasowej, migracji plików bazy albo przenoszenia bazy do innej instancji SQL Server. Po migracji Query Store nadal może zawierać plany i statystyki zebrane na poprzedniej instancji, przy wcześniejszej konfiguracji sprzętowej, innym układzie plików, odmiennych ustawieniach pamięci lub innej wersji silnika. Sam fakt przeniesienia bazy nie oznacza, że wcześniejsze dane stają się błędne. Trzeba jednak rozróżnić historię zapytania od warunków, w których zapytanie było wykonywane. Plan uznany wcześniej za szybki mógł powstać przy innej liczbie rdzeni procesora, innym poziomie obciążenia wejścia-wyjścia, innym rozmiarze pamięci podręcznej albo odmiennych statystykach tabel. Jeżeli po migracji te warunki istotnie się zmieniły, bez wyczyszczenia Query Store porównanie wyników sprzed i po migracji może prowadzić do nieprawidłowych wniosków. Kiedy wyczyszczenie Query Store ma uzasadnienieWyczyszczenie całej zawartości Query Store jest uzasadnione wtedy, gdy migracja rozpoczyna nowy okres pomiarowy. Dotyczy to w szczególności przeniesienia bazy na inną instancję, zmian parametrów sprzętowych wpływających na wykonanie zapytań, zmiany konfiguracji pamięci lub podsystemu dyskowego, a także przejścia do innej wersji SQL Server, jeśli po zmianie ma być oceniane zachowanie nowych mechanizmów optymalizatora. Nowy pomiar pozwala traktować pierwsze wykonania po migracji jako dane bazowe dla aktualnego środowiska. W SQL Server administrator może usunąć wszystkie dane Query Store poleceniem Kontrola działania po zmianie środowiskaPrzed czyszczeniem warto zapisać informacje potrzebne do porównania migracji: czas wykonania najważniejszych zapytań, odczyty logiczne, zużycie procesora, liczbę wykonań oraz występujące błędy. Jeżeli Query Store zawiera plan wymuszony dla konkretnego zapytania, należy sprawdzić także wymuszenia planów. Wymuszony plan może nadal wpływać na optymalizację po migracji, a jego pozostawienie może utrudnić ocenę zachowania aktualnego optymalizatora. Historia Query Store i wymuszenia planów są odrębnymi elementami kontroli, dlatego samo zebranie nowych statystyk nie rozwiązuje każdego problemu z odziedziczoną konfiguracją. Po migracji należy potwierdzić, że Query Store jest włączony i przyjmuje nowe dane. Trzeba sprawdzić jego stan, tryb pracy oraz ewentualne komunikaty o przejściu w tryb READ_ONLY z powodu osiągnięcia limitu rozmiaru. Istotne jest również odczekanie na rzeczywiste wykonania analizowanych zapytań, ponieważ pusty lub świeżo wyczyszczony Query Store nie zawiera od razu reprezentatywnego obrazu obciążenia. Pierwsze wyniki należy interpretować razem z aktualnymi planami wykonania, statystykami obiektów i informacjami o obciążeniu instancji. Bezpieczna interpretacja planów po migracji SQL ServerNie każda migracja wymaga automatycznego czyszczenia Query Store. Jeżeli baza została przeniesiona bez istotnej zmiany instancji, parametrów sprzętowych, wersji silnika i warunków pracy, dotychczasowa historia może nadal być przydatna jako punkt odniesienia. W takiej sytuacji lepiej najpierw ocenić, czy dane sprzed migracji opisują porównywalne środowisko. Czyszczenie powinno wynikać z celu pomiaru i różnicy między środowiskami, a nie z samego użycia kopii zapasowej lub zmiany lokalizacji plików. W praktyce po decyzji o wyczyszczeniu Query Store warto oznaczyć moment migracji w dokumentacji i rozpocząć obserwację od ustalonego okresu stabilnej pracy. Należy porównywać zapytania o podobnym obciążeniu, uwzględniać zmiany liczby wierszy i sprawdzać, czy nowe plany nie są skutkiem chwilowego braku aktualnych statystyk. Diagnostyka powinna obejmować także indeksy, parametry połączeń, blokady i konfigurację instancji, ponieważ Query Store rejestruje objawy związane z wykonaniem zapytań, lecz nie zastępuje pełnej analizy przyczyny problemu. |