powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Поэтапное сжатие БД MS SQL Server
107 сообщений из 107, показаны все 5 страниц
Поэтапное сжатие БД MS SQL Server
    #40113649
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, сжимаем его
По идее за несколько проходов вся база сожмется. Но я не нашел как получить параметр сжатия именно у индекса.

Или есть более грамотные решения?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113651
архивариус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206,

давно нашел скрипт (он для SAP изначально) может пригодится:
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113654
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
архивариус,
посмотрел скрипт, мудрено. Но не понял в чем его особенность. Он так же долго будет сжимать базу. Или я что то проглядел?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113669
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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. Займитесь более продуктивной деятельностью.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113672
архивариус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206,

никаких особенностей, он просто делает то что вам нужно. хотите свой пишите.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113675
4es
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4es
Гость
cad2206
Но я не нашел как получить параметр сжатия именно у индекса.

Код: sql
1.
2.
3.
4.
5.
select
   object_name(i.object_id) as ObjectName, i.name as IndexName, p.data_compression, p.data_compression_desc, p.partition_id
from sys.indexes i
inner join sys.partitions p
   on p.object_id = i.object_id and p.index_id = i.index_id
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113680
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
aleks222,

1. Сжал, отдал 1С программистам на тесты, 3 дня тестировали нагрузку и т.п. Показали результаты, прирост в производительности есть. Делали тестирование и исправление БД, все в норме. Чего ожидать можно еще?

2. Признак сжатия таблицы я могу найти, например так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SELECT st.name,
       CAST(ROUND(((SUM(au.total_pages)*8)/1024.00), 2) AS NUMERIC(36, 2)) AS TotalSpaceMB,
       CAST(ROUND(((SUM(au.used_pages)*8)/1024.00), 2) AS NUMERIC(36, 2)) AS UsedSpaceMB,
       sp.index_id,
       sp.data_compression
FROM sys.tables st
LEFT JOIN  sys.partitions sp on st.object_id = sp.object_id
INNER JOIN sys.allocation_units au ON sp.partition_id = au.container_id

group by st.name, sp.index_id, sp.data_compression
order by UsedSpaceMB desc


Я не могу найти признак сжатия именно у индекса таблицы.
Сжимать по одной таблице за ночь 5000 таблиц, это как бы 13 лет)

3. "Займитесь более продуктивной деятельностью." - например? Я без всякого сарказма. Предполагаю, что чего то могу не понимать, поэтому и пишу тут.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113683
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
архивариус,
спасибо. Но мне бы хотелось получить советы, как грамотно организовать алгоритм поэтапного сжатия, не останавливая работу.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113686
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
4es,
спасибо
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113704
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks222

1. Чудеса, прям, глаголите.
Сжали усе и... завертелось.
Мой хрустальный шар немного потрескался, но более вероятно, что перестроение индексов вызвало обновление статистики.


Почему это чудеса?
Вполне реально, что производительность улучшилась просто за счет того, что теперь с диска меньше данных читается.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113721
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
И вопрос, ответ на который поможет мне быстрее понять, как правильно сделать: команда ALTER TABLE 'TableName' REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE) сжимает данные в таблице, или же только устанавливает флаг сжатия и сжимаются данные, которые пишутся в нее после установки флага?
Если только устанавливается флаг, то данные сжимаются командой DBCC SHRINKDATABASE?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113738
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
И вопрос, ответ на который поможет мне быстрее понять, как правильно сделать: команда ALTER TABLE 'TableName' REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE) сжимает данные в таблице, или же только устанавливает флаг сжатия и сжимаются данные, которые пишутся в нее после установки флага?
Если только устанавливается флаг, то данные сжимаются командой DBCC SHRINKDATABASE?


Рано те "сжимать таблицы". Учиться надо.

ALTER TABLE 'TableName' REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)

Толсто намекает. А время, потребное для оной операции, подтверждает толстый намек.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113743
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
aleks222,
1. Сжал, отдал 1С программистам на тесты, 3 дня тестировали нагрузку и т.п. Показали результаты, прирост в производительности есть. Делали тестирование и исправление БД, все в норме. Чего ожидать можно еще?


Ну я так понимаю, UPDATE STATISTICS with fullscan вы тоже делали?
И тоже тестировали?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113755
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Про сжатие онлайн автору темы кто-нибудь говорил, про версию его сервера спрашивали?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113804
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
aleks222,
авторРано те "сжимать таблицы". Учиться надо.
Как раз я и учусь. Поэтому и вопросы задаю. А можно научиться не пробуя?

авторALTER TABLE 'TableName' REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)

Толсто намекает. А время, потребное для оной операции, подтверждает толстый намек.
Да, уже убедился.


авторНу я так понимаю, UPDATE STATISTICS with fullscan вы тоже делали?
Нет, с параметром FULLSCAN не запускал, обновлял так:
Код: sql
1.
2.
3.
use DBName
GO  
exe sp_updatestats


Стоит обновить с этим параметром?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113807
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
.Евгений,
авторПро сжатие онлайн автору темы кто-нибудь говорил
Пока не говорили, надеюсь Вы подскажете)

авторпро версию его сервера спрашивали?
Тестирую на 2014 и на 2019
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113817
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206,

сжатие возможно выполнять онлайн (не на всех версиях MS SQL). В большинстве случаев это позволяет не останавливать работу (но подтормаживать ее).
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113821
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надо еще понять, а какие действия именно ТС называет "сжатием базы".
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113825
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
.Евгений,
Понял, про что Вы.
Код: sql
1.
alter index IndexName on TableName rebuild with (resumable = on, online = on)


Нужно экспериментировать.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113828
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Владислав Колосов,
Именно те действия, которые описаны в статье, ссылку на которую я указал в первом сообщении (https://infostart.ru/1c/articles/692209/) и затем возвратить свободное место на диск методом DBCC SHRINKDATABASE
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113833
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
.Евгений,
Понял, про что Вы.
Код: sql
1.
alter index IndexName on TableName rebuild with (resumable = on, online = on)


Нужно экспериментировать.


C (resumable = on) осторожнее экспериментируйте.

Остановка процесса не отменяет операцию, а ставит ее на паузу.
Это значит что у вас по прежнему будет висеть недоделанная версия индекса и любая модификация будет затрагивать оба этих индекса.

Для полной отмены нужно выполнить alter index ... abort
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113839
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
КритикВполне реально, что производительность улучшилась просто за счет того, что теперь с диска меньше данных читается.Такое может получится только если CPU (лицензируемое) некуда девать, а дисковая система полный шлак.
Надувной матрас - классное решение для маленькой квартирки, но надувать его по вечерам и сдувать по утрам - так себе занятие.

cad2206Или есть более грамотные решения? С какого-то возраста появился вопрос «Зачем?» (с)
Мой хрустальный шар показывает зуд попробовать новую игрушку что для (объекты работают с утра до вечера 7 дней в неделю) может быть чреватым.
cad2206 "Займитесь более продуктивной деятельностью." - например? Я без всякого сарказма. Предполагаю, что чего то могу не понимать, поэтому и пишу тут.ИМХО имеет смысл сжимать только партиции со старыми данными, которые никому особо не нужны, замерив выгоду для сжатия и решив стоит ли оно того.
Вместо сжатия ВСЕГО ПОДРЯД посмотрите на свои таблицы. Уверен что из 5000 большая часть это справочники которые сжимать нет смысла.
Выберите десяток другой больших таблиц (желательно секционированых по дате) и сжимайте только старые партиции в которых нет записи (а лучше и чтения). Их (монстров) можно сжимать и вручную написаным скриптом.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113843
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257
Такое может получится только если CPU (лицензируемое) некуда девать, а дисковая система полный шлак.




Какой бы крутой не была дисковая подсистема, она все равно будет существенно уступать по скорости RAM.

При включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данных, и это снизит (иногда, значительно) количество необходимых физических чтений.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113844
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206,

Если после DBCC SHRINKDATABASE улучшилась производительность, то возможны проблемы с физическим носителем, начиная от фрагментации и заканчивая повторяющимися чтениями секторов диска. Либо диск как-то не так отформатирован. После сжатия производительность слегка ухудшается.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113850
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Владислав Колосов,
Хм, все СХД только SSD...
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113854
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLexПри включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данныхУверен, что в памяти как раз все блоки разжаты. разжатие/сжатие идет при чтении/записи (каждый раз).
Возможно что для ТС больше подойдет ROW сжатие (гораздо дешевле по ресурсам)
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113855
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex
SERG1257
Такое может получится только если CPU (лицензируемое) некуда девать, а дисковая система полный шлак.




Какой бы крутой не была дисковая подсистема, она все равно будет существенно уступать по скорости RAM.

При включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данных, и это снизит (иногда, значительно) количество необходимых физических чтений.


Похоже мифы сжатия зохавали мир.

Даже мелкософт толкует только о "экономии дискового пр-ва".
Да оно и понятно, при считывании сжатой страницы в память она снова "разжимается".
Иначе данные с нее невозможно использовать.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113856
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257
msLexПри включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данных
Уверен, что в памяти как раз все блоки разжаты. разжатие/сжатие идет при чтении/записи (каждый раз).
Возможно что для ТС больше подойдет ROW сжатие (гораздо дешевле по ресурсам)
В памяти лежат копии страниц данных с диска, иначе как узнать, когда там наступит момент переполнения страницы.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113858
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex
SERG1257
пропущено...
Уверен, что в памяти как раз все блоки разжаты. разжатие/сжатие идет при чтении/записи (каждый раз).
Возможно что для ТС больше подойдет ROW сжатие (гораздо дешевле по ресурсам)

В памяти лежат копии страниц данных с диска, иначе как узнать, когда там наступит момент переполнения страницы.

Ваши доказательства? (c) Шварценеггер.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113859
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks222
msLex
пропущено...




Какой бы крутой не была дисковая подсистема, она все равно будет существенно уступать по скорости RAM.

При включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данных, и это снизит (иногда, значительно) количество необходимых физических чтений.


Похоже мифы сжатия зохавали мир.

Даже мелкософт толкует только о "экономии дискового пр-ва".
Да оно и понятно, при считывании сжатой страницы в память она снова "разжимается".
Иначе данные с нее невозможно использовать.



Данные на диске в файле лежат 8Кб страницами. Не больше не меньше.

Все изменения с данными происходят только после поднятие этой страницы в память.
Как, скажите, отслеживать момент окончания страницы, если ее сжатый размер будет известен только при записи на диск?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113861
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex

Данные на диске в файле лежат 8Кб страницами. Не больше не меньше.

Свежо преданье.

msLex

Все изменения с данными происходят только после поднятие этой страницы в память.
Как, скажите, отслеживать момент окончания страницы, если ее сжатый размер будет известен только при записи на диск?

Ты так и не ответил, как из "архива" достать строку, не распаковывая архив?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113868
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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

Советую особенно обратить вот на эту часть


После того как страница заполнена, добавление следующей строки вызывает операцию ее сжатия. Вся страница просматривается; каждый столбец оценивается для сжатия префикса, а затем оцениваются все столбцы для сжатия словаря.

И подумать, может ли это быть совместимо с вашим утверждением "сжатие только при записи на диск"
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113871
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Советую не читать савецких газет перед обедом.
Ну... или читать "в подлиннике".
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113872
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113873
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex


После того как страница заполнена, добавление следующей строки вызывает операцию ее сжатия. Вся страница просматривается; каждый столбец оценивается для сжатия префикса, а затем оцениваются все столбцы для сжатия словаря.



"После того как страница заполнена" => ДО момента сжатия страница НЕ сжата.

Очевидный факт.
Волга впадает в Каспийское море.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113876
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.
SELECT
  t.Name                                          AS TableName,
  s.Name                                          AS SchemaName,
  p.Rows                                          AS RowCounts,
  SUM(a.total_pages)*8/1024                       AS TotalSpace_MB,
  SUM(a.used_pages)*8/1024                        AS UsedSpace_MB,
  (SUM(a.total_pages) - SUM(a.used_pages))*8/1028 AS UnusedSpace_MB,
  t.create_date,
  t.modify_date
FROM
  sys.tables t
  INNER JOIN sys.indexes i ON t.object_id = i.object_id
  INNER JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
  INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id
  LEFT OUTER JOIN sys.schemas s ON t.schema_id = s.schema_id
WHERE
  t.Name NOT LIKE 'dt%'
  AND t.is_ms_shipped = 0
  AND i.object_id > 255
GROUP BY
  t.Name, s.Name, p.Rows
ORDER BY
  TotalSpace_MB desc;
GO



Буду признателен, если укажете где взять данные "только старые партиции в которых нет записи (а лучше и чтения)".
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113879
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks222, msLex

интересно, не могут ли в памяти жить как сжатые, так и не сжатые страницы?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113880
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks222
msLex


пропущено...



"После того как страница заполнена" => ДО момента сжатия страница НЕ сжата.

Очевидный факт.
Волга впадает в Каспийское море.


Вы бы полностью прочитали, хоть


Новая страницы заполняется без сжатие, пока на нее влезают данных, т.к. до этого момента сжатие не имеет смысла.

Как только данные без сжатия прекращают влезать, следующая же вставленная строка инициализирует процесс сжатия.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113881
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
SELECT
  t.Name                                          AS TableName,
  s.Name                                          AS SchemaName,
  p.Rows                                          AS RowCounts,
  SUM(a.total_pages)*8/1024                       AS TotalSpace_MB,
  SUM(a.used_pages)*8/1024                        AS UsedSpace_MB,
  (SUM(a.total_pages) - SUM(a.used_pages))*8/1028 AS UnusedSpace_MB,
  t.create_date,
  t.modify_date
FROM
  sys.tables t
  INNER JOIN sys.indexes i ON t.object_id = i.object_id
  INNER JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
  INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id
  LEFT OUTER JOIN sys.schemas s ON t.schema_id = s.schema_id
WHERE
  t.Name NOT LIKE 'dt%'
  AND t.is_ms_shipped = 0
  AND i.object_id > 255
GROUP BY
  t.Name, s.Name, p.Rows
ORDER BY
  TotalSpace_MB desc;
GO



Буду признателен, если укажете где взять данные "только старые партиции в которых нет записи (а лучше и чтения)".

Секционирование таблиц у тебя еще впереди.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113883
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.Евгений
aleks222, msLex

интересно, не могут ли в памяти жить как сжатые, так и не сжатые страницы?

Это такой метод "экономии памяти"?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113886
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.Евгений
интересно, не могут ли в памяти жить как сжатые, так и не сжатые страницы?


Т.е. каждая страница живет в двух экземплярах?
Нет, конечно, это уменьшит вместимость buffer pool почти в 2 раза
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113890
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex
aleks222
пропущено...


"После того как страница заполнена" => ДО момента сжатия страница НЕ сжата.

Очевидный факт.
Волга впадает в Каспийское море.


Вы бы полностью прочитали, хоть


Новая страницы заполняется без сжатие, пока на нее влезают данных, т.к. до этого момента сжатие не имеет смысла.

Как только данные без сжатия прекращают влезать, следующая же вставленная строка инициализирует процесс сжатия.


Ты не сыпь цитатами из Мао - ты на пальцах покажи "как достать что-то из архива, не распаковывая архив?"

ЗЫ. Если ты не курсе, операции сервера не ограничиваются тупым "заполнением страниц". Иногда надо что-то с них достать...
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113891
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex
.Евгений
интересно, не могут ли в памяти жить как сжатые, так и не сжатые страницы?


Т.е. каждая страница живет в двух экземплярах?
Нет, конечно, это уменьшит вместимость buffer pool почти в 2 раза

Нет. Сжатые и несжатые, аналогично тому, как они будут жить на диске (если бы были в этот момент записаны).
aleks222
.Евгений
aleks222, msLex

интересно, не могут ли в памяти жить как сжатые, так и не сжатые страницы?

Это такой метод "экономии памяти"?

Кто у нас отвечает вопросом на вопрос?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113893
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.Евгений
msLex
пропущено...


Т.е. каждая страница живет в двух экземплярах?
Нет, конечно, это уменьшит вместимость buffer pool почти в 2 раза

Нет. Сжатые и несжатые, аналогично тому, как они будут жить на диске (если бы были в этот момент записаны).


Так и есть, станицы в памяти те же, что и на диске. За исключением dirty pages, что еще не скинуты на диск.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113904
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks222
"как достать что-то из архива, не распаковывая архив?"

Распокавать на лету, конечно.

SQL Server для сжатия данных использует lightweight алгоритмы сжатия, позволяющие применять декомпрессию на потоке.

Вы почитайте,

Там все достаточно просто.
Основное :
Row Compression - урезание неиспользуемых байт из типов фиксированной длины
Page Compression - в добавлении к Row Compression постраничные справочники.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113920
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLexРаспокавать на лету, конечно.Каждый раз когда блок понадобится из буфер кэша.
Что совой об пень, что пнем об сову.
cad2206, а ты выгоду-то посчитал? Сколько гигабайт экономии получил?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113928
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks222,

авторИначе данные с нее невозможно использовать.

Там же данные не зипом пожаты, там простая табличная подстановка словарь - метасимволы. Эти данные можно прекрасно читать и преобразовывать "на лету".
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113929
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257,

с чего вы взяли, что cad2206 использовал сжатие страниц? Он нигде об этом не писал.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40113984
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав Колосовс чего вы взяли, что cad2206 использовал сжатие страниц? Он нигде об этом не писал.
22399026
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114001
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257
msLexРаспокавать на лету, конечно.
Каждый раз когда блок понадобится из буфер кэша.


Именно так

Как я уже писал выше, там очень легковесное разжатие

В случае с Row так вообще, просто превращение всех типов данных в типы с переменой длиной (varint, vardecimal и т.д.), что, фактически, эквивалентно реализации varchar в несжатых страницах.

подробности тут

В случае с Page добавляются префиксы и справочники.
подробности тут

Ни одно из этих преобразований не требует "разжимать" всю страницы целиком, при чтении конкретной записи. Все разбирается при последовательном чтении данных.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114013
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex
SERG1257
Такое может получится только если CPU (лицензируемое) некуда девать, а дисковая система полный шлак.
Какой бы крутой не была дисковая подсистема, она все равно будет существенно уступать по скорости RAM.

При включении сжатия данных, в тот же объем RAM уместиться больше (иногда, значительно) данных, и это снизит (иногда, значительно) количество необходимых физических чтений.
То есть выгодно, когда памяти не хватает для кеширования.
Если хватает, или для маленьких таблиц, то зачем оно...
SERG1257
Выберите десяток другой больших таблиц (желательно секционированых по дате) и сжимайте только старые партиции в которых нет записи (а лучше и чтения). Их (монстров) можно сжимать и вручную написаным скриптом.
Согласен.

Только ещё нужно заметить, что балк инсёрт перестаёт работать на сжатых таблицах (то есть скорость деградирует в сотни-тысячи и более раз), и приходится простую загрузку заменять на сложную (например, лить в кучу, потом строить на ней сжатый кластерный индекс, и присоединять как секцию к сжатой секционированной таблице)
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114048
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав Колосов
aleks222,

авторИначе данные с нее невозможно использовать.


Там же данные не зипом пожаты, там простая табличная подстановка словарь - метасимволы. Эти данные можно прекрасно читать и преобразовывать "на лету".
Это "алгоритм Лемпеля-Зива" называется.
ZIP, промежду прочим, его использует. Как вариант.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114062
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,
авторcad2206, а ты выгоду-то посчитал? Сколько гигабайт экономии получил?
с 830ГБт после процедуры из статьи https://infostart.ru/1c/articles/692209/ размер файла БД составил 250ГБт
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114066
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ГБт, занял все свободное место и дефрагментация вылетела в ошибку
Буду признателен, если объясните, почему так произошло?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114088
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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ГБт, занял все свободное место и дефрагментация вылетела в ошибку
Буду признателен, если объясните, почему так произошло?


Ты не нажимай на кнопки, смысла которых не понимаешь.
И будет тебе щастье.

ЗЫ. Дефрагментация = перемещение страниц = журналируемая операция.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114095
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
aleks222,
ну ты серьезный конечно.

авторТы не нажимай на кнопки, смысла которых не понимаешь.
В основном пока нажимаю только одну "Выполнить скрипт"

авторДефрагментация = перемещение страниц = журналируемая операция
Это я понимаю. Мне непонятно почему тогда на боевой базе (размер диска для журнала транзакций такой же как и на тестовом сервере) ежедневная дефрагментация не увеличивает так журнал?

Журнал увеличился во время дефрагментации после действий:
1. применение к одной таблице и ее индексам DATA_COMPRESSION = PAGE
2. SHRINKDATABASE

Причем для этой таблицы дефрагментация выполнялась командой ALTER INDEX IndexName REORGANIZE
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114102
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[deleted]
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114219
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
shrinkdatabase (без параметров) в принципе "ломает все индексы" и при их дефрагментации журнал базы данных естественно растет больше, так как дефрагментируются абсолютно все индексы. Так?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114239
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206Мне непонятно почему тогда на боевой базе (размер диска для журнала транзакций такой же как и на тестовом сервере) ежедневная дефрагментация не увеличивает так журнал?Два варианта
Кто-то настроил регулярный (раз в минуту, раз в 15 минут, и тд) лог бакап
Кто-то НЕ ДЕЛАЕТ ежедневную дефрагментацию (статья от АГ https://habr.com/ru/post/576882/ )

Теперь по пунктам. Итак выигрыш по месту у вас в разы - это хорошо, это заметно.
Теперь поинтересуйся у старших товарищей -
сколько стоит полтерабайта места на диске (добавь все тестовые экземпляры, DR и HA буде таковые существуют)
сколько стоит память. (у стандарта есть ограничение в 128Гб на буферный кэш)
сколько стоит время админа (бесплатно - плохой ответ)
сколько стоит лицензия на лишний камень для вашей редакции, а также SA на нее. (если вы пиратите то бесплатно)

Уверен что после подсчетов, в прешбывалые временя твои действия потянули бы на вредительство.

Далее
Если производительность ваших камней не просела после сжатия - то бишь лишняя нагрузка по сжатию/разжатию не стала заметной, то это говорит либо о том что ничего не делалось/не замерялось, либо что мощность серверов изначально была завышена и дополнительной нагрузки они не заметили.
А значит вредитель в конторе затесался уже давно

Если очень хочется принести максимум пользы (с мимимумом побочных эффектов) то советую провести анализ нагрузки (кто/что/когда делает с какими таблицами)
В этом отношении поможет Query Store (если версия 2016+), extended events или просто поговорить с пользователями чтобы настраивать процесс который болит.
Короче семь раз отмерь, один отрежь
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114249
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,
авторКто-то настроил регулярный (раз в минуту, раз в 15 минут, и тд) лог бакап
и на боевом и на тестовом серверах настроен бекап журнала раз в 15 минут. Но разве бекап журнала уменьшает файл журнала?

авторКто-то НЕ ДЕЛАЕТ ежедневную дефрагментацию
делается каждый день (вернее ночь)
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114250
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257
cad2206Мне непонятно почему тогда на боевой базе (размер диска для журнала транзакций такой же как и на тестовом сервере) ежедневная дефрагментация не увеличивает так журнал?
Два варианта
Кто-то настроил регулярный (раз в минуту, раз в 15 минут, и тд) лог бакап
Кто-то НЕ ДЕЛАЕТ ежедневную дефрагментацию (статья от АГ https://habr.com/ru/post/576882/ )


Либо разные модели восстановления

На тестовом Full, на проде SIMPLE
как бы это странно не звучало.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114253
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
msLex,
на обоих серверах режим восстановления "Полное"
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114256
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
msLex,
на обоих серверах режим восстановления "Полное"


А бекапы лога на тестовом сервер делаются?

покажите (ну или хотя бы сами посмотрите) результат на обоих серверах


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
select top 10 
	s.backup_start_date
	, s.is_copy_only
from msdb.dbo.backupset s 
where 
	type = 'L'
	and database_name = 'ИМЯ ВАШЕЙ БД'
order by 
	s.backup_start_date desc
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114263
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114273
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
П
3. Сделал DBCC SHRINKDATABASE('''+ DataBase() + ''')
...
5. При попытке выполнить дефрагментацию журнал транзакций вырос до 500ГБт, занял все свободное место и дефрагментация вылетела в ошибку
Буду признателен, если объясните, почему так произошло?


А так тут все просто

3-й шаг породил просто огромную фрагментацию по большому числу таблиц, что и вылилось в большое количество перемещаемых данных в момент дефрагментации.


Нужно еще глянуть, что там у вас за "дефрагментацию"
Если там есть Rebuild (возможно по условию), то это вообще транзакционная операция (если он не resumable), и в логе будут храниться все изменения ВСЕХ СЕАНОСВ, произошедших с момента начала операции alter index
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114275
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
msLex,
скрипт дефрагментации из статьи https://info-comp.ru/obucheniest/581-rebuilding-of-indexes-in-ms-sql-server.html
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114276
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,
спасибо за советы
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114292
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
msLex,
скрипт дефрагментации из статьи https://info-comp.ru/obucheniest/581-rebuilding-of-indexes-in-ms-sql-server.html



Ну как и ожидалось (с минимальными изменениями это стандартный скрипт, когда не хочется разбираться детальнее какие таблицы нужно трогать)

Вы сильно фрагментировали данные и сработал этот пункт

Если степень фрагментации более 30%, лучше выполнять перестроение индекса.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114432
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
msLex,
спасибо, теперь понимаю. Хочется все таки понять правильный алгоритм. Вопрос сжимать или не сжимать не стоит. Нужно сжимать. Сжимать буду все равно на тестовом сервере и отдавать базу в работу. Вопрос по секционированию таблиц и сжатию только тех, что редко используются, очень интересен. Но пока буду сжимать все и тестировать. Еще раз прошу подсказки, какую последовательность правильно выбрать:
1. Каждую ночь сжимать заранее подготовленный список таблиц и их индексов (так чтобы успеть перебрать его до начала работы с базой) методами:
Код: sql
1.
2.
3.
ALTER TABLE TableName REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)
и ее индексы:
ALTER INDEX IndexName ON Table REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)


2. Спустя несколько ночей, когда все таблицы будут сжаты, сделать SHRINKDATABASE (порядка 5 часов, одна ночь)
3. Произвести дефрагментацию индексов (после SHRINKDATABASE переиндексация заняла 5 часов, одна ночь). Тут два варианта:
- либо увеличить размер диска под журнал БД до размера самой БД (что бы он не переполнился),
- либо перевести БД в режим восстановления Simple, дефрагментировать и вернуть в режим Full.
Верно, нет?
Может дефрагментацию стоит делать до SHRINKDATABASE, а после запустить SHRINKDATABASE с параметром TRUNCATEONLY?
Прошу помощи у Вас, профессионалы, но не советов, мол не лезь туда, чего не знаешь. Не лезть туда, значит ничего не узнать. Вы сами это проходили, уверен.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114437
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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.
use BDName
Go
declare @DbId smallint = DB_ID('BDName')

declare @IndexTmpTable table (Id INT IDENTITY(1,1) primary key,
                              SchemaName SYSNAME, 
                              TableName SYSNAME, 
                              IndexName SYSNAME, 
                              PageCount INT,
                              AvgFrag FLOAT)

declare @RowNumber INT = 1, @CntRows INT, @CntReorganize INT = 0, @CntRebuild INT = 0
declare @SchemaName SYSNAME, @TableName SYSNAME, @IndexName SYSNAME, @AvgFrag FLOAT
declare @Command VARCHAR(8000)
declare @FileName VARCHAR(100) = 'stop_defrag.txt'

declare @profile_name as nvarchar(100) = 'profile'
declare @recipients as nvarchar(500) = 'address@domen.ru'
declare @subject as NVARCHAR(100) = ''
declare @massage as NVARCHAR(1000) = ''

begin;
    
insert into @IndexTmpTable
                select Sch.name as SchemaName, 
                           Obj.name as TableName,
                           Inx.name as IndexName,
                           Page_count as  Pagecount,
                           round(AvgFrag.avg_fragmentation_in_percent,0) as Fragmentation 
                from sys.dm_db_index_physical_stats (@DbId, NULL, NULL, NULL, NULL) as AvgFrag
                LEFT JOIN sys.indexes as Inx on AvgFrag.object_id = Inx.object_id AND AvgFrag.index_id = Inx.index_id
                LEFT JOIN sys.objects as Obj on AvgFrag.object_id = Obj.object_id 
                LEFT JOIN sys.schemas as Sch on Obj.schema_id = Sch.schema_id
                where AvgFrag.index_id > 0 AND AvgFrag.avg_fragmentation_in_percent > 5 AND AvgFrag.page_count > 8
                order by Pagecount desc

select @CntRows = COUNT(*)
from @IndexTmpTable

while @RowNumber <= @CntRows
 begin

  --Получаем названия объектов, а также степень фрагментации текущего индекса
  select @SchemaName = SchemaName, @TableName = TableName, @IndexName = IndexName, @AvgFrag = AvgFrag
  from @IndexTmpTable
  where Id = @RowNumber

  --Если текущее время больше заданного, прекращаем дефрагментацию
  if @@FETCH_STATUS < 0 OR (datepart(hour, GETDATE()) >= 8 AND datepart(minute, GETDATE()) >= 0) 
   begin
    --Запись индекса на котором остановилась дефрагментация для информирования в сообщении
    set @command='echo ' + @TableName + '.' + @IndexName + ' > ' + @FileName
    exec master..xp_cmdshell @command
    
   --Отправка email
    set @subject = @profile_name + ': Стоп дефрагментации по времени'
    set @massage ='Стоп дефрагментации по времени на индексе ' + @TableName + '.' + @IndexName + CHAR(10) + CHAR(13) +
	              'Дефрагментировано ' + CAST(@RowNumber AS VARCHAR(100)) + ' из ' + CAST(@CntRows as VARCHAR(100)) + ' индексов'
    exec msdb.dbo.sp_send_dbmail
    	@profile_name = @profile_name,
    	@recipients = @recipients,
    	@body = @massage,
    	@subject = @subject;
    
    BREAK
   end;
                        
  if @AvgFrag < 30
   begin
    select @Command = 'ALTER INDEX [' + @IndexName + '] ON ' + '[' + @SchemaName + ']' 
                               + '.[' + @TableName + '] REORGANIZE';
    exec (@Command);
    set @CntReorganize = @CntReorganize + 1;
   end 
                        
  if @AvgFrag >= 30
   begin
    select @Command = 'ALTER INDEX [' + @IndexName + '] ON ' + '[' + @SchemaName + ']' 
                               + '.[' + @TableName + '] REBUILD';
    exec (@Command);
    set @CntRebuild = @CntRebuild + 1;
   end
                        
  print 'Выполнена инструкция ' + @Command;
  set @RowNumber = @RowNumber + 1
 end

end;



Дефрагментирую только те индексы, которые занимают более 8 страниц
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114453
baracs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
я привел в пример статью...

А эту статью: Отказ от ежедневной дефрагментации читали?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114470
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
msLex,
спасибо, теперь понимаю. Хочется все таки понять правильный алгоритм. Вопрос сжимать или не сжимать не стоит. Нужно сжимать. Сжимать буду все равно на тестовом сервере и отдавать базу в работу. Вопрос по секционированию таблиц и сжатию только тех, что редко используются, очень интересен. Но пока буду сжимать все и тестировать. Еще раз прошу подсказки, какую последовательность правильно выбрать:
1. Каждую ночь сжимать заранее подготовленный список таблиц и их индексов (так чтобы успеть перебрать его до начала работы с базой) методами:
Код: sql
1.
2.
3.
ALTER TABLE TableName REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)
и ее индексы:
ALTER INDEX IndexName ON Table REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)


2. Спустя несколько ночей, когда все таблицы будут сжаты, сделать SHRINKDATABASE (порядка 5 часов, одна ночь)
3. Произвести дефрагментацию индексов (после SHRINKDATABASE переиндексация заняла 5 часов, одна ночь). Тут два варианта:
- либо увеличить размер диска под журнал БД до размера самой БД (что бы он не переполнился),
- либо перевести БД в режим восстановления Simple, дефрагментировать и вернуть в режим Full.
Верно, нет?
Может дефрагментацию стоит делать до SHRINKDATABASE, а после запустить SHRINKDATABASE с параметром TRUNCATEONLY?
Прошу помощи у Вас, профессионалы, но не советов, мол не лезь туда, чего не знаешь. Не лезть туда, значит ничего не узнать. Вы сами это проходили, уверен.


Образцово-показательная каша в голове.

1. SHRINKDATABASE - это "аварийная" операция. Ее проводят только после великой чистки базы при полной уверенности, что вы туда не насрете обратно ровно столько же, либо если вы свою базу окончательно отправляете в архив. На нормально работающей базе SHRINKDATABASE - это вредительство.

2. Дефрагментация делается "объективным по-показаниям", а не ради "дефрагментируем фсе на фсякий случай".

3. Научитесь уже статистику обновлять.

4. Вот так они создают имитацию бурной деятельности "Произвести дефрагментацию индексов (после SHRINKDATABASE переиндексация заняла 5 часов, одна ночь)". Шринкаем-дефрагментируем-Шринкаем-дефрагментируем.
А ваще-то
ALTER TABLE TableName REBUILD PARTITION
полностью "дефрагментирует" индекс.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114476
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
aleks222,
авторОбразцово-показательная каша в голове
совершенно верно, пока..

1. SHRINKDATABASE необходимо будет произвести после авторвеликой чистки базы и сжатия.
2. авторДефрагментация делается "объективным по-показаниям" - ну намекните на эти показатели
3. авторНаучитесь уже статистику обновлять - разбираюсь
4. авторВот так они создают имитацию бурной деятельности - так подскажите как правильно сделать
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114477
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
baracs,
Читал, интересно. Но нужно экспериментировать.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114566
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206Вопрос сжимать или не сжимать не стоит. Нужно сжимать. Сжимать буду все равноБезумству храбрых поем мы песню
cad2206на тестовом сервере и отдавать базу в работуНе понял насчет тестового сервера.
cad2206какую последовательность правильно выбратьСжимаете таблицу (торопится не надо).
Не делаете shrink.
Не делаете дефрагментацию. Я у себя отменил этот еженедельный джоб и никто не заметил разницы.

Если обнаружите что стало хуже, разжимаете таблицу.
Код: sql
1.
ALTER TABLE TableName REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = none)



В результате сжатия база на проде не растет в размере (а заполняет пустоты).
На тестовом сервере можно (но не нужно) сделать шринк чтобы например воткнуть еще одну базу если напряг с местом на диске.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114580
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,

авторНе понял насчет тестового сервера.
не корректно выразился. На новом сервере, где установлен MS SQL Server 2019. База переедет со старого (на MS SQL Server 2012).

авторСжимаете таблицу (торопится не надо).
Помню, что нужно секционировать таблицы, но пока без этого. С каких таблиц лучше начать? Наиболее часто используемых? Больших?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114610
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для больших таблиц прогоните 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))

Маленькие таблицы даже не рассматривайте - визгу много шерсти мало
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114745
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,
при размере файла БД 830 ГБт, какие таблицы считать большими для исследования их функцией sp_estimate_data_compression_savings?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114746
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257,
авторСжимаете таблицу (торопится не надо).
Не делаете shrink.
Не делаете дефрагментацию. Я у себя отменил этот еженедельный джоб и никто не заметил разницы.
Я правильно понял, сжимать по несколько таблиц за ночь без shrink'а (это я уже понял, что shrink крайняя мера) и без дефрагментации. И смотреть на работу пользователей?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114818
selis76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня нагруженная база 1С на 3 терабайта, по опыту пространство больше расходуется на фрагментацию поскольку кластерный (системный) код 1С много удаляет и вставляет заново особенно в итогах по регистрам.
Перестроение кластерных индексов и обычных индексов помогает гораздо эффективнее. Освобожденное место можно использовать для новых данных. Ну а вообще в решении должна быть заложена процедура обрезания старых данных и свертки остатков. База не должна расти бесконечно
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40114960
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206какие таблицы считать большими для исследования их функцией sp_estimate_data_compression_savings?Исследовать можно хоть все (это просто посмотреть, это бесплатно)
Результаты (для PAGE и для ROW) в эксельку, сортируя по разнице между sample_size_with_current_compression_setting и sample_size_with_requested_compression_setting
Уверен, что кандидатов будет не больше десятка. А дальше нужно будет принимать решение кто достоин, а кто нет.

selis76, я человек простой, а вопрос сложный. Можешь пояснить свою мысль языком ЖЭКа. (или как говорят буржуи ELI5)
Правильно ли я понял, что ты хочешь сказать что для твоей базы перестроение индексов действительно высвобождает место.
Однако следом ты утверждаешь что плотно упакованный индекс, будет снова переразбит следующей операцией (особенно в итогах по регистрам.)
Так может и не трогать эти итоги по регистрам. Ну будут некоторые страницы наполовину пусты. Стоит ли овчинка выделки? И как это относится к сабжу топика (сжатие aka компрессия данных).
По поводу удаления старых данных это тоже оффтопик. Люди годами не могут почистить балкон (гараж, подвал), а тут данные удалить. А если понадобятся?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40115005
selis76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116381
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день, знатоки.
Продолжаю свои эксперименты, не ругайтесь, это лишь эксперименты на тестовых базах, для моего понимания.

Создал этапы в плане обслуживания:
1. Создание полной резервной копии в модели восстановления "Полная"
2. SHRINKDATABASE
Код: sql
1.
DBCC SHRINKDATABASE(DBName)


3. Перевод базы в модель восстановления "Простая"
Код: sql
1.
2.
USE [master];  
ALTER DATABASE [DBName] SET RECOVERY SIMPLE;


4. Дефрагментация индексов
5. Перевод базы в модель восстановления "Полная"
Код: sql
1.
2.
USE [master];  
ALTER DATABASE [DBName] SET RECOVERY FULL;


6. Обновление статистики

Если я правильно понимаю, то в модели восстановления "Простая", лог журнала не растет. Но уже на этапе дефрагментации заметил, лог вырос, примерно до размера самой базы (после шринка).

Объясните пожалуйста, почему вырос лог?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116389
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
Если я правильно понимаю, то в модели восстановления "Простая", лог журнала не растет.


Не правильно поняли.

В простой модели, лог автоматически усекается (освобождается место внутри файлов лога) по завершению транзакций.






cad2206
Перевод базы в модель восстановления "Полная"
Код: sql
1.
2.
USE [master];  
ALTER DATABASE [DBName] SET RECOVERY FULL;



Просто для понимания.
После перевода базы в FULL, реальный переход на FULL модель восстановления произойдет только после 1-го полного бекапа.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116393
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
Добрый день, знатоки.
2. SHRINKDATABASE


забудьте эту команду
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116404
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
msLex,
Так отчего вырос лог (именно файл лога, очень сильно вырос )?

Понимаю, что при SHRINKDATABASE данные в БД фрагментируются полностью. Затем выполняю дефрагментацию для всех индексов.
Если завершенной транзакцией считать каждое выполнение:
Код: sql
1.
ALTER INDEX [IndexName] ON [TableName] REBUILD


при дефрагментации, в модели восстановления "Простая", то лог будет усекаться внутри файла и сам файл расти не будет. А тут вырос сам файл лога.
Что в моем случае тогда считается завершенной транзакцией?

авторПросто для понимания.
После перевода базы в FULL, реальный переход на FULL модель восстановления произойдет только после 1-го полного бекапа.
Это я понимаю.

felix_ff,
авторзабудьте эту команду
забуду, как только разберусь во всем
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116410
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
msLex,
Так отчего вырос лог (именно файл лога, очень сильно вырос )?

Понимаю, что при SHRINKDATABASE данные в БД фрагментируются полностью. Затем выполняю дефрагментацию для всех индексов.
Если завершенной транзакцией считать каждое выполнение:
Код: sql
1.
ALTER INDEX [IndexName] ON [TableName] REBUILD


при дефрагментации, в модели восстановления "Простая", то лог будет усекаться внутри файла и сам файл расти не будет. А тут вырос сам файл лога.
Что в моем случае тогда считается завершенной транзакцией?

авторПросто для понимания.
После перевода базы в FULL, реальный переход на FULL модель восстановления произойдет только после 1-го полного бекапа.
Это я понимаю.

felix_ff,
авторзабудьте эту команду
забуду, как только разберусь во всем
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116421
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206,

Код: sql
1.
ALTER INDEX [IndexName] ON [TableName] REBUILD

- логируемая операция, чего вы удивляетесь что у вас файл лога расти не будет?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116427
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
felix_ff,
спасибо, я понимаю что она журналируемая.
Но для большего понимания хочется усвоить:
1. В модели восстановления "Простая", журнал усекается внутри файла журнала при подтверждении транзакции. Ок. Что считать подтвержденной транзакцией? Выполнение ALTER INDEX [IndexName] ON [TableName] REBUILD считается подтвержденной транзакцией? В моем случае таких вызовов на каждый индекс, при переиндексации, за 400.
2. В зависимости от понимания первого пункта, как предотвратить переполнение журнала (диска, выделенного под журнал)? Переиндексировать в модели восстановления "Полная" и бекапить журнал раз в 15 мин? Файл журнала вырос почти на 400ГБ, при размере БД в 220ГБ.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116436
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
felix_ff,
спасибо, я понимаю что она журналируемая.
Но для большего понимания хочется усвоить:
1. В модели восстановления "Простая", журнал усекается внутри файла журнала при подтверждении транзакции. Ок. Что считать подтвержденной транзакцией? Выполнение ALTER INDEX [IndexName] ON [TableName] REBUILD считается подтвержденной транзакцией? В моем случае таких вызовов на каждый индекс, при переиндексации, за 400.
2. В зависимости от понимания первого пункта, как предотвратить переполнение журнала (диска, выделенного под журнал)? Переиндексировать в модели восстановления "Полная" и бекапить журнал раз в 15 мин? Файл журнала вырос почти на 400ГБ, при размере БД в 220ГБ.


1. @@trancount = 0
2. Так ты ничо и не понял. Увы. Даже донкихот не боролся с ростом журнала транзакций переключением мельниц на полные обороты.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116438
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ах да, "как предотвратить?"

Завязывай с реиндексированием.
Надежно.
Просто.
Эффективно.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116452
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
aleks222,
авторТак ты ничо и не понял
Ну объясни доступно. Где что я не понимаю? На каких этапах что происходит?

Уважаемые знатоки, мне придется один раз сделать шринк, кто бы что не говорил, но придется. ОДИН РАЗ! На рабочей базе, когда пойму все особенности и отлажу на тестовых базах. А после шринка придется сделать дефрагментацию, как минимум один раз (т.к. после шринка все данные фрагментированы очень сильно). Поэтому и прошу помощи разобраться.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116471
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116472
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
felix_ff,
авторshrink файлов базы данных (замечу не файлов лога) нужен только в одном случае: когда у вас к примеру файл базы данных заполнил весь объем свободного дискового пространства и дальше файлы бд в том числе файлы лога расти не могут, а руководство жопится и денег на новые диски не дает
именно!
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116475
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
felix_ff,

авторвы с какой проблемой пытаетесь бороться?

сейчас уже не проблема, а желание понять. Например, почему вырос файл журнала, при дефрагментации в модели восстановления "Простая".
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116476
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНапример, почему вырос файл журнала, при дефрагментации в модели восстановления "Простая".Файл журнала будет размером с самую большую транзацию.
Если у вас есть хотя бы одна большая таблица, то файл будет огромным вне зависимости от модели.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116482
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
L_argo,
авторФайл журнала будет размером с самую большую транзацию
Что мне понимать под транзакцией в моем случае?

авторЕсли у вас есть хотя бы одна большая таблица, то файл будет огромным вне зависимости от модели
на тестовой базе самая большая таблица занимает 24ГБт.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116489
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
felix_ff,
авторне верно, в простой модели восстановления усечение происходит после достижения контрольной точки

Из документации https://docs.microsoft.com/ru-ru/sql/relational-databases/logs/database-checkpoints-sql-server?view=sql-server-ver15:
в простой модели восстановления автоматическая контрольная точка становится в очередь, если журнал заполняется на 70 процентов.

Верный ли от сюда вывод, что журнал будет усекаться при достижении его размера в 70% от размера самого файла журнала?
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116497
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206

Верный ли от сюда вывод, что журнал будет усекаться при достижении его размера в 70% от размера самого файла журнала?


Кто на ком стоял?

ЗЫ. Прирожденный управдом. Этот тредстартер.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116503
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
aleks222,
Ох, хочется услышать от тебя что то полезное, а каждый пост все о одном...
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116516
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
aleks222,
Ох, хочется услышать от тебя что то полезное, а каждый пост все о одном...

Чтобы понять ответ - надо знать ответ на 90%.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116536
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
aleks222,

абсолютно согласен. Буду разбираться дальше. Спасибо.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116626
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Запустил эксперимент еще раз:
Модель восстановления "Полная".

После полного бекапа запустил 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 оказывает влияние на файл журнала."

Совсем запутался.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116644
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
При этом файл журнала растет. Это как?



Любые изменения в данных, в том числе и SHRINK, логируются.
В полном модели восстановления данные в логе помечаются как "не нужные" только после бекапа этих данных (на самом деле там несколько отсечек: бекап лога, открытые транзакция, чекпоинт, передача данных на все вторичные реплики и т.п.). Также в полной модели все постраничные операции записываются в лог целиком (т.е. прям полностью 8Кб страница записывается в лог).

А значит ваш SHRINKDATABASE, который как раз работает постранично, пишет в лог все перенесенные страницы данных целиком. Место в логе при этом не высвободится, пока не сделать бекап лога .
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116649
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
cad2206
L_argo,
авторФайл журнала будет размером с самую большую транзацию

Что мне понимать под транзакцией в моем случае?

авторЕсли у вас есть хотя бы одна большая таблица, то файл будет огромным вне зависимости от модели
на тестовой базе самая большая таблица занимает 24ГБт.Трудно сказать, что есть одна транзакция в данном контексте обсуждения. Я специально не изучал, что транзакционно делает МССКЛ при перестройке индексов и упаковке таблиц. Но при этом затрагивается значительно больше пространства (страницы, экстенты, временные структуры), чем заявленное занятое таблицей место.
Тем более, что есть понятие контрольной точки, которая не равна одной транзакции.

И, собственно чем нам по сабжу помогут эти знания ?

Большую БД надо сжимать поэтапно, время от времени физически усекая файл шринком.
Увы, это медленный процесс, трудно поддающийся полной автоматизации.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116662
cad2206
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо за ответы. Что то становится понятным. Продолжаю изучать и разбираться дальше.
...
Рейтинг: 0 / 0
Поэтапное сжатие БД MS SQL Server
    #40116673
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot L_argo#22403926]
cad2206
L_argo,
пропущено...
Большую БД надо сжимать поэтапно, время от времени физически усекая файл шринком.
Увы, это медленный процесс, трудно поддающийся полной автоматизации.


Если уж и сжимать БД с возможностью освобождения места операционке как по мне лучше тогда это делать в таком ключе:
создаются куча ФГ на каждую большую таблицу.

каждая таблица ребилдится с сжатием и переносом в нужную ФГ.
по окончании всех манипуляций в теории должен остаться большой пустой файл если конечно это не primary ФГ, (там тогда добавить файл в ФГ и сделать dbcc shirnkfile (emptyfile)) который в итоге можно спокойно удалить.

итог: есть сжатые разнесенные таблицы на свои собственные ФГ, нет оверхеда от shirink notruncate, не нужно дополнительный раз прокатывать ребилд индексов.
...
Рейтинг: 0 / 0
107 сообщений из 107, показаны все 5 страниц
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Поэтапное сжатие БД MS SQL Server
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]