W moim poprzednim artykule o systemowych bazach danych SQL Server dowiedzieliśmy się o każdej systemowej bazie danych, która jest częścią instalacji SQL Server. Obecny artykuł skupi się na często napotykanych problemach związanych z bazą danych tempdb i sposobach ich prawidłowego rozwiązywania.
Baza danych tymczasowych serwera SQL
Jak wskazuje nazwa tej systemowej bazy danych, tempdb przechowuje obiekty tymczasowe stworzony przez SQL Server. Odnoszą się one do kilku operacji i działają jako globalny obszar roboczy dla wszystkich użytkowników łączących się z instancjami SQL Server.
Baza danych Tempdb będzie przechowywać poniższe typy obiektów, podczas gdy użytkownicy wykonują swoje operacje:
- Obiekty tymczasowe są tworzone jawnie przez użytkowników. Mogą to być lokalne lub globalne tabele tymczasowe i indeksy, zmienne tabel, tabele używane w funkcjach o wartościach przechowywanych w tabeli i kursory.
- Obiekty wewnętrzne utworzone przez silnik bazy danych, takie jak
- Tabele robocze przechowujące wyniki pośrednie dla buforowania, kursorów, sortowania i tymczasowych dużych obiektów (LOB).
- Pliki robocze podczas wykonywania operacji agregujących Hash Join lub Hash.
- Wyniki sortowania pośredniego podczas tworzenia lub odbudowywania indeksów, jeśli opcja SORT_IN_TEMPDB jest ustawiona na ON i innych operacji, takich jak zapytania GROUP BY, ORDER BY lub SQL UNION.
- Sklepy wersji, które obsługują funkcję wersjonowania wierszy, albo magazyn wersji wspólnej, albo magazyn wersji kompilacji indeksu online, używają plików bazy danych tempdb.
Baza danych Tempdb jest tworzona przy każdym uruchomieniu usługi SQL Server. W związku z tym czas utworzenia bazy danych tempdb można uznać za przybliżony czas uruchamiania usługi SQL Server. Możemy go zidentyfikować z sys.databases DMV używając zapytania pokazanego poniżej:
SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'
Jednak faktyczne uruchomienie usługi SQL Server Service obejmuje uruchamianie wszystkich systemowych baz danych w określonej kolejności. Może się to zdarzyć nieco wcześniej niż czas tworzenia tempdb. Wartość możemy uzyskać za pomocą sys.databases DMV wykonując poniższe zapytanie na sys.dm_os_sys_info DMV .
SELECT ms_ticks, sqlserver_start_time_ms_ticks, sqlserver_start_time
FROM sys.dm_os_sys_info
ms_ticks kolumna określa liczbę milisekund od uruchomienia komputera lub serwera. sqlserver_start_time_ms_ticks kolumna określa liczbę milisekund od ms_ticks numer, kiedy usługa SQL Server została uruchomiona.
Więcej informacji na temat kolejności baz danych, które zostały uruchomione podczas uruchamiania usług SQL Server, można znaleźć w dzienniku błędów SQL Server.
W SSMS rozwiń Zarządzanie > Dzienniki błędów serwera SQL > otwórz bieżący dziennik błędów. Zastosuj Rozpoczęcie w górę bazy danych filtruj i kliknij Data aby posortować w porządku rosnącym:
Widzimy, że główna baza danych została uruchomiona jako pierwsza podczas uruchamiania usługi SQL Server. Następnie podążyły wszystkie bazy danych użytkowników i wszystkie inne bazy danych systemu. Wreszcie uruchomiono tempdb. Możesz także pobrać te informacje programowo, wykonując xp_readerrorlog procedura systemowa:
Uwaga :Oba powyższe podejścia mogą nie pokazywać niezbędnych informacji, jeśli usługa SQL Server nie została niedawno ponownie uruchomiona, a dziennik błędów programu SQL Server został odzyskany, co mogło spowodować wypchnięcie starszych dzienników błędów do starszych plików. W takim przypadku może być konieczne przeskanowanie danych w plikach dziennika błędów zarchiwizowanego serwera SQL.
Często napotykane problemy w bazie danych SQL TempDB
Ponieważ tempdb zapewnia globalny obszar roboczy dla wszystkich sesji lub działań użytkownika, może stać się wąskim gardłem wydajności dla operacji użytkownika, jeśli nie zostanie dokładnie skonfigurowany. W moim poprzednim artykule omówiliśmy zalecane najlepsze praktyki do wdrożenia w bazie danych tempdb. Jednak nawet po ich wdrożeniu możemy często napotykać problemy:
- Nierównomierny wzrost plików w plikach danych tempdb.
- Pliki danych Tempdb osiągają ogromną wartość i wymagają zmniejszenia Tempdb.
Nierównomierny wzrost plików w plikach danych TempDB
Począwszy od SQL Server 2000, domyślnym zaleceniem jest posiadanie wielu plików danych w oparciu o liczbę rdzeni logicznych dostępnych na serwerze.
Gdy mamy wiele plików danych, na przykład 4 pliki danych tempdb, jak na poniższym obrazku, autorozrost plików danych tempdb nastąpi o 64 MB w trybie round-robin, zaczynając od tempdev> temp2> temp3> temp4> tempdev> i tak dalej.
Jeśli z jakiegoś powodu jeden z rozmiarów plików nie może się automatycznie zwiększyć, spowoduje to ogromne rozmiary niektórych plików w porównaniu z innymi plikami. Prowadzi to do dodatkowego przeciążenia dużych plików i negatywnego wpływu na wydajność bazy danych tempdb.
Musimy ręcznie upewnić się, że wszystkie pliki danych tempdb mają równomierny rozmiar w dowolnym momencie, aby uniknąć rywalizacji lub problemów z wydajnością do SQL Server 2014. Microsoft zmienił to zachowanie, zaczynając od SQL Server 2016 i nowszych wersji, wdrażając kilka funkcji, które zostaną omówione w dalszej części tego artykułu.
Aby przezwyciężyć powyższe problemy z wydajnością, SQL Server wprowadził 2 flagi śledzenia o nazwie 1117 i 1118 aby uniknąć problemów z sporami wokół tempdb.
- Flaga śledzenia 1117 – umożliwia automatyczny wzrost wszystkich plików w jednej grupie plików
- Flaga śledzenia 1118 – włącza UNIFORM FULL EXTENTS dla tempdb
Flaga śledzenia 1117
Bez włączonej flagi śledzenia 1117 zawsze, gdy baza danych tempdb jest skonfigurowana z wieloma plikami danych o równych rozmiarach, a pliki danych muszą być automatycznie powiększane, program SQL Server domyślnie spróbuje zwiększyć rozmiary plików w sposób okrężny, jeśli wszystkie pliki. Jeśli pliki danych nie mają równomiernego rozmiaru, SQL Server spróbuje zwiększyć rozmiar największego pliku danych tempdb i użyje tego większego pliku do większości operacji użytkownika, co spowoduje problemy z rywalizacją o tempdb.
Aby rozwiązać ten problem, w programie SQL Server wprowadzono flagę śledzenia 1117. Po włączeniu, jeśli jeden plik w grupie plików musi automatycznie rosnąć, będzie automatycznie zwiększać wszystkie pliki w tej grupie plików. Rozwiązuje problemy z rywalizacją o tempdb. Jednak haczyk polega na tym, że po włączeniu flagi Trace 1117 automatyczny wzrost jest również konfigurowany dla wszystkich baz danych użytkowników.
Flaga śledzenia 1118
Flaga śledzenia 1118 służy do włączania JEDNOLITEGO PEŁNEGO ZAKRESU. Cofnijmy się, aby zrozumieć, w jaki sposób SQL Server przechowuje dane z wersji basic.
Strona jest podstawową jednostką pamięci w SQL Server o rozmiarze 8 kilobajtów (KB).
Zakres to zestaw 8 przylegających fizycznie stron o rozmiarze 64KB(8*8KB). W oparciu o liczbę obiektów lub właścicieli przechowujących dane w zakresie, zakres można podzielić na:
- Jednolity zakres to 8 sąsiadujących stron używanych lub dostępnych dla jednego obiektu lub właściciela;
- Mieszane Zakresy – czy 8 sąsiednich stron jest używanych lub do których uzyskuje dostęp co najmniej 2 i maksymalnie 8 obiektów lub właścicieli
Włączenie flagi śledzenia 1118 pozwoli tempdb na ujednolicenie zakresu, co zapewni lepszą wydajność.
Jak włączyć flagi śledzenia 1117 i 1118
Flagi śledzenia można włączyć na kilka sposobów. Możesz zdefiniować odpowiedni sposób z poniższych opcji:
Parametry uruchamiania usługi SQL Server
Stale dostępne nawet po ponownym uruchomieniu usługi SQL Service. Zalecany sposób to włączenie flag śledzenia 1117 i 1118 za pomocą parametrów uruchamiania usługi SQL Server .
Otwórz Menedżera konfiguracji serwera SQL i kliknij Usługi serwera SQL aby wyświetlić listę dostępnych usług na tym serwerze:
- Kliknij prawym przyciskiem myszy SQL Server (MSSQLSERVER) > Właściwości > Parametry uruchamiania .
- Wpisz –T w puste pole, aby wskazać Flagę śledzenia .
- Podaj wartości 1117 i 1118 jak pokazano poniżej.
- Kliknij Dodaj aby dodać flagi śledzenia jako parametry startowe.
Następnie kliknij OK aby na stałe dodać flagi śledzenia dla tego wystąpienia programu SQL Server. Uruchom ponownie usługę SQL Server, aby zmiany zostały odzwierciedlone.
DBCC TRACEON (, -1)
Włącz globalnie flagę śledzenia. Usługa SQL Server utraci flagi śledzenia po ponownym uruchomieniu usługi. Aby włączyć flagę śledzenia globalnie, wykonaj poniższy skrypt w nowym oknie zapytania:
DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);
DBCC TRACEON ()
Włącz flagę śledzenia na poziomie sesji. Dotyczy tylko bieżącej sesji utworzonej przez użytkownika. Aby włączyć flagę śledzenia na poziomie sesji, wykonaj poniższy skrypt w nowym oknie zapytania:
DBCC TRACEON(1117);
DBCC TRACEON(1118);
Aby wyświetlić listę flag śledzenia włączonych w wystąpieniu SQL Server, możemy użyć DBCC TRACESTATUS polecenie:
DBCC TRACESTATUS();
Jak widać, Flagi śledzenia 1117 i 1118 są włączone globalnie w mojej instancji wraz z sesją .
Aby wyłączyć flagę śledzenia, możemy użyć polecenia DBCC TRACEOFF, takiego jak:
DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);
Rozszerzenia bazy danych SQL Server 2016 TempDB
W wersjach SQL Server od SQL Server 2000 do SQL Server 2014 musimy włączyć flagi śledzenia 1117 i 1118 wraz z pełnym monitorowaniem bazy danych tempdb, aby uniknąć problemów z rywalizacją o tempdb. Począwszy od SQL Server 2016 i nowszych wersji, flagi śledzenia 1117 i 1118 są domyślnie implementowane.
Jednak na podstawie moich osobistych doświadczeń lepiej jest wstępnie rozbudować tempdb do ogromnych rozmiarów, aby uniknąć konieczności wielokrotnego autowzrostu i wyeliminować nierówne rozmiary plików lub pojedyncze pliki, które są intensywnie używane przez SQL Server .
Możemy zweryfikować, jak Trace Flag 1117 i 1118 są zaimplementowane w SQL Server 2016:
Flaga śledzenia 1117 który ustawia autorozrost wszystkich plików w grupie plików jest teraz właściwością grupy plików . Możemy to skonfigurować podczas tworzenia nowej grupy plików lub modyfikowania istniejącej.
Aby sprawdzić właściwość automatycznego powiększania grupy plików , uruchom poniższy skrypt z sys.filegroups DMV :
SELECT name Filegroup_Name, is_autogrow_all_files
FROM sys.filegroups
Aby zmodyfikować właściwość automatycznego wzrostu podstawowej grupy plików bazy danych AdventureWorks , wykonujemy poniższy skrypt albo z AUTOGROW_ALL_FILES, aby automatycznie powiększać wszystkie pliki równomiernie, albo z AUTOGROW_SINGLE_FILE, aby umożliwić automatyczny wzrost tylko jednego pliku danych.
ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE
-- AUTOGROW_ALL_FILES is the default behavior
GO
Flaga śledzenia 1118 która ustawia właściwość Jednolity zakres plików danych jest domyślnie włączona dla tempdb i wszystkich baz danych użytkowników, począwszy od SQL Server 2016 . Nie możemy zmienić właściwości tempdb, ponieważ teraz obsługuje tylko opcję Uniform Extent.
W przypadku baz danych użytkowników możemy zmodyfikować ten parametr. System baz danych, model i msdb obsługują domyślnie zakresy mieszane i nie można ich również zmienić.
Aby zmodyfikować wartości właściwości alokacji stron mieszanych dla baz danych użytkowników, użyj poniższego skryptu:
ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON
-- OFF is the default behavior
GO
Aby zweryfikować właściwość mieszanej alokacji stron, możemy wysłać zapytanie do is_mixed_page_allocation_on kolumna z sys.databases DMV z wartością 0, wskazującą jednolitą alokację stron z zakresem, a 1, aby wskazać alokację stron z mieszanym zakresem.
SELECT name, is_mixed_page_allocation_on
FROM sys.databases
Pliki danych TempDB rosną do ogromnej wartości wymagającej zmniejszania tempDB
W SQL Server 2014 lub wcześniejszych wersjach, jeśli flagi śledzenia 1117 i 1118 nie są poprawnie skonfigurowane wraz z wieloma plikami danych utworzonymi dla bazy danych tempdb, niektóre z tych plików nieuchronnie urosną. Jeśli tak się stanie, administrator baz danych zwykle próbuje zmniejszyć pliki danych tempdb. Ale jest to niewłaściwe podejście do obsługi tego scenariusza.
Dostępne są inne opcje zmniejszania tempdb.
Rozważmy polecenia DBCC dostępne dla Shrink tempdb i wpływ wykonywania tych operacji.
DBCC SHRINKDATABASE
DBCC SHRINKDATABASE polecenie konsoli działa przez zmniejszenie końca plików Data\Log .
Aby skutecznie zmniejszyć bazę danych, polecenie potrzebuje wolnego miejsca na końcu pliku. Jeśli na końcu pliku są jakieś aktywne transakcje, pliki bazy danych nie mogą zostać skurczone.
Wpływ wykonania DBCC SHRINKDATABASE polega na tym, że spróbuje wyczyścić dostępne wolne miejsce na końcu każdego pliku danych lub pliku dziennika, które mogło zostać zarezerwowane na przyszły wzrost danych tabeli. Dlatego uruchomienie tego polecenia może spowodować nierówne rozmiary plików, prowadzące do problemów z rywalizacją o tempdb.
Składnia zmniejszająca bazę danych użytkowników, na przykład bazę Adventureworks, byłaby
DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);plik DBCC SHRINKFILE
plik DBCC SHRINKFILE polecenie konsoli działa podobnie do DBCC SHRINKDATABASE, ale zmniejsza określone pliki danych lub dzienników bazy danych .
Jeśli stwierdzisz, że określony plik danych tempdb jest ogromny, możemy spróbować zmniejszyć ten konkretny element za pomocą DBCC SHRINKFILE, jak pokazano poniżej.
Zachowaj ostrożność podczas używania tego polecenia w tempdb, ponieważ jeśli plik zostanie zmniejszony do wartości niższej lub wyższej niż inne pliki danych, ten konkretny plik danych nie będzie efektywnie używany. Lub będzie używany częściej, co prowadzi do problemów z rywalizacją o tempdb.
Składnia do wykonania operacji DBCC SHRINKFILE na pliku danych AdventureWorks do 1 GB (1024 MB) będzie następująca:
DBCC SHRINKFILE (AdventureWorks, 1024);
GO
DBCC DROPCLEANBUFFERS
DBCC DROPCLEANBUFFERS Polecenie konsoli służy do wyczyszczenia wszystkich czystych buforów z puli buforów i obiektów magazynu kolumn z puli obiektów magazynu kolumn .
Po prostu wykonaj poniższe polecenie:
DBCC DROPCLEANBUFFERSDBCC FREEPROCCACHE
DBCC FREEPROCCACHE polecenie czyści całą pamięć podręczną planu wykonania procedury składowanej .
Pamięć podręczna planu wykonywania procedur jest używana przez SQL Server do szybszego wykonywania tych samych wywołań procedur. Po wykonaniu polecenia DBCC FREEPROCCACHE pamięć podręczna planów jest czyszczona. W związku z tym SQL Server musi ponownie utworzyć tę pamięć podręczną, gdy procedura składowana jest wykonywana w instancji. Pozostawia poważny negatywny wpływ, gdy jest wykonywany w instancjach Production DB.
Nie zaleca się wykonywania DBCC FREEPROCCACHE na produkcyjnej instancji bazy danych!
Składnia do wykonania DBCC FREEPROCCACHE jest poniżej:
DBCC FREEPROCCACHEDBCC FREESESSIONCACHE
DBCC FREESESSIONCACHE polecenie czyści pamięć podręczną połączenia zapytania dystrybucji z instancji SQL Server . Będzie to pomocne, gdy na konkretnej instancji SQL Server wykonywanych jest wiele zapytań rozproszonych.
Składnia do wykonania DBCC FREESESSIONCACHE to:
DBCC FREESESSIONCACHEDBCC FREESYSTEMCACHE
DBCC FREESYSTEMCACHE polecenie usuwa wszystkie nieużywane wpisy w pamięci podręcznej z całej pamięci podręcznej . SQL Server robi to domyślnie, aby udostępnić więcej pamięci dla nowych operacji. Możemy jednak wykonać go ręcznie za pomocą poniższego polecenia:
DBCC FREESYSTEMCACHEJak wiemy, tempdb przechowuje wszystkie tymczasowe obiekty użytkownika lub obiekty wewnętrzne, w tym pamięć podręczną planu wykonania, dane puli buforów, pamięci podręczne sesji i pamięci podręczne systemu. Dlatego wykonanie powyższych 6 poleceń DBCC pomoże usunąć pliki danych tempdb, które uniemożliwiają normalny proces zmniejszania.
Mimo że przeszliśmy przez kroki, jak zmniejszyć tempdb za pomocą różnych podejść, zalecane najlepsze praktyki dotyczące bazy danych tempdb są wymienione poniżej:
a. Jeśli to możliwe, uruchom ponownie usługi SQL Server, aby równomiernie odtworzyć pliki danych tempdb. Potencjalny wpływ byłby taki, że stracimy wszystkie plany wykonania i inne informacje o pamięci podręcznej omówione powyżej.
b. Wstępnie powiększaj pliki danych tempdb do ogromnego rozmiaru dostępnego na dysku zawierającym pliki danych tempdb. Zapobiegnie to nierównomiernemu zwiększaniu rozmiarów plików przez SQL Server w wersjach SQL Server 2014 i wcześniejszych.
c. Jeśli nie można ponownie uruchomić usług SQL Server z powodu RTO lub RPO, wypróbuj powyższe polecenia DBCC po dokładnym zrozumieniu wpływu.
d. Zmniejszanie bazy danych tempdb lub plików danych nie jest zalecanym podejściem, dlatego nigdy nie rób tego w środowisku produkcyjnym, chyba że nie ma innych opcji.
Wniosek
Dowiedzieliśmy się więcej o wewnętrznych elementach działania tempdb, dzięki czemu możemy skonfigurować tempdb w celu uzyskania lepszej wydajności, unikając problemów z rywalizacją w tempdb. Przejrzeliśmy również często napotykane problemy w tempdb, środki dostępne w SQL Server w różnych wersjach oraz sposoby skutecznego radzenia sobie z nimi. Oprócz tego zbadaliśmy, dlaczego zmniejszanie bazy danych tempdb lub plików danych nie jest zalecanym podejściem podczas pracy z bazą danych tempdb.
