Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде? / 25 сообщений из 31, страница 1 из 2
  1  все
20.09.2019, 11:02
    #39864446
teCa
teCa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Добры день.
Поделитесь мыслями и советами по следующей задаче.
Есть база общим объемом 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: )
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 11:23
    #39864456
_ч_
_ч_
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
teCa,

попробуйте шринковать маленькими порциями, по X Мб.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 11:28
    #39864459
teCa
teCa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
_ч_teCa,

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

Была такая мысль, не был уверен, что это ускорило бы шринк, нужно потестировать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 11:42
    #39864465
Yasha123
Yasha123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
это никак не ускорит.
все будет ровно то же, только еще + он вначале информацию собирает,
и эта часть будет повторена много раз.
мне пришлось прерывать шринк, когда юзеры тормозились,
и он каждый раз начинал с начала.
до сделанного уже процента percent_complete бежит очень быстро,
потом доходит до места, где прервался в последний раз, и начинаются тормоза.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 11:51
    #39864471
teCa
teCa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Yasha123это никак не ускорит.
все будет ровно то же, только еще + он вначале информацию собирает,
и эта часть будет повторена много раз.
мне пришлось прерывать шринк, когда юзеры тормозились,
и он каждый раз начинал с начала.
до сделанного уже процента percent_complete бежит очень быстро,
потом доходит до места, где прервался в последний раз, и начинаются тормоза.

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

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

Как думаете?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 11:52
    #39864475
TaPaK
TaPaK
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
teCaYasha123это никак не ускорит.
все будет ровно то же, только еще + он вначале информацию собирает,
и эта часть будет повторена много раз.
мне пришлось прерывать шринк, когда юзеры тормозились,
и он каждый раз начинал с начала.
до сделанного уже процента percent_complete бежит очень быстро,
потом доходит до места, где прервался в последний раз, и начинаются тормоза.

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

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

Как думаете?
ну если всё свободное место в конце, иначе как
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 12:01
    #39864486
Yasha123
Yasha123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
у меня с TRUNCATEONLY ничего не высвободилось.
что логично, т.к. то, что тут массово удалили,
было как раз древнее либо повторяющееся.
если у вас просто пустое место в конце,
(например, потому что приращение 100Гб,
и даже когда мегабайта не хватило,
такой кусок сразу прирастился),
то может и повезет.
пробуйте, с TRUNCATEONLY ответ почти моментальный
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 12:02
    #39864489
_ч_
_ч_
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Yasha123это никак не ускорит.
все будет ровно то же, только еще + он вначале информацию собирает,
и эта часть будет повторена много раз.
мне пришлось прерывать шринк, когда юзеры тормозились,
и он каждый раз начинал с начала.
до сделанного уже процента percent_complete бежит очень быстро,
потом доходит до места, где прервался в последний раз, и начинаются тормоза.

Мне казалось, что это должно уменьшить время блокировок.
Можно попробовать радикальный способ:
https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 12:08
    #39864495
Yasha123
Yasha123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
_ч_Мне казалось, что это должно уменьшить время блокировок.

с чего бы это.
он же за раз всего пару страниц блокирует:
ту, что перемещает, и ту, куда перемещает.
там даже дело не в блокировке,
шрик поднимает в память тучу никому не нужного,
если у вас и без того низкое PLE, юзеры сразу заметят
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 12:12
    #39864504
Yasha123
Yasha123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
_ч_Можно попробовать радикальный способ:
https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/
Код: sql
1.
CREATE INDEX … WITH (DROP_EXISTING = ON) ON


вообще не вариант.
вы своим одним переносимым индексом
вообще всю таблицу блокируете.
а онлайново даже лучше и не пытаться,
из-за каких-то 50Гб на терабайтной базе вы в лог запишете пару терабайт
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 12:14
    #39864506
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Yasha123с чего бы это.
он же за раз всего пару страниц блокирует:
ту, что перемещает, и ту, куда перемещает.
там даже дело не в блокировке,
шрик поднимает в память тучу никому не нужного,
если у вас и без того низкое PLE, юзеры сразу заметят

а как же страницы "слева/справа/сверху" в B-tree?
в них же ссылки менять надо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 12:21
    #39864518
Yasha123
Yasha123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
msLexYasha123с чего бы это.
он же за раз всего пару страниц блокирует:
ту, что перемещает, и ту, куда перемещает.
там даже дело не в блокировке,
шрик поднимает в память тучу никому не нужного,
если у вас и без того низкое PLE, юзеры сразу заметят

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

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

а вот зато перенос индекса в новую ФГ это блокировка всей таблицы целиком.
и онлайново это тоже не только лог засрать, там чтобы получить Sch-M,
придется в очереди постоять, а пока стоишь в очереди за Sch-M,
накопишь целый паровоз из жаждущих Sch-S и IS
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 12:24
    #39864521
Yasha123
Yasha123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
 
@msLexmsLex,
а вы здесь?
хочу запостить вопрос про план,
и чтобы не на dba.stackexchange
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 12:24
    #39864522
teCa
teCa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
А в случае с TRUNCATEONLY, в данном случае чем шринк вызывает блокировку? В момент сбора информации о страницах? Вроде бы данные он никуда не перемещает.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 12:47
    #39864557
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Yasha123ок,
это было фигурально.
пускай будут 10 страниц в произвольный момент времени
в худшем случае, согласны?

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


Да, конечно.

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

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

в 2019 создание индекса сделали resumable, лог можно будет засирать только в положенное время.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 12:48
    #39864558
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Yasha123
 
@msLexmsLex,
а вы здесь?
хочу запостить вопрос про план,
и чтобы не на dba.stackexchange


 
@Yasha123
я почти каждый день здесь темы почитываю
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 13:37
    #39864594
teCa
teCa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Пробовал шринковать малыми порциями, шринк не проходит и выдает следующую ошибку:

Could not adjust the space allocation for file 'Bl_SSD_1'.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 14:18
    #39864633
Критик
Критик
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
teCa,

у вас только один выход - ожидать завершения,
хотя, учитывая приведенные объемы, смысл сего действия не ясен
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 15:35
    #39864703
uaggster
uaggster
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Yasha123_ч_Можно попробовать радикальный способ:
https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/
Код: sql
1.
CREATE INDEX … WITH (DROP_EXISTING = ON) ON


вообще не вариант.
вы своим одним переносимым индексом
вообще всю таблицу блокируете.
а онлайново даже лучше и не пытаться,
из-за каких-то 50Гб на терабайтной базе вы в лог запишете пару терабайт
А если создать синонимичный индекс в другой файловой группе, а потом исходный просто удалить?
Это, по крайней мере, можно делать online.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.09.2019, 15:52
    #39864723
Yasha123
Yasha123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
uaggsterА если создать синонимичный индекс в другой файловой группе, а потом исходный просто удалить?
Это, по крайней мере, можно делать online.
я чего-то не пойму, какая разница, где создавать.
хоть там, хоть здесь, или оффлайново или онлайново.
онлайново ему не светит, ибо стандард 2014 .
но даже если энтерпрайз и онлайновость доступна,
онлайново -- это ГЕНЕРАЦИЯ ТУЧИ ЛОГА
(построчное логирование)
+ на нагруженной системе блокировки вы получите похлеще шринка.
потому что ваше Sch-M непременно встанет в очередь,
а пока оно ждет, за вами вырастет очередь несовместимых со Sch-M блокировок.
оно (Sch-M) типа всего на мгновенье нужно,
но поезд из блокировок, пока ждете, вам устроит
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.09.2019, 22:39
    #39867116
Slava_Nik
Slava_Nik
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
если в таблицах есть поля BLOB которые лежат в этих файловых группах, то можете забыть про шринк на таких объемах. Быстрее будет перенос таблиц в новые файлы и ФГ, либо проанализировать какие таблицы имеют BLOB поля, их перенести и после это шринк выполнится быстрее(может их немного).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.09.2019, 22:42
    #39867118
Slava_Nik
Slava_Nik
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Yasha123uaggsterА если создать синонимичный индекс в другой файловой группе, а потом исходный просто удалить?
Это, по крайней мере, можно делать online.
я чего-то не пойму, какая разница, где создавать.
хоть там, хоть здесь, или оффлайново или онлайново.
онлайново ему не светит, ибо стандард 2014 .
но даже если энтерпрайз и онлайновость доступна,
онлайново -- это ГЕНЕРАЦИЯ ТУЧИ ЛОГА
(построчное логирование)
+ на нагруженной системе блокировки вы получите похлеще шринка.
потому что ваше Sch-M непременно встанет в очередь,
а пока оно ждет, за вами вырастет очередь несовместимых со Sch-M блокировок.
оно (Sch-M) типа всего на мгновенье нужно,
но поезд из блокировок, пока ждете, вам устроит

если правильно все организовать можно перенести, блокировки требутся только в начале процесса и в конце, это нужно отследить.
Переносил террабайтные индексы в онлайне все Ок, главное за логами следить и блокировками, все можно автоматизировать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.09.2019, 23:27
    #39867126
Гавриленко Сергей Алексеевич
Гавриленко Сергей Алексеевич
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Yasha123,

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

Ну и если совсем с логом беда, то можно свитчится в балк-логгед модель (с разбором AlwaysOn) и молиться, чтобы во время операции не было проблем с СХД под данными.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.09.2019, 10:08
    #39867185
Yasha123
Yasha123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Гавриленко Сергей Алексеевич,
а чем переключение в балк логгд поможет при онлайновом ребилде?
при оффлайновом залогируетcя минимально, но онлайново же все равно полно логируется
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.09.2019, 10:18
    #39867190
Yasha123
Yasha123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде?
Гавриленко Сергей АлексеевичПо богатому опыту: онлайново не все так плохо, как разрисовано
ну не знаю.
на новом месте мне постоянно приходится править онлайново их триггеры.
тоже ведь "мгновенный alter" и такой же мгновенный Sch-M.
тем не менее, alter trigger встает в очередь и минимум минуту ждет (таблицы не отчетные, OLTP)
за это время накапливается поезд из жаждущих залезть в данную таблицу,
половина из них неизменно отваливается по таймауту
(у них в приложении всем 30 секунд выставлено)
и товарищи успевают нажаловаться.
а ведь у нас смешные объемы пользователей по сравнению с вашими.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / DBCC SHRINKFILE объемом 1Тб в высоконагруженной среде? / 25 сообщений из 31, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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