Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Загадка массовой загрузки XML  [new]
aleks222
Guest 		Грузится 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 выдает чудовищную картину. 

name                                         rows	        reserved           data	                index_size	 unused
pricesServiceSetsPriceDates	1187065	75972400 KB	9496520 KB	240 KB	 66475640 KB

Куда и зачем оно хавает такую чортову прорву пустого места?
Data = 9 496 520 KB
!!!
unused = 66 475 640 KB!!!
13 дек 17, 08:55    [21029352]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30821
aleks222
Куда и зачем оно хавает такую чортову прорву пустого места?
А параметр updateusage на всякий случай применяли?
13 дек 17, 09:34    [21029445]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
aleks222
Guest
alexeyvg
aleks222
Куда и зачем оно хавает такую чортову прорву пустого места?
А параметр updateusage на всякий случай применяли?

Применял.
Дык ведь, и свободное место в tempdb уменьшается соответственно.
13 дек 17, 09:38    [21029457]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30821
aleks222
alexeyvg
пропущено...
А параметр updateusage на всякий случай применяли?

Применял.
Дык ведь, и свободное место в tempdb уменьшается соответственно.
А, то есть sqlXmlBulkLoad на время импорта распирает таблицу, а потом отпускает неиспользованное? И появляется огромный unused? Занятно, не слышал о таком.
13 дек 17, 09:42    [21029472]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
aleks222
Guest
alexeyvg
aleks222
пропущено...

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


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

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

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

Что самое забавное, есть две таблички - практически полных аналога. Только на одной есть кластерный индекс... и ее не "разносит".
13 дек 17, 09:48    [21029491]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30821
aleks222
Если б он "отпускал". Оно так и остается после загрузки.
Я, я имел в виду "отпускает в unused"
aleks222
Data = 9 496 520 KB
Заметьте - размер данных точно соответствует количеству строк * размер страницы.
А размер данных неточно, но примерно близок к количеству строк * размер экстента
13 дек 17, 10:01    [21029522]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30821
alexeyvg
А размер данных неточно, но примерно близок к количеству строк * размер экстента
То есть размер unused
А вот размер reserved точно равен количеству строк * размер экстента
:-)
13 дек 17, 10:03    [21029525]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30821
alexeyvg
alexeyvg
А размер данных неточно, но примерно близок к количеству строк * размер экстента
То есть размер unused
А вот размер reserved точно равен количеству строк * размер экстента
:-)
Видимо, умный сервер, видя колонку ntext, решает зарезервировать по экстенту на строку, "а там разберёмся"
13 дек 17, 10:04    [21029527]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
aleks222
Guest
alexeyvg
alexeyvg
пропущено...
То есть размер unused
А вот размер reserved точно равен количеству строк * размер экстента
:-)
Видимо, умный сервер, видя колонку ntext, решает зарезервировать по экстенту на строку, "а там разберёмся"


Не, удаление колонки ntext ничего не меняет. Я попробовал.
Радикально меняет дело только кластерный индекс.
13 дек 17, 10:11    [21029562]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
 		aleks222,

сдаётся мне что дело в TEXTIMAGE_ON но доказать не могу:)
13 дек 17, 10:13    [21029569]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30821
aleks222
alexeyvg
пропущено...
Видимо, умный сервер, видя колонку ntext, решает зарезервировать по экстенту на строку, "а там разберёмся"


Не, удаление колонки ntext ничего не меняет. Я попробовал.
Радикально меняет дело только кластерный индекс.
Хм, всё равно резервирует экстент на строку?
Прикольно.
Вот небольшое обсуждение было https://social.technet.microsoft.com/Forums/en-US/727f0ff2-4598-497b-b3f8-05805e0cf4e2/sqlxmlbulkload-size-of-database-40-times-bigger-than-xml-file?forum=sqlxml
13 дек 17, 10:17    [21029582]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30821
TaPaK
aleks222,

сдаётся мне что дело в TEXTIMAGE_ON но доказать не могу:)
Но он же удалил ntext
13 дек 17, 10:17    [21029585]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
 		Похоже на
автор
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
13 дек 17, 10:45    [21029681]     Ответить | Цитировать Сообщить модератору
 Re: Загадка массовой загрузки XML  [new]
aleks222
Guest
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


Вопщем понятно - делаем кластерный индекс.
13 дек 17, 13:56    [21030522]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить