Гость
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Архивирование и удаление миллиардов записей / 24 сообщений из 24, страница 1 из 1
12.11.2019, 19:40
    #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
12.11.2019, 21:02
    #39888281
кит северных морей
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Архивирование и удаление миллиардов записей
lord2kim,

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

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

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

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

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

временная таблица с идешками мне представляется детским садом.....
...
Рейтинг: 0 / 0
13.11.2019, 07:02
    #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
13.11.2019, 07:16
    #39888360
кит северных морей
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Архивирование и удаление миллиардов записей
lord2kim
конкретно с архивированной датой (из основного namespace-a) ничего не произойдет и в архивный namespace тоже не полезут, но в процессе архивации таблицы из основного namespace-a будут активно юзаться (INSERT/UPDATE)

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

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


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


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

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

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


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

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

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

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

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


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

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

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

PsyMisha
lord2kim

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


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

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


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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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


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


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