powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Архивирование и удаление миллиардов записей
24 сообщений из 24, страница 1 из 1
Архивирование и удаление миллиардов записей
    #39888254
lord2kim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем доброго времени суток.

Есть база с 2-мя пространствами имен (основное и архивное), расположенные на одном дисковом пространстве.

Задача: перенести записи до определенного времени создания (дата присутствует в одной из таблиц) в архивное пространство в идентичную таблицу. (Oracle 12c) (в каждой таблице сотни миллиардов строк)

Т.к. это будет работать на проде, вариант с переносом в новую таблицу только нужных записей не подходит, потому что данные будут обновляться в процессе работы.

На текущий момент лучший найденный вариант:
Код: plsql
1.
CREATE TABLE MAIN_NAME_SPACE.TEMP AS SELECT ID FROM MAIN_NAME_SPACE.MAIN_TABLE


создаем темповую таблицу с id-шниками за какой нибудь период (~5 дней) (отдельной процедурой);
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
PROCEDURE ARCH AS
  table variable;
BEGIN

  SELECT ID INTO table FROM TEMP;

  FORALL i IN table
    DELETE ARCH_NAME_SPACE.TABLE_1 T WHERE T.ID = i;

  FORALL i IN table
    INSERT INTO ARCH_NAME_SPACE.TABLE_1 VALUES(SELECT * FROM MAIN_NAME_SPACE.TABLE_1 T WHERE T.ID = i);

...

  FORALL i IN table
    DELETE ARCH_NAME_SPACE.TABLE_N T WHERE T.ID = i;

  FORALL i IN table
    INSERT INTO ARCH_NAME_SPACE.TABLE_N VALUES(SELECT * FROM MAIN_NAME_SPACE.TABLE_N T WHERE T.ID = i);

END ARCH;


вычитываем данные в табличную переменную и для каждой таблицы в архиве через FORALL удаляем записи (если они там существуют) и записываем по новой;
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
PROCEDURE DELETE AS
  table variable;
BEGIN

  SELECT ID INTO table FROM TEMP;

  FORALL i IN table
    DELETE MAIN_NAME_SPACE.TABLE_1 T WHERE T.ID = i;

...

  FORALL i IN table
    DELETE MAIN_NAME_SPACE.TABLE_N T WHERE T.ID = i;

END ARCH;


Другой процедурой удаляем данные из основного namespace-a по аналогии (оставляя этот кусок в рамках одной и той же процедуры время увеличивается до 2.5ч по не понятным причинам).

Но скорость оставляет желать лучшего (10кк записей переноса в архив 43мин, удаление из оригинального namespace-а - 1ч 5мин).

Есть ли способ как то еще ускорить сие удовольствие? (раньше, до обновления до 12c все это работало через курсор ооочень медленно и оооочень редко запускалось).

Заранее спасибо.
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888281
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim,

таблицы секционированы?

данные будут обновляться в процессе работы - что конкретно это значит? может быть вставка в любую архивную дату? апдейт? удаление? что должно произойти при попытке вставить в дату, которую уже архивировали?
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888283
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
lord2kim
(в каждой таблице сотни миллиардов строк)

я бы даже не пытался без партиций это мутить.

без этого будет очень долго/очень нудно ябы сказал мучительно. для таблиц не архивных массовые удаления тоже не пользу.

и даже если делать без партиций то плскл код скорости не добавить.
только хардкор, только отдельные запросы (вставляем в архивную таблицу ОДНИМ запросом. удаляем из основной ОДНИМ запросом). для которых не забыть включить параллель и выключить генерацию редулогов.

временная таблица с идешками мне представляется детским садом.....
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888357
lord2kim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
кит северных морей
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.
  PROCEDURE DELETE_PROC AS
    minID NUMBER := 1;
    maxID NUMBER := 50000;
    step NUMBER := 50000;
    cnt NUMBER;

    str VARCHAR2(2048);

    TYPE doc_indexes IS TABLE OF VARCHAR2(1024) INDEX BY BINARY_INTEGER;
    index_tbl doc_indexes;
  BEGIN

    -- кол-во записей
    str := 'SELECT COUNT(*) FROM VERY_TEMP_TABLE VTT';
    EXECUTE IMMEDIATE str INTO cnt;
    
    -- считываем индексы
    str := 'SELECT UI.INDEX_NAME FROM USER_INDEXES UI WHERE ui.table_name IN (''TABLE_1'', ''TABLE_2'', ...)
AND UI.INDEX_NAME NOT LIKE ''SYS_%''';
    EXECUTE IMMEDIATE str BULK COLLECT INTO index_tbl;

    str := 'BEGIN ';

    -- выключаем индксы
    FOR i IN 1..index_tbl.COUNT
    LOOP

      -- отключаем индексы
      str := str || 'EXECUTE IMMEDIATE ''ALTER INDEX ' || index_tbl(i) || ' INVISIBLE''; ';

    END LOOP;

    str := str || ' END;';
    EXECUTE IMMEDIATE str;

    WHILE (maxID < cnt)
    LOOP

      -- удаляем
      str := 'BEGIN EXECUTE IMMEDIATE ''alter session enable parallel dml''; ';
      str := str || ' DELETE /*+ parallel(T,12) */ TABLE_1 T WHERE T.PRIMARY_FIELD IN
(SELECT TT.ID FROM TEMP_TABLE TT WHERE ROWNUM BETWEEN ' || minID || ' AND ' || maxID || ');
DELETE /*+ parallel(T,12) */ TABLE_2 T WHERE T.PRIMARY_FIELD IN (); ... END;';
      EXECUTE IMMEDIATE str;

      minID := minID + step;
      maxID := maxID + step;

    END LOOP;
    
    str := 'BEGIN ';

    -- включаем индексы
    FOR i IN 1..index_tbl.COUNT
    LOOP

      str := str || 'EXECUTE IMMEDIATE ''ALTER INDEX ' || index_tbl(i) || ' VISIBLE''; ';

    END LOOP;

    str := str || ' END;';
    EXECUTE IMMEDIATE str;
  
  END DELETE_PROC;
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888360
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim
конкретно с архивированной датой (из основного namespace-a) ничего не произойдет и в архивный namespace тоже не полезут, но в процессе архивации таблицы из основного namespace-a будут активно юзаться (INSERT/UPDATE)

какой процент строк уйдет в архив, а какой останется (и будет подвержен select/update)?
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888361
lord2kim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
кит северных морей
lord2kim
конкретно с архивированной датой (из основного namespace-a) ничего не произойдет и в архивный namespace тоже не полезут, но в процессе архивации таблицы из основного namespace-a будут активно юзаться (INSERT/UPDATE)

какой процент строк уйдет в архив, а какой останется (и будет подвержен select/update)?


наименьший % останется (так эдак 30-40% от силы)
но я не могу перенести все это дело в новую таблицу, построить индексы, а затем удалить оригинал и переименовать новую в оригинальную, т.к. INSERT/UPDATE идет 24/7
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888368
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim
сотни миллиардов строк)
lord2kim
к сожалению не секционированы...
У бизнеса есть безответсвенное лицо, неспособное вздрючить архи-не-тектора за подобный бардак?
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888375
lord2kim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Elic
lord2kim
сотни миллиардов строк)
lord2kim
к сожалению не секционированы...
У бизнеса есть безответсвенное лицо, неспособное вздрючить архи-не-тектора за подобный бардак?


за неимением никого/ничего работаем с тем, что есть
база полное г....
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888380
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim
база полное г....
Если к Г добавить "автоматизацию", то она в нём всё равно растворится и останется то же Г.
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888435
Фотография PsyMisha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Про нюансы Оракла не знаю, честно, - но то, что этой 100% partitioning по функции и схеме - даже, мне кажется не обсуждается, особенно учитывая такой объем строк.
Зачем изобретать невесть что, какую-то поделку, которую потом надо будет непонятно как сопровождать с болью и слезами, если это типичный паттерн горячих/теплых/холодных данных

Холодные данные - в виде секций наверху и файловых групп/файлов внизу - так и хранятся на отдельных сетевых стораджах, дисках или даже датацентрах.
Microsoft вообще, к примеру, предлагает делать эластичные БД, и хранить холодные данные в Azure
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888448
lord2kim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PsyMisha
Про нюансы Оракла не знаю, честно, - но то, что этой 100% partitioning по функции и схеме - даже, мне кажется не обсуждается, особенно учитывая такой объем строк.
Зачем изобретать невесть что, какую-то поделку, которую потом надо будет непонятно как сопровождать с болью и слезами, если это типичный паттерн горячих/теплых/холодных данных

Холодные данные - в виде секций наверху и файловых групп/файлов внизу - так и хранятся на отдельных сетевых стораджах, дисках или даже датацентрах.
Microsoft вообще, к примеру, предлагает делать эластичные БД, и хранить холодные данные в Azure


Прошу учитывать что партиций нет, и создать их нет возможности.
Суть не в том как кто-то советует делать, а что можно сделать в конкретной ситуации.
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888450
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim
а что можно сделать в конкретной ситуации.
Идти в магазин, менять деньги на мыло с верёвкой... Потому что поздно уже пить боржоми
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888452
Фотография PsyMisha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim,

Ну тогда, безусловно, только ручная переливка, - опций то мало

Просто партишенинг - сделал бы тоже самое, но на более низком нативном уровне и эффективно, минимизируя кол-во потенциальных ошибок

В MSSQL я бы для переливки использовал bcp.exe - имхо нет инструмента производительней в этом нашем мире, - про Оракл - не скажу, тут другие средства должны быть, по аналогии
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888454
Фотография PsyMisha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim

и создать их нет возможности.


Знаний, или технических возможностей? Просто трудно представить себе ситуацию, именно техническую, - при которой кто-либо был бы против еще нескольких файлов на дисках. Суммарный объем данных все равно останется то +- таким же, так что владельцы стораджа не пострадают (С)

Конечно, есть еще и ситуация с доступностью, - так как требуется технологическое окно для реализации, ну и какое-то время, понятно, клиенты потеряют часть функционала работы с данными, либо вообще не смогут читать/писать всю базу.
Но, с другой стороны, - и ручная переливка так же отрубит часть клиентов, так как перекачивать такое кол-во строк, безусловно, нужно только в монопольном режиме.
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888491
lord2kim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Elic
lord2kim
а что можно сделать в конкретной ситуации.
Идти в магазин, менять деньги на мыло с верёвкой... Потому что поздно уже пить боржоми

Предпочту потратить деньги на пиво =)))

PsyMisha
lord2kim

и создать их нет возможности.


Знаний, или технических возможностей? Просто трудно представить себе ситуацию, именно техническую, - при которой кто-либо был бы против еще нескольких файлов на дисках. Суммарный объем данных все равно останется то +- таким же, так что владельцы стораджа не пострадают (С)

Конечно, есть еще и ситуация с доступностью, - так как требуется технологическое окно для реализации, ну и какое-то время, понятно, клиенты потеряют часть функционала работы с данными, либо вообще не смогут читать/писать всю базу.
Но, с другой стороны, - и ручная переливка так же отрубит часть клиентов, так как перекачивать такое кол-во строк, безусловно, нужно только в монопольном режиме.


да действительно, google теперь показал что в 12c Release 2 есть возможность разбить таблицу на партиции...очевидно это будет быстрее...другой вопрос в ребилде индексов...это может занять огромное кол-во времени на одной такой таблице

будем пытаться...(((
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888500
Фотография PsyMisha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim,

:) не надо грустных скобочек - делайте бекап-рестор базы в тестовое окружение - и ффпиред! (С)

Или на задачу поставлены жёсткие сроки и дедлайны?
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888508
lord2kim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PsyMisha
lord2kim,

:) не надо грустных скобочек - делайте бекап-рестор базы в тестовое окружение - и ффпиред! (С)

Или на задачу поставлены жёсткие сроки и дедлайны?


жестких требований нету вроде
на проде backup делают постоянно на сколько мне известно

тут еще суть в том, что проект построен так криво, что для проброса данных в шину постоянно мониторится БД...каждые n секунд дергаются вьюхи...тех.окна может не хватить на ребилд индексов...на сколько это будет критично?
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888510
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
lord2kim

на текущий момент ничего быстрее FORALL по темповой таблицы с IDшниками не робит...(((

позволю себе усомнится.
ну или я сильно отстал от жизни.
уверен, два запроса на вставку в одну таблицу и удаление из другой будут быстрей чем колупание каждой отдельной записи в плскл коде через промежуточные ИДешки.
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888512
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
lord2kim


да действительно, google теперь показал что в 12c Release 2 есть возможность разбить таблицу на партиции...очевидно это будет быстрее...другой вопрос в ребилде индексов...это может занять огромное кол-во времени на одной такой таблице

странно иметь таблицы с охулиардами записей и не слышать про партиции.
не помню на счет 9 версии. в 10 100% партиции уже были.
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888528
lord2kim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Надфиль
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 ?
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888530
Надфиль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888557
Фотография PsyMisha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim,

Ссылку выше не открывал, но на уровне формирования секций - ссылочные и ограничения домена - не важны.
Главное - найти ключ секционирования - колонку таблицы, по которой будут нарезаться секции.
Часто - это период - как раз ваш кейс - архивные данные. Могут нарезаться по ЮрЛицам, по локации и т.д. и т.п.
Можно так же создать суррогатный ключ в таблице - например - естественную колонку DateDime этот искусственный ключ будет вычленять, скажем YearMonthPart - '2019/11/13 12:34' --> '201911'
Это как раз подходит для транзакционных таблиц-фактов, и вот по этому виртуальному системному ключу и будут построены схема и функция секционирования. Функция - управляет смещением, Схема - связывает логику от функции с физической моделью БД - файловые группы и файлы.
И вот, создаете секции на предшествующие года, - 201701, 201702,... 201911, 201912,... 204501, 204502 - опционально - делаете партицию по-умолчанию, куда сыпется все, что не определено границами функции - и вуаля - профит
Дальше этими файловыми группами прозрачно для таблицы манипулируете, как хотите - перемещаете между стораджами, делаете ребилды индексов только по горячим партициям и т.д. и т.п.

Так, по крайней мере, сделано в MSSQL. Полагаю, что Oracle - нечто похожее
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888571
Фотография PsyMisha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim,

Я так понимаю - вы IDшниками оперируете еще?
Можно и по диапазону IDшников нарезать секции, кстати. Границы - [1-9999], [10000-99999] и т.д
...
Рейтинг: 0 / 0
Архивирование и удаление миллиардов записей
    #39888582
Фотография PsyMisha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lord2kim

Разбивка по партициям TABLE_MAIN вполне понятна, а как разбить TABLE_1 зная IDшники записей из TABLE_MAIN PARTITION 1 ?


а тут и не нужно никаких перекрестных ссылок между таблицами.
Вы один раз делаете решение секционирования - далее - все таблицы - одна, две, сколько бы их там не было - строите на этом решении - то-есть - связываете таблицу с функцией/схемой и все - движок просто хранит данные в разбитом табличном виде и всю эту магию РСУБД берет на себя.
...
Рейтинг: 0 / 0
24 сообщений из 24, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Архивирование и удаление миллиардов записей
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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