Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Добрый день всем. Recovery Model Simple Надо было удалить 30 млн записей с одной достаточно широкой таблицы с кластерным индексом Таблица стейжинговая - т.е используется только для ETL чтобы перелить в DWH (разовая задача - но перидоически возможны повторения - фиксы данных ) посчитал это где то 1.5% от общего числа и решил не замарачивать Delete FRom Date between ибо на сервре я один - НЕ прошло - пепреполнение лога Наверно надо было Select * into from в другую таблицу и переименовать но все таки большой кусок - да и потом я понимаю надо опять ALTER TABLE <t1> ADD CONSTRAINT <pk1> PRIMARY KEY CLUSTERED Решил поудалять батчами по 10000 (5000) WITH T1 AS ( SELECT TOP 10000 id FROM BIG where id > 73465236123 ORDER BY 1 desc ) DELETE FROM T1 проверил - вроде удаляется быстро запустил по циклу - через 15 мни смотрю не то - зависло - снял поглядел запрос - не пашет UPDATE STATISTICS помогло - запустил опять - тоже самое Вообщем дропнул я clustered PK (минут 25 - тоже не даром ) Создал NONclustered - запустил удаление по циклу и мин за 10-15 оно отработало (без UPDATE STATISTICS ) 1) Понимаю что по хорошему надо делать партиции по месяцам и просто дропать но пока не дошли руки к тому же в PK надо включать поле даты в этом случаей (а там пока ID достаточно ) к тому же не факт что надо именно месяц дропать - тут было 1.5 1?) После большой заливки (удаления ) данных я так поинмаю UPDATE STATISTICS обязательная операция 2?) По ощущениям удаление больших кусков из табл. с кластерным индексом более затратно киньте плз ссылки на мат. часть или кто сталкивался на практике - (может и не так - частный случай ) зы гуглил сей момент - но не нашел пока толкового объяснения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 13:47 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Гулин Федор, А TOP 100000 TOP 500000 TOP 1000000 пробовали? Второе предложение -- попробуйте перевести в колумнстор. Хотя может стать как лучше, так и хуже. версия sql Какая? и партиционирование должно помочь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 14:48 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
a_voroninГулин Федор, А TOP 100000 TOP 500000 TOP 1000000 пробовали? Второе предложение -- попробуйте перевести в колумнстор. Хотя может стать как лучше, так и хуже. версия sql Какая? и партиционирование должно помочь. Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) Oct 28 2016 18:17:30 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows Server 2016 Datacenter 6.3 <X64> (Build 14393: ) (Hypervisor) да про партицировние я в курсе - поможет - надо было быстро сделать Из практичсекого опыта как раз размер батча делете д.б небольшой (обычно 5000 - здесь ставил 10000 ибо данных ) Про колмунстор вообще не понял - это ж вроде R/Only штука а это стейжниговая таблица грузящаяся каждый день зы вопросы были то не про воркараунд - я его то нашел а больше есть ли особенности кластерного индекса при больших делетах ( особенно скажем в середине ) по ср. с некластерным. ну и до кучи делает ли народ UPDATE STATISTICS - хотя здесь ясно что скорей всего надо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 15:12 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Гулин Федоресть ли особенности кластерного индекса при больших делетах ( особенно скажем в середине ) по ср. с некластерным.Есть, с кластерным серверу удалять проще. Только скрипт бы поудобнее для сервера надо. Скажем, если удаляется диапазок Id, и Id более менее равномерны, то лучше удалять по мелким вычисленным диапазонам id Гулин ФедорПонимаю что по хорошему надо делать партиции по месяцам и просто дропатьЕсли данных много, удаление - постоянная задача, и поле секциоонирования хорошо лдожиться в ПК, то да, это самое лучшее решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 15:35 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Гулин ФедорПро колмунстор вообще не понял - это ж вроде R/Only штука а это стейжниговая таблица грузящаяся каждый день Вы очень сильно отстали от жизни. Колумстор с 2014 read write, а под 2016 он уже очень хорошо оптимизирован. И сжимает данные он очень серьезно. Я бы попробовал. А партиционированный колумнстор -- это вообще круть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 16:29 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
DELETE WITH (TABLOCK) должно снизить потребление журнала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 16:47 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
alexeyvgГулин Федоресть ли особенности кластерного индекса при больших делетах ( особенно скажем в середине ) по ср. с некластерным. Есть, с кластерным серверу удалять проще. Только скрипт бы поудобнее для сервера надо. Скажем, если удаляется диапазок Id, и Id более менее равномерны, то лучше удалять по мелким вычисленным диапазонам id вот код - тут удалял начиная с какого то ИД ( по хорошему можно было с по ) - но чтобы упростить я удалял до конца (т.е по факту с какой то даты ) Код: sql 1. 2. 3. 4. 5. 6. 7. Вот у меня в моем кейсе получилось ровно наооборот - почему до конца не пнял ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 17:04 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовDELETE WITH (TABLOCK) должно снизить потребление журнала. https://blogs.msdn.microsoft.com/bartd/2010/06/01/purging-data/ СПАСИБО возможно в моем случае разового удаления это бы решило проблему хотя по ссылке (TABLOCK) используется в delete by chunks т.е сложно сказать хватило бы лога на удаление 25 млн записей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 17:11 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовDELETE WITH (TABLOCK) должно снизить потребление журнала.Ух ты! А засчет чего и с какой версии? Может все-таки попутали с INSERT? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 17:13 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
invmУх ты! А засчет чего и с какой версии? Может все-таки попутали с INSERT? Всего навсего меньше инфы о блокировках в лог записывать будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 17:22 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
msLexinvmУх ты! А засчет чего и с какой версии? Может все-таки попутали с INSERT? Всего навсего меньше инфы о блокировках в лог записывать будет. не будет никакого меньше, просто "другая" информация о блокировке каждой строки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 17:29 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
TaPaKmsLexпропущено... Всего навсего меньше инфы о блокировках в лог записывать будет. не будет никакого меньше, просто "другая" информация о блокировке каждой строки будет, указатель на таблицу меньше чем указатель на строку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 17:39 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Гулин ФедорВот у меня в моем кейсе получилось ровно наооборот - почему до конца не пнялНе знаю, надо планы смотреть, разбираться... Нужно что то вроде такого цикла, тогда планы точно не собьются: Код: sql 1. 2. 3. 4. 5. 6. 7. PS Получается, у вас удаляются последние записи, самые новые, начиная с некоего id? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 17:41 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
msLexTaPaKпропущено... не будет никакого меньше, просто "другая" информация о блокировке каждой строки будет, указатель на таблицу меньше чем указатель на строку дейсвительно "уменьшит" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 17:47 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
TaPaK, msLexВсего навсего меньше инфы о блокировках в лог записывать будет. TaPaKне будет никакого меньше Какое из утверждений верно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 18:02 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
alexeyvgГулин ФедорВот у меня в моем кейсе получилось ровно наооборот - почему до конца не пнялНе знаю, надо планы смотреть, разбираться... Нужно что то вроде такого цикла, тогда планы точно не собьются: Код: sql 1. 2. 3. 4. 5. 6. 7. PS Получается, у вас удаляются последние записи, самые новые, начиная с некоего id? да - я пошел по простому пути по идее надо было betwwen - но проще было перегрузить с какого-то момента - за 1.5 мес чем прогружать в реальности 2 гапа зы насчет не собьется - хз - по факту сбивалась статистика я на этой БД уже сталкивался когда загружались большие объемы инф-ции в таблицы переставала рабоать даже Explain <Select Query> и помогало UPDATE STATISTICS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 18:07 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Всем отвечавшим посвящается Код: 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. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. Код: plaintext 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. 51. 52. 53. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 18:14 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
msLexTaPaKпропущено... не будет никакого меньше, просто "другая" информация о блокировке каждой строки будет, указатель на таблицу меньше чем указатель на строкуА зачем вообще серверу записывать информацию о блокировках в лог? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 19:14 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
MindА зачем вообще серверу записывать информацию о блокировках в лог? https://www.sqlskills.com/blogs/paul/lock-logging-and-fast-recovery/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 19:35 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей Алексеевич, Спасибо. Не знал такой нюанс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2019, 20:57 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
@Invm СПС за пример есть пару вопросов я попробровал T4 Код: sql 1. 2. 3. 4. 5. 6. Cannot find a row in the system catalog with the index ID 1 for table "t4". Основная задача была сравнить удаление в кластерном и некластерном индексе ( columnstore всплыли позднее ) 1?) Как можно это сделать для некластерных ghost_record_count - почитал что данные логически удаленные но физически оставшиеся - я так понимаю это вспомгательная инфа я так понимаю осн. польза от database_transaction_log_record_count ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2019, 16:50 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Гулин Федор Cannot find a row in the system catalog with the index ID 1 for table "t4". Поправьте функцию: Код: sql 1. Гулин ФедорОсновная задача была сравнить удаление в кластерном и некластерном индексеЭто бессмысленно. Гулин Федоря так понимаю осн. польза от database_transaction_log_record_count ?Польза для чего? Для определения объема потребления ЖТ? Тогда database_transaction_log_bytes_used. PS: Эффективно удалять фрагментами можно либо на простой модели восстановления, периодически делая checkpoint, либо периодически делать бекап ЖТ. А тормоза, скорее всего, вызваны приращениями ЖТ. Если у таблицы только кластерный ПК по id, для показанного запроса статистика роли не играет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2019, 17:58 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
Гулин ФедорОсновная задача была сравнить удаление в кластерном и некластерном индексе ( columnstore всплыли позднее ) 1?) Как можно это сделать для некластерных Что нужно сделать? Провести эксперимент, или понять, что происходит на сервере? Эксприменты проводите сами, само собой, а что происходит, понять очень просто: - при удалении по диапазону ключей кластерного индекса сервер удалит диапазон расположенных рядом страниц БД (то есть цепочку расположенных рядом секторов с диска). Конечно, с учётом фрагментации, но на практике фрагментация не влияет. - при удалении по диапазону ключей из некластерного индекса сервер пройдёт циклом по диапазону записей в индексе, найдёт ссылки на страницы с данными, и записи (строки данных) в них, считает каждую найденную страницу, и удалит записи изнутри этой страницы. Вот, как то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2019, 11:38 |
|
||
|
Удаление большого куска записей в середине кластерного индекса
|
|||
|---|---|---|---|
|
#18+
по идее надо было некластерные индексы дропать. ониж все перестраиваются и там write amplification недетский. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2019, 12:03 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39789748&tid=1688072]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
130ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
75ms |
get tp. blocked users: |
3ms |
| others: | 237ms |
| total: | 490ms |

| 0 / 0 |
