Podstawy we/wy programu SQL Server

Dotyczy:SQL ServerAzure SQL Managed InstanceProgram SQL Server na maszynach wirtualnych platformy 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. Ten proces pomaga administratorowi systemu odróżnić 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; komunikat obecnie nie wskazuje, które. 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 pomagają administratorowi systemu szybciej znaleźć przyczynę słabych czasów odpowiedzi programu SQL Server i rozróżniać problemy 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 we/wy może wskazywać, że operacje we/wy są trwale zablokowane i nigdy nie zostaną ukończone (określane jako utracone operacje we/wy) lub tylko, że jeszcze nie zostały ukończone. Nie można powiedzieć z komunikatu, który scenariusz jest w tym przypadku, chociaż utracone we/wy 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.

Składnik w ścieżce we/wy (na przykład sterownik, kontroler lub firmware) może powodować długotrwałe operacje wejścia/wyjścia poprzez ciągłe odkładanie obsługi starego żądania wejścia/wyjścia na rzecz obsługi nowszych żądań. Ten problem może wystąpić w środowiskach połączonych ze sobą, takich jak sieci iSCSI i Fibre Channel (spowodowane błędną konfiguracją lub niepowodzeniem ścieżki). Narzędzie Monitor wydajności może utrudnić potwierdzenie tego problemu, ponieważ większość operacji we/wy jest szybko serwisowana. Obciążenia, które wykonują duże ilości sekwencyjnych operacji we/wy, takich jak tworzenie kopii zapasowych i przywracanie, skanowanie tabel, sortowanie, tworzenie indeksów, ładowanie zbiorcze i czyszczenie plików, mogą pogorszyć długie żądania we/wy.

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 we/wy mogą być spowodowane zapytaniami, które nie są napisane wydajnie lub prawidłowo dostrojone z indeksami i statystykami. 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 w 15-sekundowym we/wy jest bardziej typowy dla komponentów sprzętowych, krótsze opóźnienia we/wy są częściej obserwowane w przypadku niezoptymalizowanych zapytań lub nieprawidłowo 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 I/O, które nie korzystają z pamięci podręcznej, mogą trwać znacznie dłużej na dyskach mechanicznych z powodu prędkości obrotowej dysku twardego, czasu potrzebnego na przesunięcie głowic dysku i innych czynników ograniczających. Instalacje programu SQL Server są przeznaczone dla systemów, które zapewniają 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.

Stosowanie buforowania zapisu (znanego również jako buforowanie typu write-back) przez kontroler pamięci masowej może poprawić wydajność SQL Server. Kontrolery buforujące zapis i podsystemy magazynowania są bezpieczne dla programu SQL Server, jeśli są zaprojektowane do użycia w środowisku transakcyjnego systemu zarządzania bazami danych (DBMS) o krytycznym znaczeniu dla danych. Te funkcje projektowe muszą zachowywać buforowane dane, jeśli wystąpi awaria systemu. Korzystanie z zewnętrznego zasilacza awaryjnego (UPS) w celu osiągnięcia tej ochrony jest na ogół 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 zawierają te kontrolery, 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.

Wytyczne dotyczące bezpieczeństwa podsystemu pamięci podręcznej

Kontrolery buforowania zapisu mogą zwiększyć wydajność, jeśli spełniają określone wymagania dotyczące bezpieczeństwa:

• Dołącz pamięć podręczną podtrzymywaną bateryjnie lub pamięć nieulotną, taką jak NVDIMM lub pamięć flash wspierana przez superkondensator.
• Być certyfikowanym przez dostawcę dla środowisk bazy danych OLTP o krytycznym znaczeniu dla danych.
• Zapewnij ochronę, która obejmuje wszystkie warunki awarii, a nie tylko utratę zasilania.

Rejestrowanie z wyprzedzeniem zapisu

Instrukcje modyfikacji danych programu SQL Server generują zapisy stron logicznych. Możesz wyobrazić sobie ten strumień zapisów jako idący do dwóch miejsc: dziennika i samej bazy danych. Ze względów wydajnościowych program SQL Server opóźnia zapisywanie do bazy danych, korzystając z własnego systemu buforowania. System tylko chwilowo odkłada operacje zapisu w dzienniku do czasu COMMIT. Nie buforuje tych zapisów w taki sam sposób, jak zapisy danych. Ponieważ zapisy dziennika dla danej strony są zawsze wykonywane przed zapisem danych strony, dziennik jest czasami określany jako dziennik zapisu 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, tak samo 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 leniwie opróżnić. Aby uzyskać więcej informacji, zobacz CreateFileA.

Opcja FILE_FLAG_WRITE_THROUGH zapewnia, że w przypadku gdy operacja zapisu zakończy się pomyślnie, dane są poprawnie przechowywane w stabilnej pamięci masowej. Ta funkcja jest zgodna ze specyfikacją protokołu Write-Ahead Logging (WAL), aby zapewnić integralność danych. 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 sektorów. 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 to atomowe jednostki pracy, które są całkowicie stosowane lub 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 ponowne uruchomienie sprzętu serwera, ładowanie i inicjowanie oprogramowania sieciowego oraz ponowne uruchamianie programu SQL Server. 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. Po ponownym uruchomieniu stacji roboczych klienckich 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 transakcyjnym środowisku systemu baz danych (DBMS) o znaczeniu krytycznym dla danych, może naruszyć zdolność programu SQL Server do odzyskiwania, potencjalnie uszkadzając bazę danych. Ten problem 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.

Ryzyko buforowania zapisu na dysku

Większość kontrolerów buforowania urządzeń magazynujących wykonuje buforowanie zapisu. Nie zawsze da się wyłączyć funkcję buforowania zapisu.

Nawet jeśli serwer korzysta z zasilacza UPS, urządzenie nie gwarantuje 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ą, aby restartować system operacyjny lub ponownie uruchamiać system 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 pozwala bezpiecznie korzystać z serwera bazy danych. Niektóre z tych funkcji projektowych obejmują przechwytywanie sygnału magistrali RST (reset), aby uniknąć niekontrolowanego resetowania kontrolera buforowania, kopii zapasowej baterii na pokładzie i dublowania lub sprawdzania błędów i poprawiania pamięci (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. Te właściwości są 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. Aby uzyskać więcej informacji na temat buforowania i dyskusji na temat alternatywnych trybów awaryjnych, zobacz następujące artykuły:

• 86903 SQL Server i kontrolery dysków buforowania
• Opis algorytmów rejestrowania i przechowywania danych, które rozszerzają niezawodność danych w programie SQL Server

Zapoznaj się również z następującą zarchiwizowaną zawartością.

• Podstawy operacji we/wy programu SQL Server 2000
• Podstawy we/wy programu SQL Server — rozdział 2

Pojęcia w tych dwóch artykułach pozostają szeroko stosowane do bieżących 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 tych systemów umożliwia ustanowienie proporcji pamięci podręcznej odczytu do zapisu w celu uzyskania optymalnej wydajności. Niektóre systemy 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. Te systemy mogą znacznie zwiększyć wydajność bazy danych. Rozwiązania buforowania oparte na baterii zapewniają trwałość i spójność danych, których oczekuje program SQL Server.

Implementacje podsystemu magazynowania

Podsystemy magazynowania istnieją w wielu typach. Dwa typowe przykłady to RAID (nadmiarowa macierz niezależnych dysków) i SIEĆ SAN (sieć magazynowania). Te systemy zwykle używają dysków opartych na protokole SCSI. W poniższej sekcji opisano zagadnienia dotyczące magazynu wysokiego poziomu.

SCSI, SAS i NVMe

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

• Są zwykle przeznaczone do ciężkiego użytku.
• Są zwykle przeznaczone dla implementacji opartych na wielu użytkownikach i serwerach.
• Zazwyczaj mają lepszy średni czas na błędy niż inne implementacje.
• Zawierają zaawansowane heurystyki, aby pomóc w przewidywaniu nieuchronnych niepowodzeń.

Bez interfejsu SCSI

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

• Są zwykle przeznaczone do lekkiego i średniego użytkowania.
• Są zwykle przeznaczone dla aplikacji pojedynczego użytkownika.

Kontrolery bez interfejsu SCSI wymagają większego obciążenia procesora głównego (CPU) i są często ograniczone przez jedno aktywne polecenie. 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. To ograniczenie pozostawia jeden dysk bezczynny, a drugi 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

Dysk lub tablica oparta na komputerze może być rozwiązaniem o niskich kosztach w niektórych sytuacjach. Jeśli na przykład skonfigurujesz bazę danych tylko do odczytu na potrzeby raportowania, nie napotkasz wielu czynników wydajności bazy danych OLTP, gdy buforowanie dysku jest wyłączone.

Rozmiary urządzeń magazynujących nadal rosną. Tanie napędy o wysokiej pojemności 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 oraz 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.

Systemy oparte na IDE i ATA mogą odroczyć polecenia hosta, gdy wykonują działania, takie jak dostosowanie złych bloków, prowadząc do przerw w działaniu we/wy.

Korzyści z SAS (Serial Attached SCSI) obejmują zaawansowane kolejkowanie do 256 poziomów, a także kolejkowanie typu head-of-queue i out-of-order. 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 dyskami twardymi (wirującymi), ale jest podatna na wiele tych samych wzorców awarii co wirujące nośniki danych. Pamięć półprzewodnikową można połączyć 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 pokazują 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 warstwie translacji flash (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ść dysków półprzewodnikowych podaje rozmiary sektorów o wielkości 512 bajtów, ale używa stron o rozmiarze 4 KB wewnątrz bloków wymazywania o rozmiarze 1 MB. 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 aktywność bazy danych jest wykonywana względem tego samego dysku, nieprawidłowe zachowanie (nieaktualny odczyt, utrata zapisu lub odczyt nieprawidłowego przesunięcia) można wykryć w momencie, gdy wzorzec niespodziewanie się pojawi.

Ta technika nie działa dobrze w przypadku pamięci półprzewodnikowej. Wymazywanie i działania RMW podczas zapisu niszczą schemat. Działania związane z odzyskiwaniem przestrzeni (GC), wyrównywaniem zużycia, blokami listy proporcjonalnej/zarezerwowanej oraz inne optymalizacje powodują, że zapisy trafiają do różnych lokalizacji fizycznych, w przeciwieństwie do ponownego wykorzystania sektorów w pamięciach wirujących.

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 jest tylko do odczytu i w związku z tym musi być przeniesiony. Ten ruch zazwyczaj prowadzi do bardziej zużytego bloku, więc oryginalny blok może być użyty do zapisu. Ten proces pomaga 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łowicy, co eliminuje czas dostępu. Wiele urządzeń półprzewodnikowych zaprojektowano tak, aby umożliwić równoległe operacje na różnych blokach. W związku z tym 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.

Rekomendacje:

• Użyj odpowiedniego, wspieranego przez baterię kontrolera zaprojektowanego do optymalizacji działań zapisu. Ten wybór może poprawić wydajność, zmniejszyć zużycie dysku i obniżyć poziom fragmentacji fizycznej.

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

• Upewnij się, że ustawienia wzrostu 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 przedłużyć żywotność dysku 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 ich wdrożeniem 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 producenta sprzętu.

Konfiguracja pamięci podręcznej dysku

Aby użyć dysku z programem SQL Server, wyłącz buforowanie dysków. Domyślnie pamięć podręczna dysku jest włączona. W systemie Windows Server użyj karty Właściwości dysku>Sprzęt>Zasady, aby wyłączyć buforowanie zapisu na poziomie systemu operacyjnego.

Nie należy polegać tylko na ustawieniach na poziomie systemu operacyjnego. Niektóre dyski ignorują ustawienia systemu Windows i wymagają narzędzi dostarczonych przez producenta lub ustawień oprogramowania układowego, aby wyłączyć buforowanie zapisu. Potwierdź za pomocą narzędzi dostawcy, że buforowanie zapisu jest rzeczywiście wyłączone.

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

Aby potwierdzić gwarancje trwałości transakcyjnej, przed przejściem do środowiska produkcyjnego zweryfikuj podsystem I/O przy użyciu SQLIOSim. To narzędzie symuluje duże działanie asynchroniczne odczytu i zapisu na symulowanym urządzeniu danych i urządzeniu dziennika. Aby uzyskać więcej informacji, zobacz Używanie narzędzia SQLIOSim do symulowania aktywności programu SQL Server w podsystemie dysku.

Wielu producentów komputerów zamawia dyski z wyłączoną pamięcią podręczną zapisu. Jednak testowanie pokazuje, że ten warunek nie zawsze musi zachodzić, więc zawsze należy go przetestować dokładnie. Jeśli masz pytania dotyczące stanu buforowania urządzenia magazynującego, skontaktuj się z producentem i uzyskaj odpowiednie narzędzie, aby wyłączyć operacje buforowania zapisu. Na starszych nośnikach danych mogą być również potrzebne ustawienia zworek.

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.

Ryzyko związane z nieprawidłowym buforowaniem zapisu

Po włączeniu buforowania zapisu bez odpowiednich zabezpieczeń niektóre podsystemy magazynowania uznają operacje zapisu jako ukończone, zanim dane będą bezpiecznie zapisywane na nośniku trwałym. Jeśli wystąpi utrata zasilania lub awaria systemu, ten warunek może spowodować:

• Utrata danych, w przypadku której zatwierdzone transakcje nigdy nie są utrwalane.
• Uszkodzenie bazy danych z powodu uszkodzonych gwarancji kolejności zapisu.

Treści powiązane

• Przewodnik architektury stron i zakresów
• przewodnik po architekturze zarządzania pamięcią
• Storage: najlepsze rozwiązania dotyczące wydajności programu SQL Server na maszynach wirtualnych platformy Azure
• SQL Server w systemie Linux: wewnętrzny Forced Unit Access (FUA)
• Podstawy we/wy programu SQL Server, rozdział 2