Udostępnij za pośrednictwem

Błędy systemu operacyjnego 665 i 1450 są zgłaszane dla plików programu SQL Server

  • Artykuł

Ten artykuł pomaga rozwiązać problem polegający na tym, że błędy systemu operacyjnego 1450 i 665 są zgłaszane dla plików bazy danych podczas wykonywania DBCC CHECKDB, tworzenia migawki bazy danych lub wzrostu pliku.

Oryginalna wersja produktu: SQL Server
Oryginalny numer KB: 2002606

Symptomy

Załóżmy, że wykonasz jedną z następujących akcji na komputerze z uruchomionym programem SQL Server:

  • Utworzysz migawkę bazy danych w dużej bazie danych. Następnie wykonujesz wiele operacji modyfikacji danych lub konserwacji w źródłowej bazie danych.
  • Migawkę bazy danych można utworzyć w dublowej bazie danych.
  • Wykonujesz rodzinę DBCC CHECKDB poleceń, aby sprawdzić spójność dużej bazy danych, a także wykonać dużą liczbę zmian danych w tej bazie danych.

Uwaga 16.

Program SQL Server używa rozrzednych plików dla tych operacji: migawki bazy danych i DBCC CHECKDB.

  • Tworzenie kopii zapasowej lub przywracanie baz danych.
  • Kopie zbiorcze są wykonywane za pośrednictwem narzędzia BCP do wielu plików przy użyciu równoległych wykonań BCP i zapisu na tym samym woluminie.

W wyniku tych operacji można zauważyć co najmniej jeden z tych błędów zgłoszonych w dzienniku błędów programu SQL Server w zależności od środowiska, na którym działa program SQL Server.

The operating system returned error 665(The requested operation could not be completed due to a file system limitation) to SQL Server during a write at offset 0x00002a3ef96000 in file 'Sam.mdf:MSSQL_DBCC18'

The operating system returned error 1450 (Insufficient system resources exist to complete the requested service.) to SQL Server during a write at offset 0x00002a3ef96000 in file with handle 0x0000000000000D5C. This is usually a temporary condition and the SQL Server will keep retrying the operation. If the condition persists, then immediate action must be taken to correct it.`

Oprócz tych błędów można również zauważyć następujące błędy przekroczenia limitu czasu zatrzaśnięć:

Timeout occurred while waiting for latch: class *'DBCC_MULTIOBJECT_SCANNER'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  

Timeout occurred while waiting for latch: class *'ACCESS_METHODS_HOBT_COUNT'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.

Ponadto można również zauważyć blokowanie podczas wyświetlania różnych dynamicznych widoków zarządzania (DMV), takich jak sys.dm_exec_requests i sys.dm_os_waiting_tasks.

W rzadkich przypadkach w dzienniku błędów programu SQL Server może wystąpić problem z brakiem wydajności harmonogramu i że program SQL Server generuje zrzut pamięci.

Przyczyna

Ten problem występuje, jeśli wymagana jest duża liczba ATTRIBUTE_LIST_ENTRY wystąpień w celu obsługi mocno pofragmentowanego pliku w systemie plików NTFS. Jeśli miejsce znajduje się obok klastra, który jest już śledzony przez system plików, atrybuty są kompresowane do pojedynczego wpisu. Jeśli jednak spacja jest fragmentowana, musi być śledzona za pomocą wielu atrybutów. W związku z tym fragmentacja dużych plików może prowadzić do wyczerpania atrybutów i wynikowego błędu 665. To zachowanie zostało wyjaśnione w następującym artykule BAZY wiedzy: Mocno pofragmentowany plik w woluminie NTFS może nie wzrosnąć poza określony rozmiar.

Zarówno zwykłe, jak i rozrzedzone pliki utworzone przez program SQL Server lub inne aplikacje mogą być fragmentowane na tych poziomach, gdy w życiu tych plików migawek występują duże ilości modyfikacji danych.

W przypadku wykonywania kopii zapasowych bazy danych w zestawie plików znajdujących się na tym samym woluminie lub w przypadku zbiorczego kopiowania danych (BCP-ing) do wielu plików na tym samym woluminie zapisy mogą znajdować się w sąsiednich lokalizacjach, ale należących do różnych plików. Na przykład jeden zapis strumienia w celu przesunięcia między 201 a 400, drugi strumień zapisuje z 401 do 600, trzeci strumień może zapisywać z 601 do 800. Ten proces jest również kontynuowany dla innych strumieni. Spowoduje to fragmentację pliku na tym samym nośniku fizycznym. Każdy z plików kopii zapasowych lub strumieni wyjściowych BCP może wyczerpać magazyn atrybutów, ponieważ żaden z nich nie uzyskuje sąsiedniego magazynu.

Aby uzyskać pełne informacje na temat sposobu, w jaki aparat programu SQL Server używa rozrzedzynych plików NTFS i alternatywnych strumieni danych, zobacz Więcej informacji.

Rozwiązanie

Rozważ użycie co najmniej jednej z następujących opcji, aby rozwiązać ten problem:

  1. Umieść pliki bazy danych na woluminie systemu plików ReFS (Resilient File System), który nie ma tych samych ATTRIBUTE_LIST_ENTRY limitów, które przedstawia ntfs . Jeśli chcesz użyć bieżącego woluminu NTFS, musisz ponownie sformatować przy użyciu systemu plików ReFS po tymczasowym przeniesieniu plików bazy danych. Korzystanie z systemu plików ReFS to najlepsze długoterminowe rozwiązanie problemu.

    Uwaga 16.

    Program SQL Server 2012 i starsze wersje używały nazwanych strumieni plików zamiast rozrzednych plików do tworzenia CHECKDB migawek. System plików ReFS nie obsługuje strumieni plików. Uruchamianie DBCC CHECKDB w plikach programu SQL Server 2012 w systemie plików ReFS może spowodować błędy. Aby uzyskać więcej informacji, zobacz notatkę w temacie How DBCC CHECKDB tworzy wewnętrzną bazę danych migawek rozpoczynającą się od programu SQL Server 2014.

  2. Cofnięć fragment woluminu, w którym znajdują się pliki bazy danych. Upewnij się, że narzędzie defragmentacji jest transakcyjne. Aby uzyskać więcej informacji na temat defragmentacji dysków, na których znajdują się pliki programu SQL Server, zobacz Środki ostrożności podczas defragmentowania dysków bazy danych programu SQL Server i zaleceń. Aby wykonać tę operację na plikach, należy zamknąć program SQL Server. Zalecamy utworzenie pełnych kopii zapasowych bazy danych przed defragmentację plików jako środek bezpieczeństwa. Defragmentacja działa inaczej na nośnikach ssd i zwykle nie dotyczy problemu. Kopiowanie plików i umożliwienie ponownego spakowania magazynu fizycznego przez oprogramowanie układowe SSD jest często lepszym rozwiązaniem. Aby uzyskać więcej informacji, zobacz Błąd systemu operacyjnego (665 — ograniczenie systemu plików): już nie tylko dla DBCC.

  3. Kopiowanie pliku — wykonanie kopii pliku może pozwolić na uzyskanie lepszego miejsca, ponieważ bajty mogą być ściśle spakowane razem w procesie. Kopiowanie pliku (lub przeniesienie go do innego woluminu) może zmniejszyć użycie atrybutów i może zapobiec błędowi systemu operacyjnego 665. Skopiuj jeden lub więcej plików bazy danych na inny dysk. Następnie możesz pozostawić plik na nowym woluminie lub skopiować go z powrotem do oryginalnego woluminu.

  4. Sformatuj wolumin NTFS przy użyciu /L opcji, aby uzyskać duży frS. Ten wybór może zapewnić ulgę dla tego problemu, ponieważ sprawia, że ATTRIBUTE_LIST_ENTRY jest większy. Ten wybór może nie być przydatny w przypadku użycia DBCC CHECKDB , ponieważ ten ostatni tworzy plik rozrzednia migawki bazy danych.

    Uwaga 16.

    W przypadku systemów z systemem Windows Server 2008 R2 i Vista należy najpierw zastosować poprawkę z artykułu KB 967351 przed użyciem /L opcji za format pomocą polecenia .

  5. Podziel dużą bazę danych na mniejsze pliki. Jeśli na przykład masz jeden plik danych o rozmiarze 8 TB, możesz podzielić go na osiem plików danych o rozmiarze 1 TB. Ta opcja może pomóc, ponieważ mniejsza liczba modyfikacji będzie miała miejsce w mniejszych plikach, co powoduje mniejsze prawdopodobieństwo wprowadzenia wyczerpania atrybutów. Ponadto w procesie przenoszenia danych pliki będą zorganizowane zwartie, a fragmentacja zostanie zmniejszona. Poniżej przedstawiono ogólne kroki, które przedstawiają proces:

    1. Dodaj siedem nowych plików o rozmiarze 1 TB do tej samej grupy plików.
    2. Ponownie skompiluj indeksy klastrowane istniejących tabel, co spowoduje automatyczne rozłożenie danych każdej tabeli między osiem plików. Jeśli tabela nie ma indeksu klastrowanego, utwórz go i upuść, aby wykonać to samo.
    3. Zmniejsz oryginalny plik o rozmiarze 8 TB, który jest teraz około 12% pełny.

  6. Ustawienie automatycznego zwiększania bazy danych: dostosuj ustawienie automatycznej przyrostowej bazy danych, aby uzyskać rozmiary sprzyjające wydajności produkcyjnej i pakowania atrybutów NTFS. Im rzadsze wystąpienia automatycznego wzrostu i im większy rozmiar przyrostu, tym mniej prawdopodobne jest możliwość fragmentacji pliku.

  7. Zmniejsz okres istnienia DBCC CHECK poleceń przy użyciu ulepszeń wydajności, a tym samym unikaj błędów 665: Ulepszenia polecenia DBCC CHECKDB mogą spowodować szybszą wydajność podczas korzystania z opcji PHYSICAL_ONLY. Należy pamiętać, że uruchomienie DBCC CHECKDB z przełącznikiem PHYSICAL_ONLY nie zapewnia gwarancji, że ten błąd zostanie uniknąć, ale zmniejszy prawdopodobieństwo w wielu przypadkach.

  8. Jeśli wykonujesz kopie zapasowe bazy danych w wielu plikach (zestaw stripe), dokładnie zaplanuj liczbę plików MAXTRANSFERSIZE i (zobacz KOPIA ZAPASOWABLOCKSIZE). Celem jest zmniejszenie fragmentów w systemie plików, który jest zwykle osiągany przez zapisanie większych fragmentów bajtów razem do pliku. Możesz rozważyć usunięcie plików na wielu woluminach w celu zwiększenia wydajności i zmniejszenia fragmentacji.

  9. Jeśli używasz narzędzia BCP do jednoczesnego zapisywania wielu plików, dostosuj rozmiary zapisu narzędzi, na przykład zwiększ rozmiar partii BCP. Należy również rozważyć zapisanie wielu strumieni do różnych woluminów, aby uniknąć fragmentacji, lub zmniejszyć liczbę zapisów równoległych.

  10. Aby wykonać DBCC CHECKDBpolecenie , możesz rozważyć skonfigurowanie grupy dostępności lub serwera wysyłki dziennika/wstrzymania. Możesz też użyć drugiego serwera, na którym można uruchomić DBCC CHECKDB polecenia, aby odciążyć pracę i uniknąć wystąpienia problemów spowodowanych dużym fragmentacją rozrzedowanych plików.

  11. Po wykonaniu DBCC CHECKDBpolecenia , jeśli uruchomisz polecenie w czasie, gdy na serwerze bazy danych będzie mało aktywności, pliki rozrzedzonych zostaną lekko wypełnione. Mniejsza liczba operacji zapisu w plikach zmniejszy prawdopodobieństwo wyczerpania atrybutów w systemie plików NTFS. Mniejsze działanie to kolejny powód uruchamiania DBCC CHECKDB na drugim serwerze tylko do odczytu, jeśli jest to możliwe.

  12. Jeśli używasz programu SQL Server 2014, przeprowadź uaktualnienie do najnowszego dodatku Service Pack. Aby uzyskać więcej informacji, zobacz FIX: OS error 665 when you execute DBCC CHECKDB command for database that contains columnstore index in SQL Server 2014 (POPRAWKA: błąd systemu operacyjnego 665 podczas wykonywania polecenia DBCC CHECKDB dla bazy danych zawierającej indeks magazynu kolumn w programie SQL Server 2014).

Więcej informacji