alex-lsMinistrBobЧтобы быстрее вставлялось или хотя бы скорость не уменьшалась а оставалась на одном уровне.
так скорость значительно падает? или Вы пишите из-за 1-2%?
вставьте одним insert select, без разбиения на мелкие порции
ElicНе гонять через PL/SQL.
Смысл в PL\SQL и разбиении на маленькие порции в задаче.
Нужно перебросить таблицу размером 30Тб из одного ТП в другое, потому что уже максимум файлов в ТП - 1022 и больше его расширять не получиться.
На оборудовании заказчика такая операция оценочно идет 20-30 дней.
Поэтому нужен процесс переноса, который можно перезапускать многократно.
Пробовали alter table ... move и dbms_redefinition - не подходит в данном случае. Если эти процессы падают, а они падают это время и не один раз, а еще иногда просят остановить всё потому что тормозит всё сильно. Поэтому нужен полностью управляемый код, который можно править как хочешь.
andrey_anonymousПо деградации производительности: в Вашем случае, скорее всего, дело в запросе, которым гребет данные курсор.
Если он гребет данные из интенсивно обновляемой таблицы - то сценарий весьма вероятен.
Я бы снял 10046 level8 с процесса и локализовал проблему, но апологеты ash/awr, боюсь, сейчас забросают меня помидорами :)
По поводу трассировки хорошая идея, только заказчик не даёт доступ к серверу непосредственно, у меня есть только машина с Toad и учёткой пользователя sysdba, а вот sys у меня нет. Из Toad можно конечно запустить трассировку, но как потом получить файл, а самое главное его обработать, чего-то не хочеться в сыром трейсе копаться.
Запрос гребет из опорной таблицы в которой просто список ID переносимых строк, чтобы понимать что уже перенесено. После вставки порции 10000 этаже порция ID удаляется из этой таблицы, т.е. да она постоянно обновляется, насчёт интенсивно или нет - не знаю. А что тут можно сделать?
Последний замер показал что скорость не уменьшается линейно, она постоянно разная, просто она стала меньше чем в первый день в целом, поэтому показалось что она уменьшается. Во вложении график скорости процесса за вчера - пик был в 6 утра, спрошу у админа чего у них там такое происходит в это время.
Приведу ниже всю процедуру чтобы было понятно. Таких процедур выполняется 10 шт, т.е. 10 потоков, и в каждом потоке еще и вставка идет порциями по 10000 строк. Такая порция, при работающих пользователях, сейчас вставляется примерно за 30 минут.
ИЗ ИДЕЙ:
- Хочу попробовать одну процедуру (один поток) с +APPEND_VALUES и порциями побольше, 50-100тыс.строк.
Вот текст типовой процедуры (одна из 10).
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.
declare
TYPE ARRAY IS TABLE OF ela_document%ROWTYPE;
l_data ARRAY;
l_cnt NUMBER := 0;
l_obj BINARY_INTEGER;
l_log_rindex BINARY_INTEGER;
l_log_slno BINARY_INTEGER;
l_log_total NUMBER;
l_chunk_name VARCHAR2 (255);
l_cursor SYS_REFCURSOR;
t NUMBER;
BEGIN
insert into ora_move (text,cdate) values ('START PROG_MOVE_TABLE_10', sysdate);
OPEN l_cursor FOR
select d.* from ela_document d
where d.elado_document_id in (select id from ela_doc_chunks where chunk# = 10);
commit;
l_log_total := 7098807;
l_chunk_name := 'PROG_MOVE_TABLE_10';
SELECT o.object_id
INTO l_obj
FROM user_objects o
WHERE o.object_type = 'TABLE' AND o.object_name = 'ELA_DOCUMENT';
DBMS_APPLICATION_INFO.set_client_info ('Move_Table_Chunk');
l_log_rindex := DBMS_APPLICATION_INFO.set_session_longops_nohint;
DBMS_APPLICATION_INFO.set_session_longops (l_log_rindex, -- ид. строки в v$session_longops
l_log_slno, -- зарезервировано Oracle
l_chunk_name, -- имя длительной операции
l_obj, -- ид. обрабатываемого объекта
0, -- произвольное число, которое мы хотим публиковать
0, -- сколько уже сделано
l_log_total, -- сколько всего нужно сделать
'row', -- одна единица работы
'rows'); -- единицы работы (мн. число)
LOOP
BEGIN
--t := DBMS_UTILITY.get_time;
FETCH l_cursor BULK COLLECT INTO l_data LIMIT 10000;
--insert into ora_move (text,cdate, description) values ('FETCH PROG_MOVE_TABLE_10', sysdate, (DBMS_UTILITY.get_time - t)/100);
t := DBMS_UTILITY.get_time;
FORALL i IN 1 .. l_data.COUNT
INSERT /*+ APPEND */
INTO ela_document_copy
VALUES l_data (i);
insert into ora_move (text,cdate, description) values ('insert10->'||l_cnt, sysdate, (DBMS_UTILITY.get_time - t)/100);
--t := DBMS_UTILITY.get_time;
FORALL i IN 1..l_data.COUNT
DELETE FROM ela_doc_chunks WHERE ID = l_data(i).elado_document_id;
--insert into ora_move (text,cdate, description) values ('delete10->'||l_cnt, sysdate, (DBMS_UTILITY.get_time - t)/100);
commit;
l_cnt := l_cnt + 10000;
DBMS_APPLICATION_INFO.set_session_longops (l_log_rindex,
l_log_slno,
l_chunk_name,
l_obj,
0,
l_cnt,
l_log_total,
'row',
'rows');
exception when others then
insert into ora_move (text,cdate, description) values (DBMS_UTILITY.format_error_stack, sysdate, l_chunk_name||': '||l_cnt||' из '||l_log_total);
commit;
END;
EXIT WHEN l_cursor%NOTFOUND;
END LOOP;
commit;
CLOSE l_cursor;
insert into ora_move (text,cdate) values ('STOP PROG_MOVE_TABLE_10', sysdate);
END;
