はなぜ私の行サイズが8060バイトの許容最大値を超えない

Question

IているSQL Server 2012の、ウェブ版では、次の表：私の知る限り、合計サイズが3175バイトである必要が集まるよう

CREATE TABLE [dbo].[MyTable] 
(
    [Id]    INT   IDENTITY (1, 1) NOT NULL, 
    [Created]   DATETIME  DEFAULT (getdate()) NOT NULL, 
    [RefId]   INT   NULL, 
    [Name]    NVARCHAR (128) NULL, 
    [Email]   NVARCHAR (128) NULL, 
    [ImageUrl]   NVARCHAR (256) NULL, 
    [Url]    VARCHAR (256) NULL, 
    [Age]    TINYINT  NULL, 
    [Country]   VARCHAR (6) NULL, 
    [Location]   NVARCHAR (192) NULL, 
    [People]   INT   NULL, 
    [Categories]  NVARCHAR (128) NULL, 
    [Block]   BIT   DEFAULT ((0)) NOT NULL, 
    [GeneratedRevenue] INT   NULL, 
    [IsFemale]   BIT   DEFAULT ((1)) NULL, 
    [HasInstalled]  BIT   NULL, 
    [Keywords]   VARCHAR (128) NULL, 
    [Brands]   NVARCHAR (512) NULL, 
    [Source]   TINYINT  NULL, 
    [Alias]   VARCHAR (65) NULL, 

    PRIMARY KEY CLUSTERED ([Id] ASC) 
); 

。テーブルを更新するとき、私は定期的に、次のエラーを取得する：

は、上記の結果をどのように8060

の許容最大行サイズより大きいサイズ8068の行を作成できません8068の行サイズ？

を編集してください：この表は変更され、変更追跡が使用され、4つのインデックスがあります。

また、同じ定義の新しいテーブルにコンテンツをコピーすると、しばらくエラーは発生しませんが、戻ってきます。

Answer 1

変更トラッキングを使用しているとします。あなたは - 万一、Change Trackingのバージョン管理部分を無視し、以下を実行してエントリをリセットしていますか？

ALTER TABLE dbo.MyTable disable change_tracking 
ALTER TABLE dbo.MyTable enable change_tracking 

もしそうなら、容疑者がいる可能性があります。チェンジトラッキングは、チェンジトラッキングを再び有効にするたびにシーンの裏側に8ビットの列を追加します。チェンジトラッキングは、既に存在する場合は削除されます。列を削除するのはメタ操作に過ぎないため、変更追跡を再び有効にする頻度に応じて、舞台裏で多数のドロップされた8ビット列がドロップされることがあります。

これを確認するには、system_internals_partition_columnsビューを確認し、is_dropped列が多数あるかどうかを確認してください。多くの理由があるかもしれませんが、この方法で変更トラッキングを使用する方法もあります。

私はRemus Rusanuがコメント（rusanu.com/2011/10/20/sql-server-table-columns-under-the-hoo‌​d）の中の良い記事にリンクしていることを見ています。彼がリストしたクエリは、上記の場合に必要なものでなければなりません。

編集： 削除された列を削除する必要がある場合は、削除された列が多いテーブルのクラスタードインデックスを再構築できます。これは、クラスタ化インデックスをMyTableに再構築すると、症状が緩和されることを意味します。