|
|
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
Есть не секционированная таблица в несколько десятков GB. Ежесуточно пополняется на несколько десятков млн. строк. Ежесуточно нужно удалять несколько десятков млн. строк (не обязательно тех, что были добавлены за эти сутки). Удаление происходит ночью в рамках одной транзакции по условию WHERE NUMBER_COLUMN = :A AND DATE_COLUMN < :B (индексы есть, если что). При этом происходит переполнение UNDO (очевидно, параллельно происходит более другая работа). Решено разбить одну транзакцию удаления на несколько. (секционирование пока не рассматривается в качестве решения) Задача состоит в том чтобы понять оптимальное количество записей, которые следует удалять при таком подходе. Возможно, есть более лучший способ? Подскажите, пожалуйста. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2016, 19:03:32 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
--Eugene--оптимальное количество записей10000 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2016, 19:39:28 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
--Eugene--, Оптимальное 12345. Я даже скрипт тебе подарю. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2016, 19:45:44 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
-2-, Почему именно 10000? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2016, 22:59:21 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
--Eugene--, попробуй ещё так и сравни быстродействие c другими способами Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2016, 23:06:07 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
--Eugene--, Тебе пытались намекнуть про бредовость постановки. Одно дело если б ты хоть мерил в блоках, поскольку 10000 строк это может быть 10000 блоков а может 50. И то безотносительно нагрузки и размера анду это сферическая оптимизация в вакууме. А так ты получишь разве что идиотские решения в духе "попробуй ещё так". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2016, 23:30:49 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
--Eugene--, в любом случае вместо loop для своих циклов delete используй forall только логику выборки под этот перечень продумай примеры можно найти здесь . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2016, 23:47:21 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
Fogel--Eugene--, в любом случае вместо loop для своих циклов delete используй forallты если сам не в состоянии прочиьать приводимые ссылки, то хотя бы обрати внимание с какой проблемой автор завел тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2016, 00:21:47 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopОдно дело если б ты хоть мерил в блоках, поскольку 10000 строк это может быть 10000 блоков а может 50. И то безотносительно нагрузки и размера анду это сферическая оптимизация в вакууме.Разве не понятно что размер UNDO известен, как и размер блока. Допустим, все строки таблицы примерно одной длины (в байтах). Таким образом, можно получить среднее отношение (кол-во строк / кол-во блоков). Прочая нагрузка на базу во время удаления неизвестна, это верно. Но возможно получить размер используемого/свободного пространства UNDO через системные вьюхи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2016, 03:16:27 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
объем транзакции удаления определяется опытным путем. делаем цикл на 1000 записей, смотрим на реакцию. делаем цикл на 10 000 записей - сморим на реакцию. на 5000. сравниваем. думаем. имхо. такое удаление ведет к разреживанию индексов и замедлению поиска по таблице. и место на диске ест. настоятельно рекомендую подумать в сторону партиционирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2016, 03:27:50 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
Fogel--Eugene--, попробуй ещё так и сравни быстродействие c другими способами Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Я не понял, это юмор такой несмешной? Или ты можешь объяснить какую роль здесь выполняет FORALL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2016, 06:21:11 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
Fogelв любом случае вместо loop для своих циклов delete используй forallУ тебя плохо получается выглядеть умным, каждый раз давая такие бредовые советы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2016, 07:36:25 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
--Eugene--Есть не секционированная таблица в несколько десятков GB. ,... При этом происходит переполнение UNDO (очевидно, параллельно происходит более другая работа)...... по нынешним временам сотня гигов - это тьфу просто попроси админов добавить неcколько десятков гигов в undo и не парься с оптимизацией а то здешние недогуру тебя с дерьмом смешают ниче полезного не скажут, но ты узнаешь много нового о своем уровне развития, о благонадежности и здравомыслии своих родственников до седьмого колена, ну и т.д. это форум оракл, детка!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2016, 11:11:24 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
казинакпо нынешним временам сотня гигов - это тьфу просто попроси админов добавить неcколько десятков гигов в undo простец ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2016, 11:36:32 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
--Eugene--Задача состоит в том чтобы понять оптимальное количество записей, которые следует удалять при таком подходе. Оптимальное количество - это, думаю, между 2 огней: 1) чтобы undo не переполнялся? 2) чтобы сервер слишком частыми коммитами не изнасиловать. То, что между этими крайностями, - оптимально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2016, 12:54:52 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
Nobody1111Оптимальное количество - это, думаю, между 2 огней: 1) чтобы undo не переполнялся? 2) чтобы сервер слишком частыми коммитами не изнасиловать. То, что между этими крайностями, - оптимально.в том-то и дело Этот диапазон не так уж мал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2016, 16:33:17 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
--Eugene--, Оптимальность определяется: - уложиться в ресурсы (undo); - время выполнения; - время на раздумья. Если бы послушался первого ответа, то решение было бы на сутки оптимальнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2016, 16:47:40 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
--Eugene--, совершенно согласен с много раз вышеозвученным мнением насчет ресурсов. ресурсы надо иметь, но ежели, например, работа-на-раз (быстро сделать и убежать ), то имейте ввиду метод деления поляны на известное количество статистически-равных частей например, substr например rowid, например, -1 Код: plsql 1. ну а вокруг этого можно накрутить например и (пещерный;)параллелизм раздачей значений для критериев хвоста сабстра по сессиям ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2016, 12:53:13 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
--Eugene--, > Задача состоит в том чтобы понять оптимальное количество записей, которые следует удалять при таком подходе. Оптимальное количество = <Сколько UNDO можно использовать> / <UNDO, требуемое на удаление одной записи> UNDO на удаление записи (в среднем) можно узнать из V$TRANSACTION.USED_UBLK > Возможно, есть более лучший способ? Оптимальный способ - не делать таких массовых удалений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2016, 18:01:03 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровFogel--Eugene--, попробуй ещё так и сравни быстродействие c другими способами Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Я не понял, это юмор такой несмешной? Или ты можешь объяснить какую роль здесь выполняет FORALL? это ум, бегущий впереди рук а что я имел ввиду, сейчас продемонстрирую. сегодня как раз потребовалось решить нечто подобное: дано: таблица без партиций, два индекса. Нужно удалить все записи с определённых файлов - данное поле без индекса Замер показал около 7,5 млн строк Код: plsql 1. 2. База - пром, в таблицу что-то льётся не каждую секунду, но раз в 5 минут или чаще. Оценил вообще размер бедствия по индексированному полю Код: plsql 1. 2. Кол-во больше (примерно на 0,5 млн), чем по условию имени файлов за то же время, это неправильно, кто-то за собой не чистит. Решил совместить приятное с полезным и вначале пройтись по индексу Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. / время очистки 498 с После этого запрос вернул 1,3 млн Код: plsql 1. 2. В скрипте исправил условие на неиндексируемое. Удаление заняло 148 с около года назад тоже нечто подобное делал на этой же таблице "опытные" товарищи тогда как раз предложили loop c пачками по 10 тыс и коммитом было около 15 млн строк - удалялось несколько часов, благо в джоб запихнул. Ах, да, забыл. Размер табличного пространства undo 2 gb После этого вспомнил про данную тему и решил посмотреть, что тут ещё насоветовали. Прочитал комментарии и решил поделиться. ElicУ тебя плохо получается выглядеть умным, каждый раз давая такие бредовые советы. зато хорошо получается троллить снобов, для которых набор знаний синоним ума. умные не троллятся, а делают выводы себе на пользу. ну или не делают, если им не интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2016, 13:37:23 |
|
||
|
Оптимальный способ очистки таблицы по критерию
|
|||
|---|---|---|---|
|
#18+
Fogel Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Эх, это уё$ище эквивалентно следующему коду: Код: plsql 1. 2. 3. 4. 5. 6. 7. А с учётом отсутствия фиксации - следующему: Код: plsql 1. Естественно, более короткая форма эффективнее (вплоть до гораздо) более длинной. Ты поменьше выпячивай свою альтернативную одарённость. Это выглядит как-то нездорово ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2016, 14:43:15 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39291632&tid=1887636]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 383ms |

| 0 / 0 |
