1

そのため、私たちが使用しているいくつかのデータベースでかなり大きな問題が発生しました。何らかの理由で、人々 のデータベースは、テーブルのデータを変更することなく、途方もないファイル サイズに成長しました。何が突然これを引き起こしているのかわかりませんが、現在、使用しているディスク領域をクリアすることにもっと関心があります. sp_spaceused を実行し、主な原因を 2 つのテーブルのうちの 1 つまで追跡しました (データベースによって異なります)。データベースごとに、これらのテーブルの 1 つが予約済みスペースに 0.5 GB 以上を割り当てていますが、データはわずか 50 MB 程度です。index_size が ~113 MB であることを示しています。テーブルにはクラスター化インデックスがなく、約 15 の列があり、長さが 255 の nvarchar 型の 2 つの列を除いて、すべて比較的短い長さです (これらは通常、テーブル内で null または空です)。

DBCC シュリンク データベースとトランケート テーブルを実行しようとしましたが、何もしませんでした。私はこれを少し調べましたが、他の人もこの問題を抱えていましたが、shrinkdatabase で修正されなかった場合、解決策も見つかりませんでした。

テーブルまたはデータベースの設定について他に知っておくべきことがあれば教えてください。他に何を試すべきかわかりませんが、これは私たちにとって重大な問題です。なぜなら、人々のデータベースは突然、以前の 10 倍のスペースを占有するようになっているからです。

編集: DBCC DBREINDEX を実行しようとした後、Enterprise Manager を使用してクラスター化インデックスに変更しようとすると、次のようなエラー メッセージが表示されます。

データベース 'DB' に新しいページを割り当てることができませんでした。ファイル グループ PRIMARY で使用できるページはこれ以上ありません。スペースは、オブジェクトを削除するか、ファイルを追加するか、ファイルの拡張を許可することで作成できます。

このテーブルからも行を削除しようとしましたが、テーブルのサイズには影響しません。予想どおり、ログ ファイルは増加しますが、それがテーブルのサイズの唯一の変更点です。

4

1 に答える 1

2

これらはヒープですか (クラスター化されたインデックスはありません)? なんで?

ユーザーが多くの更新または削除を行った場合は、テーブルを再構築してみます。Shrinkdatabase はこれを行う方法ではありません。断片化、削除または列幅の変更による回復されないスペース、または転送ポインターとして無駄になった行は修正されません。再構築やクラスター化インデックスを使用すると、テーブルがはるかにうまくいくに違いありません。SQL Server 2000 では、次のいずれかでこれを行います。

(a) クラスター化インデックスの追加。(テーブルに関する十分な情報がないため、クラスター化されたインデックスを追加する (または既存のインデックスの 1 つを変更する、またはクラスター化されていない主キーを変更する) ための正確な構文を提供することはできません。)

(b) DBCC DBREINDEX('dbo.tablename');

これにより、ヒープ上の非クラスター化インデックスが再構築されますが、無駄なスペースがどこで発生しているかによっては、うまくいかない場合があります。クラスター化インデックスを作成することをお勧めします。テーブルに関する詳細を共有できる場合 (たとえば、存在するインデックス、通常実行されるクエリの種類、現在行を一意に識別する方法、このテーブルへのデータの変更/追加の性質) を提供できる可能性があります。細かなアドバイス。

于 2012-06-19T18:23:56.667 に答える