Udostępnij za pośrednictwem

Wymagania podsystemu we/wy programu Microsoft SQL Server dla bazy danych tempdb

W tym artykule przedstawiono wymagania podsystemu we/wy dla bazy danych tempdb w programie SQL Server.

Oryginalna wersja produktu: Microsoft SQL Server
Oryginalny numer KB: 917047

Podsumowanie

Program Microsoft SQL Server wymaga, aby podsystem we/wy używany do przechowywania baz danych systemu i użytkowników w pełni przestrzegał wymagań dotyczących rejestrowania zapisu i zapisu (WAL) za pośrednictwem określonych podmiotów zabezpieczeń we/wy. Te wymagania są niezbędne do przestrzegania właściwości ACID transakcji: Niepodzielne, Spójne, Izolowane i Trwałe. Szczegółowe informacje o wymaganiach dotyczących zgodności podsystemu we/wy znajdują się w temacie Podstawy we/wy programu SQL Server.

Poniższa lista zawiera krótkie podsumowanie wymagań:

  • Kolejność zapisu musi być zachowana.
  • Spójność zapisu zależnego musi być zachowana.
  • Zapisy muszą być zawsze zabezpieczone w/w stabilnym nośniku.
  • Konieczne jest rozdarte zapobieganie we/wy.

Konserwacja trwałości pozostaje krytyczna dla wszystkich innych baz danych, ale może być złagodzona dla bazy danych tempdb. Poniższa tabela zawiera podsumowanie kilku krytycznych wymagań dotyczących operacji we/wy dla baz danych programu SQL Server.

Wymaganie we/wy Krótki opis System lub użytkownik tempdb
Porządkowanie zapisu

Spójność zapisu zależnego		 Zdolność podsystemu do utrzymania prawidłowej kolejności operacji zapisu. Może to być szczególnie ważne w przypadku rozwiązań dublowania, wymagań dotyczących spójności grup i użycia protokołu WAL programu SQL Server. Wymagania Zalecane
Odczyt po zapisie Możliwość obsługi żądań odczytu podsystemu przy użyciu najnowszego obrazu danych po pomyślnym zakończeniu odczytu. Wymagania Wymagania
Przetrwanie w całej awarii Możliwość pozostania w pełni nienaruszonym (trwałym) danych w przypadku awarii, takiej jak ponowne uruchomienie systemu. Wymagania Nie dotyczy
Rozdarta zapobieganie we/wy Zdolność systemu do unikania dzielenia pojedynczych żądań we/wy. Wymagania Zalecane
Ponowne zapisywanie sektora Sektor można napisać tylko w całości i nie można go przepisać z powodu żądania zapisu w pobliskim sektorze. * Zniechęcony, dozwolony tylko wtedy, gdy transakcyjny * Zniechęcony, dozwolony tylko wtedy, gdy transakcyjny
Dane ze wzmocnionym zabezpieczeniami Oczekiwanie, że po pomyślnym zakończeniu żądania zapisu lub operacji FlushFileBuffers dane zostały zapisane na stabilnym nośniku. Wymagania Nie dotyczy
Wyrównanie i rozmiar sektora fizycznego Program SQL Server przesłuchuje lokalizacje przechowywania danych i plików dziennika. Wszystkie urządzenia są wymagane do obsługi atrybutów sektora, które umożliwiają programowi SQL Server wykonywanie zapisów w granicach wyrównanych do sektora fizycznego i w wielokrotnościach rozmiaru sektora. Wymagania Wymagania

Ponowne zapisy w sektorze transakcyjnym obejmują w pełni zarejestrowane operacje podsystemu zezwalające na pełne przeniesienie, zastąpienie lub wycofanie sektora do oryginalnego obrazu. Przepisy te są zwykle zniechęcane ze względu na dodatkowe nakłady pracy wymagane do wykonywania takich akcji. Przykładem może być defragmentation narzędzie, które przenosi dane pliku. Nie można zastąpić oryginalnego sektora w pliku nową lokalizacją sektora do momentu zabezpieczenia nowego sektora i danych. Ponowne mapowanie sektora musi nastąpić w sposób transakcyjny, tak aby wszelkie awarie, w tym awaria zasilania, spowodowały ponowne ustanowienie oryginalnych danych. Upewnij się, że masz mechanizmy blokowania dostępne podczas tego rodzaju procesu, aby zapobiec nieprawidłowemu dostępowi do danych, tym samym podtrzymując inne dzierżawy operacji we/wy programu SQL Server.

Przetrwanie w całej awarii

Baza danych tempdb jest obszarem tymczasowym dla programu SQL Server i jest odbudowywana przy każdym uruchomieniu programu SQL Server. Inicjowanie zastępuje wszelkie potrzeby, aby dane przetrwały ponowne uruchomienie.

Operacje ponownego zapisywania sektora transakcyjnego

Aby zagwarantować powodzenie procesów odzyskiwania, takich jak wycofywanie i odzyskiwanie po awarii, rekordy dziennika muszą być poprawnie przechowywane na stabilnym nośniku przed zapisaniem strony danych i nie można ich odpisać bez honorowania właściwości transakcyjnych. Wymaga to podsystemu i programu SQL Server do zachowania określonych atrybutów, takich jak porządkowanie zapisu, wyrównanie sektora i rozmiar zapisu oraz inne atrybuty bezpieczeństwa we/wy opisane wcześniej w dokumentach. W przypadku bazy danych tempdb odzyskiwanie awaryjne jest niepotrzebne, ponieważ baza danych jest zawsze inicjowana podczas uruchamiania programu SQL Server. Jednak baza danych tempdb nadal wymaga możliwości wycofania. W związku z tym niektóre atrybuty protokołu WAL mogą być złagodzone.

Lokalizacja magazynu bazy danych tempdb musi działać ściśle zgodnie z ustalonymi protokołami dysków. Na wszystkie sposoby urządzenie, na którym jest przechowywana baza danych tempdb, musi być wyświetlane i działać jako dysk fizyczny zapewniający odczyt po zapisie. Operacje ponownego zapisywania sektora transakcji mogą być dodatkowym wymaganiem dla określonych implementacji. Na przykład program SQL Server nie obsługuje modyfikacji bazy danych przy użyciu kompresji systemu plików NTFS, ponieważ kompresja NTFS może przepisać sektory dziennika, które zostały już zapisane i uznane za wzmocnione. Awaria podczas tego typu ponownego zapisywania może spowodować, że baza danych będzie bezużyteczna, uszkadzając dane, które program SQL Server został już uznany za bezpieczny.

Uwaga 16.

Rozszerzona obsługa lub kompresja programu SQL Server w celu odczytu tylko baz danych i grup plików. Aby uzyskać szczegółowe informacje, zobacz książki programu SQL Server Online.

Operacje ponownego zapisywania sektora transakcyjnego są istotne dla wszystkich baz danych programu SQL Server, które obejmują bazę danych tempdb. Rosnąca różnorodność rozszerzonych technologii magazynowania korzysta z urządzeń i narzędzi, które mogą ponownie pisać dane, które program SQL Server uznaje za bezpieczne. Na przykład niektóre nowe technologie wykonują buforowanie w pamięci lub kompresję danych. Aby uniknąć poważnych uszkodzeń bazy danych, każdy ponowny zapis sektora musi mieć pełną obsługę transakcyjną w taki sposób, aby w przypadku wystąpienia awarii dane zostały wycofane z poprzednich obrazów sektorów. Gwarantuje to, że program SQL Server nigdy nie jest narażony na nieoczekiwaną przerwę lub uszkodzenie danych.

Bazę danych tempdb można umieścić w podsystemach specjalnych, takich jak dyski RAM, stan półprzewodnikowy lub inne szybkie implementacje, których nie można używać w innych bazach danych. Jednak podczas oceny tych opcji należy rozważyć kluczowe czynniki przedstawione w sekcji Więcej informacji .

Uwaga 16.

Dyski lokalne w środowiskach klastra trybu failover są obsługiwane tylko w przypadku implementacji półprzewodnikowych lub szybkich. Dzieje się tak, ponieważ dysk RAM można utworzyć tylko za pośrednictwem obiektu docelowego iSCSI. Ponadto funkcje obiektu docelowego iSCSI i klastra trybu failover nie mogą być używane na tym samym hoście.

Więcej informacji

Podczas oceny lokalizacji magazynu bazy danych tempdb należy dokładnie zbadać kilka czynników. Na przykład użycie bazy danych tempdb obejmuje, ale nie jest ograniczone do pamięci, planu zapytania i decyzji dotyczących operacji we/wy. Odpowiednie dostrajanie i implementacja bazy danych tempdb mogą zwiększyć skalowalność i czas reakcji systemu. W tej sekcji omówiono kluczowe czynniki określania potrzeb magazynu dla bazy danych tempdb.

Podsystemy o dużej szybkości

Na rynku są dostępne różne implementacje podsystemu o dużej szybkości, które zapewniają wymagania dotyczące protokołu podsystemu we/wy programu SQL Server, ale nie zapewniają trwałości nośnika.

Ważne

Zawsze potwierdź u dostawcy produktu, aby zagwarantować pełną zgodność z potrzebami we/wy programu SQL Server.

Dysk RAM jest jednym z typowych przykładów takiej implementacji. Dyski RAM instalują niezbędne sterowniki i umożliwiają wyświetlenie części głównego dysku RAM i działanie jak każdy dysk dołączony do systemu. Wszystkie podsystemy we/wy powinny zapewnić pełną zgodność z wymaganiami we/wy programu SQL Server. Jednak oczywiste jest, że dysk RAM nie jest trwałym nośnikiem. W związku z tym implementacja, taka jak dysk RAM, może być używana tylko jako lokalizacja bazy danych tempdb i nie może być używana dla żadnej innej bazy danych.

Klucze do rozważenia przed wdrożeniem i wdrożeniem

Przed wdrożeniem bazy danych tempdb w tym rodzaju podsystemu należy wziąć pod uwagę różne kwestie. Ta sekcja używa dysku RAM jako podstawy do dyskusji, ale podobne wyniki występują w innych implementacjach o dużej szybkości.

Bezpieczeństwo we/wy

Zgodność odczytu po zapisach z sektora zapisu i transakcji jest wymagana. Nigdy nie wdrażaj programu SQL Server w żadnym systemie, który nie obsługuje w pełni wymagań dotyczących operacji we/wy programu SQL Server, ani nie ryzykujesz uszkodzenia i utraty danych.

Strony już buforowane (podwójna pamięć podręczna RAM)

Tabele tymczasowe są podobne do wszystkich innych tabel w bazie danych. Są one buforowane przez pulę i obsługiwane przez leniwe operacje zapisu. Przechowywanie tymczasowych stron tabeli na dysku RAM powoduje podwójne buforowanie pamięci RAM, jeden w puli i jeden na dysku RAM. Spowoduje to bezpośrednie odjęcie całkowitego możliwego rozmiaru puli i zwykle zmniejsza wydajność programu SQL Server.

Rezygnacja z pamięci RAM

Dysk RAM wyznacza część głównej pamięci RAM, co oznacza nazwa. Dostępnych jest kilka implementacji dysków RAM i pamięci podręcznych plików opartych na pamięci RAM. Niektóre umożliwiają również fizyczne operacje tworzenia kopii zapasowych we/wy. Kluczowym elementem pamięci podręcznej plików opartej na pamięci RAM jest to, że bezpośrednio pobiera pamięć fizyczną, która może być używana przez program SQL Server. Zawsze mają silne dowody na to, że dodanie pamięci podręcznej plików opartej na pamięci RAM poprawia wydajność aplikacji i nie zmniejsza wydajności innych zapytań ani aplikacji.

Dostrajanie najpierw

Aplikacja powinna dostroić się, aby usunąć niepotrzebne i niepożądane sortowanie i skróty, które mogą spowodować użycie bazy danych tempdb. Wiele razy dodanie indeksu może całkowicie usunąć potrzebę sortowania lub skrótu w planie, co prowadzi do optymalnej wydajności bez konieczności korzystania z bazy danych tempdb.

Możliwe punkty korzyści

Korzyści wynikające z umieszczania bazy danych tempdb w systemie o dużej szybkości można określić tylko poprzez rygorystyczne testowanie i pomiary obciążeń aplikacji. Obciążenie musi być dokładnie zbadane pod kątem cech, z których może korzystać baza danych tempdb, a bezpieczeństwo we/wy należy potwierdzić przed wdrożeniem.

Operacje sortowania i skrótu współpracują z menedżerami pamięci programu SQL Server w celu określenia rozmiaru obszaru tymczasowego w pamięci dla każdej operacji sortowania lub skrótu. Gdy tylko dane sortowania lub skrótu przekraczają przydzielony obszar tymczasowy w pamięci, dane mogą być zapisywane w bazie danych tempdb. Ten algorytm został rozszerzony w programie SQL Server, zmniejszając wymagania dotyczące użycia bazy danych tempdb we wcześniejszych wersjach programu SQL Server.

Uwaga

Program SQL Server został zaprojektowany tak, aby uwzględniał poziomy pamięci i bieżące działania zapytań podczas podejmowania decyzji dotyczących planu zapytań obejmujących korzystanie z operacji bazy danych tempdb. W związku z tym wzrost wydajności różni się znacznie w zależności od obciążeń i projektowania aplikacji. Zdecydowanie zalecamy ukończenie testowania z preferowanym rozwiązaniem w celu określenia możliwych korzyści i oceny wymagań dotyczących bezpieczeństwa we/wy przed takim wdrożeniem.

Program SQL Server używa bazy danych tempdb do obsługi różnych działań obejmujących sortowanie, skróty, magazyn wersji wierszy i tabele tymczasowe:

  • Tabele tymczasowe są obsługiwane przez typowe procedury puli dla stron danych i zazwyczaj nie wykazują korzyści z wydajności z implementacji podsystemu specjalnego.
  • Baza danych tempdb jest używana jako obszar tymczasowy dla skrótów i sortowania. Zmniejszenie opóźnienia operacji we/wy dla takich operacji może być korzystne. Należy jednak pamiętać, że dodanie indeksu w celu uniknięcia skrótu lub sortowania może zapewnić podobną korzyść.

Uruchom linie bazowe z bazą danych tempdb i bez bazy danych tempdb przechowywanej w podsystemie o dużej szybkości, aby porównać korzyści. Część testowania powinna zawierać zapytania względem bazy danych użytkownika, które nie obejmują sortowania, skrótów ani tabel tymczasowych, a następnie potwierdzić, że te zapytania nie mają negatywnego wpływu. Podczas oceniania systemu mogą być przydatne następujące wskaźniki wydajności.

Wskaźnik Opis/użycie
Odczyty i zapisy stron Zwiększenie wydajności operacji we/wy bazy danych tempdb może zmienić szybkość odczytu i zapisu stron dla baz danych użytkowników z powodu mniejszego opóźnienia związanego z operacjami we/wy bazy danych tempdb. W przypadku stron bazy danych użytkowników ogólna liczba nie powinna się różnić w zależności od tego samego obciążenia.
Fizyczne odczyty i zapis bajtów w bazie danych tempdb Jeśli przeniesienie bazy danych tempdb na urządzenie, takie jak dysk PAMIĘCI RAM, zwiększa rzeczywiste we/wy bazy danych tempdb, wskazuje, że pamięć zabrana z puli powoduje zwiększenie aktywności bazy danych tempdb. Ten wzorzec jest wskaźnikiem, że oczekiwana długość życia strony stron bazy danych może również mieć negatywny wpływ.
Średnia długość życia strony Spadek średniej długości życia strony może wskazywać na wzrost wymagań fizycznych we/wy dla bazy danych użytkownika. Spadek szybkości może prawdopodobnie wskazywać, że pamięć zabrana z puli zmusza strony bazy danych do przedwczesnego zamknięcia puli. Połącz się z innymi wskaźnikami i przetestuj, aby w pełni zrozumieć granice parametrów.
Ogólna przepływność
Użycie procesora CPU
Skalowalność
Czas odpowiedzi		 Głównym celem zmiany konfiguracji bazy danych tempdb jest zwiększenie ogólnej przepływności. Testowanie powinno obejmować kombinację powtarzalnych obciążeń, które można skalować w poziomie, aby określić wpływ przepływności.

Implementacja dysku RAM oparta na kompresji może działać dobrze z 10 użytkownikami. Jednak w przypadku zwiększonego obciążenia może to spowodować wypchnięcie poziomów procesora CPU poza żądane poziomy i mieć negatywny wpływ na czas odpowiedzi, gdy obciążenia są wysokie. Zachęcamy do przeprowadzania rzeczywistych testów obciążeniowych i przyszłych testów przewidywania obciążenia.
Akcje tworzenia plików roboczych i tabeli roboczej Jeśli przeniesienie bazy danych tempdb na urządzenie, takie jak dysk RAM, zmieni plan zapytania, zwiększając liczbę lub rozmiar plików roboczych lub tabel roboczych, wskazuje, że pamięć zabrana z puli powoduje zwiększenie aktywności bazy danych tempdb. Ten wzorzec wskazuje, że oczekiwana długość życia strony stron bazy danych może również mieć negatywny wpływ.

Przykład ponownego zapisywania sektora transakcyjnego

W poniższym przykładzie przedstawiono zabezpieczenia danych wymagane przez bazy danych programu SQL Server.

Załóżmy, że dostawca dysku RAM używa implementacji kompresji w pamięci. Implementacja musi być poprawnie hermetyzowana przez zapewnienie fizycznego wyglądu strumienia plików, tak jakby sektor był wyrównany i miał rozmiar, więc program SQL Server nie jest świadomy i prawidłowo zabezpieczony przed implementacją podstawową. Przyjrzyj się bliżej przykładowi kompresji.

  • Sektor 1 jest zapisywany na urządzeniu i kompresowany w celu zaoszczędzenia miejsca.
  • Sektor 2 jest zapisywany na urządzeniu i jest kompresowany z sektorem 1, aby zaoszczędzić miejsce.

Urządzenie może wykonać następujące czynności, aby zabezpieczyć dane sektora 1 w połączeniu z danymi sektora 2.

  • Blokuj wszystkie operacje zapisu w sektorach 1 i 2.
  • Nieskompresowany sektor 1 do obszaru tymczasowego, pozostawiając bieżący sektor 1 magazynu jako aktywne dane do pobrania.
  • Kompresuj sektory 1 i 2 do nowego formatu magazynu.
  • Blokuj wszystkie operacje odczytu i zapisu sektorów 1 i 2.
  • Wymiana starego magazynu dla sektorów 1 i 2 z nowym magazynem. Jeśli próba wymiany zakończy się niepowodzeniem (wycofanie):
    • Przywróć oryginalny magazyn dla sektorów 1 i 2.
    • Usuń sektory 1 i 2 połączone dane z obszaru tymczasowego.
    • Niepowodzenie operacji zapisu sektora 2.
  • Odblokuj odczyty i zapisy dla sektorów 1 i 2.

Możliwość zapewnienia mechanizmów blokowania modyfikacji sektora i wycofania zmian, gdy próba wymiany sektora zakończy się niepowodzeniem, jest uznawana za przejściowo zgodną. W przypadku implementacji, które używają magazynu fizycznego do rozszerzonego tworzenia kopii zapasowych, uwzględnia odpowiednie aspekty dziennika transakcji, aby ułatwić zabezpieczanie i wycofywanie zmian zastosowanych do struktur na dysku w celu zachowania integralności plików bazy danych programu SQL Server.

Każde urządzenie, które umożliwia ponowne zapisywanie sektorów, musi obsługiwać ponowne zapisywanie w sposób transakcyjny, aby program SQL Server nie był narażony na utratę danych.

Uwaga 16.

Wystąpienie programu SQL Server jest uruchamiane ponownie, gdy we/wy w trybie online wystąpią błędy wycofywania w bazie danych tempdb.

Podczas przenoszenia bazy danych tempdb należy zachować ostrożność

Podczas przenoszenia bazy danych tempdb należy zachować ostrożność, ponieważ jeśli nie można utworzyć bazy danych tempdb, program SQL Server nie zostanie uruchomiony. Jeśli nie można utworzyć bazy danych tempdb, uruchom program SQL Server przy użyciu parametru uruchamiania (-f) i przenieś bazę danych tempdb do prawidłowej lokalizacji.

Aby zmienić fizyczną lokalizację bazy danych tempdb, wykonaj następujące kroki:

  1. Użyj instrukcji ALTER DATABASE i MODIFY FILE klauzuli , aby zmienić nazwy plików fizycznych każdego pliku w bazie danych tempdb, aby odwoływać się do nowej lokalizacji fizycznej, takiej jak nowy dysk.

    ALTER DATABASE tempdb MODIFY FILE 
(name = tempdev, filename = 'C:\MyPath\tempdb.mdf')

ALTER DATABASE tempdb MODIFY FILE 
(name = templog, filename = 'C:\MyPath\templog.ldf')

  2. Zatrzymaj, a następnie uruchom ponownie program SQL Server.

Certyfikaty produktów partnerskich nie są gwarancją zgodności ani bezpieczeństwa

Produkt innej firmy lub określony dostawca może otrzymać certyfikat logo firmy Microsoft. Jednak certyfikacja partnera lub określone logo firmy Microsoft nie certyfikowa zgodności ani kondycji dla określonego celu w programie SQL Server.

Pomoc techniczna

Jeśli używasz podsystemu z programem SQL Server, który obsługuje gwarancje we/wy dla transakcyjnego użycia bazy danych zgodnie z opisem w tym artykule, firma Microsoft zapewni obsługę aplikacji opartych na programie SQL Server i programie SQL Server. Jednak problemy z podsystemem lub spowodowane przez nie będą odwoływały się do producenta.

W przypadku problemów związanych z bazą danych tempdb usługa pomoc techniczna firmy Microsoft Services poprosi o przeniesienie bazy danych tempdb. Skontaktuj się z dostawcą urządzenia, aby sprawdzić, czy urządzenie zostało prawidłowo wdrożone i skonfigurowane do obsługi transakcyjnej bazy danych.

Firma Microsoft nie certyfikowa ani nie weryfikuje, czy produkty innych firm działają prawidłowo z programem SQL Server. Ponadto firma Microsoft nie zapewnia żadnej gwarancji, gwarancji ani oświadczenia o kondycji produktu innej firmy do użytku z programem SQL Server.

Informacje

Aby uzyskać więcej informacji, zobacz: