Udostępnij za pośrednictwem

Podstawy we/wy programu SQL Server

Dotyczy:SQL ServerAzure SQL Managed InstanceSQL Server na maszynie wirtualnej Azure

Podstawowym celem bazy danych programu SQL Server jest przechowywanie i pobieranie danych, dlatego intensywne wejście/wyjście dysku (We/Wy) jest główną cechą aparatu bazy danych. Ponieważ operacje we/wy dysku mogą zużywać wiele zasobów i trwać stosunkowo długo, program SQL Server koncentruje się na dokonaniu wysokiej wydajności operacji we/wy.

Podsystemy magazynowania dla programu SQL Server są dostępne w wielu formach, w tym dysków mechanicznych i magazynu półprzewodnikowego. Ten artykuł zawiera szczegółowe informacje na temat używania zasad buforowania dysków w celu ulepszenia operacji we/wy aparatu bazy danych.

Program SQL Server wymaga, aby systemy obsługiwały gwarantowane dostarczanie danych na stabilne nośniki, zgodnie z Wymaganiami programu niezawodności We/Wy programu SQL Server. Aby uzyskać więcej informacji na temat wymagań dotyczących danych wejściowych i wyjściowych aparatu bazy danych programu SQL Server, zobacz Wymagania dotyczące wejścia/wyjścia (we/wy) aparatu bazy danych programu SQL Server.

Wejście/Wyjście dysku

Menedżer buforów wykonuje tylko operacje odczytu i zapisu na bazie danych. Inne operacje na plikach i bazach danych, takie jak otwieranie, zamykanie, rozszerzanie i zmniejszanie, są wykonywane przez składniki menedżera bazy danych i menedżera plików.

Operacje wejścia/wyjścia dysku przez menedżera buforowania mają następujące cechy:

  • Operacje we/wy są zwykle wykonywane asynchronicznie, co umożliwia wątkowi wywołującemu kontynuowanie przetwarzania, podczas gdy operacje we/wy odbywają się w tle. W niektórych okolicznościach (na przykład niezrównoważone operacje we/wy dziennika) mogą wystąpić synchroniczne operacje we/wy.

  • Wszystkie operacje wejścia/wyjścia są wykonywane w wątkach wywołujących, chyba że opcja afinity I/O jest używana. Opcja maski we/wy koligacji wiąże operacje we/wy dysku SQL Server z określonym podzestawem CPU. W wysokiej klasy środowiskach przetwarzania transakcyjnego (OLTP) programu SQL Server to rozszerzenie może zwiększyć wydajność wątków programu SQL Server inicjujących operacje wejścia/wyjścia.

  • Wiele operacji we/wy wielu stron odbywa się za pomocą operacji we/wy typu scatter-gather, co umożliwia przesyłanie danych do lub z nieciągłych obszarów pamięci. Oznacza to, że program SQL Server może szybko wypełnić lub opróżnić pamięć podręczną buforu, unikając wielu fizycznych żądań we/wy.

Długie żądania I/O

Menedżer buforowania zgłasza każde żądanie we/wy, które jest zaległe przez co najmniej 15 sekund. Pomaga to administratorowi systemu rozróżniać problemy z programem SQL Server i problemy podsystemu we/wy. Komunikat o błędzie MSSQLSERVER_833 jest zgłaszany i pojawia się w dzienniku błędów programu SQL Server w następujący sposób:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

Długie operacje wejścia/wyjścia mogą być odczytem lub zapisem; nie jest to obecnie wskazane w komunikacie. Komunikaty we/wy o długim czasie trwania są ostrzeżeniami, a nie błędami. Nie wskazują one problemów z programem SQL Server, ale z bazowym systemem we/wy. Komunikaty są zgłaszane w celu ułatwienia administratorowi systemu szybszego znalezienia przyczyny złej odpowiedzi programu SQL Server oraz odróżnienia problemów spoza kontroli programu SQL Server. W związku z tym nie wymagają żadnej akcji, ale administrator systemu powinien zbadać, dlaczego żądanie we/wy trwało tak długo i czy czas jest uzasadniony.

Przyczyny długich żądań we/wy

Długi komunikat wejścia/wyjścia może wskazywać, że operacje I/O są trwale zablokowane i nigdy nie zostaną ukończone (znane jako utracone operacje I/O) lub że po prostu jeszcze się nie zakończyły. Nie można określić z komunikatu, który scenariusz ma miejsce, chociaż utrata wejścia/wyjścia często prowadzi do przekroczenia limitu czasu zatrzaśnięcia.

Długie operacje we/wy często wskazują obciążenie programu SQL Server, które jest zbyt intensywne dla podsystemu dysków. Nieodpowiedni podsystem dysku może być wskazany w przypadku:

  • Wiele długich komunikatów we/wy jest wyświetlanych w dzienniku błędów podczas dużego obciążenia programu SQL Server.
  • Liczniki monitora wydajności pokazują długie opóźnienia dysku, długie kolejki dysków lub brak czasu bezczynności dysku.

Długie operacje we/wy mogą być również spowodowane przez składnik w ścieżce we/wy (na przykład sterownik, kontroler lub oprogramowanie układowe) stale opóźniając obsługę starego żądania we/wy na korzyść obsługi nowszych żądań. Może się to zdarzyć w środowiskach połączonych, takich jak sieci iSCSI i fibre channel (spowodowane błędną konfiguracją lub niepowodzeniem ścieżki). Może to być trudne do potwierdzenia za pomocą narzędzia Monitor wydajności, ponieważ większość operacji we/wy są obsługiwane szybko. Długie żądania I/O mogą się pogarszać z powodu obciążeń wykonujących duże liczby sekwencyjnych operacji I/O, takich jak tworzenie kopii zapasowych i przywracanie, skanowanie tabel, sortowanie, tworzenie indeksów, ładowanie zbiorcze i wyzerowanie plików.

Izolowane długie operacje wejścia/wyjścia, które nie wydają się być związane z żadnym z poprzednich warunków, mogą być spowodowane problemem ze sprzętem lub sterownikiem. Dziennik zdarzeń systemu może zawierać powiązane zdarzenie, które pomaga zdiagnozować problem.

Problemy z wydajnością we/wy spowodowane nieefektywnymi zapytaniami lub sterownikami filtrów

Powolne wejścia/wyjścia mogą być spowodowane zapytaniami, które nie są napisane efektywnie lub nie zostały odpowiednio dostosowane do indeksów i statystyk. Innym typowym czynnikiem opóźnienia we/wy jest obecność oprogramowania antywirusowego lub innych programów zabezpieczeń, które skanują pliki bazy danych. To oprogramowanie skanujące może rozszerzać warstwę sieciową, co zwiększa opóźnienie sieci, co z kolei pośrednio wpływa na opóźnienie bazy danych. Chociaż scenariusz opisany 15-sekundowym we/wy jest bardziej powszechny w przypadku składników sprzętowych, mniejsza latencja we/wy jest częściej obserwowana w przypadku niezoptymalizowanych zapytań lub błędnie skonfigurowanych programów antywirusowych.

Aby uzyskać szczegółowe informacje na temat rozwiązywania tych problemów, zobacz Rozwiązywanie problemów z wolną wydajnością SQL Server spowodowanych problemami I/O.

Aby uzyskać informacje na temat konfigurowania ochrony antywirusowej w programie SQL Server, zobacz Konfigurowanie oprogramowania antywirusowego do pracy z programem SQL Server.

Buforowanie zapisu w kontrolerach pamięci masowej

Transfery we/wy wykonywane bez użycia pamięci podręcznej mogą być znacznie dłuższe w dyskach mechanicznych, ze względu na współczynniki spin dysku twardego, czas mechaniczny potrzebny do przenoszenia głowic dysków i inne czynniki ograniczające. Instalacje programu SQL Server są przeznaczone dla systemów zapewniających kontrolery buforowania. Te kontrolery wyłączają pamięci podręczne na dysku i zapewniają stabilne pamięci podręczne multimediów, aby spełnić wymagania we/wy programu SQL Server. Unikają problemów z wydajnością związanych z czasem wyszukiwania i zapisu danych poprzez zastosowanie różnych optymalizacji kontrolera buforowania.

Uwaga / Notatka

Niektórzy dostawcy pamięci masowej używają pamięci trwałej (PMEM) jako magazynu, zamiast pamięci podręcznej, co może poprawić ogólną wydajność. Aby uzyskać więcej informacji, zobacz Konfigurowanie pamięci trwałej (PMEM) dla programu SQL Server w systemie Windows i Konfigurowanie pamięci trwałej (PMEM) dla programu SQL Server w systemie Linux.

Stosowanie buforowania zapisu (znanego również jako buforowanie typu write-back) przez kontroler pamięci masowej może poprawić wydajność SQL Server. Kontrolery buforowania zapisu i systemy magazynowania są bezpieczne dla SQL Server, jeżeli zostały zaprojektowane do użytku w środowisku krytycznym dla danych, jakim jest transakcyjny system zarządzania bazą danych (DBMS). Te funkcje projektowe muszą zachowywać buforowane dane, jeśli wystąpi awaria systemu. Użycie zewnętrznego zasilacza awaryjnego (UPS) w celu osiągnięcia tego celu jest ogólnie nie wystarczające, ponieważ mogą wystąpić tryby awarii niepowiązane z zasilaniem.

Buforowanie kontrolerów i podsystemów magazynowania może być bezpieczne do użycia przez program SQL Server. Większość nowych specjalnie utworzonych platform serwerowych, które je zawierają, są bezpieczne. Należy jednak sprawdzić u dostawcy sprzętu, aby upewnić się, że podsystem magazynowania został przetestowany i zatwierdzony do użycia w środowisku systemu zarządzania relacyjnymi bazami danych (RDBMS) o krytycznym znaczeniu dla danych.

Rejestrowanie z wyprzedzeniem zapisu

Instrukcje modyfikacji danych programu SQL Server generują zapisy stron logicznych. Ten strumień zapisów można sobie wyobrazić jako zmierzający do dwóch miejsc: dziennika i samej bazy danych. Ze względów wydajnościowych, program SQL Server opóźnia zapisy do bazy danych, korzystając z własnego systemu buforu pamięci. Zapisy w dzienniku są jedynie tymczasowo wstrzymane do COMMIT czasu. Nie są one buforowane w taki sam sposób, jak zapisy danych. Ponieważ zapisy dziennika dla danej strony zawsze poprzedzają zapisy danych strony, dziennik jest czasami określany jako zapis z wyprzedzeniem (WAL).

Protokół rejestrowania z wyprzedzeniem (WAL)

Termin protokół jest doskonałym sposobem na opisanie WAL. Plik WAL używany przez program SQL Server jest znany jako ARIES (algorytm odzyskiwania i izolacji wykorzystujący semantyka). Aby uzyskać więcej informacji, zobacz Zarządzanie przyspieszonym odzyskiwaniem bazy danych.

Jest to określony i zdefiniowany zestaw kroków implementacji niezbędnych do zapewnienia, że dane są przechowywane i wymieniane prawidłowo i można je odzyskać do znanego stanu w przypadku awarii. Podobnie jak sieć zawiera zdefiniowany protokół wymiany danych w spójny i chroniony sposób, dlatego też wal opisuje protokół ochrony danych. Wszystkie wersje programu SQL Server otwierają pliki dziennika i danych przy użyciu funkcji Win32 CreateFile . Członek dwFlagsAndAttributes zawiera opcję FILE_FLAG_WRITE_THROUGH przy otwieraniu przez SQL Server.

FILE_FLAG_WRITE_THROUGH (Flaga zapisu wymuszonego)

Program SQL Server tworzy pliki bazy danych przy użyciu flagi FILE_FLAG_WRITE_THROUGH . Ta opcja nakazuje systemowi pomijanie pośrednich pamięci podręcznych i zapisywanie bezpośrednio w pamięci masowej. System nadal może buforować operacje zapisu, ale nie może je z opóźnieniem opróżnić. Aby uzyskać więcej informacji, zobacz CreateFileA.

Opcja FILE_FLAG_WRITE_THROUGH zapewnia, że gdy operacja zapisu zostanie pomyślnie zakończona, dane są prawidłowo przechowywane w trwałej pamięci. Jest to zgodne ze specyfikacją protokołu Write Ahead Logging (WAL), aby zapewnić dane. Wiele urządzeń magazynujących (NVMe, PCIe, SATA, ATA, SCSI i IDE) zawiera wbudowane pamięci podręczne 512 KB, 1 MB i większe. Pamięci podręczne magazynu zwykle opierają się na kondensatorze, a nie na rozwiązaniu opartym na baterii. Te mechanizmy buforowania nie mogą zagwarantować zapisu w cyklu zasilania lub podobnym punkcie awarii. Gwarantują one tylko ukończenie operacji zapisu w sektorze. W miarę jak urządzenia magazynujące zwiększają się, pamięci podręczne stają się większe i mogą ujawniać więcej danych podczas awarii.

Aby uzyskać więcej informacji na temat obsługi FUA przez dystrybucję systemu Linux i jego wpływu na działanie programu SQL Server, zobacz SQL Server on Linux: Forced Unit Access (FUA) Internals.

Integralność transakcyjna i odzyskiwanie programu SQL Server

Integralność transakcyjna jest jedną z podstawowych koncepcji systemu relacyjnej bazy danych. Transakcje są uważane za atomowe jednostki pracy, które są albo całkowicie zastosowane, albo całkowicie wycofane. Dziennik transakcji typu write-ahead w SQL Server jest istotnym składnikiem wdrażania spójności transakcyjnej.

Każdy system relacyjnej bazy danych musi również ściśle radzić sobie z koncepcją związaną z integralnością transakcyjną, która jest odzyskiwaniem po nieplanowanej awarii systemu. Kilka nie-idealnych, rzeczywistych efektów może spowodować tę porażkę. W wielu systemach zarządzania bazami danych awaria systemu może spowodować długi proces ręcznego odzyskiwania kierowany przez człowieka.

Natomiast mechanizm odzyskiwania programu SQL Server jest automatyczny i działa bez interwencji człowieka. Na przykład program SQL Server może obsługiwać aplikację produkcyjną o krytycznym znaczeniu i doświadczać awarii systemu z powodu chwilowych wahań zasilania. Po przywróceniu zasilania sprzęt serwera zostanie uruchomiony ponownie, oprogramowanie sieciowe zostanie załadowane i zainicjowane, a program SQL Server zostanie uruchomiony ponownie. Podczas inicjowania programu SQL Server automatycznie uruchamia proces odzyskiwania na podstawie danych w dzienniku transakcji. Cały ten proces odbywa się bez interwencji człowieka. Za każdym razem, gdy stacje robocze klienta zostaną uruchomione ponownie, użytkownicy znajdą wszystkie swoje dane, aż do ostatniej wprowadzonej transakcji.

Integralność transakcyjna i automatyczne odzyskiwanie w programie SQL Server stanowią zaawansowaną możliwość oszczędzania czasu i pracy. Jeśli kontroler buforowania zapisu nie jest prawidłowo zaprojektowany do użycia w środowisku transakcyjnego systemu DBMS o znaczeniu krytycznym dla danych, może zakłócić zdolność do odzyskiwania przez SQL Server, co może spowodować uszkodzenie bazy danych. Taka sytuacja może wystąpić, jeśli kontroler przechwytuje zapisy dziennika transakcji programu SQL Server i buforuje je w pamięci podręcznej sprzętowej na tablicy kontrolera, ale nie zachowuje tych zapisanych stron podczas awarii systemu.

Buforowanie zapisu i kontrolery urządzeń pamięci masowej

Większość kontrolerów buforowania urządzeń magazynujących wykonuje buforowanie zapisu. Funkcja buforowania zapisu nie zawsze może być wyłączona.

Nawet jeśli serwer korzysta z zasilacza UPS, nie gwarantuje to bezpieczeństwa buforowanych zapisów. Wiele typów awarii systemu może wystąpić, których UPS nie rozwiązuje. Na przykład błąd parzystości pamięci, pułapka systemu operacyjnego lub usterka sprzętowa powodująca zresetowanie systemu może spowodować niekontrolowaną przerwę w systemie. Awaria pamięci w sprzętowej pamięci podręcznej zapisu może również spowodować utratę istotnych informacji z dziennika.

Inny możliwy problem związany z kontrolerem buforowania zapisu może wystąpić podczas zamykania systemu. Nie jest rzadkością cyklu systemu operacyjnego ani ponownego uruchamiania systemu podczas zmian konfiguracji. Nawet jeśli ostrożny operator stosuje się do zalecenia systemu operacyjnego, aby poczekać, aż wszystkie działania magazynu zakończą się przed ponownym uruchomieniem systemu, buforowane zapisy mogą być nadal obecne w kontrolerze. Po naciśnięciu kombinacji klawiszy Ctrl+Alt+Del lub przycisku resetowania sprzętowego, buforowane dane mogą zostać odrzucone, co może uszkodzić bazę danych.

Istnieje możliwość zaprojektowania sprzętowej pamięci podręcznej zapisu, która uwzględnia wszystkie możliwe przyczyny odrzucania zanieczyszczonych danych pamięci podręcznej, co w związku z tym byłoby bezpieczne do użycia przez serwer bazy danych. Niektóre z tych funkcji projektowych obejmują przechwycenie sygnału magistrali RST, aby uniknąć niekontrolowanego resetowania kontrolera buforowania, zapasowe zasilanie bateryjne na pokładzie oraz pamięć z dublowaniem lub sprawdzaniem i korekcją błędów (ECC). Zajrzyj do dostawcy sprzętu, aby upewnić się, że pamięć podręczna zapisu zawiera te i inne funkcje niezbędne do uniknięcia utraty danych.

Korzystanie z pamięci podręcznych magazynu z programem SQL Server

System bazy danych jest przede wszystkim odpowiedzialny za dokładne przechowywanie i pobieranie danych, nawet w przypadku nieoczekiwanych awarii systemu.

System musi zagwarantować niepodzielność i trwałość transakcji, uwzględniając bieżące przetwarzanie, wiele transakcji i różne punkty awarii. Jest to często określane jako właściwości ACID (atomowość, spójność, izolacja i trwałość).

Ta sekcja omawia implikacje pamięci podręcznych. Zalecane jest zapoznanie się z następującymi artykułami w Microsoft Knowledge Base (Baza Wiedzy Microsoftu) w celu uzyskania dodatkowych informacji dotyczących buforowania i alternatywnych trybów awarii.

Zalecane są również następujące dokumenty:

Te dwa dokumenty dotyczą wszystkich aktualnie obsługiwanych wersji programu SQL Server.

Rozwiązania buforowania oparte na baterii

Ulepszone systemy buforowania wyłączają pamięć podręczną na dysku i zapewniają funkcjonalne rozwiązanie buforowania oparte na baterii. Te pamięci podręczne mogą przechowywać dane w pamięci podręcznej przez kilka dni, a nawet zezwalać na umieszczenie karty buforowania na drugim komputerze. Po prawidłowym przywróceniu zasilania dane niezapisane są całkowicie usuwane, zanim będzie dozwolony jakikolwiek dalszy dostęp do danych. Wiele z nich pozwala na ustalenie proporcji między pamięcią podręczną odczytu a zapisu w celu uzyskania optymalnej wydajności. Niektóre zawierają duże obszary magazynowania pamięci. Niektórzy dostawcy sprzętu zapewniają wysokiej klasy systemy buforowania dysków z wieloma gigabajtami pamięci podręcznej. Mogą one znacznie poprawić wydajność bazy danych. Korzystanie z rozwiązań buforowania opartego na baterii zapewnia trwałość i spójność danych, których oczekuje program SQL Server.

Implementacje podsystemu magazynowania

Istnieje wiele typów implementacji podsystemu. MACIERZ RAID (nadmiarowa macierz niezależnych dysków) i SAN (sieć magazynowania) to dwa przykłady tych typów implementacji podsystemu. Te systemy są zwykle tworzone przy użyciu dysków opartych na protokole SCSI. Istnieje kilka powodów tego problemu. W następnej części ogólnie opisano zagadnienia dotyczące przechowywania na wysokim poziomie.

SCSI, SAS i NVMe

Urządzenia magazynujące SCSI, SAS i NVMe:

  • Są zwykle produkowane do ciężkiego użytku.
  • Są zwykle przeznaczone dla implementacji opartych na wielu użytkownikach i serwerach.
  • Zazwyczaj mają lepsze średnie wskaźniki niepowodzeń niż inne implementacje.
  • Zawierają zaawansowane heurystyki, aby pomóc w przewidywaniu nieuchronnych niepowodzeń.

Uwaga / Notatka

Program SQL Server jest obsługiwany w składnikach technologii Internet Small Computer System Interface (iSCSI), które spełniają wymagania programu zgodności sprzętu systemu Windows. Mimo że program SQL Server nie współdziała bezpośrednio z interfejsem iSCSI, działa bezproblemowo, ponieważ system Windows przedstawia magazyn iSCSI jako dyski standardowe. Dzięki temu program SQL Server może odczytywać i zapisywać w zdalnym magazynie na poziomie bloku w ramach sieci IP. Ponieważ interfejs iSCSI zależy od sieci, mogą wystąpić opóźnienia lub wąskie gardła, dlatego należy zoptymalizować wydajność buforowania serwera i zminimalizować opóźnienia. Aby uzyskać więcej informacji, zobacz iSCSI Target Server Scalability Limits (Limity skalowalności serwera obiektów docelowych iSCSI).

Bez interfejsu SCSI

Inne implementacje dysków, takie jak IDE, ATA i SATA:

  • Są zwykle produkowane do lekkiego i średniego użytkowania.
  • Są zwykle przeznaczone dla aplikacji opartych na jednym użytkowniku.

Kontrolery nienależące do interfejsu SCSI, oparte na komputerach stacjonarnych, wymagają większych zasobów procesora głównego (CPU). Są często ograniczone do jednego aktywnego polecenia. Jeśli na przykład dysk inny niż SCSI koryguje nieprawidłowy blok, dysk wymaga, by komendy hosta czekały. Magistrala usługi ATA przedstawia inny przykład: magistrala usługi ATA obsługuje dwa urządzenia, ale tylko jedno polecenie może być aktywne. Pozostawia to jeden dysk bezczynny, podczas gdy drugi dysk obsługuje oczekujące polecenie. Systemy RAID oparte na technologiach klasycznych mogą doświadczać tych objawów i być znacznie dotknięte przez najwolniejszego reagowania. O ile te systemy nie używają zaawansowanych projektów, ich wydajność nie jest tak wydajna, jak wydajność systemów opartych na protokole SCSI.

Zagadnienia dotyczące magazynu

Istnieją sytuacje, w których dysk lub tablica oparta na komputerze stacjonarnym jest odpowiednim niskokosztowym rozwiązaniem. Jeśli na przykład skonfigurujesz bazę danych tylko do odczytu na potrzeby raportowania, nie należy napotkać wielu czynników wydajności bazy danych OLTP, gdy buforowanie dysku jest wyłączone.

Rozmiary urządzeń magazynujących nadal rosną. Dyski o wysokiej pojemności i niskich kosztach mogą być atrakcyjne. Jednak podczas konfigurowania dysku dla programu SQL Server i potrzeb związanych z czasem reagowania biznesowego należy dokładnie rozważyć następujące problemy:

  • Projekt ścieżki dostępu
  • Konieczność wyłączenia pamięci podręcznej na dysku

Mechaniczne dyski twarde

Dyski mechaniczne używają wirujących talerzy magnetycznych do przechowywania danych. Są one dostępne w kilku pojemnościach i formatach, takich jak IDE, SATA, SCSI i Serial Attached SCSI (SAS). Niektóre dyski SATA obejmują konstrukcje przewidywania błędów. Dyski SCSI są zaprojektowane z myślą o cięższych cyklach pracy i obniżonych współczynnikach awarii.

Buforowanie dysków powinno być wyłączone, aby można było używać dysku z programem SQL Server. Domyślnie pamięć podręczna dysku jest włączona. W systemie Windows Server użyj karty Właściwości> dyskuSprzęt, aby uzyskać dostęp do karty Zasady właściwości>, aby kontrolować ustawienie pamięci podręcznej dysku.

Uwaga / Notatka

Niektóre dyski nie uznają tego ustawienia. Te dyski wymagają określonego narzędzia producenta, aby wyłączyć pamięć podręczną.

Systemy oparte na IDE i ATA mogą odroczyć polecenia hosta, gdy wykonują działania, takie jak dostosowanie bloków o błędach. Może to prowadzić do okresów zatrzymanych działań we/wy.

Zalety SAS obejmują zaawansowane kolejkowanie do 256 poziomów, a także kolejkowanie na początku kolejki oraz kolejkowanie poza kolejnością. Płyta tylna SAS została zaprojektowana, aby umożliwić korzystanie zarówno z dysków SAS, jak i SATA w tym samym systemie.

Instalacja programu SQL Server zależy od zdolności kontrolera do wyłączenia pamięci podręcznej na dysku i zapewnienia stabilnej pamięci podręcznej we/wy. Zapisywanie danych poza kolejnością na różnych dyskach nie jest przeszkodą dla programu SQL Server, o ile kontroler zapewnia prawidłowe stabilne możliwości buforowania multimediów. Złożoność projektu kontrolera zwiększa się dzięki zaawansowanym technikom zabezpieczeń danych, takim jak dublowanie.

Pamięć półprzewodnikowa

Pamięć półprzewodnikowa ma przewagę nad mechanicznymi (obracającymi się) dyskami twardymi, ale jest podatna na wiele takich samych wzorców awarii jak media obrotowe. Pamięć masowa półprzewodnikowa łączy się z serwerem za pomocą różnych interfejsów, w tym NVM Express (NVMe), PCI Express (PCIe) i SATA. Traktuj nośniki półprzewodnikowe tak jak wirujące nośniki i upewnij się, że odpowiednie zabezpieczenia są wprowadzone na wypadek awarii zasilania, takie jak kontroler buforowania wspierany przez baterię.

Typowe problemy spowodowane błędem zasilania obejmują:

  • Uszkodzenie bitów: Rekordy wykazują błędy bitów losowych.
  • Błędne zapisy: Dobrze uformowane dane trafiają w niewłaściwe miejsce.
  • Shorn pisze: Operacje są częściowo wykonywane na poziomie poniżej oczekiwanego rozmiaru sektora.
  • Uszkodzenie metadanych: metadane w FTL są uszkodzone.
  • Urządzenie nie odpowiada: urządzenie w ogóle nie działa lub w większości nie działa.
  • Unserializability: Stan końcowy magazynu nie wynika z kolejności operacji, które można zserializować.

512e

Większość nośników półprzewodnikowych zgłasza rozmiary 512-bajtowych sektorów, ale wewnątrz bloków wymazywania o rozmiarze 1 MB używają stron 4 KB. Użycie sektorów wyrównanych do 512 bajtów dla urządzenia dziennika SQL Server może powodować więcej operacji odczytu/modyfikacji/zapisu (RMW), co może prowadzić do niższej wydajności i zużycia dysków.

Zalecenie: upewnij się, że kontroler buforowania jest zaznajomiony z prawidłowym rozmiarem strony urządzenia magazynującego i może prawidłowo dopasować zapisy fizyczne do infrastruktury pamięci półprzewodnikowej.

0xFFFFFFFF

Nowo sformatowany dysk zwykle przechowuje wszystkie zera. Wymazany blok urządzenia półprzewodnikowego składa się w całości z elementów 1, co oznacza, że surowe odczyty wymazanego bloku zawierają wyłącznie znaki 0xFF. Jednak rzadko się zdarza, aby użytkownik odczytywał wymazany blok podczas normalnych operacji we/wy.

Stemplowanie wzoru

Techniką używaną w przeszłości jest napisanie znanego wzorca dla całego dysku. Następnie, gdy wykonujemy działanie bazy danych na tym samym dysku, możemy wykryć nieprawidłowe zachowanie (takie jak nieaktualny odczyt, utracony zapis lub odczyt nieprawidłowego przesunięcia), kiedy wzorzec niespodziewanie się pojawia.

Ta technika nie działa dobrze w przypadku pamięci półprzewodnikowej. Wymazywanie i działania związane z odczytem-modyfikacją-zapisem niszczą wzorzec. Działanie odzyskiwania miejsca w pamięci półprzewodnikowej (GC), bilansowanie zużycia, proporcjonalnie/odłożone bloki listy i inne optymalizacje mają tendencję do powodowania, że zapisy trafiają do różnych lokalizacji fizycznych, w przeciwieństwie do ponownego wykorzystania sektorów w dyskach twardych.

Firmware (oprogramowanie sprzętowe)

Oprogramowanie układowe używane w pamięci półprzewodnikowej wydaje się być złożone w porównaniu do odpowiedników z wirującymi nośnikami. Wiele napędów używa wielu rdzeni przetwarzania do obsługi żądań przychodzących i działań związanych z zarządzaniem śmieciami. Upewnij się, że oprogramowanie układowe urządzenia półprzewodnikowego jest aktualne, aby uniknąć znanych problemów.

Uszkodzenie danych odczytu i bilansowanie zużycia

Typowe podejście do gospodarki odpadami (GC) dla magazynu półprzewodnikowego pomaga uniknąć powtarzającego się uszkodzenia danych podczas odczytu. Podczas wielokrotnego odczytywania tej samej komórki możliwe jest, że aktywność elektronów może wyciekać i powodować uszkodzenie sąsiednich komórek. Magazyn półprzewodnikowy chroni dane za pomocą różnych poziomów kodu korekty błędów (ECC) i innych mechanizmów.

Jeden z takich mechanizmów odnosi się do bilansowania zużycia. Pamięć półprzewodnikowa śledzi aktywność odczytu i zapisu na urządzeniu pamięci. Zarządzanie pamięcią może określać punkty aktywne lub lokalizacje zużywające się szybciej niż inne lokalizacje. Na przykład GC określa, że blok był w stanie tylko do odczytu przez pewien czas i musi zostać przeniesiony. Ten ruch zazwyczaj prowadzi do bardziej zużytego bloku, więc oryginalny blok może być użyty do zapisu. Pomaga to zrównoważyć zużycie dysku, ale przenosi dane tylko do odczytu do lokalizacji, która ma więcej zużycia i matematycznie zwiększa prawdopodobieństwo awarii, nawet jeśli nieznacznie.

Inny efekt uboczny bilansowania zużycia może wystąpić w programie SQL Server. Załóżmy, że wykonujesz bazę danych DBCC CHECKDB i zgłasza błąd. Jeśli uruchomisz go drugi raz, istnieje niewielkie prawdopodobieństwo, że DBCC CHECKDB zgłosi dodatkowy lub inny schemat błędów, ponieważ działanie procesu GC w magazynie półprzewodnikowym może wprowadzać zmiany między DBCC CHECKDB wykonaniami.

Błąd systemu operacyjnego 665 i defragmentacja

Wirujące nośniki muszą utrzymywać bloki blisko siebie, aby zmniejszyć ruch głowicy napędu i zwiększyć wydajność. Pamięć półprzewodnikowa nie ma fizycznej główki, co eliminuje czas wyszukiwania. Wiele urządzeń półprzewodnikowych zaprojektowano tak, aby umożliwić równoległe operacje na różnych blokach. Oznacza to, że defragmentacja nośnika półprzewodnikowego jest niepotrzebna. Działania szeregowe to najlepsze wzorce we/wy w celu zmaksymalizowania przepływności we/wy na urządzeniach magazynujących półprzewodnikowych.

Uwaga / Notatka

Pamięć półprzewodnikowa korzysta z funkcji trim, komendy systemu operacyjnego, która usuwa bloki uznawane za nieużywane. W systemie Windows użyj narzędzia Optymalizuj dyski , aby ustawić tygodniowy harmonogram optymalizacji dysków.

Rekomendacje:

  • Użyj odpowiedniego, wspieranego przez baterię kontrolera zaprojektowanego do optymalizacji działań zapisu. Może to poprawić wydajność, zmniejszyć zużycie dysku i poziom fragmentacji fizycznej.

  • Rozważ użycie systemu plików ReFS , aby uniknąć ograniczeń atrybutów NTFS.

  • Upewnij się, że rozmiary przyrostu pliku są odpowiednie.

Aby uzyskać więcej informacji na temat rozwiązywania problemów z błędem systemu operacyjnego 665 w odniesieniu do fragmentacji, zobacz Błędy systemu operacyjnego 665 i 1450 są zgłaszane dla plików programu SQL Server.

Kompresja

Tak długo, jak dysk utrzymuje intencję stabilnego nośnika, kompresja może wydłużyć żywotność napędu i może pozytywnie wpłynąć na wydajność. Jednak niektóre oprogramowanie układowe może już kompresować dane niewidocznie. Pamiętaj, aby przetestować nowe scenariusze magazynowania przed wdrożeniem go w środowisku produkcyjnym.

Podsumowanie

  • Zachowaj odpowiednie procedury tworzenia kopii zapasowych i odzyskiwania po awarii oraz procesy.
  • Zachowaj aktualność oprogramowania układowego.
  • Uważnie słuchaj wskazówek od producenta sprzętu.

Zagadnienia dotyczące pamięci podręcznej i SQLIOSim

Aby w pełni zabezpieczyć dane, upewnij się, że wszystkie buforowanie danych jest prawidłowo obsługiwane. W wielu sytuacjach oznacza to, że należy wyłączyć buforowanie zapisu dysku.

Uwaga / Notatka

Upewnij się, że dowolny alternatywny mechanizm buforowania może prawidłowo obsługiwać wiele typów awarii.

Firma Microsoft przeprowadziła testy na kilku dyskach SCSI i IDE przy użyciu narzędzia SQLIOSim . To narzędzie symuluje duże działanie asynchroniczne odczytu/zapisu na symulowanym urządzeniu danych i urządzeniu dziennika. Aby uzyskać więcej informacji i szczegóły dotyczące SQLIOSim, zobacz Skorzystaj z narzędzia SQLIOSim do symulowania aktywności SQL Server w podsystemie dyskowym.

Wielu producentów komputerów zamawia dyski z wyłączoną pamięcią podręczną zapisu. Jednak testowanie pokazuje, że może to nie zawsze być możliwe, więc zawsze należy go całkowicie przetestować. Jeśli masz pytania dotyczące stanu buforowania urządzenia pamięci masowej, skontaktuj się z producentem i uzyskaj odpowiednie narzędzia lub ustawienia zworek, aby wyłączyć operacje buforowania zapisu.

Program SQL Server wymaga, aby systemy obsługiwały gwarantowane dostarczanie do stabilnego nośnika, zgodnie z Wymaganiami dotyczącymi Niezawodności We/Wy SQL Server. Aby uzyskać więcej informacji na temat wymagań dotyczących danych wejściowych i wyjściowych aparatu bazy danych programu SQL Server, zobacz Wymagania dotyczące wejścia/wyjścia (we/wy) aparatu bazy danych programu SQL Server.

Treści powiązane