Delen via

Fouten in het besturingssysteem 665 en 1450 worden gerapporteerd voor SQL Server-bestanden

  • Artikel

Dit artikel helpt u bij het oplossen van het probleem waarbij besturingssysteemfouten 1450 en 665 worden gerapporteerd voor databasebestanden tijdens het uitvoeren DBCC CHECKDB, maken van een momentopname van een database of bestandsgroei.

Oorspronkelijke productversie: SQL Server
Oorspronkelijk KB-nummer: 2002606

Symptomen

Stel dat u een van de volgende acties uitvoert op een computer waarop SQL Server wordt uitgevoerd:

  • U maakt een momentopname van een database op een grote database. Vervolgens voert u talloze bewerkingen voor gegevenswijziging of onderhoudsbewerkingen uit in de brondatabase.
  • U maakt een momentopname van een database op een gespiegelde database.
  • U voert de DBCC CHECKDB reeks opdrachten uit om de consistentie van een grote database te controleren en u voert ook een groot aantal gegevenswijzigingen in die database uit.

Notitie

SQL Server maakt gebruik van sparse-bestanden voor deze bewerkingen: momentopname van de database en DBCC CHECKDB.

Als gevolg van deze bewerkingen ziet u mogelijk een of meer van deze fouten die worden gerapporteerd in het SQL Server-foutenlogboek, afhankelijk van de omgeving waarop SQL Server wordt uitgevoerd.

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.`

Naast deze fouten ziet u mogelijk ook de volgende time-outfouten voor vergrendeling:

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.

Daarnaast ziet u mogelijk ook blokkeren wanneer u verschillende dynamische beheerweergaven (DMV) bekijkt, zoals sys.dm_exec_requests en sys.dm_os_waiting_tasks.

In zeldzame gevallen kunt u een niet-opleverend scheduler-probleem observeren dat in het foutenlogboek van SQL Server is gerapporteerd en dat SQL Server een geheugendump genereert.

Oorzaak

Dit probleem treedt op als een groot aantal ATTRIBUTE_LIST_ENTRY exemplaren nodig zijn om een sterk gefragmenteerd bestand in NTFS te onderhouden. Als de ruimte zich naast een cluster bevindt dat al door het bestandssysteem wordt bijgehouden, worden de kenmerken gecomprimeerd in één vermelding. Als de ruimte echter is gefragmenteerd, moet deze worden bijgehouden met meerdere kenmerken. Daarom kan zware bestandsfragmentatie leiden tot kenmerkuitputting en de resulterende 665-fout. Dit gedrag wordt uitgelegd in het volgende KB-artikel: Een sterk gefragmenteerd bestand in een NTFS-volume kan niet groter worden dan een bepaalde grootte.

Zowel reguliere als sparsebestanden die zijn gemaakt door SQL Server of andere toepassingen, kunnen worden gefragmenteerd naar deze niveaus wanneer grote hoeveelheden gegevenswijzigingen plaatsvinden voor de levensduur van deze momentopnamebestanden.

Als u databaseback-ups uitvoert voor een stripe-set bestanden die zich allemaal op hetzelfde volume bevinden, of als u bulksgewijs gegevens kopieert (BCP-ing) naar meerdere bestanden op hetzelfde volume, kunnen de schrijfbewerkingen eindigen op aangrenzende locaties, maar behoren tot verschillende bestanden. Eén stream schrijft bijvoorbeeld naar offset tussen 201 en 400, de andere stream schrijft van 401 tot 600, de derde stream kan van 601 tot 800 schrijven. Dit proces wordt ook voortgezet voor andere streams. Dit leidt tot bestandsfragmentatie op dezelfde fysieke media. Elk van de back-upbestanden of BCP-uitvoerstromen kan de kenmerkopslag uitputten omdat ze geen aangrenzende opslag krijgen.

Zie meer informatie voor een volledige achtergrond van hoe SQL Server Engine NTFS-sparsebestanden en alternatieve gegevensstromen gebruikt.

Oplossing

U kunt een of meer van de volgende opties gebruiken om dit probleem op te lossen:

  1. Plaats de databasebestanden op een ReFS-volume (Resilient File System), dat niet dezelfde ATTRIBUTE_LIST_ENTRY limieten heeft als NTFS. Als u het huidige NTFS-volume wilt gebruiken, moet u ReFS opnieuw opmaken nadat u de databasebestanden ergens anders tijdelijk hebt verplaatst. Het gebruik van ReFS is de beste oplossing voor de lange termijn om dit probleem op te lossen.

    Notitie

    SQL Server 2012 en eerdere versies gebruikten benoemde bestandsstromen in plaats van sparsebestanden om momentopnamen te maken CHECKDB . ReFS biedt geen ondersteuning voor bestandsstreams. Uitvoeren DBCC CHECKDB op SQL Server 2012-bestanden in ReFS kan leiden tot fouten. Zie de opmerking in Hoe DBCC CHECKDB een interne momentopnamedatabase maakt vanaf SQL Server 2014 voor meer informatie.

  2. Defragmentatie van het volume waarin de databasebestanden zich bevinden. Zorg ervoor dat uw hulpprogramma voor de fragmentatie transactioneel is. Zie Voorzorgsmaatregelen wanneer u SQL Server-databasestations en aanbevelingen defragmenteert voor meer informatie over het defragmenteren van stations waarin SQL Server-bestanden zich bevinden. U moet SQL Server afsluiten om deze bewerking uit te voeren op de bestanden. U wordt aangeraden volledige databaseback-ups te maken voordat u de bestanden defragmenteert als veiligheidsmaatregel. Defragmentatie werkt anders op SSD-media (Solid-State Drives) en is doorgaans niet geschikt voor het probleem. Het kopiëren van de bestanden en het toestaan van de SSD-firmware om de fysieke opslag opnieuw te verpakken, is vaak een betere oplossing. Zie Operating System Error (665 - File System Limitation) Not just for DBCC Anymore (Besturingssysteemfout (665 - beperking van bestandssysteem) Niet alleen meer voor DBCC)) voor meer informatie.

  3. Bestandskopie: het uitvoeren van een kopie van het bestand kan een betere ruimteverwerving mogelijk maken, omdat de bytes mogelijk nauw zijn verpakt in het proces. Het kopiëren van het bestand (of het verplaatsen naar een ander volume) kan het gebruik van kenmerken verminderen en kan het besturingssysteemfout 665 voorkomen. Kopieer een of meer databasebestanden naar een ander station. Vervolgens kunt u het bestand op het nieuwe volume laten staan of het terug naar het oorspronkelijke volume kopiëren.

  4. Maak het NTFS-volume op met behulp van de optie /L om een grote FRS te verkrijgen. Deze keuze kan een oplossing bieden voor dit probleem, omdat dit des ATTRIBUTE_LIST_ENTRY te groter wordt. Deze keuze is mogelijk niet handig wanneer u deze gebruikt DBCC CHECKDB , omdat deze laatste een sparse-bestand maakt voor de momentopname van de database.

    Notitie

    Voor systemen met Windows Server 2008 R2 en Vista moet u eerst de hotfix toepassen vanuit het KB-artikel 967351 voordat u de /L optie met de format opdracht gebruikt.

  5. Een grote database opsplitsen in kleinere bestanden. Als u bijvoorbeeld een gegevensbestand van 8 TB hebt, kunt u het opsplitsen in acht gegevensbestanden van 1 TB. Deze optie kan helpen omdat er minder wijzigingen optreden op kleinere bestanden, waardoor de kans op uitputting van kenmerken minder groot is. In het proces van het verplaatsen van gegevens worden de bestanden ook compact georganiseerd en wordt fragmentatie verminderd. Hieronder vindt u stappen op hoog niveau, waarin het proces wordt beschreven:

    1. Voeg de zeven nieuwe 1 TB-bestanden toe aan dezelfde bestandsgroep.
    2. Bouw de geclusterde indexen van de bestaande tabellen opnieuw, waardoor de gegevens van elke tabel automatisch worden verspreid over de acht bestanden. Als een tabel geen geclusterde index heeft, maakt u er een en zet u deze neer om hetzelfde te bereiken.
    3. Verklein het oorspronkelijke bestand van 8 TB, dat nu ongeveer 12% vol is.

  6. Instelling voor automatisch vergroten van database: pas de database-instelling voor automatische groei aan om grootten te verkrijgen die leiden tot productieprestaties en het inpakken van NTFS-kenmerken. Hoe minder frequent de automatische groei voorkomt en hoe groter de toename van de groei, hoe minder waarschijnlijk de mogelijkheid van bestandsfragmentatie is.

  7. Verminder de levensduur van opdrachten met behulp van DBCC CHECK de prestatieverbeteringen en vermijd zo de 665-fouten: Verbeteringen voor de DBCC CHECKDB-opdracht kunnen leiden tot snellere prestaties wanneer u de optie PHYSICAL_ONLY gebruikt. Houd er rekening mee dat het uitvoeren DBCC CHECKDB met PHYSICAL_ONLY een switch geen garantie biedt dat u deze fout vermijdt, maar dat dit in veel gevallen de kans vermindert.

  8. Als u databaseback-ups uitvoert voor veel bestanden (stripe set), moet u het aantal bestanden MAXTRANSFERSIZE zorgvuldig plannen en BLOCKSIZE (zie BACKUP). Het doel is om de fragmenten in het bestandssysteem te verminderen die over het algemeen worden bereikt door de grotere bytesegmenten samen te schrijven naar een bestand. U kunt overwegen de bestanden over meerdere volumes te stripen voor snellere prestaties en het verminderen van fragmentatie.

  9. Als u BCP gebruikt om meerdere bestanden tegelijk te schrijven, past u schrijfgrootten van hulpprogramma's aan, bijvoorbeeld de BCP-batchgrootte verhogen. Overweeg ook om meerdere streams naar verschillende volumes te schrijven om fragmentatie te voorkomen of het aantal parallelle schrijfbewerkingen te verminderen.

  10. Als u wilt uitvoeren DBCC CHECKDB, kunt u overwegen om een beschikbaarheidsgroep of logboekverzending/stand-byserver in te stellen. Of gebruik een tweede server waar u de DBCC CHECKDB opdrachten kunt uitvoeren om het werk te offloaden en te voorkomen dat er problemen optreden die worden veroorzaakt door de zware fragmentatie van sparse-bestanden.

  11. Wanneer u de opdracht uitvoert DBCC CHECKDB, als u de opdracht uitvoert op een moment waarop er weinig activiteit op de databaseserver is, worden de sparse-bestanden licht gevuld. Hoe minder schrijfbewerkingen naar de bestanden de kans op uitputting van kenmerken op de NTFS verminderen. Minder activiteit is een andere reden om te worden uitgevoerd DBCC CHECKDB op een tweede alleen-lezenserver, indien mogelijk.

  12. Als u SQL Server 2014 uitvoert, voert u een upgrade uit naar het nieuwste Service Pack. Zie FIX: OS-fout 665 bij het uitvoeren van de DBCC CHECKDB-opdracht voor database die columnstore-index bevat in SQL Server 2014 voor meer informatie.

Meer informatie