|
|
|
Поэтапное сжатие БД 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?fid=46&gotonew=1&tid=1684055]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
123ms |
get topic data: |
10ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 245ms |
| 0 / 0 |
