Jak sama nazwa wskazuje, TempDB to tymczasowy obszar roboczy wymagany przez SQL Server do tworzenia i przechowywania obiektów pośrednich i tymczasowych.
TempDB jest istotnym trybem w całym aparacie SQL Server i jako tymczasowa przestrzeń robocza – dane, które przechowuje, mają charakter przejściowy. Innymi słowy, twoja instancja SQL Server odtwarza bazę danych TempDB za każdym razem, gdy jest ponownie uruchamiana – dając sobie czysty notatnik, z którym może pracować.
- obiekty tymczasowe wyzwalane przez żądania użytkownika
- obiekty wymagane przez wewnętrzne procesy systemowe
- informacje o wersji wierszy
Nie trzeba dodawać, że jeśli TempDB nie jest optymalnie skonfigurowany, może to prowadzić do operacyjnych wąskich gardeł i pogorszenia wydajności. Może to sprawić, że będziesz się zastanawiać, dlaczego zapytania ze złożonymi sprzężeniami i operacjami sortowania nie dają wyników tak szybko, jak oczekiwano.
Nie ma łatwego sposobu na uogólnienie najlepszych praktyk dotyczących optymalizacji TempDB, scenariusze są zbyt zróżnicowane, a to, co działa w danej sytuacji, może nie działać w innej. Nawet jeśli baza danych weszła do produkcji, zawsze dobrze jest kontynuować przeglądanie konfiguracji TempDB, aby upewnić się, że jest skonfigurowana tak, jak powinna.
Jednym z najpoważniejszych problemów z wydajnością bazy danych jest rywalizacja o TempDB. Dzieje się tak, gdy wiele zasobów wymaga TempDB, ale jest tylko jeden plik danych TempDB, do którego można uzyskać dostęp.
Rywalizacja o TempDB może powodować poważne problemy z wydajnością i często jest błędnie rozumiana jako normalne blokowanie z powodu blokad bazy danych. Wiele razy jest to faktycznie zatrzaśnięta rywalizacja na stronach alokacji przez współbieżne procesy. Może to prowadzić do wąskich gardeł, ponieważ każdy proces czeka na swoją kolej. Ponieważ kolej nie przychodzi wystarczająco szybko, limit czasu połączenia i procesy muszą zostać cofnięte.
Co dostajesz? Wirtualny korek zablokowanych procesów.
Jak rozwiązać rywalizację o TempDB i zoptymalizować wydajność programu SQL Server? Przyjrzyjmy się podstawom i stamtąd wypracujmy sobie drogę.
Liczba plików danych – Ile powinienem mieć?
Po skonfigurowaniu programu SQL Server i zachowaniu konfiguracji domyślnej masz tylko jeden plik danych dla bazy danych TempDB. Nie zadowalaj się tą konfiguracją.
Jedną z często reklamowanych zasad jest jeden plik danych na rdzeń. Ale zachowaj ostrożność w tym przypadku, jeśli twój serwer ma 12 rdzeni, nie używaj 12 plików danych TempDB, chyba że jest to uzasadnione wymaganiami aplikacji i obciążenia.
Najlepszą opcją, biorąc pod uwagę dzisiejsze konfiguracje sprzętowe, jest rozpoczęcie od 8 podstawowych plików danych o jednakowej wielkości i sprawdzenie, czy problem z rywalizacją został rozwiązany. Idź w górę i w razie potrzeby dodaj więcej czterech plików. Kreator instalacji i konfiguracji programu SQL Server 2016 ma wbudowaną funkcję, która zapewnia wystarczającą liczbę plików danych TempDB, wykrywając liczbę rdzeni procesora i automatycznie tworząc odpowiednią liczbę plików danych TempDB.
Rozmiar ma znaczenie – Jak należy skonfigurować pliki danych pod kątem rozmiaru?
Teraz, gdy omówiliśmy liczbę plików, przyjrzyjmy się zalecanemu rozmiarowi każdego pliku. Domyślny rozmiar to 8 MB, co zapewnia programowi SQL Server łącznie 64 MB miejsca na bazę danych TempDB, co jest niewystarczające dla większości środowisk produkcyjnych. Zachowanie Autowzrostu jest również opcją, ale SQL Server będzie musiał wstrzymać i w razie potrzeby przydzielić więcej miejsca na dysku dla plików TempDB – dodając znaczne obciążenie do SQL Server podczas uruchomienia produkcyjnego.
Zalecaną praktyką jest utrzymywanie plików i początkowego miejsca wymaganego dla każdego pliku na około 80 do 90% woluminu, na którym przechowywana jest baza danych TempDB. 10 do 20% miejsca na dysku pozostaje na pamięć wirtualną systemu operacyjnego.
Innymi słowy, wstępnie dostosuj rozmiar plików danych podczas instalacji lub zmień rozmiar plików w środowisku produkcyjnym. Zapewni to przydzielenie wystarczającej ilości miejsca na dysku dla bazy danych TempDB. W tym momencie zawsze zaleca się pozostawienie włączonej opcji Autogrowth, ale najlepiej jest upewnić się, że SQL Server nie musi zbyt często przydzielać dodatkowego miejsca na dysku w locie.
Ciekawostką jest, że przed SQL Server 2017 nie było możliwe przydzielenie więcej niż 1 GB na plik danych TempDB w momencie instalacji. W najnowszej wersji możliwe jest przydzielenie nawet 256 GB na plik danych TempDB podczas instalacji.
Co prowadzi nas do następnego pytania:
Gdzie mam przechowywać pliki danych TempDB?
Przed SQL Server 2012, w przypadku środowiska klastrowego, TempDB musiała być zlokalizowana na dyskach współużytkowanych przez środowisko klastrowane, takie jak sieć pamięci masowej (SAN). Począwszy od SQL Server 2012, możliwe jest przechowywanie plików danych TempDB w lokalnym magazynie opartym na SSD. Zmniejsza to duży ruch między współużytkowaną siecią SAN a instancją SQL Server.
W większości przypadków najlepszą opcją lokalizacji TempDB jest dedykowany lokalny dysk SSD. Jeśli nie jest to możliwe, utrzymywanie go na oddzielnym woluminie ze wstępnie przydzielonym wystarczającym miejscem na dysku powinno rozwiązać prawdopodobne problemy z wydajnością. Upewnij się, że stale monitorujesz stan dysku, aby odczyty i zapisy na dysku były przeprowadzane na optymalnym poziomie.
W idealnym przypadku nośniki powinny być jak najszybsze, biorąc pod uwagę konfigurację serwera, wymagania aplikacji i, co nie mniej ważne, przydzielony budżet.
Teraz, gdy przyjrzeliśmy się podstawom, spójrzmy na odpowiednie i mile widziane dodatki do różnych dodatków SQL Server po SQL Server 2012.
Co jeszcze jest nowego?
Serwer SQL 2016
Dedykowana karta podczas konfiguracji
- W tej edycji SQL Server ma dedykowaną kartę do konfiguracji TempDB podczas przepływu pracy instalacji
- Kreator instalacji i konfiguracji programu SQL Server 2016 ma wbudowaną funkcję, która zapewnia wystarczającą liczbę plików danych TempDB w momencie instalowania programu SQL Server. Wykrywa liczbę rdzeni procesora i automatycznie tworzy pliki danych TempDB, z zastrzeżeniem maksymalnie 8. Możesz zwiększyć tę liczbę po skonfigurowaniu programu SQL Server.
Natychmiastowa inicjalizacja pliku
- SQL Server musi przydzielić miejsce na dysku dla bazy danych TempDB podczas początkowej konfiguracji, a także gdy rozmiar pliku rośnie w trakcie pracy produkcyjnej. Przydział ten może być możliwy na dwa sposoby. Pierwszym sposobem jest inicjowanie nieużywanego miejsca na dysku przez wpisanie zer przed przydzieleniem miejsca. Drugim sposobem jest natychmiastowe przydzielanie miejsca na pliki na potrzeby wzrostu bazy danych TempDB.
- W pierwszej metodzie SQL Server musi przeprowadzić operację intensywnie korzystającą z dysku, inicjując każdy logiczny klaster dysków. W tej metodzie procesy działające na serwerze, które potrzebują bazy danych TempDB, mogą wymagać oczekiwania, tworząc wąskie gardło.
- Jeśli zamiast tego zdecydujesz się na natychmiastową alokację miejsca na pliki, serwer SQL natychmiast alokuje miejsce na Autowzrost bez inicjowania miejsca na dysku. Zmniejsza to liczbę operacji we/wy na dysku za każdym razem, gdy pojawia się wymóg automatycznego wzrostu, a także zapewnia lepszą przepustowość i wydajność. Chociaż w poprzednich edycjach można było włączyć IFI, był to uciążliwy proces. W tej edycji SQL Server łatwiej jest skonfigurować IFI w czasie konfiguracji serwera.
- Flagi śledzenia 1117 i 1118 są zbędne
Serwer SQL 2017
- Przed SQL Server 2017 nie było możliwe przydzielenie więcej niż 1 GB na plik danych TempDB w czasie instalacji, co oznaczało, że rozmiar pliku TempDB musiał zostać zwiększony po zakończeniu instalacji. W tej wersji możliwe jest przydzielenie nawet 256 GB na plik danych TempDB podczas instalacji.
Monitorowanie bazy danych TempDB
Śledzenie bazy danych TempDB może być trudne. Jak możesz stwierdzić, czy masz rywalizację o TempDB? Co jest przydzielane do obiektów użytkownika, magazynu wersji lub obiektów wewnętrznych? Jak te trendy zmieniają się w czasie? Jakie sesje zużywają TempDB iw jakim stopniu? Spotlight Cloud ułatwia udzielenie odpowiedzi na te pytania. Monitoruje wszystkie aspekty wydajności serwera SQL 24/7 i zapewnia głębokie analityczne przepływy pracy, aby rozwiązać każdy problem z wydajnością. Śledź bazę danych TempDB w czasie i otrzymuj automatyczne porady ekspertów dotyczące konfiguracji.
Jako rozwiązanie SaaS, Spotlight Cloud jest łatwy w konfiguracji i konfiguracji. Zachowuje dane dotyczące wydajności z roku, dając niezrównane wglądy w strojenie. Problemy z wydajnością można rozwiązać w ciągu kilku sekund dzięki analizie przyczyn źródłowych. Nie trać więcej czasu na przekopywanie się przez złożone skrypty — rozpocznij 30-dniowy okres próbny już teraz. Najwyższej klasy monitorowanie wydajności SQL Server rozpoczyna się teraz.
