Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
senn Member Откуда: Сообщений: 410 |
У кого есть опыт использования страничного сжатия таблиц? (SQL 2017) Интересует положительный/отрицательный (последний больше) опыт. Особенность, как я понимаю, относительно свежая (SQL 2016). Положительные стороны более или менее очевидны. Интересуют грабли, на которые можно наступить (кроме анонсированного MS требовательности к cpu). Имеет ли смысл в DWH включать эту опцию по умолчанию, или все же от определенного (от какого?) объема данных в таблице. Влияние сжатия на разные форматы данных понятно. Надо ли, для часто обновляемых таблиц, повторять инструкцию ALTER TABLE MyTab REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE); по аналогии с ребилдом индекса, или это происходит автоматически? Как я понял - нет, но где-то проскочило, что вроде бы нужно.. Спасибо! |
25 окт 19, 09:45 [22002255] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1957 |
ваша осетрина второй свежести. page compression появилось в 2008. опыт положителен. очень не хватает этого в Стандарде |
||
25 окт 19, 10:02 [22002277] Ответить | Цитировать Сообщить модератору |
senn Member Откуда: Сообщений: 410 |
Yasha123, "осетрина второй свежести" имеет отрицательную коннотацию, а опыт положительный)) Спасибо, я исходил из того, что статья в MSDN, на версии ниже 2016 не давала инфу (вероятно изменился источник ссылки). Опыт у меня тоже положительный, а хотелось бы услышать что-то плохое)) |
25 окт 19, 10:06 [22002282] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
senn, Всё подрят не знаю зачем, смотрите sp_estimate_data_compression_savings и решаете |
25 окт 19, 10:11 [22002288] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8353 |
senn, используйте, если изменение схем таблиц происходит крайне редко, т.к. при этом происходит полная перепаковка с потреблением ресурсов и даунтаймом. |
25 окт 19, 11:52 [22002400] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1957 |
я всегда точно цитирую фразу, на которую отвечаю, фиче 10+ лет, поэтому и свежесть соответствующая :) разумеется, компрессию не надо всюду включать, но текстового мусора всегда хватает и там это помогает. + на всех мне достающихся серверах вечный нехват оперативки, так что компрессия спасала, пока были Энтерпрайзы. на Стандарде ни компрессии, ни колумнсторов, все продумано, чтобы заставить покупать 2016 или же Энтерпрайз... |
||
25 окт 19, 11:53 [22002401] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8730 |
Никаких отрицательных момент (ну кроме чуть большего расхода CPU) не обнаружено. У нас, постраничное сжатие данных включено на всех таблицах. Помимо явного плюса "освобождение дискового пространства", есть и более приятный бонус - большее количество данных, вмещающихся в тот же объем RAM, а значит уменьшение IOPS. Польза второго бонуса в DWH сильно зависит от структуры запросов и соотношения RAM/DB Size Если большая часть запросов идут к последним секциям, и данные этих секций умещаются в RAM без сжатия, профит будет меньше Если большая часть запросов идут к последним секциям, и данные этих секций не умещаются в RAM без сжатия, профит будет больше Сообщение было отредактировано: 25 окт 19, 12:02 |
||
25 окт 19, 12:01 [22002408] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
Правда, это было на 2008 R2, может, сейчас пофиксили? |
||
25 окт 19, 17:01 [22002867] Ответить | Цитировать Сообщить модератору |
Remind Member Откуда: UK Сообщений: 523 |
В DWH имееть смысл подумать над columnstore |
25 окт 19, 18:01 [22002943] Ответить | Цитировать Сообщить модератору |
VicSO Member Откуда: Сообщений: 189 |
Еще насколько я понял (DATA_COMPRESSION = PAGE); для ALTER INDEX [еее] ON [ее] REBUILD WITH ( ONLINE = ON ) обрабатывается по другому. |
28 окт 19, 09:19 [22003864] Ответить | Цитировать Сообщить модератору |
vitkhv Member Откуда: Москва Сообщений: 940 |
senn, Вполне положительный опыт на редко используемых данных. На часто используемых стараюсь не включать компрессию. Хотя работал и с полностью сжатыми базами с достаточно высокой нагрузкой как разработчик, не сказал бы что там был прям критичный провал в производительности. |
28 окт 19, 18:37 [22004521] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8730 |
А что именно другого? |
||
28 окт 19, 18:41 [22004523] Ответить | Цитировать Сообщить модератору |
VicSO Member Откуда: Сообщений: 189 |
msLex, Как выяснил, если работать с жатой таблицей и делать REBUILD WITH ( ONLINE = ON ) То данная операция разжимает и потом повторно сжимает. Естественно лог в этом случае забивается хорошо. то есть если сделать REBUILD WITH ( ONLINE = OFF ) то лог транзакций будет 50 гб, но если сделать REBUILD WITH ( ONLINE = ON ) то лог транзакций будет уже под 300гигов Пока обратного подтверждения не получил, более подробно ссылка ниже. https://www.sql.ru/forum/1318488/problema-s-alter-index-rebuild-online-on |
31 окт 19, 13:21 [22007107] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4805 |
senn, COLUMSTRORE жмет сильней чем PAGE COMPRESSION. Попробуйте его, если не наткнетесь на ограничения. На 2016 он уже хорошо оптимизирован под вставку |
31 окт 19, 13:36 [22007124] Ответить | Цитировать Сообщить модератору |
a_voronin Member Откуда: Москва Сообщений: 4805 |
Конкретно в DWH очень сильно не рекомендую. Юзайте COLUMNSTORE COLUMNSTORE_ARCHIVE |
||
31 окт 19, 13:37 [22007127] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8730 |
rebuild всегда будет "разжимать/сжимать" данные, т.к. он перераспределяет данные по страницам. |
||
31 окт 19, 13:43 [22007132] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8353 |
Расщепление страниц также должно выполнять перепаковку. |
31 окт 19, 14:01 [22007148] Ответить | Цитировать Сообщить модератору |
VicSO Member Откуда: Сообщений: 189 |
msLex, Но такого при REBUILD WITH ( ONLINE = OFF ) нету, лог не забивается. как при ON |
1 ноя 19, 07:19 [22007666] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8730 |
У этого могут быть разные причины, но с постраничным сжатием это не связанно. |
||
1 ноя 19, 07:37 [22007670] Ответить | Цитировать Сообщить модератору |
VicSO Member Откуда: Сообщений: 189 |
msLex, Какие можете назвать? Пока только нашел в этом проблему. то есть если взять оригинальный индекс (не сжатый) то он на генерит 300гиг в OFF и 340гигов в ON ту то понятно и это норма. Но вот если его упаковать, и получится он 50 гигов, то при OFF получится 50гигов, но вот при ON то получится уже 340гигов, то есть обрабатывает его как не жатый. |
1 ноя 19, 11:47 [22007932] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |