2009-12-23 10 views
44

Unsere Datenbank ist derzeit bei 64 Gb und einer unserer Apps gestartet mit dem folgenden Fehler fehlschlagen:„primäre Dateigruppe ist voll“ in SQL Server 2008 Standard ohne ersichtlichen Grund

System.Data.SqlClient.SqlException : Could not allocate space for object 'cnv.LoggedUnpreparedSpos'.'PK_LoggedUnpreparedSpos' in database 'travelgateway' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

ich doppelt überprüft alles : Alle Dateien in einer einzelnen Dateigruppe dürfen sich in angemessenen Schritten automatisch vergrößern (100 MB für eine Datendatei, 10% für eine Protokolldatei), mehr als 100 GB freier Speicherplatz für die Datenbank, tempdb ist auf automatische Vergrößerung eingestellt gut mit viel freiem Festplattenspeicher auf seiner Festplatte.

Um ein Problem zu beheben, habe ich eine zweite Datei zur Dateigruppe hinzugefügt und der Fehler ist verschwunden. Aber ich fühle mich in dieser ganzen Situation unwohl.

Wo ist das Problem, Jungs?

+1

Und es ist keine maximale Dateigröße angegeben? –

Antwort

25

OK, habe es funktioniert. Stellt sich heraus, dass ein NTFS-Volume, wo die DB-Dateien gefunden wurden schwer fragmentiert. Gestoppt SQL Server, defragmentiert die ganze Sache und alles war gut seitdem.

+0

Danke, wachte auf, um das gleiche Problem heute zu lösen und das Defragmentieren der Datendatei (.mdf) reparierte es. Ich habe Defraggler benutzt. – dtbarne

+0

Ich hatte das gleiche Problem und nach dem Ausführen der Defragmentierung auf der Festplatte wurde die Datendatei gespeichert, es wurde gelöst! Vielen Dank. –

2

fand ich, dass dies geschieht, weil: http://support.microsoft.com/kb/913399

SQL Server only releases all the pages that a heap table uses when the following conditions are true: A deletion on this table occurs. A table-level lock is being held. Note A heap table is any table that is not associated with a clustered index.

If pages are not deallocated, other objects in the database cannot reuse the pages.

However, when you enable a row versioning-based isolation level in a SQL Server 2005 database, pages cannot be released even if a table-level lock is being held.

Microsoft-Lösung: http://support.microsoft.com/kb/913399

To work around this problem, use one of the following methods: Include a TABLOCK hint in the DELETE statement if a row versioning-based isolation level is not enabled. For example, use a statement that is similar to the following:

DELETE FROM TableName WITH (TABLOCK)

Note represents the name of the table. Use the TRUNCATE TABLE statement if you want to delete all the records in the table. For example, use a statement that is similar to the following:

TRUNCATE TABLE TableName

Create a clustered index on a column of the table. For more information about how to create a clustered index on a table, see the "Creating a Clustered Index" topic in SQL

Sie am unteren Rand des Links auffallen wird, dass es nicht darauf hingewiesen wird, dass es zu SQL gilt Server 2008 aber ich denke es tut

19

Anton,

Als bewährte Methode sollten keine Benutzerobjekte in der primären Dateigruppe erstellt werden. Wenn Sie über Bandbreite verfügen, erstellen Sie eine neue Dateigruppe und verschieben Sie die Benutzerobjekte, und belassen Sie die Systemobjekte im primären Bereich.

Die folgenden Abfragen helfen Ihnen dabei, den Platz in jeder Datei und die obersten Tabellen zu identifizieren, die die höchste Anzahl an Zeilen haben und wenn es irgendwelche Heaps gibt. Es ist ein guter Ausgangspunkt, um dieses Problem zu untersuchen.

SELECT 
ds.name as filegroupname 
, df.name AS 'FileName' 
, physical_name AS 'PhysicalName' 
, size/128 AS 'TotalSizeinMB' 
, size/128.0 - CAST(FILEPROPERTY(df.name, 'SpaceUsed') AS int)/128.0 AS 'AvailableSpaceInMB' 
, CAST(FILEPROPERTY(df.name, 'SpaceUsed') AS int)/128.0 AS 'ActualSpaceUsedInMB' 
, (CAST(FILEPROPERTY(df.name, 'SpaceUsed') AS int)/128.0)/(size/128)*100. as '%SpaceUsed' 
FROM sys.database_files df LEFT OUTER JOIN sys.data_spaces ds 
    ON df.data_space_id = ds.data_space_id; 

EXEC xp_fixeddrives 
select t.name as TableName, 
    i.name as IndexName, 
    p.rows as Rows 
from sys.filegroups fg (nolock) join sys.database_files df (nolock) 
    on fg.data_space_id = df.data_space_id join sys.indexes i (nolock) 
    on df.data_space_id = i.data_space_id join sys.tables t (nolock) 
    on i.object_id = t.object_id join sys.partitions p (nolock) 
on t.object_id = p.object_id and i.index_id = p.index_id 
where fg.name = 'PRIMARY' and t.type = 'U' 
order by rows desc 
select t.name as TableName, 
    i.name as IndexName, 
    p.rows as Rows 
from sys.filegroups fg (nolock) join sys.database_files df (nolock) 
    on fg.data_space_id = df.data_space_id join sys.indexes i (nolock) 
    on df.data_space_id = i.data_space_id join sys.tables t (nolock) 
    on i.object_id = t.object_id join sys.partitions p (nolock) 
on t.object_id = p.object_id and i.index_id = p.index_id 
where fg.name = 'PRIMARY' and t.type = 'U' and i.index_id = 0 
order by rows desc 
+0

Wunderbares Skript. Eines der Probleme, auf die ich gestoßen bin, ist "size/128", das die Berechnung, die eine Division durch Nullfehler verursachte, integerisierte. In "Größe/128" geändert. – Dave

+0

Dieses Skript funktioniert nicht für mich. Ich bekomme einige Zeilen betroffen und dann einen Fehler - Msg 8134, Ebene 16, Zustand 1, Zeile 1 Division durch Null Fehler aufgetreten. – Steam

+0

Dave postete die Lösung genau über Ihrem Kommentar ... – Charleh

2

Ich lief gerade in das gleiche Problem. Der Grund dafür war, dass sich die virtuelle Speicherdatei "pagefile.sys" auf demselben Laufwerk wie unsere Datendateien für unsere Datenbanken befand (Laufwerk D:). Es hatte sich verdoppelt und die Platte gefüllt, aber Windows nahm es nicht auf, d. H. Es sah so aus, als hätten wir 80 GB frei, als wir es tatsächlich nicht hatten.

Neustart des SQL-Servers hat nicht geholfen, vielleicht Defragmentierung würde das OS Zeit geben, um die Auslagerungsdatei freizugeben, aber wir starteten nur den Server neu und voila, die Auslagerungsdatei war geschrumpft und alles hat gut funktioniert.

Interessant ist, dass Windows während der 30 min, die wir untersuchten, nicht die Größe der Pagefile.sys überhaupt (80 GB) berechnet. Nach dem Neustart haben Windows die Auslagerungsdatei gefunden und ihre Größe in die Gesamtdiskettenauslastung aufgenommen (jetzt 40 GB - was immer noch zu groß ist).

3

Ich lief auch in das gleiche Problem, wo die anfängliche dtabasegröße auf 4Gb gesetzt ist und autogrowth von 1Mb gesetzt wird. Das virtuell verschlüsselte TrueCrypt-Laufwerk, auf dem sich die Datenbank befand, schien reichlich Platz zu bieten.

änderte ich ein paar (oben) Dinge:

  • ich den Windows-Dienst für SQL Server Express von automatische-manuelle, so drehte nur die 'normalen' SQL Server ausgeführt wird . (Auch wenn ich SQL Server 2008 R2 leite die 10 GB ermöglichen soll.)
  • ich die automatische Vergrößerung von 1 MB bis 10% geändert
  • änderte ich die automatische Vergrößerung Erhöhungs-Größe von 10% bis 1000 MB
  • I das Laufwerk defragmentiert
  • ich die Datenbank schrumpfte:
    • manuell DBCC SHRINKDATABASE('...')
    • automatisch die rechte Maustaste auf Datenbank | "Eigenschaften" | "Auto Schrumpf" | „Kürzt Protokoll auf Kontrollpunkt“)

Alle mit wenig Erfolg (ich konnte einige weitere Datensätze einfügen, aber bald lief in das gleiche Problem). Die von Tobbi erwähnte Auslagerungsdatei ließ mich eine größere virtuelle Festplatte ausprobieren. (Auch wenn mein Laufwerk soll keine solche Systemdateien enthält, da ich laufe, ohne dass es eine Menge Zeit montiert.)

  • Ich habe ein neues, größeres virtuelles Laufwerk mit TrueCrypt

Bei der Herstellung von Dies führte zu einer TrueCrypt-Frage, wenn ich Dateien mit mehr als 4GB (as shown in this SuperUser question) speichern möchte.

  • sagte ich TrueCrypt Ich würde Dateien speichern größer als 4 GB

Nach diesen letzten zwei ich gut tat, und ich gehe davon aus dem letzten dem Trick. Ich denke TrueCrypt wählt ein exfat Dateisystem (as described here), das alle Dateien auf 4 GB beschränkt. (Also musste ich die Festplatte wahrscheinlich nicht vergrößern, aber ich habe es trotzdem getan.)

Dies ist wahrscheinlich ein sehr seltener Grenzfall, aber vielleicht hilft es jemandem.

2

bitte den Dateityp Wachstum der Datenbank chceck, wenn sie es eingeschränkt machen uneingeschränkte

3

eine Sache, gehen zu Eigenschaften von Datenbank Dateien auswählen und erhöhen Anfangsgröße der Datenbank und stellte primäre Dateigruppe als automatisch inkrementiert. Starten Sie den SQL Server neu.

Sie können die Datenbank wie früher verwenden.

17

Ran in das gleiche Problem und zunächst Defragmentierung schien zu arbeiten. Aber es war nur für kurze Zeit. Stellt den Server her, den der Kunde verwendet hat, hat Express version ausgeführt und das hat ein Lizenzierungslimit von ungefähr 10gb.

Also obwohl die Größe auf "unbegrenzt" eingestellt war, war es nicht.

0

Unser Problem war, dass die Festplatte auf Null verfügbar war.

Verwandte Themen