Tabela globalna tymczasowa

Tabela globalna tymczasowa jest widoczna dla wszystkich sesji i istnieje do zamknięcia ostatniej z nich.

Jak działa globalna tabela tymczasowa w SQL Server

Globalna tabela tymczasowa w Microsoft SQL Server jest obiektem tworzonym w bazie systemowej tempdb i oznaczanym podwójnym znakiem kratki, na przykład ##WspolneDane. W odróżnieniu od lokalnej tabeli tymczasowej zapisanej jako #Dane, jej nazwa może być rozpoznawana przez inne sesje po pomyślnym wykonaniu instrukcji CREATE TABLE. Dzięki temu kilka połączeń z tym samym serwerem SQL może odczytywać i modyfikować wspólny zestaw tymczasowych wierszy.

Przykładowa definicja może wyglądać następująco: CREATE TABLE ##WspolneDane (Id int NOT NULL, Opis nvarchar(200) NULL);. Tabela otrzymuje strukturę, kolumny, typy danych i ewentualne ograniczenia określone w instrukcji. Jest to obiekt tymczasowy, ale nie oznacza to, że jego dane są automatycznie prywatne dla sesji. Właśnie współdzielenie zawartości odróżnia globalną tabelę tymczasową od lokalnej tabeli tymczasowej.

Widoczność, nazwa i cykl życia obiektu

Po utworzeniu globalnej tabeli tymczasowej inne sesje mogą odwoływać się do niej przez tę samą nazwę, o ile tabela nadal istnieje. Sesja może wykonać zapytanie takie jak SELECT * FROM ##WspolneDane;, dodać rekord za pomocą INSERT albo zmienić istniejące dane instrukcją UPDATE. Uprawnienia i blokady nadal obowiązują, dlatego równoczesny dostęp może powodować oczekiwanie na zwolnienie blokady, konflikty aktualizacji lub błędy wynikające z niezgodności struktury danych.

SQL Server usuwa globalną tabelę tymczasową automatycznie wtedy, gdy sesja, która ją utworzyła, zakończy działanie, a inne instrukcje korzystające z tego obiektu przestaną być wykonywane. W praktyce tabela może więc pozostać dostępna przez pewien czas po rozłączeniu twórcy, jeżeli druga sesja ma aktywne odwołanie do obiektu. Można ją także usunąć wcześniej poleceniem DROP TABLE ##WspolneDane, lecz takie działanie kończy dostęp wszystkich sesji i może przerwać zależne zapytania.

Globalna tabela tymczasowa nie jest trwałym elementem schematu aplikacji. Po jej usunięciu albo zakończeniu całego cyklu życia obiektu dane znikają. Nie należy więc używać jej jako zamiennika zwykłej tabeli przeznaczonej do przechowywania informacji pomiędzy uruchomieniami aplikacji. Jeżeli kilka procesów musi wymieniać dane przez dłuższy czas, właściwym miejscem jest tabela trwała z określonym schematem, kluczami i regułami dostępu.

Współbieżność i konsekwencje użycia w zapytaniach

Wspólna widoczność oznacza, że dane zapisane przez jedną sesję mogą być odczytane przez inne sesje. Projektant zapytania musi zatem określić, która sesja odpowiada za utworzenie tabeli, jakie rekordy należą do konkretnego zadania oraz kiedy dane można bezpiecznie usunąć. Bez dodatkowego identyfikatora, na przykład kolumny SessionId albo JobId, jedna sesja może przypadkowo odczytać wiersze przygotowane przez inną sesję.

Globalne tabele tymczasowe są umieszczane w tempdb, dlatego ich operacje obciążają zasoby tej bazy: miejsce na dysku, pamięć podręczną oraz mechanizmy blokowania. Duża liczba operacji INSERT, UPDATE i DELETE może zwiększać aktywność dziennika transakcji tempdb. Indeksy, klucze i ograniczenia można definiować podobnie jak w innych tabelach, ale ich użycie powinno wynikać z rzeczywistego planu zapytań, ponieważ niepotrzebne indeksy zwiększają koszt zapisu.

Podwójna kratka jest częścią nazwy obiektu i należy zachować ją w każdym odwołaniu. Próba utworzenia drugiej globalnej tabeli o tej samej nazwie może zakończyć się błędem, gdy pierwszy obiekt nadal istnieje. Z tego powodu aplikacje wykonujące niezależne zadania często stosują nazwy zawierające rozpoznawalny identyfikator operacji albo tworzą zwykłe tabele tymczasowe, jeśli współdzielenie danych nie jest wymagane. Warto również jawnie wykonać DROP TABLE po zakończeniu pracy, aby skrócić czas zajmowania zasobów i ograniczyć ryzyko kolizji nazw.

Sprawdzanie tabeli w diagnostyce SQL Server

Obecność globalnej tabeli tymczasowej można kontrolować w metadanych tempdb, między innymi przez zapytanie do widoku tempdb.sys.tables. Przykład SELECT name FROM tempdb.sys.tables WHERE name LIKE '##WspolneDane%'; pozwala sprawdzić obiekty, których nazwa zaczyna się od wskazanego prefiksu. SQL Server może wewnętrznie rozszerzać nazwy tabel tymczasowych o dodatkowe znaki, dlatego diagnostyka powinna uwzględniać wyszukiwanie prefiksu, a nie zakładać zawsze identycznej pełnej nazwy.

Podczas analizy problemu należy sprawdzić kolejność utworzenia obiektu, moment zakończenia sesji twórczej, aktywne zapytania oraz blokady w tempdb. Pomocne są widoki dynamiczne SQL Server, takie jak sys.dm_exec_sessions, sys.dm_exec_requests i sys.dm_tran_locks. Jeżeli tabela znika wcześniej, niż przewiduje aplikacja, przyczyną może być rozłączenie właściciela obiektu, jawne usunięcie tabeli albo zakończenie instrukcji korzystającej z obiektu w sposób, którego kod nie uwzględnił. Jeżeli tabela pozostaje długo, warto poszukać aktywnej sesji lub transakcji utrzymującej odwołanie.

W środowisku serwisowym poprawna diagnoza powinna rozróżniać błąd samego SQL Server od błędu logiki aplikacji. Komunikat o nieistniejącej tabeli może oznaczać niewłaściwą kolejność wykonywania poleceń, użycie innej instancji SQL Server, pracę w innym kontekście połączenia albo przedwczesne zakończenie sesji tworzącej obiekt. Z kolei brak oczekiwanych wierszy może wynikać z niezatwierdzonej transakcji, usunięcia danych przez równoległe zadanie lub braku izolacji rekordów należących do poszczególnych operacji.