|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex SERG1257 Такое может получится только если CPU (лицензируемое) некуда девать, а дисковая система полный шлак. При включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данных, и это снизит (иногда, значительно) количество необходимых физических чтений. Если хватает, или для маленьких таблиц, то зачем оно... SERG1257 Выберите десяток другой больших таблиц (желательно секционированых по дате) и сжимайте только старые партиции в которых нет записи (а лучше и чтения). Их (монстров) можно сжимать и вручную написаным скриптом. Только ещё нужно заметить, что балк инсёрт перестаёт работать на сжатых таблицах (то есть скорость деградирует в сотни-тысячи и более раз), и приходится простую загрузку заменять на сложную (например, лить в кучу, потом строить на ней сжатый кластерный индекс, и присоединять как секцию к сжатой секционированной таблице) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 21:41 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Владислав Колосов aleks222, авторИначе данные с нее невозможно использовать. Там же данные не зипом пожаты, там простая табличная подстановка словарь - метасимволы. Эти данные можно прекрасно читать и преобразовывать "на лету". Это "алгоритм Лемпеля-Зива" называется. ZIP, промежду прочим, его использует. Как вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 07:02 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257, авторcad2206, а ты выгоду-то посчитал? Сколько гигабайт экономии получил? с 830ГБт после процедуры из статьи https://infostart.ru/1c/articles/692209/ размер файла БД составил 250ГБт ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 09:01 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Провел такой эксперимент: 1. Взял самую большую таблицу (138ГБт), сжал ее: ALTER TABLE TableName REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE) и ее индексы: ALTER INDEX IndexName ON Table REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE) 2. В БД размер таблицы уменьшился до 20ГБт 3. Сделал DBCC SHRINKDATABASE('''+ DataBase() + ''') 4. Размер файла БД уменьшился с 830ГБт до 675ГБт 5. При попытке выполнить дефрагментацию журнал транзакций вырос до 500ГБт, занял все свободное место и дефрагментация вылетела в ошибку Буду признателен, если объясните, почему так произошло? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 09:13 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 Провел такой эксперимент: 1. Взял самую большую таблицу (138ГБт), сжал ее: ALTER TABLE TableName REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE) и ее индексы: ALTER INDEX IndexName ON Table REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE) 2. В БД размер таблицы уменьшился до 20ГБт 3. Сделал DBCC SHRINKDATABASE('''+ DataBase() + ''') 4. Размер файла БД уменьшился с 830ГБт до 675ГБт 5. При попытке выполнить дефрагментацию журнал транзакций вырос до 500ГБт, занял все свободное место и дефрагментация вылетела в ошибку Буду признателен, если объясните, почему так произошло? Ты не нажимай на кнопки, смысла которых не понимаешь. И будет тебе щастье. ЗЫ. Дефрагментация = перемещение страниц = журналируемая операция. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 10:31 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222, ну ты серьезный конечно. авторТы не нажимай на кнопки, смысла которых не понимаешь. В основном пока нажимаю только одну "Выполнить скрипт" авторДефрагментация = перемещение страниц = журналируемая операция Это я понимаю. Мне непонятно почему тогда на боевой базе (размер диска для журнала транзакций такой же как и на тестовом сервере) ежедневная дефрагментация не увеличивает так журнал? Журнал увеличился во время дефрагментации после действий: 1. применение к одной таблице и ее индексам DATA_COMPRESSION = PAGE 2. SHRINKDATABASE Причем для этой таблицы дефрагментация выполнялась командой ALTER INDEX IndexName REORGANIZE ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 10:55 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
[deleted] ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 11:18 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
shrinkdatabase (без параметров) в принципе "ломает все индексы" и при их дефрагментации журнал базы данных естественно растет больше, так как дефрагментируются абсолютно все индексы. Так? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 16:39 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206Мне непонятно почему тогда на боевой базе (размер диска для журнала транзакций такой же как и на тестовом сервере) ежедневная дефрагментация не увеличивает так журнал?Два варианта Кто-то настроил регулярный (раз в минуту, раз в 15 минут, и тд) лог бакап Кто-то НЕ ДЕЛАЕТ ежедневную дефрагментацию (статья от АГ https://habr.com/ru/post/576882/ ) Теперь по пунктам. Итак выигрыш по месту у вас в разы - это хорошо, это заметно. Теперь поинтересуйся у старших товарищей - сколько стоит полтерабайта места на диске (добавь все тестовые экземпляры, DR и HA буде таковые существуют) сколько стоит память. (у стандарта есть ограничение в 128Гб на буферный кэш) сколько стоит время админа (бесплатно - плохой ответ) сколько стоит лицензия на лишний камень для вашей редакции, а также SA на нее. (если вы пиратите то бесплатно) Уверен что после подсчетов, в прешбывалые временя твои действия потянули бы на вредительство. Далее Если производительность ваших камней не просела после сжатия - то бишь лишняя нагрузка по сжатию/разжатию не стала заметной, то это говорит либо о том что ничего не делалось/не замерялось, либо что мощность серверов изначально была завышена и дополнительной нагрузки они не заметили. А значит вредитель в конторе затесался уже давно Если очень хочется принести максимум пользы (с мимимумом побочных эффектов) то советую провести анализ нагрузки (кто/что/когда делает с какими таблицами) В этом отношении поможет Query Store (если версия 2016+), extended events или просто поговорить с пользователями чтобы настраивать процесс который болит. Короче семь раз отмерь, один отрежь ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 17:10 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257, авторКто-то настроил регулярный (раз в минуту, раз в 15 минут, и тд) лог бакап и на боевом и на тестовом серверах настроен бекап журнала раз в 15 минут. Но разве бекап журнала уменьшает файл журнала? авторКто-то НЕ ДЕЛАЕТ ежедневную дефрагментацию делается каждый день (вернее ночь) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 17:21 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257 cad2206Мне непонятно почему тогда на боевой базе (размер диска для журнала транзакций такой же как и на тестовом сервере) ежедневная дефрагментация не увеличивает так журнал? Кто-то настроил регулярный (раз в минуту, раз в 15 минут, и тд) лог бакап Кто-то НЕ ДЕЛАЕТ ежедневную дефрагментацию (статья от АГ https://habr.com/ru/post/576882/ ) Либо разные модели восстановления На тестовом Full, на проде SIMPLE как бы это странно не звучало. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 17:21 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex, на обоих серверах режим восстановления "Полное" ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 17:22 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 msLex, на обоих серверах режим восстановления "Полное" А бекапы лога на тестовом сервер делаются? покажите (ну или хотя бы сами посмотрите) результат на обоих серверах Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 17:27 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex, результат с тестового сервера backup_start_date is_copy_only 2021-11-23 17:30:00.000 0 2021-11-23 17:15:01.000 0 2021-11-23 17:00:01.000 0 2021-11-23 16:45:01.000 0 2021-11-23 16:30:01.000 0 2021-11-23 16:15:00.000 0 2021-11-23 16:00:01.000 0 2021-11-23 15:45:01.000 0 2021-11-23 15:30:01.000 0 2021-11-23 15:15:00.000 0 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 17:35 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 П 3. Сделал DBCC SHRINKDATABASE('''+ DataBase() + ''') ... 5. При попытке выполнить дефрагментацию журнал транзакций вырос до 500ГБт, занял все свободное место и дефрагментация вылетела в ошибку Буду признателен, если объясните, почему так произошло? А так тут все просто 3-й шаг породил просто огромную фрагментацию по большому числу таблиц, что и вылилось в большое количество перемещаемых данных в момент дефрагментации. Нужно еще глянуть, что там у вас за "дефрагментацию" Если там есть Rebuild (возможно по условию), то это вообще транзакционная операция (если он не resumable), и в логе будут храниться все изменения ВСЕХ СЕАНОСВ, произошедших с момента начала операции alter index ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 17:47 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex, скрипт дефрагментации из статьи https://info-comp.ru/obucheniest/581-rebuilding-of-indexes-in-ms-sql-server.html ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 17:54 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257, спасибо за советы ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 17:57 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 msLex, скрипт дефрагментации из статьи https://info-comp.ru/obucheniest/581-rebuilding-of-indexes-in-ms-sql-server.html Ну как и ожидалось (с минимальными изменениями это стандартный скрипт, когда не хочется разбираться детальнее какие таблицы нужно трогать) Вы сильно фрагментировали данные и сработал этот пункт Если степень фрагментации более 30%, лучше выполнять перестроение индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2021, 18:18 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex, спасибо, теперь понимаю. Хочется все таки понять правильный алгоритм. Вопрос сжимать или не сжимать не стоит. Нужно сжимать. Сжимать буду все равно на тестовом сервере и отдавать базу в работу. Вопрос по секционированию таблиц и сжатию только тех, что редко используются, очень интересен. Но пока буду сжимать все и тестировать. Еще раз прошу подсказки, какую последовательность правильно выбрать: 1. Каждую ночь сжимать заранее подготовленный список таблиц и их индексов (так чтобы успеть перебрать его до начала работы с базой) методами: Код: sql 1. 2. 3.
2. Спустя несколько ночей, когда все таблицы будут сжаты, сделать SHRINKDATABASE (порядка 5 часов, одна ночь) 3. Произвести дефрагментацию индексов (после SHRINKDATABASE переиндексация заняла 5 часов, одна ночь). Тут два варианта: - либо увеличить размер диска под журнал БД до размера самой БД (что бы он не переполнился), - либо перевести БД в режим восстановления Simple, дефрагментировать и вернуть в режим Full. Верно, нет? Может дефрагментацию стоит делать до SHRINKDATABASE, а после запустить SHRINKDATABASE с параметром TRUNCATEONLY? Прошу помощи у Вас, профессионалы, но не советов, мол не лезь туда, чего не знаешь. Не лезть туда, значит ничего не узнать. Вы сами это проходили, уверен. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 09:10 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex, авторНу как и ожидалось (с минимальными изменениями это стандартный скрипт, когда не хочется разбираться детальнее какие таблицы нужно трогать) я привел в пример статью, скрипт переделывал немного исходя из прочтенной информации. Вот чуть переделанный мной: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88.
Дефрагментирую только те индексы, которые занимают более 8 страниц ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 09:45 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 10:56 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 msLex, спасибо, теперь понимаю. Хочется все таки понять правильный алгоритм. Вопрос сжимать или не сжимать не стоит. Нужно сжимать. Сжимать буду все равно на тестовом сервере и отдавать базу в работу. Вопрос по секционированию таблиц и сжатию только тех, что редко используются, очень интересен. Но пока буду сжимать все и тестировать. Еще раз прошу подсказки, какую последовательность правильно выбрать: 1. Каждую ночь сжимать заранее подготовленный список таблиц и их индексов (так чтобы успеть перебрать его до начала работы с базой) методами: Код: sql 1. 2. 3.
2. Спустя несколько ночей, когда все таблицы будут сжаты, сделать SHRINKDATABASE (порядка 5 часов, одна ночь) 3. Произвести дефрагментацию индексов (после SHRINKDATABASE переиндексация заняла 5 часов, одна ночь). Тут два варианта: - либо увеличить размер диска под журнал БД до размера самой БД (что бы он не переполнился), - либо перевести БД в режим восстановления Simple, дефрагментировать и вернуть в режим Full. Верно, нет? Может дефрагментацию стоит делать до SHRINKDATABASE, а после запустить SHRINKDATABASE с параметром TRUNCATEONLY? Прошу помощи у Вас, профессионалы, но не советов, мол не лезь туда, чего не знаешь. Не лезть туда, значит ничего не узнать. Вы сами это проходили, уверен. Образцово-показательная каша в голове. 1. SHRINKDATABASE - это "аварийная" операция. Ее проводят только после великой чистки базы при полной уверенности, что вы туда не насрете обратно ровно столько же, либо если вы свою базу окончательно отправляете в архив. На нормально работающей базе SHRINKDATABASE - это вредительство. 2. Дефрагментация делается "объективным по-показаниям", а не ради "дефрагментируем фсе на фсякий случай". 3. Научитесь уже статистику обновлять. 4. Вот так они создают имитацию бурной деятельности "Произвести дефрагментацию индексов (после SHRINKDATABASE переиндексация заняла 5 часов, одна ночь)". Шринкаем-дефрагментируем-Шринкаем-дефрагментируем. А ваще-то ALTER TABLE TableName REBUILD PARTITION полностью "дефрагментирует" индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 11:48 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222, авторОбразцово-показательная каша в голове совершенно верно, пока.. 1. SHRINKDATABASE необходимо будет произвести после авторвеликой чистки базы и сжатия. 2. авторДефрагментация делается "объективным по-показаниям" - ну намекните на эти показатели 3. авторНаучитесь уже статистику обновлять - разбираюсь 4. авторВот так они создают имитацию бурной деятельности - так подскажите как правильно сделать ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 12:08 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
baracs, Читал, интересно. Но нужно экспериментировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 12:11 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206Вопрос сжимать или не сжимать не стоит. Нужно сжимать. Сжимать буду все равноБезумству храбрых поем мы песню cad2206на тестовом сервере и отдавать базу в работуНе понял насчет тестового сервера. cad2206какую последовательность правильно выбратьСжимаете таблицу (торопится не надо). Не делаете shrink. Не делаете дефрагментацию. Я у себя отменил этот еженедельный джоб и никто не заметил разницы. Если обнаружите что стало хуже, разжимаете таблицу. Код: sql 1.
В результате сжатия база на проде не растет в размере (а заполняет пустоты). На тестовом сервере можно (но не нужно) сделать шринк чтобы например воткнуть еще одну базу если напряг с местом на диске. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 16:04 |
|
|
start [/forum/topic.php?fid=46&msg=40114273&tid=1684055]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
305ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 417ms |
0 / 0 |