Таблица сервера SQl использует слишком много дискового пространства

У меня есть две идентичные таблицы в двух отдельных базах данных на одном экземпляре SQL-сервера, определенные следующим образом (обратите внимание, что это стороннее программное обеспечение, поэтому я не могу изменить схему таблицы): -
РЕДАКТИРОВАТЬ: [RouteParamXml] nvarchar NOT NULL всегда является пустой строкой
РЕДАКТИРОВАТЬ: все поля UserDef являются пустыми строками, только 110 строк содержат данные в SecondaryOrderID, ActionUserId и FIXBrokerOrderID все заполнены, я не вижу никакой причины, почему несоответствие пространства настолько велико

CREATE TABLE blah(
    [AuditEventID] [int] NOT NULL,
    [ActionCode] [tinyint] NOT NULL,
    [ActionDate] [datetime] NOT NULL,
    [ActionUserID] [nvarchar](15) NOT NULL,
    [OrderID] [int] NOT NULL,
    [PlaceID] [int] NOT NULL,
    [FIXMsgType] [int] NOT NULL,
    [FIXOrderStatus] [int] NOT NULL,
    [FIXBrokerOrderID] [nvarchar](60) NOT NULL,
    [FilledQty] [float] NOT NULL,
    [Stamp] [varbinary](8) NOT NULL,
    [MarkForDelete] [smallint] NOT NULL,
    [NewOrderAuditTime] [datetime] NOT NULL,
    [ReplaceOrderAuditTime] [datetime] NOT NULL,
    [SendRecvTime] [datetime] NOT NULL,
    [QueueID] [int] NOT NULL,
    [SecondaryOrderID] [nvarchar](255) NOT NULL,
    [RouteParamXml] [nvarchar](max) NOT NULL,
    [UserDef1] [nvarchar](255) NOT NULL,
    [UserDef2] [nvarchar](255) NOT NULL,
    [UserDef3] [nvarchar](255) NOT NULL,
    [UserDef4] [nvarchar](255) NOT NULL,
    [UserDef5] [nvarchar](255) NOT NULL,
    [UserDef6] [nvarchar](255) NOT NULL,
    [FIXOrderID] [int] NOT NULL,
    [OrigFIXOrderID] [int] NOT NULL,
 CONSTRAINT [blah_PK] PRIMARY KEY CLUSTERED 
(
    [OrderID] ASC,
    [PlaceID] ASC,
    [AuditEventID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]

Одна таблица имеет 1,3 миллиарда строк и использует около 22 МБ (мегабайт) дискового пространства для разгрузки. Другая таблица содержит 1 миллион строк и использует 15 ГБ (гигабайт) дискового пространства.

Я копался в различных вариантах DBCC, и я не вижу ничего неправильного в выводе DBCC CHECKALLOC (хорошая таблица)

Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594046316544 (type LOB data). FirstIAM (1:390). Root (1:389). Dpages 0.
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594046316544 (type LOB data). 241 pages used in 29 dedicated extents.
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594198687744 (type In-row data). FirstIAM (1:362878). Root (1:549074). Dpages 27571.
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594198687744 (type In-row data). 27646 pages used in 3457 dedicated extents.
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594198753280 (type Row-overflow data). FirstIAM (0:0). Root (0:0). Dpages 0.
Index ID 1, partition ID 72057594188726272, alloc unit ID 72057594198753280 (type Row-overflow data). 0 pages used in 0 dedicated extents.

Вывод команды DBCC CHECKALLOC (неверная таблица)

Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594046316544 (type LOB data). FirstIAM (1:2845). Root (1:2844). Dpages 0.
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594046316544 (type LOB data). 1880724 pages used in 235090 dedicated extents.
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594197901312 (type In-row data). FirstIAM (1:1155704). Root (1:2024010). Dpages 25147.
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594197901312 (type In-row data). 25216 pages used in 3153 dedicated extents.
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594197966848 (type Row-overflow data). FirstIAM (0:0). Root (0:0). Dpages 0.
Index ID 1, partition ID 72057594188005376, alloc unit ID 72057594197966848 (type Row-overflow data). 0 pages used in 0 dedicated extents.

Есть идеи, с которых я должен начать разбираться, почему этот стол такой массивный