Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
teCa
Member

Откуда:
Сообщений: 581
Добры день.
Поделитесь мыслями и советами по следующей задаче.
Есть база общим объемом 8Тб, состоит из двух файловых групп, файлы в группе весом по 1Тб Autogrowth - none.
В БД нонстоп заливаются и удаляются данные.
Требуется уменьшить размер файлов данных одной из групп (которая принимает на себя основную нагрузку тк лежит на ssd дисках) на 50Гб. Available free space для каждого файла в группе более 50Гб.

Есть ли способы минимизировать блокировки, не знаю, ускорением шринка грубо говоря?

Microsoft SQL Server 2014 (SP2-CU1) (KB3178925) - 12.0.5511.0 (X64) Aug 19 2016 14:32:30 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: )
20 сен 19, 11:02    [21975033]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
_ч_
Member

Откуда:
Сообщений: 1422
teCa,

попробуйте шринковать маленькими порциями, по X Мб.
20 сен 19, 11:23    [21975049]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
teCa
Member

Откуда:
Сообщений: 581
_ч_
teCa,

попробуйте шринковать маленькими порциями, по X Мб.


Была такая мысль, не был уверен, что это ускорило бы шринк, нужно потестировать.
20 сен 19, 11:28    [21975058]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
это никак не ускорит.
все будет ровно то же, только еще + он вначале информацию собирает,
и эта часть будет повторена много раз.
мне пришлось прерывать шринк, когда юзеры тормозились,
и он каждый раз начинал с начала.
до сделанного уже процента percent_complete бежит очень быстро,
потом доходит до места, где прервался в последний раз, и начинаются тормоза.
20 сен 19, 11:42    [21975071]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
teCa
Member

Откуда:
Сообщений: 581
Yasha123
это никак не ускорит.
все будет ровно то же, только еще + он вначале информацию собирает,
и эта часть будет повторена много раз.
мне пришлось прерывать шринк, когда юзеры тормозились,
и он каждый раз начинал с начала.
до сделанного уже процента percent_complete бежит очень быстро,
потом доходит до места, где прервался в последний раз, и начинаются тормоза.


Я примерно так же представлял эту логику.

А если использовать TRUNCATEONLY, как я понимаю, если я указываю filesize, то при выполнении DBCC SHRINKFILE данные будут перестраиваться (и не факт, что шринк удастся, если перемещаемые данные используются другим процессом), как понимаю при использовании TRUNCATEONLY, данные не перестраиваются, а освобождается место занятое пустыми страницами, что казалось бы должно выполнится быстрее и не создавать конфликты с заполненными страницами.

Как думаете?
20 сен 19, 11:51    [21975081]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
teCa
Yasha123
это никак не ускорит.
все будет ровно то же, только еще + он вначале информацию собирает,
и эта часть будет повторена много раз.
мне пришлось прерывать шринк, когда юзеры тормозились,
и он каждый раз начинал с начала.
до сделанного уже процента percent_complete бежит очень быстро,
потом доходит до места, где прервался в последний раз, и начинаются тормоза.


Я примерно так же представлял эту логику.

А если использовать TRUNCATEONLY, как я понимаю, если я указываю filesize, то при выполнении DBCC SHRINKFILE данные будут перестраиваться (и не факт, что шринк удастся, если перемещаемые данные используются другим процессом), как понимаю при использовании TRUNCATEONLY, данные не перестраиваются, а освобождается место занятое пустыми страницами, что казалось бы должно выполнится быстрее и не создавать конфликты с заполненными страницами.

Как думаете?

ну если всё свободное место в конце, иначе как
20 сен 19, 11:52    [21975085]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
у меня с TRUNCATEONLY ничего не высвободилось.
что логично, т.к. то, что тут массово удалили,
было как раз древнее либо повторяющееся.
если у вас просто пустое место в конце,
(например, потому что приращение 100Гб,
и даже когда мегабайта не хватило,
такой кусок сразу прирастился),
то может и повезет.
пробуйте, с TRUNCATEONLY ответ почти моментальный
20 сен 19, 12:01    [21975099]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
_ч_
Member

Откуда:
Сообщений: 1422
Yasha123
это никак не ускорит.
все будет ровно то же, только еще + он вначале информацию собирает,
и эта часть будет повторена много раз.
мне пришлось прерывать шринк, когда юзеры тормозились,
и он каждый раз начинал с начала.
до сделанного уже процента percent_complete бежит очень быстро,
потом доходит до места, где прервался в последний раз, и начинаются тормоза.


Мне казалось, что это должно уменьшить время блокировок.
Можно попробовать радикальный способ:
https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/
20 сен 19, 12:02    [21975102]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
_ч_
Мне казалось, что это должно уменьшить время блокировок.

с чего бы это.
он же за раз всего пару страниц блокирует:
ту, что перемещает, и ту, куда перемещает.
там даже дело не в блокировке,
шрик поднимает в память тучу никому не нужного,
если у вас и без того низкое PLE, юзеры сразу заметят
20 сен 19, 12:08    [21975114]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
_ч_
Можно попробовать радикальный способ:
https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/

CREATE INDEXWITH (DROP_EXISTING = ON) ON 

вообще не вариант.
вы своим одним переносимым индексом
вообще всю таблицу блокируете.
а онлайново даже лучше и не пытаться,
из-за каких-то 50Гб на терабайтной базе вы в лог запишете пару терабайт
20 сен 19, 12:12    [21975124]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
msLex
Member

Откуда:
Сообщений: 7730
Yasha123
с чего бы это.
он же за раз всего пару страниц блокирует:
ту, что перемещает, и ту, куда перемещает.
там даже дело не в блокировке,
шрик поднимает в память тучу никому не нужного,
если у вас и без того низкое PLE, юзеры сразу заметят


а как же страницы "слева/справа/сверху" в B-tree?
в них же ссылки менять надо.
20 сен 19, 12:14    [21975128]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
msLex
Yasha123
с чего бы это.
он же за раз всего пару страниц блокирует:
ту, что перемещает, и ту, куда перемещает.
там даже дело не в блокировке,
шрик поднимает в память тучу никому не нужного,
если у вас и без того низкое PLE, юзеры сразу заметят


а как же страницы "слева/справа/сверху" в B-tree?
в них же ссылки менять надо.

ок,
это было фигурально.
пускай будут 10 страниц в произвольный момент времени
в худшем случае, согласны?

но сколько блокируется за раз на шринке с параметром n,
столько же будет блокироваться за раз при шринке с параметром 100n.
в этом был смысл моего ответа.

а вот зато перенос индекса в новую ФГ это блокировка всей таблицы целиком.
и онлайново это тоже не только лог засрать, там чтобы получить Sch-M,
придется в очереди постоять, а пока стоишь в очереди за Sch-M,
накопишь целый паровоз из жаждущих Sch-S и IS
20 сен 19, 12:21    [21975143]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
+ @msLex
msLex,
а вы здесь?
хочу запостить вопрос про план,
и чтобы не на dba.stackexchange
20 сен 19, 12:24    [21975148]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
teCa
Member

Откуда:
Сообщений: 581
А в случае с TRUNCATEONLY, в данном случае чем шринк вызывает блокировку? В момент сбора информации о страницах? Вроде бы данные он никуда не перемещает.
20 сен 19, 12:24    [21975149]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
msLex
Member

Откуда:
Сообщений: 7730
Yasha123
ок,
это было фигурально.
пускай будут 10 страниц в произвольный момент времени
в худшем случае, согласны?

но сколько блокируется за раз на шринке с параметром n,
столько же будет блокироваться за раз при шринке с параметром 100n.
в этом был смысл моего ответа.



Да, конечно.

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

Yasha123
а вот зато перенос индекса в новую ФГ это блокировка всей таблицы целиком.
и онлайново это тоже не только лог засрать, там чтобы получить Sch-M,
придется в очереди постоять, а пока стоишь в очереди за Sch-M,
накопишь целый паровоз из жаждущих Sch-S и IS


в 2019 создание индекса сделали resumable, лог можно будет засирать только в положенное время.
20 сен 19, 12:47    [21975196]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
msLex
Member

Откуда:
Сообщений: 7730
Yasha123
+ @msLex
msLex,
а вы здесь?
хочу запостить вопрос про план,
и чтобы не на dba.stackexchange


+ @Yasha123

я почти каждый день здесь темы почитываю
20 сен 19, 12:48    [21975197]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
teCa
Member

Откуда:
Сообщений: 581
Пробовал шринковать малыми порциями, шринк не проходит и выдает следующую ошибку:

Could not adjust the space allocation for file 'Bl_SSD_1'.
20 сен 19, 13:37    [21975257]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 33260
Блог
teCa,

у вас только один выход - ожидать завершения,
хотя, учитывая приведенные объемы, смысл сего действия не ясен
20 сен 19, 14:18    [21975316]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
uaggster
Member

Откуда:
Сообщений: 767
Yasha123
_ч_
Можно попробовать радикальный способ:
https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/

CREATE INDEXWITH (DROP_EXISTING = ON) ON 

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

А если создать синонимичный индекс в другой файловой группе, а потом исходный просто удалить?
Это, по крайней мере, можно делать online.
20 сен 19, 15:35    [21975456]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
uaggster
А если создать синонимичный индекс в другой файловой группе, а потом исходный просто удалить?
Это, по крайней мере, можно делать online.

я чего-то не пойму, какая разница, где создавать.
хоть там, хоть здесь, или оффлайново или онлайново.
онлайново ему не светит, ибо стандард 2014.
но даже если энтерпрайз и онлайновость доступна,
онлайново -- это ГЕНЕРАЦИЯ ТУЧИ ЛОГА
(построчное логирование)
+ на нагруженной системе блокировки вы получите похлеще шринка.
потому что ваше Sch-M непременно встанет в очередь,
а пока оно ждет, за вами вырастет очередь несовместимых со Sch-M блокировок.
оно (Sch-M) типа всего на мгновенье нужно,
но поезд из блокировок, пока ждете, вам устроит
20 сен 19, 15:52    [21975488]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Slava_Nik
Member

Откуда: из России
Сообщений: 886
если в таблицах есть поля BLOB которые лежат в этих файловых группах, то можете забыть про шринк на таких объемах. Быстрее будет перенос таблиц в новые файлы и ФГ, либо проанализировать какие таблицы имеют BLOB поля, их перенести и после это шринк выполнится быстрее(может их немного).
25 сен 19, 22:39    [21979328]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Slava_Nik
Member

Откуда: из России
Сообщений: 886
Yasha123
uaggster
А если создать синонимичный индекс в другой файловой группе, а потом исходный просто удалить?
Это, по крайней мере, можно делать online.

я чего-то не пойму, какая разница, где создавать.
хоть там, хоть здесь, или оффлайново или онлайново.
онлайново ему не светит, ибо стандард 2014.
но даже если энтерпрайз и онлайновость доступна,
онлайново -- это ГЕНЕРАЦИЯ ТУЧИ ЛОГА
(построчное логирование)
+ на нагруженной системе блокировки вы получите похлеще шринка.
потому что ваше Sch-M непременно встанет в очередь,
а пока оно ждет, за вами вырастет очередь несовместимых со Sch-M блокировок.
оно (Sch-M) типа всего на мгновенье нужно,
но поезд из блокировок, пока ждете, вам устроит


если правильно все организовать можно перенести, блокировки требутся только в начале процесса и в конце, это нужно отследить.
Переносил террабайтные индексы в онлайне все Ок, главное за логами следить и блокировками, все можно автоматизировать.
25 сен 19, 22:42    [21979331]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36694
Yasha123,

По богатому опыту: онлайново не все так плохо, как разрисовано, даже AlwaysOn через пару дней догоняет, только места под лог надо действительно много, однако, опять же, далеко не x40 от размера таблицы, за исключением одного кейса. Весьма паскудно то, что если пересоздавать кластерный, в комплект включается ребилд всех некластерных, даже если у кластерного при пересоздании никак не меняется ключ.

Ну и если совсем с логом беда, то можно свитчится в балк-логгед модель (с разбором AlwaysOn) и молиться, чтобы во время операции не было проблем с СХД под данными.

Сообщение было отредактировано: 25 сен 19, 23:30
25 сен 19, 23:27    [21979347]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
Гавриленко Сергей Алексеевич,
а чем переключение в балк логгд поможет при онлайновом ребилде?
при оффлайновом залогируетcя минимально, но онлайново же все равно полно логируется
26 сен 19, 10:08    [21979495]     Ответить | Цитировать Сообщить модератору
 Re: DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
Гавриленко Сергей Алексеевич
По богатому опыту: онлайново не все так плохо, как разрисовано

ну не знаю.
на новом месте мне постоянно приходится править онлайново их триггеры.
тоже ведь "мгновенный alter" и такой же мгновенный Sch-M.
тем не менее, alter trigger встает в очередь и минимум минуту ждет (таблицы не отчетные, OLTP)
за это время накапливается поезд из жаждущих залезть в данную таблицу,
половина из них неизменно отваливается по таймауту
(у них в приложении всем 30 секунд выставлено)
и товарищи успевают нажаловаться.
а ведь у нас смешные объемы пользователей по сравнению с вашими.
26 сен 19, 10:18    [21979502]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить