Tempdb to systemowa baza danych SQL Servera, która służy jako globalny obszar roboczy dla wszystkich użytkowników instancji — przechowuje tabele tymczasowe, zmienne tabelaryczne, wyniki pośrednie sortowań, work tables dla zapytań GROUP BY i hash joinów oraz version stores dla izolacji snapshot. Prawidłowa konfiguracja tempdb jest jednym z trzech najważniejszych czynników wpływających na wydajność całego serwera SQL — obok pamięci RAM i podsystemu dyskowego.
W skrócie
- Zacznij od jednego pliku danych na każdy procesor logiczny, maksymalnie 8 — to standard Microsoftu od SQL Server 2016
- Wszystkie pliki danych tempdb muszą mieć identyczny rozmiar początkowy i parametry autogrow — proporcjonalny algorytm fill faworyzuje pliki z większą ilością wolnego miejsca
- Prealokuj przestrzeń od razu do rozmiaru docelowego zamiast polegać na autogrow — każdy autogrow to kosztowna operacja blokująca alokacje
- Włącz Instant File Initialization (IFI) — bez niego każdy autogrow pliku danych zeruje przydzielone strony, co może trwać sekundy lub minuty
- Umieść pliki tempdb na najszybszym dostępnym podsystemie dyskowym (NVMe/SSD), najlepiej na osobnych dyskach niż bazy użytkowników
- SQL Server 2025 wprowadza ADR w tempdb (natychmiastowy rollback) oraz tempdb space resource governance — limity przestrzeni per workload
- Memory-optimized tempdb metadata (od SQL 2019) eliminuje contention na metadanych tymczasowych obiektów — włącz, gdy diagnostyka wykaże PAGELATCH_UP na system tables tempdb
- Trace flagi 1117 i 1118 nie są już potrzebne od SQL Server 2016 — zachowanie to jest teraz domyślne
Czym jest tempdb i dlaczego jej konfiguracja ma znaczenie
Tempdb to baza systemowa obecna w każdej instancji SQL Servera, odtwarzana od nowa przy każdym restarcie serwera. Jest współdzielona przez wszystkie bazy użytkownika na danej instancji — nie ma osobnej tempdb per baza (poza Azure SQL Database, gdzie każda baza ma własną). Jej wydajność bezpośrednio przekłada się na responsywność całego serwera.
W tempdb przechowywane są trzy kategorie obiektów:
| Kategoria | Przykłady |
|---|---|
| Obiekty użytkownika | Tabele tymczasowe (#tmp, ##tmp), indeksy na nich, zmienne tabelaryczne, kursory, procedury tymczasowe |
| Obiekty wewnętrzne | Work tables dla sortów, buforów, spooli; work files dla hash join/hash aggregate; pośrednie wyniki przebudowy indeksów z SORT_IN_TEMPDB |
| Version stores | Wersje wierszy dla READ COMMITTED SNAPSHOT, SNAPSHOT ISOLATION, online index rebuild, MARS, AFTER triggers; od SQL 2025 dodatkowo Persistent Version Store (PVS) gdy ADR włączone |
Każdy obiekt wewnętrzny zużywa minimum 9 stron (IAM + 8-stronicowy extent). Przy tysiącach równoległych zapytań tempdb może rosnąć błyskawicznie — a jeśli zabraknie w niej miejsca, cała instancja przestaje działać.
Ile plików danych tempdb potrzebujesz
Reguła Microsoftu, obowiązująca od SQL Server 2016:
- ≤ 8 procesorów logicznych: tyle samo plików danych co procesorów
- > 8 procesorów logicznych: zacznij od 8 plików danych
- Jeśli contention (
PAGELATCH_UPna stronach PFS/GAM/SGAM) nadal występuje — dodawaj pliki w grupach po 4, aż contention spadnie lub osiągniesz liczbę równą procesorom logicznym
Dlaczego to działa: każdy plik danych ma własne strony GAM (Global Allocation Map), SGAM (Shared GAM) i PFS (Page Free Space). Przy jednym pliku wszystkie alokacje walczą o te same strony metadanych. Przy 8 plikach każdy ma własny zestaw — contention rozkłada się na 8 niezależnych ścieżek.
Rozmiar początkowy i autogrow — kluczowe zasady
Wszystkie pliki danych tempdb muszą mieć identyczny rozmiar początkowy i te same ustawienia autogrow. SQL Server używa algorytmu proportional fill — przydziela extenty z pliku, który ma proporcjonalnie najwięcej wolnego miejsca. Jeśli jeden plik jest większy od pozostałych, dostanie nieproporcjonalnie dużo alokacji, tworząc hot spot i marnując sens posiadania wielu plików.
Zalecane parametry:
| Parametr | Zalecenie |
|---|---|
| Rozmiar początkowy | Ustal na podstawie testów obciążenia — prealokuj rozmiar docelowy, nie polegaj na autogrow |
| Przyrost autogrow (dane) | 64–512 MB (stała wartość w MB, nie procent) — dla wszystkich plików identyczny |
| Przyrost autogrow (log) | 64–256 MB (maks. 64 MB korzysta z IFI od SQL 2022) |
| Maksymalny rozmiar | Ograniczony tylko przestrzenią dyskową — nie ustawiaj MAXSIZE dla tempdb, chyba że używasz Resource Governor (SQL 2025) |
Prealokacja jest krytyczna: każdy autogrow pliku danych wymaga wyzerowania nowych stron, chyba że włączone jest Instant File Initialization (IFI). Bez IFI przyrost o 512 MB może zająć kilka sekund — w tym czasie wszystkie alokacje w tym pliku są wstrzymane. Przy pliku logu IFI nie działa (do SQL 2022, gdzie wprowadzono IFI dla przyrostów logu do 64 MB).
Umiejscowienie plików tempdb na dyskach
Hierarchia wydajności:
- NVMe SSD (PCIe 4.0/5.0) — preferowane, szczególnie dla obciążeń OLTP z tysiącami tymczasowych tabel
- Enterprise SSD (SATA/SAS) — akceptowalne dla mniejszych obciążeń
- HDD — absolutnie niezalecane; tempdb na HDD to gwarancja bottlenecku
Jeśli występuje I/O contention między tempdb a bazami użytkownika, umieść tempdb na osobnym wolumenie dyskowym. Nie musisz rozdzielać poszczególnych plików danych tempdb na osobne dyski, chyba że widzisz kolejki I/O na poziomie dysku (PerfMon: PhysicalDisk\Avg. Disk Queue Length > 2).
Konfiguracja tempdb według wersji SQL Server
| Funkcja / zalecenie | SQL 2014 i starsze | SQL 2016–2017 | SQL 2019 | SQL 2022 | SQL 2025 |
|---|---|---|---|---|---|
| Wiele plików danych (auto podczas instalacji) | ❌ Ręcznie | ✅ Setup dodaje do 8 | ✅ | ✅ | ✅ |
| Uniform extents (odpowiednik TF 1118) | ❌ Wymaga TF 1118 | ✅ Domyślnie | ✅ | ✅ | ✅ |
| Autogrow wszystkich plików razem (TF 1117) | ❌ Wymaga TF 1117 | ✅ Domyślnie | ✅ | ✅ | ✅ |
| Concurrent PFS updates | ❌ | ❌ | ✅ | ✅ | ✅ |
| Memory-optimized tempdb metadata | ❌ | ❌ | ✅ (opcjonalnie) | ✅ | ✅ |
| System page latch concurrency (GAM/SGAM) | ❌ | ❌ | ❌ | ✅ | ✅ |
| ADR w tempdb (instant rollback) | ❌ | ❌ | ❌ | ❌ | ✅ |
| Tempdb space resource governance | ❌ | ❌ | ❌ | ❌ | ✅ |
| IFI dla pliku logu (do 64 MB) | ❌ | ❌ | ❌ | ✅ | ✅ |
| ZSTD backup compression | ❌ | ❌ | ❌ | ❌ | ✅ |
Monitorowanie tempdb — na co patrzeć
Najważniejsze zapytanie diagnostyczne — przestrzeń w tempdb:
SELECT
SUM(unallocated_extent_page_count) * 8.0 / 1024 AS tempdb_free_mb,
SUM(version_store_reserved_page_count) * 8.0 / 1024 AS version_store_mb,
SUM(internal_object_reserved_page_count) * 8.0 / 1024 AS internal_objects_mb,
SUM(user_object_reserved_page_count) * 8.0 / 1024 AS user_objects_mb
FROM tempdb.sys.dm_db_file_space_usage;
Sprawdzenie contention — jeśli widzisz wiele sesji z PAGELATCH_UP na stronach tempdb (szczególnie 2:1:1, 2:1:3 — strony PFS i SGAM), potrzebujesz więcej plików danych:
SELECT session_id, wait_type, wait_resource
FROM sys.dm_exec_requests
WHERE wait_type LIKE 'PAGELATCH%' AND wait_resource LIKE '2:%';
Dla SQL Server 2019+: sprawdź, czy warto włączyć memory-optimized tempdb metadata:
SELECT OBJECT_NAME(dpi.object_id, dpi.database_id) AS system_table,
COUNT(DISTINCT r.session_id) AS sessions_contending
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.fn_PageResCracker(r.page_resource) AS prc
CROSS APPLY sys.dm_db_page_info(prc.db_id, prc.file_id, prc.page_id, 'LIMITED') AS dpi
WHERE dpi.database_id = 2
AND dpi.object_id IN (3, 9, 34, 40, 41, 54, 55, 60, 74, 75)
AND UPPER(r.wait_type) LIKE N'PAGELATCH[_]%'
GROUP BY dpi.object_id, dpi.database_id;
Jeśli zapytanie zwraca wiersze — masz contention na metadanych obiektów tymczasowych i włączenie memory-optimized tempdb metadata może znacząco pomóc.
SQL Server 2025 — nowości w tempdb
SQL Server 2025 (17.x) wprowadza dwie przełomowe funkcje dla tempdb:
-
Accelerated Database Recovery (ADR) w tempdb — natychmiastowy rollback transakcji i agresywne przycinanie logu dla operacji na tymczasowych tabelach. Eliminuje długie czasy rollbacku przy dużych transakcjach w tempdb. Wymaga restartu instancji do włączenia.
-
Tempdb space resource governance — możliwość nałożenia limitu przestrzeni tempdb dla konkretnych aplikacji lub użytkowników. Zapobiega scenariuszom, w których jedno runaway query konsumuje całą tempdb i wywraca instancję. Konfiguruje się przez Resource Governor.
Ponadto SQL 2025 wprowadza Persistent Version Store (PVS) gdy ADR jest włączone — równoległy, niezależny version store obok tradycyjnego. Należy uwzględnić PVS w planowaniu przestrzeni dyskowej tempdb.
Typowe problemy i rozwiązania
Tempdb rośnie do gigantycznych rozmiarów
Sprawdź, co konsumuje przestrzeń: długotrwałe transakcje z snapshot isolation, niezamknięte kursory, zapytania z ogromnymi sortami/hash joinami, lub przebudowa indeksów z SORT_IN_TEMPDB. Użyj sys.dm_db_session_space_usage aby zidentyfikować winne sesje. Rozważ ALTER INDEX ... REBUILD WITH (SORT_IN_TEMPDB = OFF) dla dużych indeksów.
Autogrow powoduje timeouty
Prealokuj tempdb do rozmiaru docelowego. Włącz Instant File Initialization (dodaj konto usługi SQL Server do polityki Wykonywanie zadań konserwacji woluminu w secpol.msc). Ustaw stały przyrost autogrow w MB, nie w procentach — przyrost procentowy 10% z 50 GB to 5 GB, których wyzerowanie bez IFI może trwać minutę.
Contention PAGELATCH_UP mimo 8 plików
Zwiększ liczbę plików do 12, 16, maksymalnie do liczby procesorów logicznych. W SQL Server 2019+ sprawdź, czy włączenie memory-optimized tempdb metadata rozwiąże problem. Upewnij się, że pliki są identycznego rozmiaru.
Częste pytania
Czy trace flag 1117 i 1118 są nadal potrzebne?
Nie — od SQL Server 2016 oba zachowania są domyślne. Wszystkie alokacje tempdb używają uniform extents (dawniej TF 1118), a wszystkie pliki danych autogrowują razem (dawniej TF 1117). Jeśli nadal masz te trace flagi w parametrach startowych, możesz je bezpiecznie usunąć.
Ile plików danych tempdb ustawić na serwerze z 16 rdzeniami?
Zacznij od 8 plików danych. Jeśli diagnostyka (sys.dm_exec_requests z PAGELATCH_UP na stronach tempdb) wykaże contention, zwiększaj do 12, potem 16. Rzadko kiedy potrzeba więcej niż 16 plików — jeśli contention utrzymuje się przy 16, problem leży prawdopodobnie w kodzie aplikacji (np. masowe tworzenie i usuwanie #tmp w pętli).
Czy tempdb musi być na osobnym dysku?
Nie musi, ale jest to silnie zalecane dla wydajności. Jeśli budżet na to nie pozwala, przynajmniej umieść tempdb na tym samym szybkim wolumenie co bazy użytkowników — nigdy na wolnym HDD. W środowiskach produkcyjnych separacja tempdb od data files baz użytkowników to standard.
Czy memory-optimized tempdb metadata warto włączyć?
Włącz tylko wtedy, gdy diagnostyka wykaże contention na metadanych obiektów tymczasowych (zapytanie diagnostyczne powyżej zwraca wiersze). Włączenie bez potrzeby nie daje korzyści, a wprowadza ograniczenia: brak columnstore na tabelach tymczasowych, limity transakcji między bazami z In-Memory OLTP, oraz wyższe zużycie pamięci przez MEMORYCLERK_XTP. Zaleca się bindowanie tempdb do resource pool z limitem pamięci (np. 20%).
Jak sprawdzić, czy moja tempdb jest poprawnie skonfigurowana?
Uruchom SELECT name, size * 8 / 1024 AS size_mb, growth FROM tempdb.sys.database_files; — sprawdź, czy rozmiar i growth wszystkich plików danych są identyczne. Następnie sprawdź, czy liczba plików danych jest zgodna z regułą (min. liczba procesorów, maks. 8 na start). Na koniec uruchom zapytanie monitorujące contention — jeśli nie ma PAGELATCH_UP na stronach tempdb, konfiguracja jest w dobrej kondycji.
Co nowego w tempdb w SQL Server 2025?
SQL Server 2025 wprowadza ADR w tempdb (natychmiastowy rollback transakcji w tempdb), tempdb space resource governance (limity przestrzeni per workload), Persistent Version Store (PVS) przy włączonym ADR oraz tmpfs support na Linuxie (tempdb w pamięci RAM przez tmpfs). To największa zmiana w architekturze tempdb od wersji 2016.
Czy mogę używać tempdb na tmpfs pod Linuxem?
Tak — SQL Server 2025 oficjalnie wspiera uruchamianie tempdb na tmpfs, czyli w systemie plików w pamięci RAM. Daje to ekstremalnie niskie opóźnienia I/O dla tempdb, ale wymaga odpowiedniej ilości wolnej pamięci RAM — tempdb na tmpfs zużywa RAM bezpośrednio, więc przewymiarowanie może doprowadzić do OOM (out of memory). To konfiguracja dla zaawansowanych administratorów z dokładnym monitoringiem.
Wydajny SQL Server zaczyna się od poprawnie skonfigurowanej tempdb
Nieprawidłowa konfiguracja tempdb — zbyt mało plików danych, brak prealokacji, pominięcie IFI, wolny dysk — to najczęstsza przyczyna niewytłumaczalnych spadków wydajności SQL Servera, szczególnie pod dużym obciążeniem OLTP. Wdrożenie opisanych wyżej praktyk (wielokrotne, równe pliki danych, prealokacja, IFI, szybki podsystem I/O) to inwestycja kilku godzin pracy administratora, która zwraca się natychmiast w postaci stabilnej, przewidywalnej wydajności.
Jeśli planujesz wdrożenie nowej instancji SQL Server 2022 lub 2025 i potrzebujesz legalnej licencji w atrakcyjnej cenie, sprawdź ofertę licencji serwerowych w sklepie KluczeSoft — Licencje Microsoft SQL Server i Windows Server — legalne klucze w modelu resale, zgodne z prawem UE (wyrok UsedSoft). KluczeSoft jest niezależnym sprzedawcą i nie jest powiązany z Microsoft Corporation.