Freigeben über

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

  • Artikel

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

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

Problembeschreibung

Gehen Sie davon aus, dass Sie eine der folgenden Aktionen auf einem Computer ausführen, auf dem SQL Server ausgeführt wird:

  • Sie erstellen eine Datenbankmomentaufnahme in einer großen Datenbank. Anschließend führen Sie zahlreiche Datenänderungs- oder Wartungsvorgänge in der Quelldatenbank aus.
  • Sie erstellen eine Datenbankmomentaufnahme in einer Spiegeldatenbank.
  • Sie führen die DBCC CHECKDB Familie der Befehle 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.

Notiz

SQL Server verwendet sparse Dateien für diese Vorgänge: Datenbankmomentaufnahme und DBCC CHECKDB.

  • Sicherung oder Wiederherstellung von Datenbanken.
  • Sie führen Massenkopien über BCP in mehrere Dateien mithilfe paralleler BCP-Ausführung und Schreiben auf dasselbe Volume aus.

Aufgrund dieser Vorgänge können Sie feststellen, dass je nach Der Umgebung, auf der SQL Server-Fehler ausgeführt wird, mindestens ein dieser Fehler im SQL Server-Fehlerprotokoll gemeldet 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 feststellen:

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 können Sie beim Anzeigen verschiedener dynamischer Verwaltungsansichten (DYNAMIC Management Views, DMV) blockieren, z sys.dm_exec_requests . B. und sys.dm_os_waiting_tasks.

In seltenen Fällen können Sie ein nicht ertragendes Planerproblem beobachten, das im SQL Server-Fehlerprotokoll gemeldet wurde und dass 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 aufrechtzuerhalten. Wenn sich das Leerzeichen neben einem Cluster befindet, der bereits vom Dateisystem nachverfolgt wird, werden die Attribute in einen einzelnen Eintrag komprimiert. Wenn der Raum jedoch fragmentiert ist, muss er mit mehreren Attributen nachverfolgt werden. Daher kann eine starke Dateifragmentierung zu 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 kann nicht über eine bestimmte Größe hinausgehen.

Sowohl normale als auch spärliche Dateien, die von SQL Server oder anderen Anwendungen erstellt wurden, können auf diese Ebenen fragmentiert werden, wenn große Datenmengen für die Lebensdauer dieser Momentaufnahmendateien vorgenommen werden.

Wenn Sie Datenbanksicherungen über einen Stripesatz von Dateien ausführen, die sich alle auf demselben Volume befinden, oder wenn Sie BCP-ing-Daten (Massenkopien) in mehrere Dateien auf demselben Volume kopieren, können die Schreibvorgänge an benachbarten Speicherorten enden, aber zu verschiedenen Dateien gehören. Beispielsweise schreibt ein Datenstrom zwischen 201 und 400, der andere Datenstrom schreibt zwischen 401 und 600, der dritte Datenstrom kann zwischen 601 und 800 schreiben. Dieser Prozess wird auch für andere Datenströme fortgesetzt. Dies führt zur Dateifragmentierung auf denselben physischen Medien. Jede der Sicherungsdateien oder BCP-Ausgabedatenströme kann den Attributspeicher ausschöpfen, da keiner davon angrenzenden Speicher erhält.

Einen vollständigen Hintergrund der Verwendung von NTFS-Sparsedateien und alternativen Datenströmen 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 über die gleichen ATTRIBUTE_LIST_ENTRY Grenzwerte verfügt, die NTFS darstellt. Wenn Sie das aktuelle NTFS-Volume verwenden möchten, müssen Sie reformatieren, nachdem Sie Ihre Datenbankdateien vorübergehend verschoben haben. Die Verwendung von ReFS ist die beste langfristige Lösung, um dieses Problem zu bewältigen.

    Notiz

    SQL Server 2012 und frühere Versionen haben benannte Dateidatenströme anstelle von sparsamen Dateien zum Erstellen von CHECKDB Momentaufnahmen verwendet. ReFS unterstützt keine Dateidatenströme. Die Ausführung DBCC CHECKDB auf SQL Server 2012-Dateien in ReFS kann zu Fehlern führen. Weitere Informationen finden Sie in der Notiz in how DBCC CHECKDB creates an internal snapshot database beginning with SQL Server 2014.

  2. Defragmentieren Sie das Volume, in dem sich die Datenbankdateien befinden. Stellen Sie sicher, dass ihr Defragmentierungshilfsprogramm transaktionsal ist. Weitere Informationen zum Defragmentieren von Laufwerken, auf denen SICH SQL Server-Dateien befinden, finden Sie unter Vorsichtsmaßnahmen beim Defragmentieren von 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. Defragmentierung funktioniert auf SSD-Medien (Solid State Drives) unterschiedlich und löst das Problem in der Regel nicht. Das Kopieren der Dateien und das Zulassen, dass die SSD-Firmware den physischen Speicher umpackt, ist häufig eine bessere Lösung. Weitere Informationen finden Sie unter Betriebssystemfehler (665: Dateisystemeinschränkung) – Nicht mehr nur für DBCC.

  3. Dateikopie – Das Ausführen einer Kopie der Datei kann einen besseren Speicherplatzerwerb ermöglichen, da die Bytes möglicherweise eng im Prozess 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 Datenbankdateien auf ein anderes Laufwerk. Anschließend können Sie die Datei auf dem neuen Volume belassen oder wieder 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 diesem Problem Entlastung bieten, da sie größer ATTRIBUTE_LIST_ENTRY wird. Diese Auswahl ist bei der Verwendung DBCC CHECKDB möglicherweise nicht hilfreich, da letztere eine spärliche Datei für die Datenbankmomentaufnahme erstellt.

    Notiz

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

  5. Trennen Sie eine große Datenbank in kleinere Dateien. Wenn Sie beispielsweise eine 8-TB-Datendatei haben, können Sie sie in acht 1 TB-Datendateien aufteilen. Diese Option kann hilfreich sein, da weniger Änderungen an kleineren Dateien auftreten würden, wodurch die Attributausschöpfung weniger wahrscheinlich wird. Außerdem werden die Dateien im Prozess des Verschiebens von Daten kompakt organisiert, und die Fragmentierung würde reduziert. Nachfolgend sind allgemeine Schritte aufgeführt, die den Prozess beschreiben:

    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 jeder Tabelle automatisch unter den acht Dateien verteilt werden. Wenn eine Tabelle keinen gruppierten Index hat, erstellen Sie einen, und legen Sie ihn ab, um dasselbe zu erreichen.
    3. Verkleinern Sie die ursprüngliche 8-TB-Datei, die jetzt etwa 12 % voll ist.

  6. Einstellung für automatisches Vergrößern der Datenbank: Passen Sie die Einstellung für die automatische Wachstumsdatenbank an, um Größen zu erwerben, die zur Produktionsleistung und zum Packen von NTFS-Attributen beitragen. Je seltener die Vorkommen des automatischen Wachstums und je größer die Größe des Wachstums inkrementiert werden, desto wahrscheinlicher ist die Wahrscheinlichkeit einer Dateifragmentierung.

  7. Verringern Sie die Lebensdauer von DBCC CHECK Befehlen mithilfe der Leistungsverbesserungen und vermeiden Sie somit die 665 Fehler: Verbesserungen für den BEFEHL DBCC CHECKDB können zu einer schnelleren Leistung führen, wenn Sie die option PHYSICAL_ONLY verwenden. Denken Sie daran, dass das Ausführen DBCC CHECKDB mit PHYSICAL_ONLY switch keine Garantie dafür bietet, dass Sie diesen Fehler vermeiden, aber es verringert die Wahrscheinlichkeit in vielen Fällen.

  8. Wenn Sie Datenbanksicherungen über viele Dateien hinweg durchführen (Stripe set), planen Sie sorgfältig die Anzahl der Dateien MAXTRANSFERSIZE und BLOCKSIZE (siehe SICHERUNG). Ziel ist es, die Fragmente auf dem Dateisystem zu reduzieren, die im Allgemeinen durch das Zusammenschreiben der größeren Byteblöcke in eine Datei erreicht werden. Sie sollten die Dateien möglicherweise über mehrere Volumes hinweg entfernen, um die Leistung zu beschleunigen und die Fragmentierung zu verringern.

  9. Wenn Sie BCP verwenden, um mehrere Dateien gleichzeitig zu schreiben, passen Sie die Größen des Hilfsprogramms an, um beispielsweise die BCP-Batchgröße zu erhöhen. Erwägen Sie außerdem das Schreiben mehrerer Datenströme in verschiedene Volumes, um Fragmentierung zu vermeiden oder die Anzahl paralleler Schreibvorgänge zu verringern.

  10. Zur Ausführung DBCC CHECKDBkö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 auszuladen und zu vermeiden, dass die Probleme auftreten, die durch die starke Fragmentierung von spärlichen Dateien verursacht werden.

  11. Wenn Sie den DBCC CHECKDBBefehl gleichzeitig ausführen, wenn auf dem Datenbankserver wenig Aktivität vorhanden ist, werden die sparsamen Dateien leicht aufgefüllt. Je weniger Schreibvorgänge in die Dateien führen, 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 die Datenbank, die den Spaltenspeicherindex in SQL Server 2014 enthält.

Weitere Informationen