|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
У меня есть база на SQL Server 2012. В ней есть таблица с кластерным индексом, в которой 1200 миллионов строк. Сейчас из неё удаляют 1000 миллионов строк. Удаляют не одним оператором DELETE; а серией DELETE, каждый из которых удаляет тысяч 20 строк. Вопрос: а что делать с таблицей и базой после того как удаление завершится? Правильно ли я понимаю, что после такого массивного удаления надо как-то “сжать” эту таблицу; иначе в её кластерном индексе останется слишком много “дырок”? После удаления размер таблицы уже не будет достигать такого большого размера как 1200 миллионов строк; в ней будет 200 миллионов строк; ну и потом будут понемногу добавляться строки. Что делать – вызвать ALTER INDEX REBUILD ? А какой именно - с опцией ONLINE? У таблицы также есть некластерный индекс. Что делать с ним? И наконец – а что делать с файлом данных базы? Вызвать shrink ? Я в такой ситуации (удаление столь большого количества строк) ещё не бывал; поэтому не очень понимаю – как поступить. Заранее спасибо за советы. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 18:06 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
KellyLynch У меня есть база на SQL Server 2012. В ней есть таблица с кластерным индексом, в которой 1200 миллионов строк. Сейчас из неё удаляют 1000 миллионов строк. Удаляют не одним оператором DELETE; а серией DELETE, каждый из которых удаляет тысяч 20 строк. Дешевле будет перелить 200 кк в новую таблицу, чем удалять 1000 кк строк из текущей с последующим ребилдом. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 18:08 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
Во-первых, для вашего случая более логичен вариант перелить нужные 200М в новую таблицу, а старую грохнуть целимком. Во-вторых, если все-таки хотите удалять. При удалении данных, которые идут в индексе послдеовательно, по идее, пустые страницы должны поудаляться, но могут быть нюансы с ghost cleanup. Далее, для каждого индекса, если место не высвободилось, надо деалть ребилд (возможно, реорг). Онлайн или не онлайн зависит от того, нужен ли вам доступ к данным на время этой операции. Файл базы данных лучше не трогать, кроме случая, когда удаление данных целенаправленно делалось для высвобождения места на диске и уменьшения размера файлов БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 18:13 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
KellyLynch, Перед удалением лучше отключить все некластерные индексы. Потом перестроите. Быстрее всего перегрузить в новую таблицу. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 18:15 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
Так-то оно конечно, быстрее перезагрузить (с точки зрения длительности процесса на сервере), но с точки зрения трудозатрат сотрудников дешевле будет запустить Код: sql 1. 2.
а потом сделать REBUILD оставшихся миллионов. Смотрите сами, может у вас там есть окно, когда никто не работает, если у вас какое-нибудь ХД или подобная система. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 18:23 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
Критик Так-то оно конечно, быстрее перезагрузить (с точки зрения длительности процесса на сервере), но с точки зрения трудозатрат сотрудников дешевле будет ... |
|||
:
Нравится:
Не нравится:
|
|||
03.11.2020, 23:17 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
Если места в базе (это НЕ express-версия с ограничением на 10ГБ) и на диске хватает и таблица должна опять вырасти,- ни чего не делайте. Если таблица используется 24ч в сутки и версия сервера позволяет,- перестраивайте online . ИМХО. PS Я бы поступил именно так. Но могу ошибаться. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 08:28 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
Гавриленко Сергей Алексеевич, Спасибо за ответ. “ Онлайн или не онлайн зависит от того, нужен ли вам доступ к данным на время этой операции.” – а правильно ли я понимаю что Online и не-Online отличаются, помимо прочего, “качеством сжатия”? То есть не-Online даст “ЛУЧШЕЕ сжатие” чем не-Online? Или это не так; и “качество сжатия” окажется одинаковым? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 14:48 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
SIMPLicity_ Если места в базе (это НЕ express-версия с ограничением на 10ГБ) и на диске хватает и таблица должна опять вырасти,- ни чего не делайте. Если таблица используется 24ч в сутки и версия сервера позволяет,- перестраивайте online . ИМХО. PS Я бы поступил именно так. Но могу ошибаться. “Если места в базе (это НЕ express-версия с ограничением на 10ГБ) и на диске хватает и таблица должна опять вырасти,- ни чего не делайте” – у меня ситуация такая: таблица будет расти очень умеренно. За каждый месяц она будет вырастать не больше чем на 1% от того огромного количества строк что удалены. Что касается “и на диске хватает” – увы, вижу что нужно бы размер файлов базы уменьшить. Исходя из этого моего уточнения, что бы Вы могли посоветовать? Я (признаюсь честно :-) ) никогда ещё не применял Shrink для файлов данных/индексов базы. Применял shrink только для DB logs; это совсем другое. Читал на форумах что “Shrink для файлов данных/индексов базы” в случае огромного файла (а у меня такие размеры у этих файлов, как 1.2 TeraBytes) будет работать ужасно долго. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 14:57 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
Гавриленко Сергей Алексеевич, Гавриленко Сергей Алексеевич Во-первых, для вашего случая более логичен вариант перелить нужные 200М в новую таблицу, а старую грохнуть целимком. Во-вторых, если все-таки хотите удалять. При удалении данных, которые идут в индексе послдеовательно, по идее, пустые страницы должны поудаляться, но могут быть нюансы с ghost cleanup. Далее, для каждого индекса, если место не высвободилось, надо деалть ребилд (возможно, реорг). Онлайн или не онлайн зависит от того, нужен ли вам доступ к данным на время этой операции. Файл базы данных лучше не трогать, кроме случая, когда удаление данных целенаправленно делалось для высвобождения места на диске и уменьшения размера файлов БД. "Файл базы данных лучше не трогать, кроме случая, когда удаление данных целенаправленно делалось для высвобождения места на диске и уменьшения размера файлов БД.” – я сейчас проверил, а для чего запускалось это удаление (мне приходится “разгребать действия совсем другого человека”) – и да, одной из целей как раз было “уменьшить размер файлов БД ”. Исходя из этого уточнения – что бы Вы могли п осоветовать сделать именно в этом отношении - “уменьшить размер файлов БД ”? Я, увы, командой Shrink не пользовался никогда; только знаю что она существует. " ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 15:03 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
C терабайтными базами не работал. Я БЫ поискал место, сделал бэкап и экспериментировал сначала над поднятой из бэкапа КОПИЕЙ. Исходя из результатов действовал дальше. PS Да, если Вам обещают, что "ничего страшного" и т.п., то тут хорошо последним предложением: 22225441 . ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 15:39 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
KellyLynch одной из целей как раз было “уменьшить размер файлов БД ”. Исходя из этого уточнения – что бы Вы могли п осоветовать сделать именно в этом отношении - “уменьшить размер файлов БД ”? Я, увы, командой Shrink не пользовался никогда; только знаю что она существует. Особенность там одна - лучше делать шринк небольшими порциями, вычисляя в каждой итерации новый целевой размер. Тогда он сделается быстро. А одной операцией скорее всего не выполнится вообще. DatabaseFileShrink Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 18:20 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
alexeyvg Особенность там одна - лучше делать шринк небольшими порциями, вычисляя в каждой итерации новый целевой размер. Тогда он сделается быстро. А одной операцией скорее всего не выполнится вообще. подтверждающую ссылку приведите, пожалуйста. про то, зачем бы делать по частям, кроме как "ой, давайте скорее уже отдадим ОС хоть что-то, хоть кусочек" и про то, как "одной операцией скорее всего не выполнится вообще". а еще бы хотелось получить обоснование того, что "Тогда он сделается быстро." ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 22:01 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
Yasha123, Это опыт, который сын ошибок трудных. Я как-то оставлял на все новогодние праздники шринк многотерабайтной базы (из-за изменения архитектуры решения она сильно похудела) - он не успел выполнится. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 22:32 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
Yasha123 и про то, как "одной операцией скорее всего не выполнится вообще". Поделитесь опытом - как у вас обычно отрабатывал шринк на базе в терабайт, которая должна после него ужаться до 100 гигов? Ни разу не было проблем? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 23:16 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
alexeyvg Поделитесь опытом - как у вас обычно отрабатывал шринк на базе в терабайт, которая должна после него ужаться до 100 гигов? Ни разу не было проблем? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2020, 23:18 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
KellyLynch У меня есть база на SQL Server 2012. В ней есть таблица с кластерным индексом, в которой 1200 миллионов строк. Сейчас из неё удаляют 1000 миллионов строк. Удаляют не одним оператором DELETE; а серией DELETE, каждый из которых удаляет тысяч 20 строк. Вопрос: а что делать с таблицей и базой после того как удаление завершится? Правильно ли я понимаю, что после такого массивного удаления надо как-то “сжать” эту таблицу; иначе в её кластерном индексе останется слишком много “дырок”? После удаления размер таблицы уже не будет достигать такого большого размера как 1200 миллионов строк; в ней будет 200 миллионов строк; ну и потом будут понемногу добавляться строки. Что делать – вызвать ALTER INDEX REBUILD ? А какой именно - с опцией ONLINE? У таблицы также есть некластерный индекс. Что делать с ним? И наконец – а что делать с файлом данных базы? Вызвать shrink ? Я в такой ситуации (удаление столь большого количества строк) ещё не бывал; поэтому не очень понимаю – как поступить. Заранее спасибо за советы. Я, наверное, скажу нечто ужасное... Ничего делать не надо. Особенно если вы планируете снова пополнять эту таблицу и вам не нужно "прямо здесь и сейчас" свободное место на диске. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2020, 06:53 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
alexeyvg Yasha123 и про то, как "одной операцией скорее всего не выполнится вообще". Поделитесь опытом - как у вас обычно отрабатывал шринк на базе в терабайт, которая должна после него ужаться до 100 гигов? Ни разу не было проблем? да, именно с терабайта до 300Мб, где данных оставалось 200Мб, без прерываний за один раз. джобом ночью шринкается без проблем. не было ни разу, чтобы не выполнилось, потому и спрашиваю, в чем проблема. один раз пришлось днем это делать, когда пожаловались на тормоза, пришлось прервать, и ничего, вместо раза за два шринканулось. но не за 10 и не за 100 раз. и никак не пойму, с чего бы за несколько раз "выполнилось быстрее". ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2020, 10:58 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
aleks222 Я, наверное, скажу нечто ужасное... Ничего делать не надо. Особенно если вы планируете снова пополнять эту таблицу и вам не нужно "прямо здесь и сейчас" свободное место на диске. хотелось бы ничего не трогать, но не всегда возможно. у нас дисковое пространство где-то там арендуют и лишнего не выпросишь. а начальник обожает рядом с рабочей базой на том же сервере иметь еще 10 копий за вчера, на 3 дня назад, на 10, на месяц, и т.д., у него там эксперименты и исправления накосяченного. умещай как хочешь. пока на стандарде сидели, приходилось. сейчас на энтерпрайзе, там компрессия хотя бы, запросы не отрабатывают быстрее, но хоть место экономится, вот чем шринкать, лучше компрессить ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2020, 11:03 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
Yasha123 alexeyvg пропущено... Ни разу не получилось. Может, я что то делал не так? Но там у команды 3 параметра, что можно сделать не так? Поделитесь опытом - как у вас обычно отрабатывал шринк на базе в терабайт, которая должна после него ужаться до 100 гигов? Ни разу не было проблем? да, именно с терабайта до 300Мб, где данных оставалось 200Мб, без прерываний за один раз. джобом ночью шринкается без проблем. не было ни разу, чтобы не выполнилось, потому и спрашиваю, в чем проблема. один раз пришлось днем это делать, когда пожаловались на тормоза, пришлось прервать, и ничего, вместо раза за два шринканулось. но не за 10 и не за 100 раз. и никак не пойму, с чего бы за несколько раз "выполнилось быстрее". В деталях собака порылась. Все зависит от расспределения данных в БД. Именно потому и не было у Вас проблем, что аж до 300Мб. Т.е. она почти пустая оказалась. Суть даже не про "выполнилось быстро", а чтобы просто выполнилось. Тут Вам про опыт уже рассказали. Можно даже на гигабайтной базе зависнуть на несколько часов. Из опыта, лучше сжимать на половину величины пустого пространства (но если очень большая БД, то 20-30%). И так далее, но не доводя до предела. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2020, 03:55 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
Idol_111 Суть даже не про "выполнилось быстро", а чтобы просто выполнилось. И да, я ужимал в базе не так много, в процентах от объёма, типа, в 5 тб сжимал файл на 200-500 гиг (приходилось так делать некоторое время, месяца три, полгода, по расписанию, потом, конечно, шринк из расписания убрал). Запускаешь - и тишина. Коннект есть, никаких блокировок, операций с файлами, никакой загрузки процессора, никаких ожиданий. Может, через сутки оно бы и заиграло, но так долго не ждал. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.11.2020, 08:57 |
|
Что делать после удаления большого количества строк в кластерной таблице?
|
|||
---|---|---|---|
#18+
как пример. Недавно сжимал почти архивную бд после сжатия таблиц и переборщил с оценкой. Со 160Гб решил до 60Гб за один раз при данных на 52Гб. Крутилось аж 3 дня. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 22:57 |
|
|
start [/forum/topic.php?fid=46&msg=40015358&tid=1685218]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
147ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 299ms |
total: | 539ms |
0 / 0 |