|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
Всем доброго времени суток. Есть база с 2-мя пространствами имен (основное и архивное), расположенные на одном дисковом пространстве. Задача: перенести записи до определенного времени создания (дата присутствует в одной из таблиц) в архивное пространство в идентичную таблицу. (Oracle 12c) (в каждой таблице сотни миллиардов строк) Т.к. это будет работать на проде, вариант с переносом в новую таблицу только нужных записей не подходит, потому что данные будут обновляться в процессе работы. На текущий момент лучший найденный вариант: Код: plsql 1.
создаем темповую таблицу с id-шниками за какой нибудь период (~5 дней) (отдельной процедурой); Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
вычитываем данные в табличную переменную и для каждой таблицы в архиве через FORALL удаляем записи (если они там существуют) и записываем по новой; Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Другой процедурой удаляем данные из основного namespace-a по аналогии (оставляя этот кусок в рамках одной и той же процедуры время увеличивается до 2.5ч по не понятным причинам). Но скорость оставляет желать лучшего (10кк записей переноса в архив 43мин, удаление из оригинального namespace-а - 1ч 5мин). Есть ли способ как то еще ускорить сие удовольствие? (раньше, до обновления до 12c все это работало через курсор ооочень медленно и оооочень редко запускалось). Заранее спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2019, 19:40 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim, таблицы секционированы? данные будут обновляться в процессе работы - что конкретно это значит? может быть вставка в любую архивную дату? апдейт? удаление? что должно произойти при попытке вставить в дату, которую уже архивировали? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2019, 21:02 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim (в каждой таблице сотни миллиардов строк) я бы даже не пытался без партиций это мутить. без этого будет очень долго/очень нудно ябы сказал мучительно. для таблиц не архивных массовые удаления тоже не пользу. и даже если делать без партиций то плскл код скорости не добавить. только хардкор, только отдельные запросы (вставляем в архивную таблицу ОДНИМ запросом. удаляем из основной ОДНИМ запросом). для которых не забыть включить параллель и выключить генерацию редулогов. временная таблица с идешками мне представляется детским садом..... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2019, 21:19 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
кит северных морей lord2kim, таблицы секционированы? данные будут обновляться в процессе работы - что конкретно это значит? может быть вставка в любую архивную дату? апдейт? удаление? что должно произойти при попытке вставить в дату, которую уже архивировали? к сожалению не секционированы... конкретно с архивированной датой (из основного namespace-a) ничего не произойдет и в архивный namespace тоже не полезут, но в процессе архивации таблицы из основного namespace-a будут активно юзаться (INSERT/UPDATE) Надфиль lord2kim (в каждой таблице сотни миллиардов строк) я бы даже не пытался без партиций это мутить. без этого будет очень долго/очень нудно ябы сказал мучительно. для таблиц не архивных массовые удаления тоже не пользу. и даже если делать без партиций то плскл код скорости не добавить. только хардкор, только отдельные запросы (вставляем в архивную таблицу ОДНИМ запросом. удаляем из основной ОДНИМ запросом). для которых не забыть включить параллель и выключить генерацию редулогов. временная таблица с идешками мне представляется детским садом..... на текущий момент ничего быстрее FORALL по темповой таблицы с IDшниками не робит...((( пробовал удалять порциями, также на основе темповой таблицы, но получается дольше по времени ориентировочно на 1ч (без отключения индексов можно вообще не дождаться удаления 10кк записей) Кст...я так и не понял каким образом INVISIBLE индексы ускоряют DELETE/INSERT операции??? Не вижу логики...какую нибудь ссылку можно почитать про это? Код: plsql 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 07:02 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim конкретно с архивированной датой (из основного namespace-a) ничего не произойдет и в архивный namespace тоже не полезут, но в процессе архивации таблицы из основного namespace-a будут активно юзаться (INSERT/UPDATE) какой процент строк уйдет в архив, а какой останется (и будет подвержен select/update)? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 07:16 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
кит северных морей lord2kim конкретно с архивированной датой (из основного namespace-a) ничего не произойдет и в архивный namespace тоже не полезут, но в процессе архивации таблицы из основного namespace-a будут активно юзаться (INSERT/UPDATE) какой процент строк уйдет в архив, а какой останется (и будет подвержен select/update)? наименьший % останется (так эдак 30-40% от силы) но я не могу перенести все это дело в новую таблицу, построить индексы, а затем удалить оригинал и переименовать новую в оригинальную, т.к. INSERT/UPDATE идет 24/7 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 07:25 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim сотни миллиардов строк) lord2kim к сожалению не секционированы... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 07:38 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
Elic lord2kim сотни миллиардов строк) lord2kim к сожалению не секционированы... за неимением никого/ничего работаем с тем, что есть база полное г.... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 07:52 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim база полное г.... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 08:02 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
Про нюансы Оракла не знаю, честно, - но то, что этой 100% partitioning по функции и схеме - даже, мне кажется не обсуждается, особенно учитывая такой объем строк. Зачем изобретать невесть что, какую-то поделку, которую потом надо будет непонятно как сопровождать с болью и слезами, если это типичный паттерн горячих/теплых/холодных данных Холодные данные - в виде секций наверху и файловых групп/файлов внизу - так и хранятся на отдельных сетевых стораджах, дисках или даже датацентрах. Microsoft вообще, к примеру, предлагает делать эластичные БД, и хранить холодные данные в Azure ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 09:52 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
PsyMisha Про нюансы Оракла не знаю, честно, - но то, что этой 100% partitioning по функции и схеме - даже, мне кажется не обсуждается, особенно учитывая такой объем строк. Зачем изобретать невесть что, какую-то поделку, которую потом надо будет непонятно как сопровождать с болью и слезами, если это типичный паттерн горячих/теплых/холодных данных Холодные данные - в виде секций наверху и файловых групп/файлов внизу - так и хранятся на отдельных сетевых стораджах, дисках или даже датацентрах. Microsoft вообще, к примеру, предлагает делать эластичные БД, и хранить холодные данные в Azure Прошу учитывать что партиций нет, и создать их нет возможности. Суть не в том как кто-то советует делать, а что можно сделать в конкретной ситуации. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 10:17 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim а что можно сделать в конкретной ситуации. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 10:22 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim, Ну тогда, безусловно, только ручная переливка, - опций то мало Просто партишенинг - сделал бы тоже самое, но на более низком нативном уровне и эффективно, минимизируя кол-во потенциальных ошибок В MSSQL я бы для переливки использовал bcp.exe - имхо нет инструмента производительней в этом нашем мире, - про Оракл - не скажу, тут другие средства должны быть, по аналогии ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 10:24 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim и создать их нет возможности. Знаний, или технических возможностей? Просто трудно представить себе ситуацию, именно техническую, - при которой кто-либо был бы против еще нескольких файлов на дисках. Суммарный объем данных все равно останется то +- таким же, так что владельцы стораджа не пострадают (С) Конечно, есть еще и ситуация с доступностью, - так как требуется технологическое окно для реализации, ну и какое-то время, понятно, клиенты потеряют часть функционала работы с данными, либо вообще не смогут читать/писать всю базу. Но, с другой стороны, - и ручная переливка так же отрубит часть клиентов, так как перекачивать такое кол-во строк, безусловно, нужно только в монопольном режиме. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 10:28 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
Elic lord2kim а что можно сделать в конкретной ситуации. Предпочту потратить деньги на пиво =))) PsyMisha lord2kim и создать их нет возможности. Знаний, или технических возможностей? Просто трудно представить себе ситуацию, именно техническую, - при которой кто-либо был бы против еще нескольких файлов на дисках. Суммарный объем данных все равно останется то +- таким же, так что владельцы стораджа не пострадают (С) Конечно, есть еще и ситуация с доступностью, - так как требуется технологическое окно для реализации, ну и какое-то время, понятно, клиенты потеряют часть функционала работы с данными, либо вообще не смогут читать/писать всю базу. Но, с другой стороны, - и ручная переливка так же отрубит часть клиентов, так как перекачивать такое кол-во строк, безусловно, нужно только в монопольном режиме. да действительно, google теперь показал что в 12c Release 2 есть возможность разбить таблицу на партиции...очевидно это будет быстрее...другой вопрос в ребилде индексов...это может занять огромное кол-во времени на одной такой таблице будем пытаться...((( ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 11:27 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim, :) не надо грустных скобочек - делайте бекап-рестор базы в тестовое окружение - и ффпиред! (С) Или на задачу поставлены жёсткие сроки и дедлайны? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 11:33 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
PsyMisha lord2kim, :) не надо грустных скобочек - делайте бекап-рестор базы в тестовое окружение - и ффпиред! (С) Или на задачу поставлены жёсткие сроки и дедлайны? жестких требований нету вроде на проде backup делают постоянно на сколько мне известно тут еще суть в том, что проект построен так криво, что для проброса данных в шину постоянно мониторится БД...каждые n секунд дергаются вьюхи...тех.окна может не хватить на ребилд индексов...на сколько это будет критично? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 11:43 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim на текущий момент ничего быстрее FORALL по темповой таблицы с IDшниками не робит...((( позволю себе усомнится. ну или я сильно отстал от жизни. уверен, два запроса на вставку в одну таблицу и удаление из другой будут быстрей чем колупание каждой отдельной записи в плскл коде через промежуточные ИДешки. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 11:44 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim да действительно, google теперь показал что в 12c Release 2 есть возможность разбить таблицу на партиции...очевидно это будет быстрее...другой вопрос в ребилде индексов...это может занять огромное кол-во времени на одной такой таблице странно иметь таблицы с охулиардами записей и не слышать про партиции. не помню на счет 9 версии. в 10 100% партиции уже были. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 11:45 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
Надфиль lord2kim да действительно, google теперь показал что в 12c Release 2 есть возможность разбить таблицу на партиции...очевидно это будет быстрее...другой вопрос в ребилде индексов...это может занять огромное кол-во времени на одной такой таблице странно иметь таблицы с охулиардами записей и не слышать про партиции. не помню на счет 9 версии. в 10 100% партиции уже были. я на проекте не так давно, и судя по всему о них не слышали еще до меня (на 12c был переход буквально в этом году) PsyMisha , Надфиль в действительности таблиц с охулиардами записей более одной и в них отсутствуют констрэйны (primary key присутствует, но связей нет), IDшники контролируются самим софтом Возник вопрос можно ли в таком случае связать партиции по таблицам? Пример: есть основная таблица TABLE_MAIN с первичным ключом ID и датой записи, и есть куча других таблиц TABLE_1, TABLE_2, ... , TABLE_N в которых присутствуют IDшники из основной таблицы. Можно ли в этом случае связать партиции каким то образом? Разбивка по партициям TABLE_MAIN вполне понятна, а как разбить TABLE_1 зная IDшники записей из TABLE_MAIN PARTITION 1 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 12:00 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim, https://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/Partitioning/12c_parti.html ну начинать отсюда) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 12:05 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim, Ссылку выше не открывал, но на уровне формирования секций - ссылочные и ограничения домена - не важны. Главное - найти ключ секционирования - колонку таблицы, по которой будут нарезаться секции. Часто - это период - как раз ваш кейс - архивные данные. Могут нарезаться по ЮрЛицам, по локации и т.д. и т.п. Можно так же создать суррогатный ключ в таблице - например - естественную колонку DateDime этот искусственный ключ будет вычленять, скажем YearMonthPart - '2019/11/13 12:34' --> '201911' Это как раз подходит для транзакционных таблиц-фактов, и вот по этому виртуальному системному ключу и будут построены схема и функция секционирования. Функция - управляет смещением, Схема - связывает логику от функции с физической моделью БД - файловые группы и файлы. И вот, создаете секции на предшествующие года, - 201701, 201702,... 201911, 201912,... 204501, 204502 - опционально - делаете партицию по-умолчанию, куда сыпется все, что не определено границами функции - и вуаля - профит Дальше этими файловыми группами прозрачно для таблицы манипулируете, как хотите - перемещаете между стораджами, делаете ребилды индексов только по горячим партициям и т.д. и т.п. Так, по крайней мере, сделано в MSSQL. Полагаю, что Oracle - нечто похожее ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 12:40 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim, Я так понимаю - вы IDшниками оперируете еще? Можно и по диапазону IDшников нарезать секции, кстати. Границы - [1-9999], [10000-99999] и т.д ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 13:10 |
|
Архивирование и удаление миллиардов записей
|
|||
---|---|---|---|
#18+
lord2kim Разбивка по партициям TABLE_MAIN вполне понятна, а как разбить TABLE_1 зная IDшники записей из TABLE_MAIN PARTITION 1 ? а тут и не нужно никаких перекрестных ссылок между таблицами. Вы один раз делаете решение секционирования - далее - все таблицы - одна, две, сколько бы их там не было - строите на этом решении - то-есть - связываете таблицу с функцией/схемой и все - движок просто хранит данные в разбитом табличном виде и всю эту магию РСУБД берет на себя. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2019, 13:25 |
|
|
start [/forum/topic.php?fid=52&msg=39888283&tid=1881869]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
51ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 171ms |
0 / 0 |