|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Добрый день. На MS SQL Server имеется БД. Ее размер 830ГБт. Появилось желание сжать ее и попробовать в работе. На тестовом сервере сжал исходя из этой статьи https://infostart.ru/1c/articles/692209/. По времени около 20 часов. После сжатия тестировали, в производительности выиграли сильно. Исходя из то, что остановить работу на 20 часов не представляется возможным (объекты работают с утра до вечера 7 дней в неделю), вопрос: Как поэтапно, скажем за несколько ночей сжать базу? Имея ввиду еще то, что ночью запускается обслуживание БД (бекап, дефрагментация индексов, обновление статистики) Пока на ум приходит алгоритм 1: 1. Получили список таблиц (в БД их порядка 5000) 2. Поделили на части (например по 500 таблиц), сохранили эти части где то в виде списков таблиц (получится 10 частей) 2. И каждую ночь прогоняем по одной части Или алгоритм 2: 1. Каждую ночь получаем список таблиц и пробегаем по нему до наступления утра. 2. Если встречаем таблицу или индекс с параметром сжатия NONE, сжимаем его По идее за несколько проходов вся база сожмется. Но я не нашел как получить параметр сжатия именно у индекса. Или есть более грамотные решения? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 08:47 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206, давно нашел скрипт (он для SAP изначально) может пригодится: ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 09:24 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
архивариус, посмотрел скрипт, мудрено. Но не понял в чем его особенность. Он так же долго будет сжимать базу. Или я что то проглядел? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 09:43 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 Добрый день. На MS SQL Server имеется БД. Ее размер 830ГБт. Появилось желание сжать ее и попробовать в работе. На тестовом сервере сжал исходя из этой статьи https://infostart.ru/1c/articles/692209/. По времени около 20 часов. После сжатия тестировали, в производительности выиграли сильно. Исходя из то, что остановить работу на 20 часов не представляется возможным (объекты работают с утра до вечера 7 дней в неделю), вопрос: Как поэтапно, скажем за несколько ночей сжать базу? Имея ввиду еще то, что ночью запускается обслуживание БД (бекап, дефрагментация индексов, обновление статистики) Пока на ум приходит алгоритм 1: 1. Получили список таблиц (в БД их порядка 5000) 2. Поделили на части (например по 500 таблиц), сохранили эти части где то в виде списков таблиц (получится 10 частей) 2. И каждую ночь прогоняем по одной части Или алгоритм 2: 1. Каждую ночь получаем список таблиц и пробегаем по нему до наступления утра. 2. Если встречаем таблицу или индекс с параметром сжатия NONE, сжимаем его По идее за несколько проходов вся база сожмется. Но я не нашел как получить параметр сжатия именно у индекса. Или есть более грамотные решения? 1. Чудеса, прям, глаголите. Сжали усе и... завертелось. Мой хрустальный шар немного потрескался, но более вероятно, что перестроение индексов вызвало обновление статистики. 2. Ну хотите и не можете найти (хотя искали ли?) признак сжатия на таблице. Делаете списочек таблиц и по одной табличке из списка ночью сжимаете. 3. Займитесь более продуктивной деятельностью. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 10:37 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206, никаких особенностей, он просто делает то что вам нужно. хотите свой пишите. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 10:39 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 Но я не нашел как получить параметр сжатия именно у индекса. Код: sql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 10:42 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222, 1. Сжал, отдал 1С программистам на тесты, 3 дня тестировали нагрузку и т.п. Показали результаты, прирост в производительности есть. Делали тестирование и исправление БД, все в норме. Чего ожидать можно еще? 2. Признак сжатия таблицы я могу найти, например так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Я не могу найти признак сжатия именно у индекса таблицы. Сжимать по одной таблице за ночь 5000 таблиц, это как бы 13 лет) 3. "Займитесь более продуктивной деятельностью." - например? Я без всякого сарказма. Предполагаю, что чего то могу не понимать, поэтому и пишу тут. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 10:54 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
архивариус, спасибо. Но мне бы хотелось получить советы, как грамотно организовать алгоритм поэтапного сжатия, не останавливая работу. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 10:56 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
4es, спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 11:05 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222 1. Чудеса, прям, глаголите. Сжали усе и... завертелось. Мой хрустальный шар немного потрескался, но более вероятно, что перестроение индексов вызвало обновление статистики. Почему это чудеса? Вполне реально, что производительность улучшилась просто за счет того, что теперь с диска меньше данных читается. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 12:16 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
И вопрос, ответ на который поможет мне быстрее понять, как правильно сделать: команда ALTER TABLE 'TableName' REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE) сжимает данные в таблице, или же только устанавливает флаг сжатия и сжимаются данные, которые пишутся в нее после установки флага? Если только устанавливается флаг, то данные сжимаются командой DBCC SHRINKDATABASE? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 12:42 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 И вопрос, ответ на который поможет мне быстрее понять, как правильно сделать: команда ALTER TABLE 'TableName' REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE) сжимает данные в таблице, или же только устанавливает флаг сжатия и сжимаются данные, которые пишутся в нее после установки флага? Если только устанавливается флаг, то данные сжимаются командой DBCC SHRINKDATABASE? Рано те "сжимать таблицы". Учиться надо. ALTER TABLE 'TableName' REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE) Толсто намекает. А время, потребное для оной операции, подтверждает толстый намек. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 13:30 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 aleks222, 1. Сжал, отдал 1С программистам на тесты, 3 дня тестировали нагрузку и т.п. Показали результаты, прирост в производительности есть. Делали тестирование и исправление БД, все в норме. Чего ожидать можно еще? Ну я так понимаю, UPDATE STATISTICS with fullscan вы тоже делали? И тоже тестировали? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 13:34 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Про сжатие онлайн автору темы кто-нибудь говорил, про версию его сервера спрашивали? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 13:55 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222, авторРано те "сжимать таблицы". Учиться надо. Как раз я и учусь. Поэтому и вопросы задаю. А можно научиться не пробуя? авторALTER TABLE 'TableName' REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE) Толсто намекает. А время, потребное для оной операции, подтверждает толстый намек. Да, уже убедился. авторНу я так понимаю, UPDATE STATISTICS with fullscan вы тоже делали? Нет, с параметром FULLSCAN не запускал, обновлял так: Код: sql 1. 2. 3.
Стоит обновить с этим параметром? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 15:52 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
.Евгений, авторПро сжатие онлайн автору темы кто-нибудь говорил Пока не говорили, надеюсь Вы подскажете) авторпро версию его сервера спрашивали? Тестирую на 2014 и на 2019 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 15:56 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206, сжатие возможно выполнять онлайн (не на всех версиях MS SQL). В большинстве случаев это позволяет не останавливать работу (но подтормаживать ее). ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 16:20 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Надо еще понять, а какие действия именно ТС называет "сжатием базы". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 16:42 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
.Евгений, Понял, про что Вы. Код: sql 1.
Нужно экспериментировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 16:52 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Владислав Колосов, Именно те действия, которые описаны в статье, ссылку на которую я указал в первом сообщении (https://infostart.ru/1c/articles/692209/) и затем возвратить свободное место на диск методом DBCC SHRINKDATABASE ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 16:58 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 .Евгений, Понял, про что Вы. Код: sql 1.
Нужно экспериментировать. C (resumable = on) осторожнее экспериментируйте. Остановка процесса не отменяет операцию, а ставит ее на паузу. Это значит что у вас по прежнему будет висеть недоделанная версия индекса и любая модификация будет затрагивать оба этих индекса. Для полной отмены нужно выполнить alter index ... abort ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:00 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
КритикВполне реально, что производительность улучшилась просто за счет того, что теперь с диска меньше данных читается.Такое может получится только если CPU (лицензируемое) некуда девать, а дисковая система полный шлак. Надувной матрас - классное решение для маленькой квартирки, но надувать его по вечерам и сдувать по утрам - так себе занятие. cad2206Или есть более грамотные решения? С какого-то возраста появился вопрос «Зачем?» (с) Мой хрустальный шар показывает зуд попробовать новую игрушку что для (объекты работают с утра до вечера 7 дней в неделю) может быть чреватым. cad2206 "Займитесь более продуктивной деятельностью." - например? Я без всякого сарказма. Предполагаю, что чего то могу не понимать, поэтому и пишу тут.ИМХО имеет смысл сжимать только партиции со старыми данными, которые никому особо не нужны, замерив выгоду для сжатия и решив стоит ли оно того. Вместо сжатия ВСЕГО ПОДРЯД посмотрите на свои таблицы. Уверен что из 5000 большая часть это справочники которые сжимать нет смысла. Выберите десяток другой больших таблиц (желательно секционированых по дате) и сжимайте только старые партиции в которых нет записи (а лучше и чтения). Их (монстров) можно сжимать и вручную написаным скриптом. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:03 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257 Такое может получится только если CPU (лицензируемое) некуда девать, а дисковая система полный шлак. Какой бы крутой не была дисковая подсистема, она все равно будет существенно уступать по скорости RAM. При включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данных, и это снизит (иногда, значительно) количество необходимых физических чтений. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:08 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206, Если после DBCC SHRINKDATABASE улучшилась производительность, то возможны проблемы с физическим носителем, начиная от фрагментации и заканчивая повторяющимися чтениями секторов диска. Либо диск как-то не так отформатирован. После сжатия производительность слегка ухудшается. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:09 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Владислав Колосов, Хм, все СХД только SSD... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:18 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLexПри включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данныхУверен, что в памяти как раз все блоки разжаты. разжатие/сжатие идет при чтении/записи (каждый раз). Возможно что для ТС больше подойдет ROW сжатие (гораздо дешевле по ресурсам) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:26 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex SERG1257 Такое может получится только если CPU (лицензируемое) некуда девать, а дисковая система полный шлак. Какой бы крутой не была дисковая подсистема, она все равно будет существенно уступать по скорости RAM. При включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данных, и это снизит (иногда, значительно) количество необходимых физических чтений. Похоже мифы сжатия зохавали мир. Даже мелкософт толкует только о "экономии дискового пр-ва". Да оно и понятно, при считывании сжатой страницы в память она снова "разжимается". Иначе данные с нее невозможно использовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:28 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257 msLexПри включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данных Возможно что для ТС больше подойдет ROW сжатие (гораздо дешевле по ресурсам) В памяти лежат копии страниц данных с диска, иначе как узнать, когда там наступит момент переполнения страницы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:29 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex SERG1257 пропущено... Уверен, что в памяти как раз все блоки разжаты. разжатие/сжатие идет при чтении/записи (каждый раз). Возможно что для ТС больше подойдет ROW сжатие (гораздо дешевле по ресурсам) В памяти лежат копии страниц данных с диска, иначе как узнать, когда там наступит момент переполнения страницы. Ваши доказательства? (c) Шварценеггер. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:32 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222 msLex пропущено... Какой бы крутой не была дисковая подсистема, она все равно будет существенно уступать по скорости RAM. При включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данных, и это снизит (иногда, значительно) количество необходимых физических чтений. Похоже мифы сжатия зохавали мир. Даже мелкософт толкует только о "экономии дискового пр-ва". Да оно и понятно, при считывании сжатой страницы в память она снова "разжимается". Иначе данные с нее невозможно использовать. Данные на диске в файле лежат 8Кб страницами. Не больше не меньше. Все изменения с данными происходят только после поднятие этой страницы в память. Как, скажите, отслеживать момент окончания страницы, если ее сжатый размер будет известен только при записи на диск? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:33 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex Данные на диске в файле лежат 8Кб страницами. Не больше не меньше. Свежо преданье. msLex Все изменения с данными происходят только после поднятие этой страницы в память. Как, скажите, отслеживать момент окончания страницы, если ее сжатый размер будет известен только при записи на диск? Ты так и не ответил, как из "архива" достать строку, не распаковывая архив? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:35 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222 msLex Данные на диске в файле лежат 8Кб страницами. Не больше не меньше. Свежо преданье. Т.е. по вашему это не так? aleks222 msLex Все изменения с данными происходят только после поднятие этой страницы в память. Как, скажите, отслеживать момент окончания страницы, если ее сжатый размер будет известен только при записи на диск? Ты так и не ответил, как из "архива" достать строку, не распаковывая архив? Вот вам, почитайте как происходит сжатие данных при PAGE компрессии в SQL Server https://docs.microsoft.com/ru-ru/sql/relational-databases/data-compression/page-compression-implementation?view=sql-server-ver15 Советую особенно обратить вот на эту часть После того как страница заполнена, добавление следующей строки вызывает операцию ее сжатия. Вся страница просматривается; каждый столбец оценивается для сжатия префикса, а затем оцениваются все столбцы для сжатия словаря. И подумать, может ли это быть совместимо с вашим утверждением "сжатие только при записи на диск" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:43 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Советую не читать савецких газет перед обедом. Ну... или читать "в подлиннике". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:49 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222 Советую не читать савецких газет перед обедом. Ну... или читать "в подлиннике". Там так же черным по белому написано, что вы балабол https://docs.microsoft.com/en-us/sql/relational-databases/data-compression/page-compression-implementation?view=sql-server-ver15 When the page is full, the next row to be added initiates the page compression operation. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:51 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex После того как страница заполнена, добавление следующей строки вызывает операцию ее сжатия. Вся страница просматривается; каждый столбец оценивается для сжатия префикса, а затем оцениваются все столбцы для сжатия словаря. "После того как страница заполнена" => ДО момента сжатия страница НЕ сжата. Очевидный факт. Волга впадает в Каспийское море. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:53 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257, авторВыберите десяток другой больших таблиц (желательно секционированых по дате) и сжимайте только старые партиции в которых нет записи (а лучше и чтения) Большие таблицы выбрал так: Код: 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.
Буду признателен, если укажете где взять данные "только старые партиции в которых нет записи (а лучше и чтения)". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:57 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222, msLex интересно, не могут ли в памяти жить как сжатые, так и не сжатые страницы? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:59 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222 msLex пропущено... "После того как страница заполнена" => ДО момента сжатия страница НЕ сжата. Очевидный факт. Волга впадает в Каспийское море. Вы бы полностью прочитали, хоть Новая страницы заполняется без сжатие, пока на нее влезают данных, т.к. до этого момента сжатие не имеет смысла. Как только данные без сжатия прекращают влезать, следующая же вставленная строка инициализирует процесс сжатия. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:59 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 SERG1257, авторВыберите десяток другой больших таблиц (желательно секционированых по дате) и сжимайте только старые партиции в которых нет записи (а лучше и чтения) Большие таблицы выбрал так: Код: 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.
Буду признателен, если укажете где взять данные "только старые партиции в которых нет записи (а лучше и чтения)". Секционирование таблиц у тебя еще впереди. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 17:59 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
.Евгений aleks222, msLex интересно, не могут ли в памяти жить как сжатые, так и не сжатые страницы? Это такой метод "экономии памяти"? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 18:00 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
.Евгений интересно, не могут ли в памяти жить как сжатые, так и не сжатые страницы? Т.е. каждая страница живет в двух экземплярах? Нет, конечно, это уменьшит вместимость buffer pool почти в 2 раза ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 18:00 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex aleks222 пропущено... "После того как страница заполнена" => ДО момента сжатия страница НЕ сжата. Очевидный факт. Волга впадает в Каспийское море. Вы бы полностью прочитали, хоть Новая страницы заполняется без сжатие, пока на нее влезают данных, т.к. до этого момента сжатие не имеет смысла. Как только данные без сжатия прекращают влезать, следующая же вставленная строка инициализирует процесс сжатия. Ты не сыпь цитатами из Мао - ты на пальцах покажи "как достать что-то из архива, не распаковывая архив?" ЗЫ. Если ты не курсе, операции сервера не ограничиваются тупым "заполнением страниц". Иногда надо что-то с них достать... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 18:02 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex .Евгений интересно, не могут ли в памяти жить как сжатые, так и не сжатые страницы? Т.е. каждая страница живет в двух экземплярах? Нет, конечно, это уменьшит вместимость buffer pool почти в 2 раза Нет. Сжатые и несжатые, аналогично тому, как они будут жить на диске (если бы были в этот момент записаны). aleks222 .Евгений aleks222, msLex интересно, не могут ли в памяти жить как сжатые, так и не сжатые страницы? Это такой метод "экономии памяти"? Кто у нас отвечает вопросом на вопрос? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 18:02 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
.Евгений msLex пропущено... Т.е. каждая страница живет в двух экземплярах? Нет, конечно, это уменьшит вместимость buffer pool почти в 2 раза Нет. Сжатые и несжатые, аналогично тому, как они будут жить на диске (если бы были в этот момент записаны). Так и есть, станицы в памяти те же, что и на диске. За исключением dirty pages, что еще не скинуты на диск. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 18:08 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222 "как достать что-то из архива, не распаковывая архив?" Распокавать на лету, конечно. SQL Server для сжатия данных использует lightweight алгоритмы сжатия, позволяющие применять декомпрессию на потоке. Вы почитайте, Там все достаточно просто. Основное : Row Compression - урезание неиспользуемых байт из типов фиксированной длины Page Compression - в добавлении к Row Compression постраничные справочники. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 18:21 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLexРаспокавать на лету, конечно.Каждый раз когда блок понадобится из буфер кэша. Что совой об пень, что пнем об сову. cad2206, а ты выгоду-то посчитал? Сколько гигабайт экономии получил? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 19:33 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222, авторИначе данные с нее невозможно использовать. Там же данные не зипом пожаты, там простая табличная подстановка словарь - метасимволы. Эти данные можно прекрасно читать и преобразовывать "на лету". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 19:46 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257, с чего вы взяли, что cad2206 использовал сжатие страниц? Он нигде об этом не писал. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 19:48 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Владислав Колосовс чего вы взяли, что cad2206 использовал сжатие страниц? Он нигде об этом не писал. 22399026 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 20:58 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257 msLexРаспокавать на лету, конечно. Именно так Как я уже писал выше, там очень легковесное разжатие В случае с Row так вообще, просто превращение всех типов данных в типы с переменой длиной (varint, vardecimal и т.д.), что, фактически, эквивалентно реализации varchar в несжатых страницах. подробности тут В случае с Page добавляются префиксы и справочники. подробности тут Ни одно из этих преобразований не требует "разжимать" всю страницы целиком, при чтении конкретной записи. Все разбирается при последовательном чтении данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2021, 21:18 |
|
Поэтапное сжатие БД 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 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257, авторНе понял насчет тестового сервера. не корректно выразился. На новом сервере, где установлен MS SQL Server 2019. База переедет со старого (на MS SQL Server 2012). авторСжимаете таблицу (торопится не надо). Помню, что нужно секционировать таблицы, но пока без этого. С каких таблиц лучше начать? Наиболее часто используемых? Больших? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 16:24 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Для больших таблиц прогоните sp_estimate_data_compression_savings https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-estimate-data-compression-savings-transact-sql?view=sql-server-ver15 Посмотрите на разные типы сжатия. Может ROW будет ненамного хуже (и точно дешевле) У меня было пару случаев когда это имело смысл (большая таблицы с пустыми полями типа int и большая таблица с типом char(200)) Маленькие таблицы даже не рассматривайте - визгу много шерсти мало ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2021, 17:14 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257, при размере файла БД 830 ГБт, какие таблицы считать большими для исследования их функцией sp_estimate_data_compression_savings? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 09:16 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
SERG1257, авторСжимаете таблицу (торопится не надо). Не делаете shrink. Не делаете дефрагментацию. Я у себя отменил этот еженедельный джоб и никто не заметил разницы. Я правильно понял, сжимать по несколько таблиц за ночь без shrink'а (это я уже понял, что shrink крайняя мера) и без дефрагментации. И смотреть на работу пользователей? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 09:19 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
У меня нагруженная база 1С на 3 терабайта, по опыту пространство больше расходуется на фрагментацию поскольку кластерный (системный) код 1С много удаляет и вставляет заново особенно в итогах по регистрам. Перестроение кластерных индексов и обычных индексов помогает гораздо эффективнее. Освобожденное место можно использовать для новых данных. Ну а вообще в решении должна быть заложена процедура обрезания старых данных и свертки остатков. База не должна расти бесконечно ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 12:40 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206какие таблицы считать большими для исследования их функцией sp_estimate_data_compression_savings?Исследовать можно хоть все (это просто посмотреть, это бесплатно) Результаты (для PAGE и для ROW) в эксельку, сортируя по разнице между sample_size_with_current_compression_setting и sample_size_with_requested_compression_setting Уверен, что кандидатов будет не больше десятка. А дальше нужно будет принимать решение кто достоин, а кто нет. selis76, я человек простой, а вопрос сложный. Можешь пояснить свою мысль языком ЖЭКа. (или как говорят буржуи ELI5) Правильно ли я понял, что ты хочешь сказать что для твоей базы перестроение индексов действительно высвобождает место. Однако следом ты утверждаешь что плотно упакованный индекс, будет снова переразбит следующей операцией (особенно в итогах по регистрам.) Так может и не трогать эти итоги по регистрам. Ну будут некоторые страницы наполовину пусты. Стоит ли овчинка выделки? И как это относится к сабжу топика (сжатие aka компрессия данных). По поводу удаления старых данных это тоже оффтопик. Люди годами не могут почистить балкон (гараж, подвал), а тут данные удалить. А если понадобятся? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 17:19 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
to SERG1257, 1C это генератор таблиц и запросов на основе финансовых метаданных . Поэтому большинство информации имеет период и итоги тоже периодичны (по умолчанию месяц) . Даже в регистрах накопления агрегаты тоже порождают много операций удаления и вставки А это прямой путь к фрагментации. Конечно ребилд оптимизирует данные в прошлых периодах, но в новых периодах все начинается сначала. Играться с наполнением экстентов можно уже после того как все хорошо с фрагментацией. Пример как 1С генерит SQL код можно увидеть тут https://infostart.ru/1c/articles/184361/ Структура таблиц и индексов 1С официально выложена https://its.1c.ru/db/metod8dev/content/1798/hdoc https://its.1c.ru/db/metod8dev/content/1590/hdoc ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2021, 20:08 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Добрый день, знатоки. Продолжаю свои эксперименты, не ругайтесь, это лишь эксперименты на тестовых базах, для моего понимания. Создал этапы в плане обслуживания: 1. Создание полной резервной копии в модели восстановления "Полная" 2. SHRINKDATABASE Код: sql 1.
3. Перевод базы в модель восстановления "Простая" Код: sql 1. 2.
4. Дефрагментация индексов 5. Перевод базы в модель восстановления "Полная" Код: sql 1. 2.
6. Обновление статистики Если я правильно понимаю, то в модели восстановления "Простая", лог журнала не растет. Но уже на этапе дефрагментации заметил, лог вырос, примерно до размера самой базы (после шринка). Объясните пожалуйста, почему вырос лог? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 09:42 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 Если я правильно понимаю, то в модели восстановления "Простая", лог журнала не растет. Не правильно поняли. В простой модели, лог автоматически усекается (освобождается место внутри файлов лога) по завершению транзакций. cad2206 Перевод базы в модель восстановления "Полная" Код: sql 1. 2.
Просто для понимания. После перевода базы в FULL, реальный переход на FULL модель восстановления произойдет только после 1-го полного бекапа. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 10:14 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 Добрый день, знатоки. 2. SHRINKDATABASE забудьте эту команду ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 10:19 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex, Так отчего вырос лог (именно файл лога, очень сильно вырос )? Понимаю, что при SHRINKDATABASE данные в БД фрагментируются полностью. Затем выполняю дефрагментацию для всех индексов. Если завершенной транзакцией считать каждое выполнение: Код: sql 1.
при дефрагментации, в модели восстановления "Простая", то лог будет усекаться внутри файла и сам файл расти не будет. А тут вырос сам файл лога. Что в моем случае тогда считается завершенной транзакцией? авторПросто для понимания. После перевода базы в FULL, реальный переход на FULL модель восстановления произойдет только после 1-го полного бекапа. Это я понимаю. felix_ff, авторзабудьте эту команду забуду, как только разберусь во всем ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 11:22 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
msLex, Так отчего вырос лог (именно файл лога, очень сильно вырос )? Понимаю, что при SHRINKDATABASE данные в БД фрагментируются полностью. Затем выполняю дефрагментацию для всех индексов. Если завершенной транзакцией считать каждое выполнение: Код: sql 1.
при дефрагментации, в модели восстановления "Простая", то лог будет усекаться внутри файла и сам файл расти не будет. А тут вырос сам файл лога. Что в моем случае тогда считается завершенной транзакцией? авторПросто для понимания. После перевода базы в FULL, реальный переход на FULL модель восстановления произойдет только после 1-го полного бекапа. Это я понимаю. felix_ff, авторзабудьте эту команду забуду, как только разберусь во всем ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 11:44 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206, Код: sql 1.
- логируемая операция, чего вы удивляетесь что у вас файл лога расти не будет? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 13:34 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
felix_ff, спасибо, я понимаю что она журналируемая. Но для большего понимания хочется усвоить: 1. В модели восстановления "Простая", журнал усекается внутри файла журнала при подтверждении транзакции. Ок. Что считать подтвержденной транзакцией? Выполнение ALTER INDEX [IndexName] ON [TableName] REBUILD считается подтвержденной транзакцией? В моем случае таких вызовов на каждый индекс, при переиндексации, за 400. 2. В зависимости от понимания первого пункта, как предотвратить переполнение журнала (диска, выделенного под журнал)? Переиндексировать в модели восстановления "Полная" и бекапить журнал раз в 15 мин? Файл журнала вырос почти на 400ГБ, при размере БД в 220ГБ. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 13:46 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 felix_ff, спасибо, я понимаю что она журналируемая. Но для большего понимания хочется усвоить: 1. В модели восстановления "Простая", журнал усекается внутри файла журнала при подтверждении транзакции. Ок. Что считать подтвержденной транзакцией? Выполнение ALTER INDEX [IndexName] ON [TableName] REBUILD считается подтвержденной транзакцией? В моем случае таких вызовов на каждый индекс, при переиндексации, за 400. 2. В зависимости от понимания первого пункта, как предотвратить переполнение журнала (диска, выделенного под журнал)? Переиндексировать в модели восстановления "Полная" и бекапить журнал раз в 15 мин? Файл журнала вырос почти на 400ГБ, при размере БД в 220ГБ. 1. @@trancount = 0 2. Так ты ничо и не понял. Увы. Даже донкихот не боролся с ростом журнала транзакций переключением мельниц на полные обороты. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 14:16 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Ах да, "как предотвратить?" Завязывай с реиндексированием. Надежно. Просто. Эффективно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 14:18 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222, авторТак ты ничо и не понял Ну объясни доступно. Где что я не понимаю? На каких этапах что происходит? Уважаемые знатоки, мне придется один раз сделать шринк, кто бы что не говорил, но придется. ОДИН РАЗ! На рабочей базе, когда пойму все особенности и отлажу на тестовых базах. А после шринка придется сделать дефрагментацию, как минимум один раз (т.к. после шринка все данные фрагментированы очень сильно). Поэтому и прошу помощи разобраться. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 15:01 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206, вы с какой проблемой пытаетесь бороться? shrink файлов базы данных (замечу не файлов лога) нужен только в одном случае: когда у вас к примеру файл базы данных заполнил весь объем свободного дискового пространства и дальше файлы бд в том числе файлы лога расти не могут, а руководство жопится и денег на новые диски не дает. вы берете чистите (delete/truncate) какой то большой объем архивных данных за N-лет который уже никогда никому не понадобится, у вас высвобождается место которое можно вернуть операционной системе, тем самым позволив файлу лога расти что бы не стопорить бд, вот только в этом случае шринк файлов данных оправдан. в других ситуациях: а) файл бд должен быть всегда 300ГБ и ни капельки больше, б) о мой бог наш файл разово разросся нужно его ужать сейчас же с) прочая хрень шринк вообще ни разу не оправдан, вы только тем самым насилуете базу/диски. дайте файлам данных спокойно расти. даже если вы очистили архивные данные, не возвращайте место операционной системе, пусть оно будет зарезервировано для базы на новые данные, это место будет в последствии полезно переиспользовано без относительно дорогостоящих операций увеличения файла данных. Но для большего понимания хочется усвоить: 1. В модели восстановления "Простая", журнал усекается внутри файла журнала при подтверждении транзакции. не верно, в простой модели восстановления усечение происходит после достижения контрольной точки дополнительно надо понимать что есть факторы препятствующие усечению журнала (откладывающие его) ознакомьтесь: https://docs.microsoft.com/en-us/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver15#FactorsThatDelayTruncation ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 16:02 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
felix_ff, авторshrink файлов базы данных (замечу не файлов лога) нужен только в одном случае: когда у вас к примеру файл базы данных заполнил весь объем свободного дискового пространства и дальше файлы бд в том числе файлы лога расти не могут, а руководство жопится и денег на новые диски не дает именно! ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 16:08 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
felix_ff, авторвы с какой проблемой пытаетесь бороться? сейчас уже не проблема, а желание понять. Например, почему вырос файл журнала, при дефрагментации в модели восстановления "Простая". ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 16:19 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
авторНапример, почему вырос файл журнала, при дефрагментации в модели восстановления "Простая".Файл журнала будет размером с самую большую транзацию. Если у вас есть хотя бы одна большая таблица, то файл будет огромным вне зависимости от модели. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 16:22 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
L_argo, авторФайл журнала будет размером с самую большую транзацию Что мне понимать под транзакцией в моем случае? авторЕсли у вас есть хотя бы одна большая таблица, то файл будет огромным вне зависимости от модели на тестовой базе самая большая таблица занимает 24ГБт. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 16:39 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
felix_ff, авторне верно, в простой модели восстановления усечение происходит после достижения контрольной точки Из документации https://docs.microsoft.com/ru-ru/sql/relational-databases/logs/database-checkpoints-sql-server?view=sql-server-ver15: в простой модели восстановления автоматическая контрольная точка становится в очередь, если журнал заполняется на 70 процентов. Верный ли от сюда вывод, что журнал будет усекаться при достижении его размера в 70% от размера самого файла журнала? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 17:22 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 Верный ли от сюда вывод, что журнал будет усекаться при достижении его размера в 70% от размера самого файла журнала? Кто на ком стоял? ЗЫ. Прирожденный управдом. Этот тредстартер. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 17:58 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222, Ох, хочется услышать от тебя что то полезное, а каждый пост все о одном... ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 18:18 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 aleks222, Ох, хочется услышать от тебя что то полезное, а каждый пост все о одном... Чтобы понять ответ - надо знать ответ на 90%. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 19:02 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
aleks222, абсолютно согласен. Буду разбираться дальше. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2021, 20:09 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Запустил эксперимент еще раз: Модель восстановления "Полная". После полного бекапа запустил DBCC SHRINKDATABASE(DBName). Стал наблюдать. Журнал стал расти и с 195ГБ вырос до 290ГБ. По завершении операции перевел базу в модель восстановления "Простая" и запустил дефрагментацию. По завершению размер журнала не увеличился. Еще раз (уже не первый раз) прочитал статью https://docs.microsoft.com/ru-ru/sql/t-sql/database-console-commands/dbcc-shrinkdatabase-transact-sql?view=sql-server-ver15. Выдержки из нее: автор"DBCC SHRINKDATABASE Сокращает размер файлов данных и файлов журнала в указанной базе данных." При этом файл журнала растет. Это как? автор"При выполнении команды DBCC SHRINKDATABASE укажите параметр NOTRUNCATE или TRUNCATEONLY. Если этого не сделать (в моем случае), результат будет таким же, как если бы вы выполнили операцию DBCC SHRINKDATABASE с аргументом NOTRUNCATE и последующим запуском операции DBCC SHRINKDATABASE с аргументом TRUNCATEONLY." автор"Аргумент NOTRUNCATE применим только к файлам данных. NOTRUNCATE не влияет на файл журнала." "Аргумент TRUNCATEONLY оказывает влияние на файл журнала." Совсем запутался. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2021, 09:31 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 При этом файл журнала растет. Это как? Любые изменения в данных, в том числе и SHRINK, логируются. В полном модели восстановления данные в логе помечаются как "не нужные" только после бекапа этих данных (на самом деле там несколько отсечек: бекап лога, открытые транзакция, чекпоинт, передача данных на все вторичные реплики и т.п.). Также в полной модели все постраничные операции записываются в лог целиком (т.е. прям полностью 8Кб страница записывается в лог). А значит ваш SHRINKDATABASE, который как раз работает постранично, пишет в лог все перенесенные страницы данных целиком. Место в логе при этом не высвободится, пока не сделать бекап лога . ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2021, 10:26 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
cad2206 L_argo, авторФайл журнала будет размером с самую большую транзацию Что мне понимать под транзакцией в моем случае? авторЕсли у вас есть хотя бы одна большая таблица, то файл будет огромным вне зависимости от модели на тестовой базе самая большая таблица занимает 24ГБт.Трудно сказать, что есть одна транзакция в данном контексте обсуждения. Я специально не изучал, что транзакционно делает МССКЛ при перестройке индексов и упаковке таблиц. Но при этом затрагивается значительно больше пространства (страницы, экстенты, временные структуры), чем заявленное занятое таблицей место. Тем более, что есть понятие контрольной точки, которая не равна одной транзакции. И, собственно чем нам по сабжу помогут эти знания ? Большую БД надо сжимать поэтапно, время от времени физически усекая файл шринком. Увы, это медленный процесс, трудно поддающийся полной автоматизации. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2021, 10:32 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
Спасибо за ответы. Что то становится понятным. Продолжаю изучать и разбираться дальше. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2021, 11:23 |
|
Поэтапное сжатие БД MS SQL Server
|
|||
---|---|---|---|
#18+
[quot L_argo#22403926] cad2206 L_argo, пропущено... Большую БД надо сжимать поэтапно, время от времени физически усекая файл шринком. Увы, это медленный процесс, трудно поддающийся полной автоматизации. Если уж и сжимать БД с возможностью освобождения места операционке как по мне лучше тогда это делать в таком ключе: создаются куча ФГ на каждую большую таблицу. каждая таблица ребилдится с сжатием и переносом в нужную ФГ. по окончании всех манипуляций в теории должен остаться большой пустой файл если конечно это не primary ФГ, (там тогда добавить файл в ФГ и сделать dbcc shirnkfile (emptyfile)) который в итоге можно спокойно удалить. итог: есть сжатые разнесенные таблицы на свои собственные ФГ, нет оверхеда от shirink notruncate, не нужно дополнительный раз прокатывать ребилд индексов. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2021, 11:53 |
|
|
start [/forum/topic.php?all=1&fid=46&tid=1684055]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
139ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
127ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 323ms |
0 / 0 |