Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Добры день. Поделитесь мыслями и советами по следующей задаче. Есть база общим объемом 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.09.2019, 11:02 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
teCa, попробуйте шринковать маленькими порциями, по X Мб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 11:23 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
_ч_teCa, попробуйте шринковать маленькими порциями, по X Мб. Была такая мысль, не был уверен, что это ускорило бы шринк, нужно потестировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 11:28 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
это никак не ускорит. все будет ровно то же, только еще + он вначале информацию собирает, и эта часть будет повторена много раз. мне пришлось прерывать шринк, когда юзеры тормозились, и он каждый раз начинал с начала. до сделанного уже процента percent_complete бежит очень быстро, потом доходит до места, где прервался в последний раз, и начинаются тормоза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 11:42 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Yasha123это никак не ускорит. все будет ровно то же, только еще + он вначале информацию собирает, и эта часть будет повторена много раз. мне пришлось прерывать шринк, когда юзеры тормозились, и он каждый раз начинал с начала. до сделанного уже процента percent_complete бежит очень быстро, потом доходит до места, где прервался в последний раз, и начинаются тормоза. Я примерно так же представлял эту логику. А если использовать TRUNCATEONLY, как я понимаю, если я указываю filesize, то при выполнении DBCC SHRINKFILE данные будут перестраиваться (и не факт, что шринк удастся, если перемещаемые данные используются другим процессом), как понимаю при использовании TRUNCATEONLY, данные не перестраиваются, а освобождается место занятое пустыми страницами, что казалось бы должно выполнится быстрее и не создавать конфликты с заполненными страницами. Как думаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 11:51 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
teCaYasha123это никак не ускорит. все будет ровно то же, только еще + он вначале информацию собирает, и эта часть будет повторена много раз. мне пришлось прерывать шринк, когда юзеры тормозились, и он каждый раз начинал с начала. до сделанного уже процента percent_complete бежит очень быстро, потом доходит до места, где прервался в последний раз, и начинаются тормоза. Я примерно так же представлял эту логику. А если использовать TRUNCATEONLY, как я понимаю, если я указываю filesize, то при выполнении DBCC SHRINKFILE данные будут перестраиваться (и не факт, что шринк удастся, если перемещаемые данные используются другим процессом), как понимаю при использовании TRUNCATEONLY, данные не перестраиваются, а освобождается место занятое пустыми страницами, что казалось бы должно выполнится быстрее и не создавать конфликты с заполненными страницами. Как думаете? ну если всё свободное место в конце, иначе как ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 11:52 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
у меня с TRUNCATEONLY ничего не высвободилось. что логично, т.к. то, что тут массово удалили, было как раз древнее либо повторяющееся. если у вас просто пустое место в конце, (например, потому что приращение 100Гб, и даже когда мегабайта не хватило, такой кусок сразу прирастился), то может и повезет. пробуйте, с TRUNCATEONLY ответ почти моментальный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 12:01 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Yasha123это никак не ускорит. все будет ровно то же, только еще + он вначале информацию собирает, и эта часть будет повторена много раз. мне пришлось прерывать шринк, когда юзеры тормозились, и он каждый раз начинал с начала. до сделанного уже процента percent_complete бежит очень быстро, потом доходит до места, где прервался в последний раз, и начинаются тормоза. Мне казалось, что это должно уменьшить время блокировок. Можно попробовать радикальный способ: https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 12:02 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
_ч_Мне казалось, что это должно уменьшить время блокировок. с чего бы это. он же за раз всего пару страниц блокирует: ту, что перемещает, и ту, куда перемещает. там даже дело не в блокировке, шрик поднимает в память тучу никому не нужного, если у вас и без того низкое PLE, юзеры сразу заметят ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 12:08 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
_ч_Можно попробовать радикальный способ: https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/ Код: sql 1. вообще не вариант. вы своим одним переносимым индексом вообще всю таблицу блокируете. а онлайново даже лучше и не пытаться, из-за каких-то 50Гб на терабайтной базе вы в лог запишете пару терабайт ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 12:12 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Yasha123с чего бы это. он же за раз всего пару страниц блокирует: ту, что перемещает, и ту, куда перемещает. там даже дело не в блокировке, шрик поднимает в память тучу никому не нужного, если у вас и без того низкое PLE, юзеры сразу заметят а как же страницы "слева/справа/сверху" в B-tree? в них же ссылки менять надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 12:14 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
msLexYasha123с чего бы это. он же за раз всего пару страниц блокирует: ту, что перемещает, и ту, куда перемещает. там даже дело не в блокировке, шрик поднимает в память тучу никому не нужного, если у вас и без того низкое PLE, юзеры сразу заметят а как же страницы "слева/справа/сверху" в B-tree? в них же ссылки менять надо. ок, это было фигурально. пускай будут 10 страниц в произвольный момент времени в худшем случае, согласны? но сколько блокируется за раз на шринке с параметром n, столько же будет блокироваться за раз при шринке с параметром 100n. в этом был смысл моего ответа. а вот зато перенос индекса в новую ФГ это блокировка всей таблицы целиком. и онлайново это тоже не только лог засрать, там чтобы получить Sch-M, придется в очереди постоять, а пока стоишь в очереди за Sch-M, накопишь целый паровоз из жаждущих Sch-S и IS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 12:21 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
@msLexmsLex, а вы здесь? хочу запостить вопрос про план, и чтобы не на dba.stackexchange ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 12:24 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
А в случае с TRUNCATEONLY, в данном случае чем шринк вызывает блокировку? В момент сбора информации о страницах? Вроде бы данные он никуда не перемещает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 12:24 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Yasha123ок, это было фигурально. пускай будут 10 страниц в произвольный момент времени в худшем случае, согласны? но сколько блокируется за раз на шринке с параметром n, столько же будет блокироваться за раз при шринке с параметром 100n. в этом был смысл моего ответа. Да, конечно. Я просто немного позанудствовал, а заодно уточнил. Может там какие оптимизации придумал, о которых я не в курсе. Yasha123а вот зато перенос индекса в новую ФГ это блокировка всей таблицы целиком. и онлайново это тоже не только лог засрать, там чтобы получить Sch-M, придется в очереди постоять, а пока стоишь в очереди за Sch-M, накопишь целый паровоз из жаждущих Sch-S и IS в 2019 создание индекса сделали resumable, лог можно будет засирать только в положенное время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 12:47 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Yasha123 @msLexmsLex, а вы здесь? хочу запостить вопрос про план, и чтобы не на dba.stackexchange @Yasha123 я почти каждый день здесь темы почитываю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 12:48 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Пробовал шринковать малыми порциями, шринк не проходит и выдает следующую ошибку: Could not adjust the space allocation for file 'Bl_SSD_1'. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 13:37 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
teCa, у вас только один выход - ожидать завершения, хотя, учитывая приведенные объемы, смысл сего действия не ясен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 14:18 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Yasha123_ч_Можно попробовать радикальный способ: https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/ Код: sql 1. вообще не вариант. вы своим одним переносимым индексом вообще всю таблицу блокируете. а онлайново даже лучше и не пытаться, из-за каких-то 50Гб на терабайтной базе вы в лог запишете пару терабайт А если создать синонимичный индекс в другой файловой группе, а потом исходный просто удалить? Это, по крайней мере, можно делать online. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 15:35 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
uaggsterА если создать синонимичный индекс в другой файловой группе, а потом исходный просто удалить? Это, по крайней мере, можно делать online. я чего-то не пойму, какая разница, где создавать. хоть там, хоть здесь, или оффлайново или онлайново. онлайново ему не светит, ибо стандард 2014 . но даже если энтерпрайз и онлайновость доступна, онлайново -- это ГЕНЕРАЦИЯ ТУЧИ ЛОГА (построчное логирование) + на нагруженной системе блокировки вы получите похлеще шринка. потому что ваше Sch-M непременно встанет в очередь, а пока оно ждет, за вами вырастет очередь несовместимых со Sch-M блокировок. оно (Sch-M) типа всего на мгновенье нужно, но поезд из блокировок, пока ждете, вам устроит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2019, 15:52 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
если в таблицах есть поля BLOB которые лежат в этих файловых группах, то можете забыть про шринк на таких объемах. Быстрее будет перенос таблиц в новые файлы и ФГ, либо проанализировать какие таблицы имеют BLOB поля, их перенести и после это шринк выполнится быстрее(может их немного). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2019, 22:39 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Yasha123uaggsterА если создать синонимичный индекс в другой файловой группе, а потом исходный просто удалить? Это, по крайней мере, можно делать online. я чего-то не пойму, какая разница, где создавать. хоть там, хоть здесь, или оффлайново или онлайново. онлайново ему не светит, ибо стандард 2014 . но даже если энтерпрайз и онлайновость доступна, онлайново -- это ГЕНЕРАЦИЯ ТУЧИ ЛОГА (построчное логирование) + на нагруженной системе блокировки вы получите похлеще шринка. потому что ваше Sch-M непременно встанет в очередь, а пока оно ждет, за вами вырастет очередь несовместимых со Sch-M блокировок. оно (Sch-M) типа всего на мгновенье нужно, но поезд из блокировок, пока ждете, вам устроит если правильно все организовать можно перенести, блокировки требутся только в начале процесса и в конце, это нужно отследить. Переносил террабайтные индексы в онлайне все Ок, главное за логами следить и блокировками, все можно автоматизировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2019, 22:42 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Yasha123, По богатому опыту: онлайново не все так плохо, как разрисовано, даже AlwaysOn через пару дней догоняет, только места под лог надо действительно много, однако, опять же, далеко не x40 от размера таблицы, за исключением одного кейса. Весьма паскудно то, что если пересоздавать кластерный, в комплект включается ребилд всех некластерных, даже если у кластерного при пересоздании никак не меняется ключ. Ну и если совсем с логом беда, то можно свитчится в балк-логгед модель (с разбором AlwaysOn) и молиться, чтобы во время операции не было проблем с СХД под данными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2019, 23:27 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей Алексеевич, а чем переключение в балк логгд поможет при онлайновом ребилде? при оффлайновом залогируетcя минимально, но онлайново же все равно полно логируется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2019, 10:08 |
|
||
|
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей АлексеевичПо богатому опыту: онлайново не все так плохо, как разрисовано ну не знаю. на новом месте мне постоянно приходится править онлайново их триггеры. тоже ведь "мгновенный alter" и такой же мгновенный Sch-M. тем не менее, alter trigger встает в очередь и минимум минуту ждет (таблицы не отчетные, OLTP) за это время накапливается поезд из жаждущих залезть в данную таблицу, половина из них неизменно отваливается по таймауту (у них в приложении всем 30 секунд выставлено) и товарищи успевают нажаловаться. а ведь у нас смешные объемы пользователей по сравнению с вашими. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2019, 10:18 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39864703&tid=1687228]: |
0ms |
get settings: |
6ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
61ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
76ms |
get tp. blocked users: |
2ms |
| others: | 229ms |
| total: | 414ms |

| 0 / 0 |
