Freigeben über

Die Betriebssystemfehler 665 und 1450 werden für SQL Server Dateien gemeldet.

  • Artikel

Dieser Artikel hilft Ihnen, das Problem zu beheben, bei dem die Betriebssystemfehler 1450 und 665 für Datenbankdateien gemeldet werden, während sie ausgeführt DBCC CHECKDBwerden, eine Datenbankmomentaufnahme erstellen oder eine Dateivergrößerung.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 2002606

Symptome

Angenommen, Sie führen eine der folgenden Aktionen auf einem Computer aus, auf dem SQL Server ausgeführt wird:

  • Sie erstellen eine Datenbank Momentaufnahme in einer großen Datenbank. Anschließend führen Sie zahlreiche Datenänderungs- oder Wartungsvorgänge in der Quelldatenbank aus.
  • Sie erstellen eine Datenbank Momentaufnahme für eine Spiegel-Datenbank.
  • Sie führen die DBCC CHECKDB Befehlsfamilie aus, um die Konsistenz einer großen Datenbank zu überprüfen, und Sie führen auch eine große Anzahl von Datenänderungen in dieser Datenbank aus.

Hinweis

SQL Server verwendet Sparsedateien für diese Vorgänge: Datenbank-Momentaufnahme und DBCC CHECKDB.

  • Sicherung oder Wiederherstellung von Datenbanken.
  • Sie führen das Massenkopieren über BCP in mehrere Dateien durch, indem Sie parallele BCP-Ausführungen verwenden und auf dasselbe Volume schreiben.

Als Ergebnis dieser Vorgänge bemerken Sie möglicherweise einen oder mehrere dieser Fehler, die im SQL Server Fehlerprotokoll gemeldet werden, abhängig von der Umgebung, in der SQL Server ausgeführt wird.

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

Zusätzlich zu diesen Fehlern können Sie auch die folgenden Latch Timeout-Fehler bemerken:

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.

Darüber hinaus bemerken Sie möglicherweise auch eine Blockierung, wenn Sie verschiedene dynamische Verwaltungssichten (Dynamic Management Views, DMV) anzeigen, z sys.dm_exec_requests . B. und sys.dm_os_waiting_tasks.

In seltenen Fällen kann es vorkommen, dass im SQL Server Fehlerprotokoll ein Problem mit einem planerischen Fehler gemeldet wird, bei dem SQL Server ein Speicherabbild generiert.

Ursache

Dieses Problem tritt auf, wenn eine große Anzahl von ATTRIBUTE_LIST_ENTRY Instanzen erforderlich ist, um eine stark fragmentierte Datei in NTFS zu verwalten. Wenn sich der Speicherplatz neben einem Cluster befindet, der bereits vom Dateisystem nachverfolgt wird, werden die Attribute in einem einzelnen Eintrag komprimiert. Wenn der Raum jedoch fragmentiert ist, muss er mit mehreren Attributen nachverfolgt werden. Daher kann eine starke Dateifragmentierung zu einer Attributerschöpfung und dem resultierenden 665-Fehler führen. Dieses Verhalten wird im folgenden KB-Artikel erläutert: Eine stark fragmentierte Datei in einem NTFS-Volume wächst möglicherweise nicht über eine bestimmte Größe hinaus.

Sowohl reguläre als auch sparse Dateien, die von SQL Server oder anderen Anwendungen erstellt werden, können auf diese Ebenen fragmentiert werden, wenn große Datenmengen während der Lebensdauer dieser Momentaufnahme Dateien geändert werden.

Wenn Sie Datenbanksicherungen über einen Stripesatz von Dateien durchführen, die sich alle auf demselben Volume befinden, oder wenn Sie Daten per Massenkopieren (BCP-ing) in mehrere Dateien auf demselben Volume kopieren, können die Schreibvorgänge an angrenzenden Speicherorten enden, die jedoch zu verschiedenen Dateien gehören. Beispielsweise schreibt ein Stream in einen Offset zwischen 201 und 400, der andere Stream schreibt zwischen 401 und 600, der dritte Stream kann zwischen 601 und 800 schreiben. Dieser Prozess wird auch für andere Streams fortgesetzt. Dies führt zu einer Dateifragmentierung auf demselben physischen Medium. Jede der Sicherungsdateien oder BCP-Ausgabestreams kann den Attributspeicher aufgebraucht haben, da keine davon angrenzenden Speicher erhält.

Einen vollständigen Hintergrund dazu, wie SQL Server Engine NTFS-Sparsedateien und alternative Datenströme verwendet, finden Sie unter Weitere Informationen.

Lösung

Erwägen Sie die Verwendung einer oder mehrerer der folgenden Optionen, um dieses Problem zu beheben:

  1. Platzieren Sie die Datenbankdateien auf einem ReFS-Volume (Resilient File System ), das nicht die gleichen ATTRIBUTE_LIST_ENTRY Grenzwerte aufweist wie NTFS . Wenn Sie das aktuelle NTFS-Volume verwenden möchten, müssen Sie das Format mit ReFS neu formatieren, nachdem Sie Ihre Datenbankdateien vorübergehend an eine andere Stelle verschoben haben. Die Verwendung von ReFS ist die beste langfristige Lösung, um dieses Problem zu beheben.

    Hinweis

    SQL Server 2012 und früheren Versionen wurden benannte Dateistreams anstelle von Sparsedateien verwendet, um Momentaufnahmen zu erstellenCHECKDB. ReFS unterstützt keine Dateistreams. Die Ausführung DBCC CHECKDB auf SQL Server 2012-Dateien in ReFS kann zu Fehlern führen. Weitere Informationen finden Sie im Hinweis unter How DBCC CHECKDB creates an internal Momentaufnahme database ab SQL Server 2014.

  2. Aufheben der Fragmentierung des Volumes, auf dem sich die Datenbankdateien befinden. Stellen Sie sicher, dass Ihr Defragmentierungshilfsprogramm transaktional ist. Weitere Informationen zum Defragmentieren von Laufwerken, auf denen sich SQL Server Dateien befinden, finden Sie unter Vorsichtsmaßnahmen beim Defragmentieren SQL Server Datenbanklaufwerken und Empfehlungen. Sie müssen SQL Server herunterfahren, um diesen Vorgang für die Dateien auszuführen. Es wird empfohlen, vollständige Datenbanksicherungen zu erstellen, bevor Sie die Dateien als Sicherheitsmaßnahme defragmentieren. Die Defragmentierung funktioniert auf SSD-Medien (Solid State Drives) anders und löst das Problem in der Regel nicht. Das Kopieren der Dateien und das Erneute Packen des physischen Speichers durch die SSD-Firmware ist häufig eine bessere Lösung. Weitere Informationen finden Sie unter Betriebssystemfehler (665 – Dateisystemeinschränkung) Nicht nur für DBCC Anymore.

  3. Dateikopie: Das Ausführen einer Kopie der Datei kann eine bessere Speicherplatzerfassung ermöglichen, da die Bytes im Prozess möglicherweise eng zusammengepackt sind. Das Kopieren der Datei (oder das Verschieben auf ein anderes Volume) kann die Attributnutzung verringern und den Betriebssystemfehler 665 verhindern. Kopieren Sie eine oder mehrere der Datenbankdateien auf ein anderes Laufwerk. Anschließend können Sie die Datei auf dem neuen Volume belassen oder auf das ursprüngliche Volume kopieren.

  4. Formatieren Sie das NTFS-Volume mithilfe der Option /L , um eine große FRS abzurufen. Diese Wahl kann dieses Problem erleichtern, da sie den ATTRIBUTE_LIST_ENTRY Größeren macht. Diese Auswahl ist bei der Verwendung DBCC CHECKDB möglicherweise nicht hilfreich, da letztere eine Sparsedatei für die Datenbank Momentaufnahme erstellt.

    Hinweis

    Für Systeme mit Windows Server 2008 R2 und Vista müssen Sie zunächst den Hotfix aus dem KB-Artikel 967351 anwenden, bevor Sie die /L Option mit dem format Befehl verwenden.

  5. Teilen Sie eine große Datenbank in kleinere Dateien auf. Wenn Sie beispielsweise über eine 8 TB-Datendatei verfügen, können Sie sie in acht 1-TB-Datendateien aufteilen. Diese Option kann hilfreich sein, da weniger Änderungen an kleineren Dateien vorgenommen werden, sodass die Wahrscheinlichkeit geringer ist, dass attributauslastungen auftreten. Außerdem werden die Dateien beim Verschieben von Daten kompakt organisiert, und die Fragmentierung würde reduziert. Im Folgenden werden allgemeine Schritte aufgeführt, in denen der Prozess beschrieben wird:

    1. Fügen Sie die sieben neuen 1-TB-Dateien derselben Dateigruppe hinzu.
    2. Erstellen Sie die gruppierten Indizes der vorhandenen Tabellen neu, wodurch die Daten der einzelnen Tabellen automatisch auf die acht Dateien verteilt werden. Wenn eine Tabelle keinen gruppierten Index aufweist, erstellen Sie einen Index, und löschen Sie ihn, um dasselbe zu erreichen.
    3. Verkleinern Sie die ursprüngliche 8-TB-Datei, die jetzt etwa 12 % voll ist.

  6. Einstellung für die automatische Vergrößerung der Datenbank: Passen Sie die Datenbankeinstellung für automatisches Wachstum an, um Größen zu erhalten, die der Produktionsleistung und dem Packen von NTFS-Attributen förderlich sind. Je seltener die automatische Vergrößerung auftritt und je größer die Vergrößerungsgröße, desto geringer ist die Wahrscheinlichkeit einer Dateifragmentierung.

  7. Verringern Sie die Lebensdauer von DBCC CHECK Befehlen mithilfe der Leistungsverbesserungen, und vermeiden Sie so die 665-Fehler: Verbesserungen für den DBCC CHECKDB-Befehl können zu einer höheren Leistung führen, wenn Sie die Option PHYSICAL_ONLY verwenden. Beachten Sie, dass die Ausführung DBCC CHECKDB mit PHYSICAL_ONLY switch keine Garantie dafür bietet, dass Sie diesen Fehler vermeiden, aber die Wahrscheinlichkeit in vielen Fällen verringert wird.

  8. Wenn Sie Datenbanksicherungen über viele Dateien hinweg durchführen (Stripe-Set), planen Sie die Anzahl der Dateien MAXTRANSFERSIZE sorgfältig und BLOCKSIZE (siehe BACKUP). Das Ziel besteht darin, die Fragmente im Dateisystem zu reduzieren, was im Allgemeinen erreicht wird, indem die größeren Byteblöcke in eine Datei geschrieben werden. Sie können erwägen, die Dateien auf mehreren Volumes zu strippen, um die Leistung zu beschleunigen und die Fragmentierung zu reduzieren.

  9. Wenn Sie BCP verwenden, um mehrere Dateien gleichzeitig zu schreiben, passen Sie die Schreibgrößen des Hilfsprogramms an, z. B. erhöhen Sie die BCP-Batchgröße. Erwägen Sie außerdem, mehrere Datenströme auf verschiedene Volumes zu schreiben, um Fragmentierung zu vermeiden oder die Anzahl paralleler Schreibvorgänge zu reduzieren.

  10. Zum Ausführen DBCC CHECKDBvon können Sie eine Verfügbarkeitsgruppe oder einen Protokollversand-/Standbyserver einrichten. Oder verwenden Sie einen zweiten Server, auf dem Sie die DBCC CHECKDB Befehle ausführen können, um die Arbeit auszulagern und zu vermeiden, dass probleme auftreten, die durch die starke Fragmentierung von Sparsedateien verursacht werden.

  11. Wenn Sie ausführen DBCC CHECKDB, werden die Sparsedateien leicht aufgefüllt, wenn Sie den Befehl zu einem Zeitpunkt ausführen, zu dem nur wenige Aktivitäten auf dem Datenbankserver ausgeführt werden. Je weniger Schreibvorgänge in die Dateien ausgeführt werden, verringert die Wahrscheinlichkeit, dass Attribute auf dem NTFS erschöpft sind. Weniger Aktivitäten sind ein weiterer Grund für die Ausführung DBCC CHECKDB auf einem zweiten schreibgeschützten Server, wenn möglich.

  12. Wenn Sie SQL Server 2014 ausführen, führen Sie ein Upgrade auf das neueste Service Pack durch. Weitere Informationen finden Sie unter FIX: Betriebssystemfehler 665 beim Ausführen des DBCC CHECKDB-Befehls für eine Datenbank, die einen Columnstore-Index in SQL Server 2014 enthält.

Weitere Informationen