Dela via

OS-felen 665 och 1450 rapporteras för SQL Server filer

  • Artikel

Den här artikeln hjälper dig att lösa problemet där OS-felen 1450 och 665 rapporteras för databasfiler när du kör DBCC CHECKDB, skapar en ögonblicksbild av databasen eller filtillväxt.

Ursprunglig produktversion: SQL Server
Ursprungligt KB-nummer: 2002606

Symptom

Anta att du utför någon av följande åtgärder på en dator som kör SQL Server:

  • Du skapar en databasögonblicksbild på en stor databas. Sedan utför du flera dataändringar eller underhållsåtgärder i källdatabasen.
  • Du skapar en databasögonblicksbild på en speglingsdatabas.
  • Du kör DBCC CHECKDB en serie kommandon för att kontrollera konsekvensen för en stor databas, och du utför också ett stort antal dataändringar i databasen.

Obs!

SQL Server använder glesa filer för dessa åtgärder: ögonblicksbild av databasen och DBCC CHECKDB.

  • Säkerhetskopiering eller återställning av databaser.
  • Du utför masskopiering via BCP till flera filer med parallella BCP-körningar och skriver till samma volym.

Som ett resultat av dessa åtgärder kanske du ser ett eller flera av dessa fel som rapporteras i SQL Server felloggen beroende på vilken miljö SQL Server körs på.

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

Förutom de här felen kan du även se följande timeout-fel för spärren:

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.

Dessutom kan du också märka blockering när du visar olika dynamiska hanteringsvyer (DMV), till exempel sys.dm_exec_requests och sys.dm_os_waiting_tasks.

I sällsynta fall kan du se ett problem med en schemaläggare som inte ger någon avkastning och som rapporteras i SQL Server felloggen och som SQL Server genererar en minnesdump.

Orsak

Det här problemet uppstår om ett stort antal ATTRIBUTE_LIST_ENTRY instanser behövs för att underhålla en kraftigt fragmenterad fil i NTFS. Om utrymmet ligger bredvid ett kluster som redan spåras av filsystemet komprimeras attributen till en enda post. Men om utrymmet är fragmenterat måste det spåras med flera attribut. Tung filfragmentering kan därför leda till attributöverbelastning och det resulterande 665-felet. Det här beteendet förklaras i följande KB-artikel: En kraftigt fragmenterad fil i en NTFS-volym kanske inte växer utöver en viss storlek.

Både vanliga och glesa filer som skapats av SQL Server eller andra program kan fragmenteras till dessa nivåer när stora mängder dataändringar sker under dessa ögonblicksbildsfilers livslängd.

Om du utför databassäkerhetskopior över en stripe-uppsättning filer som alla finns på samma volym, eller om du masskopierar (BCP-ing) data till flera filer på samma volym, kan skrivningarna hamna på intilliggande platser men tillhör olika filer. En ström skriver till exempel för offset mellan 201 och 400, den andra dataströmmen skriver från 401 till 600, den tredje dataströmmen kan skriva från 601 till 800. Den här processen fortsätter även för andra strömmar. Detta leder till filfragmentering på samma fysiska medier. Var och en av säkerhetskopieringsfilerna eller BCP-utdataströmmarna kan uttömma attributlagringen eftersom ingen av dem får intilliggande lagring.

En fullständig bakgrund av hur SQL Server Engine använder NTFS-sparse-filer och alternativa dataströmmar finns i Mer information.

Åtgärd

Överväg att använda ett eller flera av följande alternativ för att lösa problemet:

  1. Placera databasfilerna på en ReFS-volym (Resilient File System), som inte har samma ATTRIBUTE_LIST_ENTRY gränser som NTFS visar. Om du vill använda den aktuella NTFS-volymen måste du formatera om med ReFS när du tillfälligt har flyttat databasfilerna någon annanstans. Att använda ReFS är den bästa långsiktiga lösningen för att hantera det här problemet.

    Obs!

    SQL Server 2012 och tidigare versioner använde namngivna filströmmar i stället för glesa filer för att skapa CHECKDB ögonblicksbilder. ReFS stöder inte filströmmar. Om du kör DBCC CHECKDB på SQL Server 2012-filer i ReFS kan det leda till fel. Mer information finns i anteckningen i How DBCC CHECKDB create an internal snapshot database beginning with SQL Server 2014 (Hur DBCC CHECKDB skapar en intern ögonblicksbildsdatabas som börjar med SQL Server 2014).

  2. Dela upp volymen där databasfilerna finns. Kontrollera att defragmenteringsverktyget är transaktionellt. Mer information om defragmentering av enheter där SQL Server filer finns finns i Försiktighetsåtgärder när du defragmenterar SQL Server databasenheter och rekommendationer. Du måste stänga av SQL Server för att utföra den här åtgärden på filerna. Vi rekommenderar att du skapar fullständiga säkerhetskopior av databasen innan du defragmenterar filerna som en säkerhetsåtgärd. Defragmentering fungerar annorlunda på SSD-media (Solid State Drives) och löser vanligtvis inte problemet. Att kopiera filer och tillåta att den inbyggda SSD-programvaran packar om den fysiska lagringen är ofta en bättre lösning. Mer information finns i Operativsystemfel (665 – Filsystembegränsning) Inte bara för DBCC längre.

  3. Filkopiering – om du utför en kopia av filen kan det ge bättre utrymmesförvärv eftersom bytena kan vara tätt packade tillsammans i processen. Att kopiera filen (eller flytta den till en annan volym) kan minska attributanvändningen och kan förhindra OS-fel 665. Kopiera en eller flera av databasfilerna till en annan enhet. Sedan kan du lämna filen på den nya volymen eller kopiera tillbaka den till den ursprungliga volymen.

  4. Formatera NTFS-volymen med alternativet /L för att hämta en stor FRS. Det här valet kan underlätta det här problemet eftersom det gör det ATTRIBUTE_LIST_ENTRY större. Det här valet kanske inte är användbart när du använder DBCC CHECKDB eftersom det senare skapar en sparse-fil för databasögonblicksbilden.

    Obs!

    För system som kör Windows Server 2008 R2 och Vista måste du först använda snabbkorrigeringen från KB-artikeln 967351 innan du använder /L alternativet med format kommandot .

  5. Dela upp en stor databas i mindre filer. Om du till exempel har en datafil på 8 TB kan du dela upp den i åtta datafiler på 1 TB. Det här alternativet kan hjälpa eftersom färre ändringar skulle ske på mindre filer, vilket är mindre troligt att det medför attributöverbelastning. När data flyttas runt ordnas filerna också kompakt och fragmenteringen minskas. Följande är övergripande steg som beskriver processen:

    1. Lägg till de sju nya 1 TB-filerna i samma filgrupp.
    2. Återskapa de klustrade indexen för de befintliga tabellerna, vilket automatiskt sprider data för varje tabell mellan de åtta filerna. Om en tabell inte har ett grupperat index skapar du ett och släpper det för att åstadkomma samma sak.
    3. Krymp den ursprungliga 8 TB-filen, som nu är cirka 12 % full.

  6. Inställning för automatisk ökning av databas: Justera inställningen för automatisk ökning av databasen för att hämta storlekar som främjar produktionsprestanda och packning av NTFS-attribut. Ju mindre frekventa förekomster av automatisk tillväxt och ju större ökningsstorlek, desto mindre sannolikt är risken för filfragmentering.

  7. Minska livslängden för kommandon med hjälp av DBCC CHECK prestandaförbättringarna och undvik därför 665-fel: Förbättringar för DBCC CHECKDB-kommandot kan resultera i snabbare prestanda när du använder alternativet PHYSICAL_ONLY. Tänk på att körning DBCC CHECKDB med PHYSICAL_ONLY switch inte ger någon garanti för att du undviker det här felet, men det minskar sannolikheten i många fall.

  8. Om du utför databassäkerhetskopior över många filer (stripe-uppsättning) planerar du noggrant antalet filer MAXTRANSFERSIZE och BLOCKSIZE (se SÄKERHETSKOPIERing). Målet är att minska fragmenten i filsystemet, vilket vanligtvis uppnås genom att de större bytesegmenten skrivs ihop till en fil. Du kan överväga att ta bort filerna över flera volymer för snabbare prestanda och minskning av fragmentering.

  9. Om du använder BCP för att skriva flera filer samtidigt justerar du verktygsskrivningsstorlekarna, till exempel öka BCP-batchstorleken. Överväg också att skriva flera strömmar till olika volymer för att undvika fragmentering eller minska antalet parallella skrivningar.

  10. Om du vill köra DBCC CHECKDBkan du överväga att konfigurera en tillgänglighetsgrupp eller loggöverförings-/väntelägesserver. Eller använd en andra server där du kan köra DBCC CHECKDB kommandona för att avlasta arbetet och undvika att stöta på de problem som orsakas av den stora fragmenteringen av glesa filer.

  11. När du kör DBCC CHECKDB, om du kör kommandot vid en tidpunkt när det finns lite aktivitet på databasservern, fylls de glesa filerna lätt i. Ju färre skrivningar till filerna minskar sannolikheten för uttömning av attribut på NTFS. Mindre aktivitet är en annan anledning att köra DBCC CHECKDB på en andra skrivskyddad server, när det är möjligt.

  12. Om du kör SQL Server 2014 uppgraderar du till det senaste Service Pack. Mer information finns i Åtgärda: OS-fel 665 när du kör DBCC CHECKDB-kommandot för databasen som innehåller columnstore-index i SQL Server 2014.

Mer information