У меня в одной из моих БД есть интересная таблица, которая меня смущает.
В рассматриваемой таблице есть несколько столбцов типа LOB (два nvarchar (max) и текст), и похоже, что происходят какие-то странные проблемы с пространством.
из этого запроса:
SELECT type_desc,
SUM(total_pages) *8 [Size in kb]
FROM sys.partitions p JOIN sys.allocation_units a
ON p.partition_id = a.container_id
WHERE p.object_id = OBJECT_ID('asyncoperationbase')
GROUP BY type_desc;
Я получил:
type_desc Size in kb
IN_ROW_DATA 27936
LOB_DATA 1198144
ROW_OVERFLOW_DATA 0
(в таблице чуть менее 8000 строк, каждая строка имеет длину данных ~ 10 КБ - не считая данных LOB)
вот где это становится несколько интересным:
SELECT ( SUM(DATALENGTH(aob.WorkflowState)) +
SUM(DATALENGTH(aob.[Message]))+
SUM(DATALENGTH(aob.[Data])) ) / 1024
ОТ AsyncOperationBase aob
возвращает:
76617
Пока я его читаю - похоже, что ~ 75 МБ LOB-данных используются для хранения в гигабайтах - я бы ожидал некоторых накладных расходов, но не прекращал бы так много.
Спасибо,
Андрей
Хорошо, я полагаю, что обновлю это, если это поможет кому-то другому. Закончил работу с MS Support по этой проблеме, и, по-видимому, есть фоновый рабочий поток, который отвечает за освобождение пространства. В этом случае он перестал работать. Легким решением было перезапустить SQL-сервер.
Ура
Андрей