いつDBCC CLEANTABLEを実行してスペースを再利用する必要があるかを判断する信頼できる方法はありますか?


11

最近、ファイル使用率が80%に近づいたときにファイルを単に成長させるのではなく、ヒープのデフラグ、クラスター化インデックスの追加と削除、行またはページの圧縮などの通常のトリックを介してスペースを再利用することに積極的に取り組んできました。

ただし、DBCC CLEANTABLEを実行してさらに多くのスペースを取り戻すことができたケースがいくつかあります。私の環境には数百のデータベースがあるため、ユーザーがそれぞれのデータベースで何をしているのかを知ることは不可能であり、固定長の列の削除に関連する変更があることは完全に許容できます。私が書いたオブジェクトスペース使用率スクリプトの行数とページ数を比較することで、これらの機会を見つけました。このようなシナリオの検出を自動化することで、これをさらに一歩進めたいと思います。

私が知りたいのは、このような機会を積極的に監視している人がいるなら、そうだとしたら、具体的に何を探しますか?

私の考えは、行の最大サイズと最小サイズ、テーブルの行数、割り当てられたページ数、および使用されたページ数を収集するという線に沿って何かを記述し、いくつかの基本的な計算を行って結果を記録することでした「期待される」はずの外にあります。


大きなテーブルでは、batch_sizeパラメータを使用することを強くお勧めします。これにより、1つの巨大なトランザクションではなく、一連のトランザクションでコマンドが実行されます。
datagod

回答:


11

この問題について私が考えている解決策は、データベース内のすべてのテーブルに対してsp_spaceusedを実行するジョブを毎週実行し、このデータをテーブルに保存することです。各テーブルのサイズに..10%以上の違いがある場合は、dbcc cleantableを実行します。

テーブルサイズをループする私のコードは次のようになります。

if OBJECT_ID ('tempdb.dbo.#temp') is not null
    drop table #temp;

if OBJECT_ID ('dbo.BigTables') is not null
    drop table dbo.BigTables;
go

CREATE TABLE [dbo].[BigTables] (
    [table_name] [sysname] NOT NULL,
    [row_count] [int] NULL,
    [col_count] [int] NULL,
    [data_size] [varchar](50) NULL,
    [Date] [datetime] NOT NULL,
    [DBName] [nvarchar](128) NULL
);
GO

CREATE TABLE #temp (
    table_name sysname ,
    row_count int,
    reserved_size varchar(50),
    data_size varchar(50),
    index_size varchar(50),
    unused_size varchar(50)
);
go

INSERT     #temp
EXEC       sp_msforeachtable 'sp_spaceused ''?'''

insert into dbo.BigTables
SELECT     a.table_name,
           a.row_count,
           count(*) as col_count,
           a.data_size,
           getdate() as [Date],
    'MY DB' as DBName
FROM       #temp a
INNER JOIN information_schema.columns b
           ON a.table_name collate database_default
                = b.table_name collate database_default
GROUP BY   a.table_name, a.row_count, a.data_size
ORDER BY   CAST(Replace(a.data_size, ' KB', '') as integer) desc

DROP TABLE #temp;

Select * from dbo.BigTables;

これで、1週間に何がサイズ変更になるかを確認してスケジュールするロジックを構築するだけで済みます。


これで、テーブルサイズレポートの不正確さが疑われる理由がある場合は、DBCC UPDATEUSAGEを実行する必要があります(これにより、行数とページ数が修正されます)。お役に立てて嬉しいです!
マリアン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.