Грузится xml через sqlXmlBulkLoad в табличку базы tempdb
[src]
CREATE TABLE [dbo].[pricesServiceSetsPriceDates](
[gross] [real] NULL,
[ids] [nvarchar](4000) NOT NULL,
[version] [nvarchar](8) NULL,
[OverflowColumn] [ntext] NULL,
[spoKey] [int] NULL DEFAULT ((-1)),
[hash] [int] NULL,
[key] [int] NOT NULL,
[from] [date] NULL,
[to] [date] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
[src]
индексов нет.
В столбце [OverflowColumn] везде NULL.
Столбец [ids] заполнен строками длиной < 900 символов, реально в среднем около 100 символов.

Но sp_spaceused выдает чудовищную картину.

Куда и зачем оно хавает такую чортову прорву пустого места?
Data = 9 496 520 KB
!!!
unused = 66 475 640 KB!!!

alexeyvgaleks222Куда и зачем оно хавает такую чортову прорву пустого места?А параметр updateusage на всякий случай применяли?
Применял.
Дык ведь, и свободное место в tempdb уменьшается соответственно.

alexeyvgaleks222пропущено...

Применял.
Дык ведь, и свободное место в tempdb уменьшается соответственно.А, то есть sqlXmlBulkLoad на время импорта распирает таблицу, а потом отпускает неиспользованное? И появляется огромный unused? Занятно, не слышал о таком.

Если б он "отпускал". Оно так и остается после загрузки.

Если построить на этой таблице кластерный индекс - размеры приходят в норму и свободное место в tempdb появляется обратно.

Есть еще пара-тройка таблиц с таким же эффектом.

Что самое забавное, есть две таблички - практически полных аналога. Только на одной есть кластерный индекс... и ее не "разносит".

alexeyvgalexeyvgпропущено...
То есть размер unused
А вот размер reserved точно равен количеству строк * размер экстента
:-)Видимо, умный сервер, видя колонку ntext, решает зарезервировать по экстенту на строку, "а там разберёмся"

Не, удаление колонки ntext ничего не меняет. Я попробовал.
Радикально меняет дело только кластерный индекс.

TaPaKПохоже на
авторIf the allocation cache and the free space cache are empty between later insert operations, SQL Server will allocate new pages from new extents so that the insert operations can succeed. When the table metadata is removed from memory, the allocation cache and the free space cache are also removed. Therefore, the next time that you perform an insert operation that references the table, these caches are empty. In this situation, SQL Server must perform step 5, and then step 5.5. This behavior causes recently allocated extents to show that eight pages are allocated when only one page is used. In a worst-case scenario, 56 kilobytes (KB) of space may be wasted for every insert operation that you perform on the table.

авторThe following are two cases where the problem occurs, and the allocation cache and the free space cache are empty. It is assumed that the table's schema allows for 100 rows to fit in a data page.
If the table has only a heap storage structure, SQL Server could allocate a new extent for every insert operation and use only one page in that extent.


https://support.microsoft.com/en-gb/help/924947/sql-server-significantly-increases-the-unused-space-for-some-tables

Вопщем понятно - делаем кластерный индекс.