Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Добрый день.

Раздумываю над вариантами хранения файлов
1) в отдельной таблице
2) в одной вместе с остальной атрибутивной информацией. Примерно так
CREATE TABLE [dbo].ayEDSStore(
	[IdDoc] [int] NOT NULL, -- идентификатор документа
	[IdFile] [int] NOT NULL, -- идентификатор файла
	[Name] [varchar](255) NOT NULL, -- наименование файла
	[DateSign] [datetime] NOT NULL DEFAULT (getdate()), -- когда добавлена ЭЦП
	[UserName] [varchar](255) NOT NULL, -- кто создал, учётка
	[Signature] varbinary(max) NULL, -- отсоединённая ЭЦП
	[Role] [varchar](100) NULL, -- характер работы (роль) подписавшего
	[Activity] tinyint NULL  -- 0 - подпись неактивна, 1- активна
) ON [PRIMARY]


Ненужные файлы будут удаляться, но атрибутивная информация должна остаться. Какой вариант лучше с точки зрения оптимизации дискового пространства?
9 дек 15, 09:16    [18533383]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10234
Блог
Вариантов куча, зависит от бизнес-требований и размеров файлов. Можно использовать еще файлстрим и файлтейбл
9 дек 15, 09:40    [18533468]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Какой вариант лучше с точки зрения оптимизации дискового пространства?

зануление какого-либо поля записи не делает занятое этим полем место доступным для других объектов.
И даже удаление всей записи не делает занятое этой записью место доступным для других объектов.
9 дек 15, 10:19    [18533684]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Knyazev Alexey,

Мне было бы достаточно уверенности в том, что если в единой заполненной таблице я в бинарное поле для файла запишу NULL, место в базе освободится. Тогда я на втором варианте остановлюсь для простоты
9 дек 15, 10:22    [18533701]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory
Papadopulos
Какой вариант лучше с точки зрения оптимизации дискового пространства?

зануление какого-либо поля записи не делает занятое этим полем место доступным для других объектов.
И даже удаление всей записи не делает занятое этой записью место доступным для других объектов.

Glory,
А после того как будет проведена оптимизация базы, будет ли разница в этих двух вариантах?
9 дек 15, 10:24    [18533717]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
А после того как будет проведена оптимизация базы,

Что будет проведено ?
9 дек 15, 10:25    [18533723]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory,
Я имел в виду сжатие.
9 дек 15, 10:30    [18533748]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Я имел в виду сжатие.

Сжатие никогда не проводит дефрагментацию внутри объектов
9 дек 15, 10:32    [18533758]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory,
Благодарю! Этого достаточно
9 дек 15, 10:33    [18533763]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory
Papadopulos
Я имел в виду сжатие.

Сжатие никогда не проводит дефрагментацию внутри объектов

Вы меня ввели в заблуждение. Удаление строк из таблиц, равно как и зануление бинарных полей после сжатия освобождает дисковое пространство.
Удаление строк даёт лучший эффект.
28 янв 16, 11:17    [18739207]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Вы меня ввели в заблуждение. Удаление строк из таблиц, равно как и зануление бинарных полей после сжатия освобождает дисковое пространство.

Да вы що ! И как же сжатие это делает ? Не поделитесь секретом ?
28 янв 16, 12:13    [18739538]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory,
откуда мне знать, как сжатие это делает. Из нас двоих специалист не я.
Объем файлов до сжатия - 3085 Мб. после удаления строк и сжатия - 747 Мб.
ms sql server 2008 R2.
28 янв 16, 12:48    [18739729]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
откуда мне знать, как сжатие это делает. Из нас двоих специалист не я.

Ну раз не знаете, то и помалкивайте о том, кто кого вводит в заблуждение.

Papadopulos
Объем файлов до сжатия - 3085 Мб. после удаления строк и сжатия - 747 Мб.

И что ?
28 янв 16, 12:50    [18739745]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory,

а то, что если сжать без удаления строк, размер базы уменьшается до 2752 Мб.
28 янв 16, 13:15    [18739936]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
а то, что если сжать без удаления строк, размер базы уменьшается до 2752 Мб.

Вы хоть знаете, что за команды выполняются при ваших "удаляю строки" и "сжимаю" ?
Или вы считаете, что можно сморозить фигню и затем заставлять других доказывать, что это фигня ?
28 янв 16, 13:19    [18739961]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory,

при удалении delete, при сжатии, полагаю, shrinkdatabase, а что это меняет?
В чём фигня с моей стороны?
28 янв 16, 13:42    [18740151]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
В чём фигня с моей стороны?

В том, что не знаете, как работают эти команды, но считаете себя в праве делать заявления о том, что происходит. Потому что "но ведь размер то уменьшился"
28 янв 16, 13:47    [18740186]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory,

автор
Опять ты веришь своим лживым глазам и не веришь моим правдивым речам (с)


Вы для меня очень великий специалист, так что диалог у нас не клеится. Всего доброго
28 янв 16, 14:05    [18740288]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7936
Papadopulos,

смотрите справку по DBCC SHRINKDATABASE.
28 янв 16, 14:14    [18740361]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Владислав Колосов,

Читаю
автор
Наибольший эффект от операции сжатия достигается при ее применении после операции, создающей много неиспользуемого пространства, например после усечения таблицы или удаления таблицы.

ЧТД
28 янв 16, 14:26    [18740471]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Читаю
автор
Наибольший эффект от операции сжатия достигается при ее применении после операции, создающей много неиспользуемого пространства, например после усечения таблицы или удаления таблицы.

ЧТД

А команда DELETE - это усечение таблицы или удаление таблицы ?

ЗЫ
Видеть глазами не означает понимать суть происходящего
А у вас как в том анекдоте - таракан без ног ничего не слышит
28 янв 16, 14:29    [18740494]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
o-o
Guest
Papadopulos
Владислав Колосов,
Читаю
автор
Наибольший эффект от операции сжатия достигается при ее применении после операции, создающей много неиспользуемого пространства, например после усечения таблицы или удаления таблицы.

ЧТД

и вы делали truncate table или может быть drop table?
вы же из кучи удаляли.
ЧТД
By default, a DELETE statement always acquires an exclusive (X) lock on the table it modifies, and holds that lock until the transaction completes. With an exclusive (X) lock, no other transactions can modify data; read operations can take place only with the use of the NOLOCK hint or read uncommitted isolation level. You can specify table hints to override this default behavior for the duration of the DELETE statement by specifying another locking method, however, we recommend that hints be used only as a last resort by experienced developers and database administrators. For more information, see Table Hints (Transact-SQL).

When rows are deleted from a heap the Database Engine may use row or page locking for the operation. As a result, the pages made empty by the delete operation remain allocated to the heap. When empty pages are not deallocated, the associated space cannot be reused by other objects in the database.

DELETE (Transact-SQL)
28 янв 16, 14:35    [18740534]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory
Papadopulos
Читаю
пропущено...

ЧТД

А команда DELETE - это усечение таблицы или удаление таблицы ?

В данном случае delete это
автор
операции, создающей много неиспользуемого пространства
28 янв 16, 14:39    [18740567]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
o-o
Guest
Papadopulos
Glory
пропущено...

А команда DELETE - это усечение таблицы или удаление таблицы ?

В данном случае delete это
автор
операции, создающей много неиспользуемого пространства

до меня дошло, что есть ЧТД.
Читаю Только Донцову.
постом выше ссылка на БОЛ, DELETE -- это то, что там описано.
и поведение у него такое, к-ое там же описано.
но это не вам, читающему лишь избранное.
это остальным, кто на тему напорется
28 янв 16, 14:42    [18740588]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
В данном случае delete это
автор
операции, создающей много неиспользуемого пространства

В данном случае вы балабол. Вставший в позу.
28 янв 16, 14:42    [18740590]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
o-o
When rows are deleted from a heap the Database Engine may use row or page locking for the operation. As a result, the pages made empty by the delete operation remain allocated to the heap. When empty pages are not deallocated, the associated space cannot be reused by other objects in the database.

DELETE (Transact-SQL)[/quote]
Здесь написано, что после удаления строк таблицы, неиспользованные страницы не могут быть использованы. Это понятно и видно - размер соотв. файла БД не меняется.
Но после сжатия эти страницы вполне прекрасно освобождаются
28 янв 16, 14:48    [18740627]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Здесь написано, что после удаления строк таблицы, неиспользованные страницы не могут быть использованы. Это понятно и видно - размер соотв. файла БД не меняется.
Но после сжатия эти страницы вполне прекрасно освобождаются

Да-да. Прекрасно освождаются. Вы же сами видели. А другие просто не туда смотрят и не так читают хелпы.
28 янв 16, 14:49    [18740638]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory
Papadopulos
В данном случае delete это
пропущено...

В данном случае вы балабол. Вставший в позу.

Есть 2 ГБ разницы и лично вы никак не можете объяснить, как они появились.
Так кто балабол, вставший в позу?
28 янв 16, 14:49    [18740640]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Есть 2 ГБ разницы и лично вы никак не можете объяснить, как они появились.

А вы что можете ? Ну не томите тогда, раскройте тайну уже.
28 янв 16, 14:51    [18740661]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
o-o
Guest
Papadopulos
o-o
When rows are deleted from a heap the Database Engine may use row or page locking for the operation. As a result, the pages made empty by the delete operation remain allocated to the heap. When empty pages are not deallocated, the associated space cannot be reused by other objects in the database.

DELETE (Transact-SQL)
Здесь написано, что после удаления строк таблицы, неиспользованные страницы не могут быть использованы. Это понятно и видно - размер соотв. файла БД не меняется.
Но после сжатия эти страницы вполне прекрасно освобождаются

ппц
там написано, что страницы все еще куче принадлежат после DELETE-а.
BOL
the pages made empty by the delete operation remain allocated to the heap

ПЕРЕИСПОЛьЗОВАТь ИХ МОЖЕТ ТОЛьКО САМА КУЧА,
НО НИКАК НИКТО ДРУГОЙ.
НИ ОБъЕКТЫ ЭТОЙ ЖЕ БАЗЫ, НИ, ПРЕДСТАВьТЕ, ОС
28 янв 16, 14:54    [18740681]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
o-o
Guest
RU-RU
Когда строки удаляются из кучи, компонент Компонент Database Engine может использовать строку или страницу блокировки для операции.
В результате пустые страницы, в которых выполняются операции удаления, остаются размещенными для кучи.
Если их не освободить, занимаемое ими место не может быть использовано под другие объекты базы данных.
28 янв 16, 14:57    [18740701]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory
Papadopulos
Есть 2 ГБ разницы и лично вы никак не можете объяснить, как они появились.

А вы что можете ? Ну не томите тогда, раскройте тайну уже.

Никакой тайны нет, всё уже сказал - в одной копии базы я делал сжатие без удаления строк таблицы с файлами, в другой - сжатие с предварительным удалением строк, в третьей - сжатие с занулением поля, хранящего файлы.
Результаты выше привёл. Размер базы в третьем случае - 2800 Мб.
И в хелпе я не нашёл ничего, что противоречило бы полученным результатам.
28 янв 16, 14:57    [18740707]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
o-o
Papadopulos
пропущено...

DELETE (Transact-SQL)
Здесь написано, что после удаления строк таблицы, неиспользованные страницы не могут быть использованы. Это понятно и видно - размер соотв. файла БД не меняется.
Но после сжатия эти страницы вполне прекрасно освобождаются

ппц
там написано, что страницы все еще куче принадлежат после DELETE-а.
BOL
the pages made empty by the delete operation remain allocated to the heap

ПЕРЕИСПОЛьЗОВАТь ИХ МОЖЕТ ТОЛьКО САМА КУЧА,
НО НИКАК НИКТО ДРУГОЙ.
НИ ОБъЕКТЫ ЭТОЙ ЖЕ БАЗЫ, НИ, ПРЕДСТАВьТЕ, ОС

Прошу прощения, неточно перевёл, но сути это не меняет. Меня больше интересует итоговый результат, после сжатия
28 янв 16, 15:00    [18740725]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Результаты выше привёл.

Результаты чего вы привели ?
Вы хоть сравнили размер таблицы до delete и после ?

Papadopulos
И в хелпе я не нашёл ничего, что противоречило бы полученным результатам.

Просто вы альтернативно одаренный. А хелп он для адекватных людей.
28 янв 16, 15:01    [18740732]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Прошу прощения, неточно перевёл, но сути это не меняет.

Конечно. Для упертых что черное, что белое - не меняет сути.
28 янв 16, 15:02    [18740742]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Papadopulos
Glory
пропущено...

А вы что можете ? Ну не томите тогда, раскройте тайну уже.

Никакой тайны нет, всё уже сказал - в одной копии базы я делал сжатие без удаления строк таблицы с файлами, в другой - сжатие с предварительным удалением строк, в третьей - сжатие с занулением поля, хранящего файлы.
Результаты выше привёл. Размер базы в третьем случае - 2800 Мб.
И в хелпе я не нашёл ничего, что противоречило бы полученным результатам.

Ошибся, в третьем случае 798 Мб получилось, 2800 это из другого эксперимента
28 янв 16, 15:04    [18740753]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Ошибся, в третьем случае 798 Мб получилось, 2800 это из другого эксперимента

да-да
И таракан без ног ничего не слышит.
28 янв 16, 15:05    [18740762]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory
Вы хоть сравнили размер таблицы до delete и после ?

Размер таблиц я не сравнивал. А что, есть другое объяснение освободившимся 2 ГБ?
28 янв 16, 15:08    [18740784]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Размер таблиц я не сравнивал. А что, есть другое объяснение освободившимся 2 ГБ?

А у вас есть объяснение того, почему без ног таракан не слышит ?
28 янв 16, 15:11    [18740802]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory,

Как я понимаю, вы хелп читаете и понимаете адекатно, но на практике не торопитесь его проверять, я неправ?
А ваш сарказм я не могу объяснить иначе, как неспособностью объяснить результаты эксперимента.
28 янв 16, 15:17    [18740837]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
А ваш сарказм я не могу объяснить иначе, как неспособностью объяснить результаты эксперимента.

Невозможно идиоту объяснить, что он идиот. Потому что он не поймет. Потому что он - идиот.

Papadopulos
Как я понимаю, вы хелп читаете и понимаете адекатно, но на практике не торопитесь его проверять, я неправ?

Этому хелпу уже больше 20ти лет
Вы думаете, что вы первый, кто решил проверить его на практике ?
28 янв 16, 15:22    [18740877]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory
Этому хелпу уже больше 20ти лет
Вы думаете, что вы первый, кто решил проверить его на практике ?

Я уже сказал, что в хелпе нет противоречий с проведённым экспериментом. Противоречия только с вашими словами
28 янв 16, 15:31    [18740920]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Я уже сказал, что в хелпе нет противоречий с проведённым экспериментом.

Я же и говорю, невозможно идиоту объяснить ....
28 янв 16, 15:35    [18740942]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7936
Papadopulos
Владислав Колосов,

Читаю
автор
Наибольший эффект от операции сжатия достигается при ее применении после операции, создающей много неиспользуемого пространства, например после усечения таблицы или удаления таблицы.

ЧТД


Вы читаете то, что хотите видеть и пропускаете то, что не хотите :)
28 янв 16, 15:46    [18740985]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
o-o
Guest
it's a picture time :)

+ репро
select *
CREATE TABLE [dbo].ayEDSStore(
	[IdFile] [int] NOT NULL, -- идентификатор файла
	[Signature] varbinary(max) NULL, -- отсоединённая ЭЦП
); 
go

declare @i int = 1
while @i <= 10
begin
	insert into [dbo].ayEDSStore
	values (@i, cast(REPLICATE('a', 8000) as binary(8000)));
	set @i = @i + 1;
end;
go

select COUNT(*)
from [dbo].ayEDSStore;

dbcc ind(db1, 'dbo.ayEDSStore', 1);
-------------------------------------------------
delete dbo.ayEDSStore
where IdFile in (1, 2);
go

select COUNT(*)
from [dbo].ayEDSStore;

dbcc ind(db1, 'dbo.ayEDSStore', 1);

создаю кучу, в нее кладу 10 "файлов" размером со страницу, итого 10 страниц данных.
опрашиваю count(*) в таблице, 10.
опрашиваю страницы таблицы: их 11, 10 data pages + 1 IAM page
----------
удаляю пару "файлов".
проверяю count(*): 8.
проверяю страницы кучи: все те же 11.

К сообщению приложен файл. Размер - 103Kb
28 янв 16, 15:50    [18741007]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
o-o
создаю кучу, в нее кладу 10 "файлов" размером со страницу, итого 10 страниц данных.
опрашиваю count(*) в таблице, 10.
опрашиваю страницы таблицы: их 11, 10 data pages + 1 IAM page
----------
удаляю пару "файлов".
проверяю count(*): 8.
проверяю страницы кучи: все те же 11.

В этом эксперименте нет сжатия базы.
Я же не оспариваю то, что после удаления записей страницы остаются в куче.
Разговор шёл о том, способствует ли удаление записей с последующим сжатием освобождению дискового пространства.
28 янв 16, 16:54    [18741361]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Владислав Колосов
Papadopulos
Владислав Колосов,

Читаю
пропущено...

ЧТД


Вы читаете то, что хотите видеть и пропускаете то, что не хотите :)

Допустим, я что-то не вижу. Тогда как вы объясните разницу в 2 Гб?
28 янв 16, 16:56    [18741370]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Тогда как вы объясните разницу в 2 Гб?

А с чего все должны поверить вашим голословным заявлениям про 2гб ?
28 янв 16, 16:58    [18741379]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Papadopulos
Member

Откуда:
Сообщений: 211
Glory,

Не верите, повторите
28 янв 16, 17:13    [18741465]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
Glory
Member

Откуда:
Сообщений: 104760
Papadopulos
Glory,

Не верите, повторите

Повторит что ?
Типа написать в форуме - у меня было 100Гб, а стало 1Гб ?
28 янв 16, 17:15    [18741487]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
o-o
Guest
Papadopulos
В этом эксперименте нет сжатия базы.

уже есть.
и 2 страницы ушли
а объяснения нет, поэтому пока что молчу.
найду, выложу.
28 янв 16, 17:17    [18741512]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
o-o
Guest
привожу Рэндалов ответ по этому поводу.
ну и кто подписан, в пн сможет почитать обсуждение
Randal
Hey <o-o> - yes, shrink will remove empty pages from a heap.
Deletes often don't result in empty page deletion from heaps -
see curious-case-empty-heap-table
(for some reason the script is messed up on the page, but it's the explanation you need).
And I'll talk about it in next Monday's Insider email too - thanks for the topic!
9 фев 16, 10:58    [18791601]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация хранения файлов  [new]
o-o
Guest
из вчерашней рассылки, полностью:
Randal
This time it’s another topic drawn from several email questions I received.
They boiled down to this (paraphrasing):
I’ve got a large heap table where the space isn’t being given up when I delete a large number of records,
but then when I shrink the database the heap is reduced in size. Can you explain?

The behavior you’re seeing is how SQL Server works, but it’s pretty non-intuitive.
When a page in an index becomes empty, it’s always deallocated
(as an empty page isn’t permitted in a SQL Server index structure from SQL Server 2005 onwards).
However, the structure of a heap is different and as a result, the behavior is too.

Whenever a row is deleted in a heap, it’s most likely that the page does not become empty.
However, if the page that the row is stored on becomes empty as a result of the delete,
the page cannot be deallocated from the table unless an exclusive table lock is held
(to remove the page from “tracking”).
This is usually not the case, unless lock escalation has occurred because you’re deleting enough rows to trigger escalation,
or if you specifically use the TABLOCK hint on the delete statement, for instance.
But, because all of these things are unlikely, the page usually cannot be deallocated.

There is a Knowledge Base article that describes this phenomenon: KB 913399.
However, the KB article only references up to and including SQL Server 2005
but this behavior exists in more recent releases too and is very easy to reproduce if you want to prove it to yourself.

The empty pages will be reused by subsequent inserts,
but if the space isn’t going to be reused following a large delete in a heap,
you might consider using the TABLOCK hint to allow the empty pages to be deallocated
and the space made available for other objects in the database to use.

Another alternative is to just use a clustered index instead, or if a heap is necessary,
you could rebuild the heap using ALTER TABLE … REBUILD
(that was added in SQL Server 2008 to support enabling compression on a heap),
with the caveat that this will cause all the table’s nonclustered indexes to be rebuilt.

On the extreme end (in my opinion), you could reclaim the empty heap space using a shrink operation.
Shrink won’t free up space inside pages as it moves them
(with the exception of compacting LOB pages as it goes –
somewhat unsuccessfully depending on which version and build you’re on – see KB 2967240),
but it will remove empty pages rather than moving them.
This will effectively shrink the heap after a large delete,
but with the usual caveats about shrink causing index fragmentation and generally being an expensive, slow operation to perform.

Call to action: Not really a call to action,
but one more thing to be aware of around how SQL Server works
and understanding the behavior you’re seeing when using heaps instead of clustered indexes.
16 фев 16, 15:43    [18824246]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Microsoft SQL Server Ответить