web-dev-qa-db-ja.com

SQL Server 2016での巨大なヒープテーブルとテーブル圧縮

私のデータベースサイズは巨大で、最近、数か月前に追加された新しいテーブルが原因であることに気付きました。

これがテーブルスクリプトです。

_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であることがわかりました。 enter image description here

それでも、テーブルサイズはノーのために巨大であると思います。レコードの。

このテーブルはアプリケーションによって照会されません。別のテーブルの同じエントリの異なるバージョンを格納するだけです。

断片化情報を確認しましたが、平均断片化が0であり、平均スペースが93％使用されています。 enter image description here

私はSQL Server 2016を使用しているので、テーブル圧縮を使用することもできたので、_sp_estimate_data_compression_savings_を使用してスペース節約の可能性を推定しました。ただし、結果は節約を示していません。

size_with_current_compression_setting(KB)はsize_with_requested_compression_setting(KB)と等しい

誰かがこのテーブルの問題を見つけるように私に指示できますか？

これは多くのディスク容量を使用するため、非常に重要です。

あなたの助けに感謝。

sql-serverdisk-spacefragmentationcompressionheap
4
user9516827

それでも私はテーブルのサイズが巨大なものだと思います。レコードの。

どうして？なんでこれを言うの？

それが行うことは、別のテーブルからの同じエントリの異なるバージョンを格納することです。

そのため、特に次の場合、バージョンが大きくなる場合と小さくなる場合があります。

[Data] [varbinary](max) NOT NULL,

行のdatalength()をチェックして、大きな行があるかどうかを確認しましたか？

データに基づいて、関数に与えられたサイズは妥当であるように思えます。バイトが変更されただけで、さまざまなアルゴリズムを使用して、どのバイト、どのように、および以前に変更されたバージョンを構築するかどうかを理解しない限り、バージョニングはめったに小さいものではありません。

6
Sean Gallardy