48

データベースは現在 64 Gb で、アプリの 1 つが次のエラーで失敗し始めました。

System.Data.SqlClient.SqlException:ファイル グループがいっぱいであるため、'cnv.LoggedUnpreparedSpos'.'PK_LoggedUnpreparedSpos'データベース内のオブジェクトに領域を割り当てることができませんでした。不要なファイルを削除するか、ファイル グループ内のオブジェクトを削除するか、ファイル グループにファイルを追加するか、ファイル グループ内の既存のファイルに対して自動拡張を設定して、ディスク領域を作成します。'travelgateway''PRIMARY'

すべてを再確認しました: 1 つのファイル グループ内のすべてのファイルは、適切な増分 (データ ファイルの場合は 100 Mb、ログ ファイルの場合は 10%) で自動拡張することが許可されており、データベース用に 100 GB を超える空き領域が利用可能ですtempdb。ドライブに十分な空き HDD スペースがある場合は、自動拡張にも設定されます。

問題を解決するために、ファイル グループに 2 番目のファイルを追加したところ、エラーはなくなりました。しかし、私はこの状況全体に不安を感じています。

みんな、ここでどこに問題があるの?

4

10 に答える 10

28

OK、うまくいきました。DB ファイルが配置されていた NTFS ボリュームが大幅に断片化されていることが判明しました。SQL Server を停止し、すべてを最適化したところ、それ以来問題なく動作していました。

于 2010-03-26T08:09:52.663 に答える
19

アントン、

ベスト プラクティスとして、プライマリ ファイル グループにユーザー オブジェクトを作成しないでください。帯域幅がある場合は、新しいファイル グループを作成し、ユーザー オブジェクトを移動して、システム オブジェクトをプライマリのままにします。

次のクエリは、各ファイルで使用されているスペースと、行数が最も多い上位のテーブルを特定し、ヒープがあるかどうかを特定するのに役立ちます。この問題を調査するための良い出発点です。

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
于 2009-12-25T05:30:11.033 に答える
4

データベース選択ファイルのプロパティに移動し、データベースの初期サイズを増やし、プライマリ ファイル グループを自動インクリメントとして設定します。SQL サーバーを再起動します。

データベースは以前と同じように使用できます。

于 2014-11-14T10:00:15.763 に答える
3

また、データベースの初期サイズが 4Gb に設定され、自動拡張が 1Mb に設定されているという同じ問題に遭遇しました。データベースが存在する暗号化された仮想 TrueCrypt ドライブには、十分なスペースがあるように見えました。

私は(上記の)いくつかのことを変更しました:

  • Sql Server Express の Windows サービスを自動から手動に変更したため、「通常の」SQL Server のみが実行されています。(10 GBを許可する必要があるSql Server 2008 R2を実行していますが。)
  • 自動拡張を 1 MB から 10% に変更しました
  • 自動拡張の増分サイズを 10% から 1000 MB に変更しました
  • ドライブを最適化しました
  • データベースを縮小しました:
    • 手動でDBCC SHRINKDATABASE('...')
    • データベースを自動的に右クリック | "プロパティ" | "自動縮小" | 「チェックポイントでログを切り捨てる」)

ほとんど役に立ちませんでした (さらにレコードを挿入することもできましたが、すぐに同じ問題に遭遇しました)。Tobbi が言及したページファイルにより、より大きな仮想ドライブを試してみることができました。(私のドライブにはそのようなシステムファイルを含めるべきではありませんが、多くの場合マウントせずに実行するためです。)

  • TrueCrypt で新しい大容量の仮想ドライブを作成しました

これを作成するとき、4 GB を超えるファイルを保存する場合 (この SuperUser の質問に示されているように)、TrueCrypt に関する質問に遭遇しました。

  • TrueCrypt に 4 GB を超えるファイルを保存すると伝えました

これらの最後の 2 つの後、私はうまくやっていて、この最後の 1 つがうまくいったと思います。TrueCrypt は、すべてのファイルを 4GB に制限するexfatファイル システム (ここで説明) を選択すると思います。(だから結局、ドライブを拡張する必要はなかったのかもしれませんが、とにかくしました。)

これはおそらく非常にまれな国境のケースですが、誰かの助けになるかもしれません.

于 2012-11-29T13:48:23.413 に答える
2

これは次の理由で発生することがわかりました: http://support.microsoft.com/kb/913399

SQL Server は、次の条件に該当する場合にのみ、ヒープ テーブルが使用するすべてのページを解放します。 このテーブルで削除が発生します。テーブル レベルのロックが保持されています。注 ヒープ テーブルは、クラスター化インデックスに関連付けられていない任意のテーブルです。

ページの割り当てが解除されない場合、データベース内の他のオブジェクトはページを再利用できません。

ただし、SQL Server 2005 データベースで行のバージョン管理ベースの分離レベルを有効にすると、テーブル レベルのロックが保持されていてもページを解放できません。

Microsoft のソリューション: http://support.microsoft.com/kb/913399

この問題を回避するには、次のいずれかの方法を使用します。 行のバージョン管理に基づく分離レベルが有効になっていない場合は、DELETE ステートメントに TABLOCK ヒントを含めます。たとえば、次のようなステートメントを使用します。

DELETE FROM TableName WITH (TABLOCK)

Note はテーブルの名前を表します。テーブル内のすべてのレコードを削除する場合は、TRUNCATE TABLE ステートメントを使用します。たとえば、次のようなステートメントを使用します。

TRUNCATE TABLE テーブル名

テーブルの列にクラスター化インデックスを作成します。テーブルにクラスター化インデックスを作成する方法の詳細については、SQL の「クラスター化インデックスの作成」トピックを参照してください。

リンクの下部に、それが SQL Server 2008 に適用されるとは記載されていませんが、適用されると思います。

于 2009-12-23T14:58:05.097 に答える
2

私はちょうど同じ問題に遭遇しました。その理由は、仮想メモリ ファイル「pagefile.sys」が、データベースのデータ ファイルと同じドライブ (D: ドライブ) に配置されていたためです。サイズが 2 倍になり、ディスクがいっぱいになりましたが、Windows はそれを認識しませんでした。つまり、実際には 80 GB の空き容量があるように見えましたが、実際にはありませんでした。

SQL サーバーを再起動しても問題は解決しませんでした。最適化によって OS がページファイルを解放する時間が得られる可能性がありますが、サーバーを再起動しただけで、ページファイルが縮小し、すべてが正常に機能しました。

興味深いのは、調査中の 30 分間、windows が pagefile.sys のサイズ (80 GB) をまったく計算しなかったことです。再起動後、ウィンドウはページファイルを見つけ、そのサイズを合計ディスク使用量に含めました (現在は 40 GB - まだ大きすぎます)。

于 2012-07-18T23:29:07.833 に答える
2

データベースのファイル拡張のタイプを確認してください。制限されている場合は制限されていません。

于 2013-01-10T08:17:33.840 に答える
1

私の経験では、このメッセージは、プライマリ ファイル (.mdf) にデータベースのメタデータを保存するスペースがない場合に発生します。このファイルにはシステム テーブルが含まれており、データのみが保存されます。

ファイルにスペースを空けると、コマンドが再び機能します。それだけです、楽しんでください

于 2019-06-01T01:14:54.977 に答える
0

私たちの問題は、ハードドライブの空き容量がゼロになったことです。

于 2016-10-21T18:25:39.630 に答える