MSSQLSERVER_833

Dotyczy:SQL ServerAzure SQL Managed Instance

Szczegóły

Atrybut	Wartość
Nazwa produktu	SQL Server
Identyfikator zdarzenia	833
Źródło zdarzenia	MSSQLSERVER
Składnik	SQLEngine
Nazwa symboliczna	BUF_LONG_IO
Tekst wiadomości	Program SQL Server napotkał %d wystąpień żądań we/wy trwa dłużej niż %d sekund w pliku [%ls] w bazie danych [%ls] (%d). Dojście do pliku systemu operacyjnego to 0x%p. Przesunięcie najnowszej długiej operacji we/wy to: %#016I64x.

Wyjaśnienie

Ten komunikat wskazuje, że program SQL Server wystawił żądanie odczytu lub zapisu z dysku i że zwrócenie żądania trwa dłużej niż 15 sekund. Program SQL Server zgłasza ten błąd i wskazuje problem z podsystemem we/wy. System zarządzania bazami danych (DBMS), taki jak PROGRAM SQL Server, opiera się na osi czasu operacji wejścia i wyjścia (we/wy). Każdy z następujących elementów może spowodować zablokowanie lub zatrzymanie operacji we/wy i niekorzystnie wpłynąć na czas odpowiedzi i wydajność programu SQL Server:

• Wadliwy sprzęt
• Niepoprawnie skonfigurowany sprzęt
• Ustawienia oprogramowania układowego
• Sterowniki filtrów
• Kompresja
• Usterki
• Inne warunki w ścieżce we/wy

Te problemy we/wy mogą powodować następujące zachowanie:

• Blokowanie.
• Rywalizacja o zatrzasanie i przekroczenia limitu czasu.
• Wolny czas odpowiedzi.
• Rozciąganie granic zasobów.
• Możesz również zauważyć inne objawy związane z tym komunikatem, takie jak:
  • Długie czasy oczekiwania na oczekiwania PAGEIOLATCH.
  • Ostrzeżenia lub błędy w dzienniku zdarzeń systemu.
  • Wskazania dotyczące problemów z opóźnieniem dysku w licznikach monitora systemu.

Jeśli operacja we/wy jest oczekująca przez 15 sekund lub dłużej, program SQL Server wykonuje następujące kroki:

1. Wykrywa, że operacja została oczekująca.

2. Zapisuje komunikat informacyjny w dzienniku błędów programu SQL Server zgodnie z opisem w sekcji Szczegóły.

   Wyjaśnienie różnych sekcji tego komunikatu informacyjnego znajduje się w poniższej tabeli:

Tekst wiadomości	Opis
< Numer> wystąpienia	Liczba żądań we/wy, które nie ukończyły operacji odczytu lub zapisu w mniej niż 15 sekund.
Informacje o pliku	Pełna nazwa pliku, nazwa bazy danych i numer identyfikacyjny bazy danych (DBID).
Uchwyt	Dojście systemu operacyjnego pliku. Możesz użyć uchwytu systemu operacyjnego z debugerami lub innymi narzędziami, aby ułatwić śledzenie żądań pakietów we/wy (IRP).
Przesunięcie	Przesunięcie ostatniej zablokowanej operacji we/wy lub ostatniej zatrzymanej operacji we/wy. Możesz użyć przesunięcia z debugerami lub innymi narzędziami, aby ułatwić śledzenie żądań IRP. Uwaga: gdy komunikat informacyjny jest zapisywany w dzienniku błędów programu SQL Server, operacja we/wy może już nie zostać zablokowana ani zatrzymana.

Możliwe przyczyny

Komunikat informacyjny wskazuje, że bieżące obciążenie może mieć jeden z następujących warunków:

• Obciążenie przekracza możliwości ścieżki we/wy albo ze względu na błędną konfigurację podsystemu we/wy (SAN, NAS i bezpośrednio dołączone) lub z powodu osiągnięcia wydajności sprzętu.
• Obciążenie przekracza bieżące możliwości systemowe, takie jak operacje we/wy, procesory CPU i karty HBA.
• Ścieżka we/wy ma nieprawidłowe działanie oprogramowania. Może to być problem z oprogramowaniem układowym lub sterownikiem.
• Ścieżka we/wy ma nieprawidłowe składniki sprzętowe.
• Problem z wydajnością na poziomie systemu operacyjnego.
• Interwencja sterownika filtru w procesie we/wy lub ścieżce magazynu plików bazy danych. Na przykład program antywirusowy.

Program SQL Server rejestruje czas zainicjowania żądania we/wy i rejestruje czas zakończenia operacji we/wy. Jeśli ta różnica wynosi 15 sekund lub dłużej, ten warunek zostanie wykryty. Oznacza to również, że program SQL Server nie jest przyczyną opóźnionego stanu we/wy, który ten komunikat opisuje i zgłasza. Ten warunek jest znany jako wstrzymane we/wy. Większość żądań dysku występuje w typowej szybkości dysku. Ta typowa szybkość dysku jest często nazywana czasem wyszukiwania dysku. Czas wyszukiwania dysku dla większości dysków standardowych występuje w ciągu 10 milisekund lub mniej. W związku z tym 15 sekund jest długi czas dla ścieżki we/wy systemu, aby powrócić do programu SQL Server. Aby uzyskać więcej informacji, zobacz sekcję Więcej informacji .

Akcja użytkownika

Rozwiąż ten błąd, wykonując następujące czynności:

1. Sprawdź dziennik zdarzeń systemu pod kątem komunikatów o błędach związanych ze sprzętem.
2. Sprawdź dzienniki specyficzne dla sprzętu, jeśli są dostępne. Użyj niezbędnych metod i technik, aby określić przyczynę opóźnienia w systemie operacyjnym, sterownikach lub sprzęcie we/wy.
3. Zaktualizuj wszystkie sterowniki urządzeń i oprogramowanie układowe lub wykonaj inną diagnostykę skojarzona z podsystemem we/wy.
4. Dostęp do dysku może zostać spowolniony przez sterowniki filtrów, na przykład program antywirusowy. Aby zwiększyć szybkość dostępu, wyklucz pliki danych programu SQL Server określone w komunikacie o błędzie z aktywnych skanowań wirusów. Aby uzyskać więcej informacji, zobacz Jak wybrać oprogramowanie antywirusowe do uruchamiania na komputerach z programem SQL Server (microsoft.com).
   • Użyj narzędzia wiersza poleceniafltmc.exe , aby wykonać zapytanie dotyczące wszystkich sterowników filtrów zainstalowanych w systemie i poznać funkcje wykonywane na ścieżce magazynu do plików bazy danych.
5. Użyj monitora wydajności, aby sprawdzić następujące liczniki:
   • Średni dysk na sekundę/transfer
   • Średnia długość kolejki dysku
   • Bieżąca długość kolejki dysku
6. Możesz również użyć obiektów, takich jak rejestrowanie Storport ETW , aby zmierzyć opóźnienie żądań wysyłanych do jednostki dysku. Inny podobny zestaw do rozwiązywania problemów z we/wy dysku jest dostępny jako wbudowany profil rejestratora wydajności systemu Windows.
7. Monitoruj sys.dm_io_virtual_file_stats i wybierz odpowiednią warstwę magazynowania i liczbę operacji we/wy na sekundę dla przepływności magazynu.

Aby zapoznać się z przewodnikiem dotyczącym diagnozowania i rozwiązywania problemów z wydajnością programu SQL Server występujących z powodu problemów z we/wy, zobacz Rozwiązywanie problemów z niską wydajnością programu SQL Server spowodowanych problemami we/wy.

Więcej informacji

Zablokowane we/wy i zablokowane we/wy

Zablokowane we/wy

Zablokowane we/wy jest definiowane jako żądanie we/wy, które nie zostało ukończone. Często zablokowane we/wy wskazuje zablokowany protokół IRP. Aby rozwiązać problem z zablokowanym stanem we/wy, zazwyczaj należy ponownie uruchomić komputer lub wykonać podobną akcję. Zablokowany warunek we/wy zwykle wskazuje jeden z następujących problemów:

• Uszkodzony sprzęt.
• Usterka w składniku ścieżki we/wy.

Wstrzymano we/wy

Zatrzymane we/wy jest definiowane jako żądanie we/wy, które zostało ukończone lub które zajmuje zbyt dużo czasu na ukończenie. Zatrzymane zachowanie we/wy zwykle występuje z jednego z następujących powodów:

• Konfiguracja sprzętu.
• Ustawienia oprogramowania układowego.
• Problem ze sterownikiem filtru, który wymaga pomocy od sprzętu lub dostawcy oprogramowania w celu śledzenia i rozwiązywania problemów.

Program SQL Server wstrzymał we/wy i zablokował rejestrowanie i raportowanie we/wy

Obsługa programu SQL Server obsługuje wiele przypadków każdego roku, które obejmują zablokowane lub zablokowane problemy we/wy. Te problemy we/wy pojawiają się na różne sposoby. Problemy z we/wy są jednymi z najtrudniejszych do zdiagnozowania i debugowania, które wymagają znacznego czasu i zasobów na potrzeby debugowania od firmy Microsoft i klienta. Raportowanie i rejestrowanie żądań we/wy zaprojektowano na podstawie poszczególnych plików. Wykrywanie i raportowanie zablokowanych żądań we/wy to dwie oddzielne akcje.

nagrywanie

W programie SQL Server występują dwie chwile. Pierwszy to po zakończeniu operacji we/wy. Drugi moment jest wtedy, gdy leniwy pisarz działa. Po uruchomieniu z opóźnieniem moduł zapisywania sprawdza wszystkie oczekujące dane i oczekujące żądania we/wy pliku dziennika. Jeśli żądanie we/wy przekroczy próg 15 sekund, nastąpi operacja rekordu.

Raportowanie

Raportowanie odbywa się w interwałach, które są od siebie co najmniej pięć minut. Raportowanie odbywa się po wysłaniu następnego żądania we/wy w pliku. Jeśli wystąpiła akcja rekordu i minęło co najmniej pięć minut od ostatniego raportu, komunikat informacyjny wymieniony w sekcji Szczegóły jest zapisywany w dzienniku błędów programu SQL Server.

Próg 15 sekund nie jest regulowany. Można jednak wyłączyć wykrywanie we/wy w martwym punkcie lub zablokować je przy użyciu flagi śledzenia 830, chociaż nie zalecamy wykonania tej czynności.

Wykrywanie zablokowanych operacji we/wy można wyłączyć przy użyciu flagi śledzenia 830. Aby włączyć tę flagę za każdym razem, gdy program SQL Server jest uruchamiany, użyj parametru uruchamiania -T830. Aby wyłączyć wykrywanie dla aktualnie uruchomionego wystąpienia programu SQL Server, użyj następującej instrukcji:

    dbcc traceon(830, -1)

To ustawienie jest skuteczne tylko dla okresu życia procesu programu SQL Server.

Uwaga / Notatka

Żądanie we/wy, które zostanie wstrzymane lub zablokowane, jest zgłaszane tylko raz. Jeśli na przykład komunikat zgłasza, że 10 żądań we/wy zostanie zatrzymanych, te 10 raportów nie wystąpi ponownie. Jeśli następny komunikat zgłasza, że 15 żądań we/wy zostanie zatrzymanych, oznacza to, że 15 nowych żądań we/wy zostało zablokowanych.

Śledzenie pakietu żądania we/wy (IRP)

Program SQL Server używa standardowych wywołań interfejsu API systemu Microsoft Windows do odczytywania i zapisywania danych. Na przykład program SQL Server używa następujących funkcji:

• ZapiszPlik
• OdczytajPlik
• WriteFileScatter
• ReadFileGather

Żądanie odczytu lub zapisu jest obsługiwane przez system Windows jako pakiet żądania we/wy (IRP). Aby określić stan IRP, użyj obu następujących funkcji:

• Obsługa systemu Windows
• Rejestrowanie funkcji ETW storportu

Zalecamy sprawdzenie dostępności wszystkich dostępnych aktualizacji dla następujących elementów:

• System BIOS
• Oprogramowanie układowe
• Wszystkie inne składniki ścieżki we/wy

Skontaktuj się z dostawcami sprzętu przed wykonaniem dodatkowych akcji debugowania. Sesja debugowania prawdopodobnie będzie obejmować składnik sterownika, oprogramowania układowego lub sterownika filtru innej firmy.

Akcje dotyczące wydajności systemu i planu zapytań

Ogólnie rzecz biorąc, wydajność systemu może odgrywać kluczową rolę w przetwarzaniu we/wy. Podczas badania raportów dotyczących zablokowanych operacji we/wy należy wziąć pod uwagę ogólną kondycję systemu. Nadmierne obciążenia mogą spowodować spowolnienie całego systemu, w tym przetwarzanie we/wy. Zachowanie systemu w przypadku wystąpienia problemu może być kluczowym czynnikiem w określaniu głównej przyczyny problemu. Jeśli na przykład użycie procesora CPU wzrasta lub pozostaje wysokie, gdy wystąpi problem, może to oznaczać, że proces systemowy używa tak dużej ilości procesora CPU, że inne procesy są niekorzystnie dotknięte.

Liczniki wydajności

Aby monitorować wydajność operacji we/wy, sprawdź następujące liczniki wydajności dla określonych informacji o ścieżce we/wy:

• Średni dysk na sekundę/transfer
• Średnia długość kolejki dysku
• Bieżąca długość kolejki dysku

Na przykład średni czas s/transfer dysku na komputerze z uruchomionym programem SQL Server jest zwykle krótszy niż 15 milisekund. Jeśli wartość Average Disk Sec/Transfer wzrośnie, oznacza to, że podsystem we/wy nie jest optymalnie na bieżąco z zapotrzebowaniem we/wy.

Należy zachować ostrożność podczas korzystania z liczników wydajności, ponieważ program SQL Server w pełni wykorzystuje asynchroniczne możliwości we/wy, które mocno wypychają długość kolejki dysku. W związku z tym dłuższe długości kolejki dysków nie wskazują problemu.

W monitorze systemu Windows można przejrzeć licznik "Dysk fizyczny: bajty dysku/s" dla każdego dysku, którego dotyczy problem, i porównać szybkość działania z licznikami "Proces: bajty danych we/wy na sekundę" i "Proces: Inne bajty/s" dla każdego procesu. W tym celu należy określić, czy określony zestaw procesów generuje nadmierne żądania we/wy. Różne inne liczniki związane z we/wy w obiekcie Process ujawniają bardziej szczegółowe informacje. Jeśli ustalisz, że wystąpienie programu SQL Server jest odpowiedzialne za nadmierne obciążenie we/wy na serwerze, zobacz następną sekcję dotyczącą indeksów i równoległości. Aby zapoznać się ze szczegółowym omówieniem wykrywania i rozwiązywania wąskich gardeł we/wy, zobacz Rozwiązywanie problemów z niską wydajnością programu SQL Server spowodowanych problemami we/wy.

Indeksy i równoległość

Często występują nagłe wzrosty operacji we/wy, ponieważ brakuje indeksu. To zachowanie może poważnie wypchnąć ścieżkę we/wy. Przekazywanie korzystające z Kreatora obracania indeksów (ITW) może pomóc rozwiązać problem z obciążeniem we/wy w systemie. Jeśli zapytanie korzysta z indeksu zamiast skanowania w tabeli lub może używać sortowania lub skrótu, system może uzyskać następujące korzyści:

• Zmniejszenie liczby operacji we/wy fizycznej jest wymagane do wykonania akcji, która bezpośrednio tworzy korzyści z wydajności zapytania.
• Należy przewrócić mniej stron w pamięci podręcznej danych. W związku z tym te strony, które są w pamięci podręcznej danych, pozostają istotne dla aktywnych zapytań.
• Używane są sortowania i skróty, ponieważ indeks może brakować lub statystyki są nieaktualne. Możesz zmniejszyć użycie bazy danych tempdb i rywalizację przez dodanie co najmniej jednego indeksu.
• Redukcja jest dokonana w zasobach, operacjach równoległych lub obu tych operacjach. Ponieważ program SQL Server nie gwarantuje równoległego wykonywania zapytań, a obciążenie systemu jest brane pod uwagę, najlepiej zoptymalizować wszystkie zapytania pod kątem wykonywania szeregowego. Aby zoptymalizować zapytanie, otwórz analizator zapytań i ustaw sp_configure wartość maksymalnego stopnia równoległości na 1. Jeśli wszystkie zapytania są dostrojone do uruchamiania natychmiast jako operacja szeregowa, wykonywanie równoległe jest często lepszym wynikiem. Jednak wykonywanie równoległe jest często wybierane, ponieważ ilość danych jest duża. W przypadku brakującego indeksu może być konieczne wystąpienie dużego sortowania. Wiele procesów roboczych wykonujących operację sortowania spowoduje utworzenie szybszej odpowiedzi. Jednak ta akcja może znacznie zwiększyć presję na system. Duże żądania odczytu wielu procesów roboczych mogą powodować wzrost liczby operacji we/wy wraz ze zwiększonym użyciem procesora CPU. Zapytanie może być często dostrojone w celu szybszego uruchamiania i używania mniejszej liczby zasobów w przypadku dodania indeksu lub wystąpienia innej akcji dostrajania.

Praktyczne przykłady pomocy technicznej programu SQL Server

Poniższe przykłady zostały obsłużone przez pomoc techniczną programu SQL Server i obsługę eskalacji systemu Windows. Te przykłady mają na celu przedstawienie ram referencyjnych i pomoc w zapewnieniu oczekiwań dotyczących sytuacji utknięcia i zakleszczenia operacji we/wy. Zapewniają one również strukturę do zrozumienia, w jaki sposób system może mieć wpływ na system lub może reagować. Żaden konkretny sprzęt ani zestaw sterowników nie stanowią żadnego konkretnego ryzyka lub zwiększonego ryzyka związanego z innym. Wszystkie systemy są takie same w tym zakresie.

Przykład 1. Zapis dziennika, który jest zablokowany przez 45 sekund

Próba zapisania pliku dziennika programu SQL Server okresowo jest blokowana przez około 45 sekund. Zapis dziennika nie jest ukończony w odpowiednim czasie. To zachowanie tworzy warunek blokowania, który powoduje przekroczenie limitu czasu klienta przez 30 sekund.

Aplikacja przesłała zatwierdzenie do programu SQL Server, a zatwierdzenie jest zablokowane jako oczekujące na zapis dziennika. To zachowanie powoduje, że zapytanie będzie nadal przechowywać blokady i blokować przychodzące żądania od innych klientów. Następnie inni klienci zaczynają się upłynął limit czasu. Powoduje to problem, ponieważ aplikacja nie cofa otwartych transakcji po przekroczeniu limitu czasu zapytania. Spowoduje to utworzenie setek otwartych transakcji, które przechowują blokady. W związku z tym występuje poważna sytuacja blokująca.

Aby uzyskać więcej informacji na temat obsługi i blokowania transakcji, zobacz następujący artykuł z bazy wiedzy Microsoft Knowledge Base: 224453 Understanding and rozwiązywanie problemów z blokowaniem programu SQL Server

Aplikacja obsługuje witrynę internetową przy użyciu buforowania połączeń. W miarę blokowania większej liczby połączeń witryna internetowa tworzy więcej połączeń. Te połączenia stają się blokowane, a cykl będzie kontynuowany.

Ukończenie zapisu dziennika trwa około 45 sekund. Jednak w tym czasie tworzone są kopie zapasowe setek połączeń. Problemy blokujące powodują kilka minut czasu odzyskiwania dla programu SQL Server i aplikacji. W połączeniu z problemami z aplikacjami zatrzymany stan we/wy ma bardzo negatywny wpływ na system.

Rozwiązanie

Problem jest śledzony do zablokowanego żądania we/wy w sterowniku karty magistrali hosta (HBA). Komputer ma wiele kart HBA z obsługą trybu failover. Jeśli jedna karta HBA znajduje się w tyle lub nie komunikuje się z siecią magazynowania (SAN), wartość limitu czasu "ponów próbę przed przejściem w tryb failover" jest skonfigurowana do 45 sekund. Po przekroczeniu limitu czasu żądanie we/wy jest kierowane do drugiej karty HBA. Druga karta HBA obsługuje żądanie i szybko zostaje ukończona. Aby zapobiec takim warunkom wstrzymania, producent sprzętu zaleca ustawienie "ponów próbę przed przejściem w tryb failover" w ciągu pięciu sekund.

Przykład 2. Interwencja sterownika filtru

Wiele programów antywirusowych i produktów do tworzenia kopii zapasowych używa sterowników filtrów we/wy. Te sterowniki filtrów we/wy stają się częścią stosu żądań we/wy i mają dostęp do żądania IRP. Usługi pomocy technicznej produktów firmy Microsoft odnotowały różne problemy z usterkami, które tworzą zablokowane warunki we/wy lub utknęły w martwym punkcie w implementacji sterownika filtru.

Jednym z takich warunków jest sterownik filtru do przetwarzania kopii zapasowej, który umożliwia tworzenie kopii zapasowych plików, które są otwierane po utworzeniu kopii zapasowej. Administrator systemu uwzględnił katalog plików danych programu SQL Server w wyborach kopii zapasowej plików. Po utworzeniu kopii zapasowej kopia zapasowa próbuje zebrać prawidłowy obraz pliku w momencie rozpoczęcia tworzenia kopii zapasowej. Spowoduje to opóźnienie żądań we/wy. Żądania we/wy mogą być kompletne tylko raz, ponieważ oprogramowanie je obsługuje.

Po uruchomieniu kopii zapasowej wydajność programu SQL Server znacznie spada, ponieważ we/wy programu SQL Server są wymuszane jednorazowe ukończenie operacji we/wy. Logika jednorazowa polega na tym, że nie można wykonać operacji we/wy asynchronicznie, co wiąże się z problemem. W związku z tym, gdy program SQL Server oczekuje opublikowania żądania we/wy i kontynuowania, proces roboczy jest zablokowany w wywołaniu odczytu lub zapisu do momentu ukończenia żądania we/wy. Akcje sterownika filtru skutecznie wyłączają zadania przetwarzania, takie jak sql Server read-ahead. Ponadto inna usterka w sterowniku filtru pozostawia te akcje jednocześnie w procesie, nawet po zakończeniu tworzenia kopii zapasowej. Jedynym sposobem przywrócenia wydajności programu SQL Server jest ponowne uruchomienie programu SQL Server w celu zwolnienia i ponownego udostępnienia dojścia pliku bez interakcji sterownika filtru.

Rozwiązanie

Aby rozwiązać ten problem, pliki danych programu SQL Server są usuwane z procesu tworzenia kopii zapasowej plików. Producent oprogramowania rozwiązał problem, który pozostawił plik w trybie "jeden naraz".

Przykład 3. Ukryte błędy

Wiele systemów wysokiej klasy ma wielokanałowe ścieżki we/wy do obsługi równoważenia obciążenia lub podobnych działań. Pomoc techniczna firmy Microsoft napotkała problemy z oprogramowaniem do równoważenia obciążenia, w którym żądanie we/wy kończy się niepowodzeniem, ale oprogramowanie nie obsługuje poprawnie warunku błędu. Oprogramowanie może podejmować nieskończone próby ponawiania prób. Operacja we/wy zostaje zablokowana, a program SQL Server nie może ukończyć określonej akcji. Podobnie jak opisany wcześniej warunek zapisu dziennika, wiele słabych zachowań systemowych może wystąpić po takim stanie zaklinuje system.

Rozwiązanie

Aby rozwiązać ten problem, uruchom ponownie program SQL Server. Jednak czasami konieczne jest ponowne uruchomienie systemu operacyjnego w celu przywrócenia przetwarzania. Zalecamy również uzyskanie aktualizacji oprogramowania od dostawcy we/wy.

Przykład 4. Zdalne przechowywanie, dublowanie i dyski raid

Wiele systemów używa dublowania lub stosuje podobne kroki, aby zapobiec utracie danych. Niektóre systemy korzystające z dublowania są oparte na oprogramowaniu, a niektóre są oparte na sprzęcie. Sytuacja, która jest zwykle wykrywana przez pomoc techniczną firmy Microsoft dla tych systemów, to zwiększone opóźnienie.

Wzrost ogólnego czasu we/wy występuje, gdy we/wy musi zakończyć się, zanim zostanie uznane za ukończone. W przypadku zdalnych instalacji dublowania próby sieci mogą być zaangażowane. W przypadku wystąpienia awarii dysku i odbudowy systemu raid można również przerwać wzorzec we/wy.

Rozwiązanie

Ścisłe ustawienia konfiguracji są wymagane w celu zmniejszenia opóźnienia dublowania lub ponownego kompilowania operacji nalotu.

Przykład 5. Kompresja

Firma Microsoft nie obsługuje plików danych programu SQL Server i plików dziennika na skompresowanych dyskach. Kompresja NTFS nie jest bezpieczna dla programu SQL Server, ponieważ kompresja NTFS przerywa protokół Write Ahead Logging (WAL). Kompresja NTFS wymaga również zwiększonego przetwarzania dla każdej operacji we/wy. Kompresja tworzy "jeden naraz", takie jak zachowanie, które powoduje wystąpienie poważnych problemów z wydajnością.

Rozwiązanie

Aby rozwiązać ten problem, usuń dekompresuj dane i pliki dziennika.

Aby uzyskać więcej informacji, zobacz Obsługa baz danych na skompresowanych woluminach.

Dodatkowe punkty danych

PAGEIOLATCH_* i oczekiwania zapisu w dynamicznych widokach zarządzania (DMV) sys.dm_os_wait_stats są kluczowymi wskaźnikami w celu zbadania wydajności ścieżki we/wy. Jeśli widzisz znaczące oczekiwania PAGEIOLATCH, oznacza to, że program SQL Server czeka na podsystem we/wy. Pewna ilość oczekiwania PAGEIOLATCH jest typowa i oczekiwana. Jeśli jednak średni czas oczekiwania PAGEIOLATCH jest stale większy niż 10 milisekund, należy zbadać, dlaczego podsystem we/wy jest pod presją. Więcej informacji można znaleźć w następujących dokumentach:

• Rozwiązywanie problemów z niską wydajnością SQL Server spowodowaną przez problemy z we/wy
• sys.dm_os_waiting_tasks (Transact-SQL)
• sys.dm_exec_requests
• Repozytorium typu oczekiwania programu SQL Server

Dokumentacja

• Używanie narzędzia DISKSPD do testowania wydajności magazynu pod obciążeniem
• diagnostyka programu SQL Server wykrywa nieraportowane problemy we/wy spowodowane nieaktualnymi operacjami odczytu lub utraconymi zapisami
• Algorytmy rejestrowania i przechowywania danych

Program SQL Server wymaga, aby systemy obsługiwały "gwarantowane dostarczanie do stabilnego nośnika", zgodnie z opisem w temacie Wymagania dotyczące 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 danych wejściowych/wyjściowych aparatu bazy danych.

Aby uzyskać więcej informacji na temat błędów we/ wy, zobacz Podstawy we/wy programu Microsoft SQL Server, rozdział 2.