私のデータベースサイズは巨大で、最近、数か月前に追加された新しいテーブルが原因であることに気付きました。
これがテーブルスクリプトです。
_SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Entry_tracker](
[S.Number] [int] IDENTITY(1,1) NOT NULL,
[EntryId] [varchar](50) NOT NULL,
[EventNumber] [varchar](18) NOT NULL,
[Data] [varbinary](max) NOT NULL,
[TrackDateTime] [datetime] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
ALTER TABLE [dbo].[Entry_tracker] ADD CONSTRAINT [DF_Entry_tracker_TrackDateTime] DEFAULT (getdate()) FOR [TrackDateTime]
GO
_
このテーブルに関する情報を収集したところ、テーブルの行数は約1,600万で、テーブルサイズは1.4 TBであることがわかりました。
それでも、テーブルサイズはノーのために巨大であると思います。レコードの。
このテーブルはアプリケーションによって照会されません。別のテーブルの同じエントリの異なるバージョンを格納するだけです。
断片化情報を確認しましたが、平均断片化が0であり、平均スペースが93%使用されています。
私はSQL Server 2016を使用しているので、テーブル圧縮を使用することもできたので、_sp_estimate_data_compression_savings
_を使用してスペース節約の可能性を推定しました。ただし、結果は節約を示していません。
size_with_current_compression_setting(KB)
はsize_with_requested_compression_setting(KB)
と等しい
誰かがこのテーブルの問題を見つけるように私に指示できますか?
これは多くのディスク容量を使用するため、非常に重要です。
あなたの助けに感謝。
それでも私はテーブルのサイズが巨大なものだと思います。レコードの。
どうして?なんでこれを言うの?
それが行うことは、別のテーブルからの同じエントリの異なるバージョンを格納することです。
そのため、特に次の場合、バージョンが大きくなる場合と小さくなる場合があります。
[Data] [varbinary](max) NOT NULL,
行のdatalength()
をチェックして、大きな行があるかどうかを確認しましたか?
データに基づいて、関数に与えられたサイズは妥当であるように思えます。バイトが変更されただけで、さまざまなアルゴリズムを使用して、どのバイト、どのように、および以前に変更されたバージョンを構築するかどうかを理解しない限り、バージョニングはめったに小さいものではありません。