ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / партицирование таблицы
14 сообщений из 14, страница 1 из 1
партицирование таблицы
    #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:12
| Ответить | Цитировать | Написать  
партицирование таблицы
    #39452038
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
А что в generate_version?
Пробежка по этой же таблице?
...
Рейтинг: 0 / 0
12.05.2017, 12:45
| Ответить | Цитировать | Написать  
партицирование таблицы
    #39452056
xserge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
xserge
Гость
Вячеслав Любомудров,

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

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

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

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

А какой глубокий смысл заложен в логику delete + insert и задлянафига тогда поле version?
Не проще сделать механизм отложенной очистки старых версий (вот тут как раз может и партиционирование пригодиться) или заменить insert на merge?
...
Рейтинг: 0 / 0
12.05.2017, 16:46
| Ответить | Цитировать | Написать  
партицирование таблицы
    #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:34
| Ответить | Цитировать | Написать  
партицирование таблицы
    #39452276
Фотография env
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
env
Участник
j2k,

Перестраивается индекс для PK как минимум.
Кстати, а какой у него clustering factor относительно количества строк?
...
Рейтинг: 0 / 0
12.05.2017, 17:45
| Ответить | Цитировать | Написать  
партицирование таблицы
    #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, 00:31
| Ответить | Цитировать | Написать  
партицирование таблицы
    #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:18
| Ответить | Цитировать | Написать  
партицирование таблицы
    #39452478
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Вячеслав ЛюбомудровДля логгирования лучше использовать AFTERХотя, извиняюсь
Для удаления это, конечно, не подойдет
...
Рейтинг: 0 / 0
13.05.2017, 09:48
| Ответить | Цитировать | Написать  
партицирование таблицы
    #39452481
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Госпади
Хватит курить шторы (с) SY
...
Рейтинг: 0 / 0
13.05.2017, 09:54
| Ответить | Цитировать | Написать  
14 сообщений из 14, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / партицирование таблицы
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&fpage=163&tid=1885946]:
 0ms
get settings:
 7ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 46ms
get topic data:
 9ms
get forum data:
 3ms
get page messages:
 46ms
get tp. blocked users:
 1ms
others: 219ms
total:  352ms
созд. / загр.: 352ms
x
x
Закрыть


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