Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Oracle [игнор отключен] [закрыт для гостей] / партицирование таблицы / 14 сообщений из 14, страница 1 из 1
12.05.2017, 12:12
    #39451995
xserge
xserge
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
Здравствуйте,
Мне необходимо повысить производительность работы с таблицей логов удаления записей.
В данный момент в таблице Delete_Log 46 млн. записей

Удаление и вставка записей в эту таблицу происходит, из триггеров Before Delete, которые созданы для многих таблиц системы.
С одной таблицей такая процедура работает более всего медленно ей соответствует 26 млн. записей в таблице Delete_Log (rpltable_id=34)
Пришел к выводу что нужно партицировать таблицу Delete_Log.

Подскажите пожалуйста по какому признаку лучше всего партицировать такую таблицу ?
Для эффективной работы SQL-DELETE этот признак необходим в фразе WHERE ?

Код: 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.
create table Delete_Log
    (Rpltable_Id                    number(18,0) not null,    -- ссылка на имя мастер таблицы , к которой относится запись лога
    Record_Id                      number(18,0) not null,     -- id записи лога
    Version                        number(18,0),              -- уникальное значение версии изменения записи
    Field1_Value                   number(18,0),              -- значения ключевых полей удаляемой записи мастер таблицы...
    Field2_Value                   number(18,0),
    Field3_Value                   number(18,0),
    Field4_Value                   number(18,0),
    Field5_Value                   number(18,0))
/

create index Uq_Delete_Log on Delete_Log
  (
    Rpltable_Id                     asc,
    Version                         asc
  )
/

create index Idx_Delete_Log_Version on Delete_Log
  (
    Version                         asc
  )
/

alter table Delete_Log
add constraint Pk_Delete_Log primary key (Rpltable_Id, Record_Id)
/

alter table Delete_Log
add constraint Fk_Delete_Log_Rpltable foreign key (Rpltable_Id)
references Rpltable (Id)
/
-- типовой триггер на удаление из таблицы EMPLOYEE
begin
  delete from delete_log where rpltable_id=34 and record_id=:old.id;
  insert into delete_log(rpltable_id, record_id, version, field1_value, field2_value, field3_value, field4_value)
    values(34, :old.id, generate_version(0), :old.DEP_ID, :old.EMP_ID, NULL, NULL);
end;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.05.2017, 12:45
    #39452038
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
А что в generate_version?
Пробежка по этой же таблице?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.05.2017, 12:58
    #39452056
xserge
xserge
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
Вячеслав Любомудров,

generate_version там всего лишь работа с sequences и с небольшой таблицей
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.05.2017, 14:12
    #39452129
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
Самое простое, конечно, сделать трассировку (лучше в нескольких параллельных сессиях) и посмотреть, где затык

Секционирование тебе вряд ли поможет
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.05.2017, 15:32
    #39452190
xserge
xserge
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
Вячеслав Любомудров,

а на что смотреть во время трассировки ?
Блокировок нет. Просто очень много данных и клиенты не довольны скоростью работы приложения.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.05.2017, 15:43
    #39452198
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
"во время" смотреть не надо
Надо смотреть результат

Например, ты увидишь, что вызывается много других (тобой явно не заказанных) операторов из твоей функции или других триггеров
Или таки действительно висит на блокировке
Или по параметрам ожиданий увидишь, что бОльшая часть прочитанных блоков из UNDO
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.05.2017, 16:17
    #39452222
xserge
xserge
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
>>Или по параметрам ожиданий увидишь, что бОльшая часть прочитанных блоков из UNDO
А на что похожа такая ситуация по логам ? как выглядят параметры ожиданий и какими они должны быть ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.05.2017, 16:46
    #39452237
env
env
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
xserge,

А какой глубокий смысл заложен в логику delete + insert и задлянафига тогда поле version?
Не проще сделать механизм отложенной очистки старых версий (вот тут как раз может и партиционирование пригодиться) или заменить insert на merge?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.05.2017, 17:34
    #39452264
j2k
j2k
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
Ммм, ну даже если там 46 лямов записей, там же выборка по уникальный ключу, через равенство. Отдельно
Код: plsql
1.
delete from delete_log where rpltable_id=34 and record_id=:old.id;

работает тоже медленно?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.05.2017, 17:45
    #39452276
env
env
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
j2k,

Перестраивается индекс для PK как минимум.
Кстати, а какой у него clustering factor относительно количества строк?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.05.2017, 00:31
    #39452437
ehcap
ehcap
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
В ASH бы посмотреть...
Думаю, что проблемы не в delete, а в insert. И причина (скорее всего) не в объеме в 40-50 млн.строк, а в числе сессий, одновременно выполняющих вставку.
И скорее всего при высококонкурентной вставке все "дерутся" за вставку в блок индекса Uq_Delete_Log или Idx_Delete_Log_Version.
Если увидим Index contention, значит надо либо разрежать индекс, либо hash-партиционировать его, а не таблицу.
А может ITL на индексе маленький и просто надо его увеличить с дефолтных 2 до 16 или 32...
Далее можно еще много разных причин придумать.

Необходимость индекса Idx_Delete_Log_Version вообще большие сомнения вызывает. Хотя, если поле version низкоселективное, то большого вреда обслуживание этого индекса при INSERT не вызовет. Но и пользы никакой не даст.

>> generate_version там всего лишь работа с sequences и с небольшой таблицей
Работа разной бывает. )) Что там поконкретнее? Может как раз все конкурируют как-то за сиквенс без cache или при обработке небольшой таблицы с банальным row lock contention.

Вообщем, без ash или трассировки - все это гадание и шаманство. Пилюли (лекарство) надо после диагностики выписывать, а не рассчитывать, что поможет также, как помогло соседу.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.05.2017, 09:18
    #39452472
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
xserge>>Или по параметрам ожиданий увидишь, что бОльшая часть прочитанных блоков из UNDO
А на что похожа такая ситуация по логам ? как выглядят параметры ожиданий и какими они должны быть ?В ожиданиях 'db file%read' первым параметром идет номер файла -- если большинство из них соответствуют UNDO TS, то приходится часто реконструировать CR-блоки, это значит, как правило, что блок горячий и за него идет конкуренция между сессиями.
Учитывая, что табличка у тебя узенькая, в одном блоке помещается много записей и когда сотня сессий изменила в ней сотню записей (и не зафиксировала к началу твоего удаления), то 101-ой придется применить сотню записей отмены, чтоб получить состояние на момент чтения
Варианты здесь -- секционировать табличку по хешу (чтоб размазать записи по нескольким блокам), ограничить количество записей в блоке (MINIMIZE RECORDS_PER_BLOCK) или перетащить ее в ТП с меньшим размером блока.
Но я сомневаюсь, что у тебя с этим проблемы, ты бы уже нарвался на ожидании блокировок или защелок на цепочку.

Опять же вопрос, зачем выполняется DELETE-INSERT, а не просто UPDATE. PK не меняется, поэтому и с индексом по нему никаких манипуляций производить не надо будет.

Опять же триггера у тебя (FOR EACH ROW) сделаны как BEFORE или AFTER? Первый вариант более ресурсоемкий и может быть вызван несколько раз для одной строки. Для логгирования лучше использовать AFTER

Свою функцию generate_version ты так и не показал и таки, возможно, держит именно она.

Ну и свои критерии не озвучил. Что значит "медленно", в каком окружении (конкуренция), при каких действиях (удаляется 1 строка, 100, 1000)?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.05.2017, 09:48
    #39452478
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
Вячеслав ЛюбомудровДля логгирования лучше использовать AFTERХотя, извиняюсь
Для удаления это, конечно, не подойдет
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.05.2017, 09:54
    #39452481
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
партицирование таблицы
Госпади
Хватит курить шторы (с) SY
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / партицирование таблицы / 14 сообщений из 14, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 583ms
Закрыть
start [/forum/topic.php?fid=52&mobile=1&tid=1885946]:
 0ms
get settings:
 9ms
get forum list:
 17ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 228ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 62ms
get tp. blocked users:
 1ms
others: 246ms
total:  583ms
x
x
Закрыть


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