Форум программистов, компьютерный форум, киберфорум
Наши страницы
Oracle
Войти
Регистрация
Восстановить пароль
 
Рейтинг 4.55/11: Рейтинг темы: голосов - 11, средняя оценка - 4.55
Gepar
1181 / 537 / 77
Регистрация: 01.07.2009
Сообщений: 3,517
#1

Очень медленный delete - всего 1000 записей в секунду

16.09.2014, 09:56. Просмотров 1927. Ответов 9
Метки нет (Все метки)

Есть таблицы a, b, c, d объёмом 100-500 млн каждая и с индексированным полем id и есть таблицы a_arch, b_arch, c_arch, d_arch.
Каждый день id записей которые нужно перенести в архив (опред. по некоторому алгоритму по одной из таблиц) помещаются в таблицу buffer пачками в 3000 записей после чего выполняются такие шаги:

Oracle 11 SQL
1
2
3
4
5
6
7
8
INSERT INTO x_arch
SELECT x.* 
FROM x
join buffer
ON x.id = buffer.id;
 
DELETE x
WHERE EXISTS (SELECT 1 FROM buffer WHERE buffer.id = x.id);
Я в значительной мере всё упростил и убрал логику, но основной смысл именно такой.
По обоим запросам план выполнения показывает использование индекса и небольшое количество операций чтения вот только результаты работы профайлера показывают что выполнение insert по всем таблицам суммарно заняло 3 секунды, а delete по каждой работал почти 30 секунд. Логи (обычный insert в таблицу для этих целей при выполнении каждой из операций) подтверждают это.
Одно удаление затрагивает примерно 25 000 записей. Куда копать? Я понимаю что индекс каждый раз перестраивается и что delete более дорогая операция чем insert, но это определённо что-то не то раз оно удаляет со скоростью ~ 1000 записей в секунду.

Добавлено через 11 часов 48 минут
Добавлю ко вчерашнему что лочки не возникают так как те записи что переносятся старые и их уже никто не читает и не изменяет, хотя по самой таблице очень активно шерстят. Учитывая что каждый delete выполняется приличный кусок времени то пока данные по всем таблицам будут перенесены я успеваю начать заглядывать в системные view, другой вопрос на что бросать подозрения и куда стоит посмотреть ?

Заказываю контрольные, курсовые, дипломные и любые другие студенческие работы здесь.

0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
16.09.2014, 09:56
Ответы с готовыми решениями:

Необходима база данных (500-1000 записей) для теста
Извини, админ, не уверен там ли создал тему... Мне нужно написать задание по...

Запись в базу данных MDB 1000 записей в секунду
Коллеги, добрый день! Я работаю с биржевыми данными. Мне нужно записывать...

Очень медленный QCryptographicHash
Хочу получить хешь файла по алгоритму SHA256. Делаю это используя...

Очень медленный интернет через WI-FI
Здравствуйте, очень нужна помощь. Ноутбук подключен к интернету через WI-FI...

Запрос По Справочнику Очень Медленный
Нужен запрос по 2-м спр-кам: головной "Товары" и подчиненный "Партии". На базе...

9
Grossmeister
Модератор
3359 / 2418 / 404
Регистрация: 21.01.2011
Сообщений: 10,650
16.09.2014, 10:26 #2
Начни с v$session_wait и v$session_event для соответствующей сессии.

Вообще, если ты озаботился оптимизацией, рекомендую почитать доку Performance Tuning Guide and Reference
1
Gepar
1181 / 537 / 77
Регистрация: 01.07.2009
Сообщений: 3,517
17.09.2014, 11:26  [ТС] #3
Цитата Сообщение от Grossmeister Посмотреть сообщение
Вообще, если ты озаботился оптимизацией, рекомендую почитать доку Performance Tuning Guide and Reference
Я не сколько озаботился оптимизацией, сколько задался вопросом почему у меня delete выполняеться экстремально долго, вот сейчас днём, в пик нагрузки, те ~25 000 удалялись вобще 3 минуты и я не вижу ничего подозрительногою. Toad показывает что да вот этот вот pid сейчас делает вот этот delete, блокировок нет, всё хорошо, ждите.

Добавлено через 17 часов 41 минуту
Посмотрел на действия в процессе delete: при удалении этих самых 25 000 идёт ожидание чтения многих файлов и многих строк индекса, вот тупо можно сидеть эти самые 3 минуты и обновлять состояние чтобы видеть как перескакивает с одного файла индекса на другой и тоже самое между строками.
В принципе я допускаю что удаляемая пачка представляет собой сильно разреженный набор id'шников которые создавались в разное время, а каждая запись достаточно большая сама по себе (есть blob поле) но тем не менее в процессе выполнения скрипта я ни разу не подловил момент чтобы увидеть в системных view как в текущий момент выполняется тот первый insert и спокойно успевал рассмотреть в подробностях как выполняется последующий delete с ценой 5 и это как-то не правильно, когда ты видишь как запрос с ценой 5 выполняется 3 минуты, когда до этого у тебя выполнялся запрос ценой 20 000 (перед этими запросами есть join по 3м таблицам по этим же индексам по id) за 10 секунд.
0
Grossmeister
Модератор
3359 / 2418 / 404
Регистрация: 21.01.2011
Сообщений: 10,650
17.09.2014, 12:15 #4
Цитата Сообщение от Gepar Посмотреть сообщение
это как-то не правильно
На самом деле эти "цены" - штука хитрая и не всегда запрос с меньшей ценой выполняется быстрее. Если очень хочется разобраться, почитай книжку Льюис. Основы стоимостной оптимизации
Ну и на sql.ru в FAQ есть материал по ошибкам оптимизатора.
1
Gepar
1181 / 537 / 77
Регистрация: 01.07.2009
Сообщений: 3,517
17.09.2014, 17:35  [ТС] #5
Цитата Сообщение от Grossmeister Посмотреть сообщение
На самом деле эти "цены" - штука хитрая и не всегда запрос с меньшей ценой выполняется быстрее.
Да я понимаю, но это бред какой-то.

--2 секунды
select x ....

--3 минуты
delete x
и при этом все 3 минуты показывает что читает индекс.
Цитата Сообщение от Grossmeister Посмотреть сообщение
Ну и на sql.ru в FAQ есть материал по ошибкам оптимизатора.
Да нет у меня ошибок оптимизатора, точнее он удаляет по индексу как и положено, не уверен могут ли у него быть другие ошибки. Я ещё в качестве эксперимента пробовал делать через for all чтобы сделать точечные удаления и закомитить их - результаты такие же.
У меня похоже случай когда надо какие-то настройки крутить либо происходит что-то странное что я упустил из виду ...

Я уже скопировал 1 млн данных на тестовый сервер, который слабее боевого в десятки раз, построил те же 5 индексов по таблице и сделал delete - он выполнился за 3 секунды. Отличия между тестовым и боевым только в том что боевой используеться сотнями процессов ну и в том что на боевом эта таблица больше в разы конечно же, но это не повод для замедления в 60 раз.

Сегодня попробую ещё получить трасировку, до этого не делал потому что у меня нет доступа к серверу чтобы забрать файл но похоже придёться искать тех кто сможет мне его предоставить.
0
Grossmeister
Модератор
3359 / 2418 / 404
Регистрация: 21.01.2011
Сообщений: 10,650
18.09.2014, 09:29 #6
Цитата Сообщение от Gepar Посмотреть сообщение
Да нет у меня ошибок оптимизатора, точнее он удаляет по индексу как и положено, не уверен могут ли у него быть другие ошибки.
Ошибки, в том числе, могут быть в определении стоимости
0
Gepar
1181 / 537 / 77
Регистрация: 01.07.2009
Сообщений: 3,517
18.09.2014, 11:23  [ТС] #7
Цитата Сообщение от Grossmeister Посмотреть сообщение
Ошибки, в том числе, могут быть в определении стоимости
Если я рядом делаю такой же select и он действительно столько стоит и отрабатывает за 3 секунды (и я уверен что большая часть этого времени тратиться на то что ide пережевывает данные так как она их выводит построчно сразу же как получила) то delete со всеми его обновлениями индексов (я так понимаю это в цену oracle не включает, по крайней мере строк idx rebuild я там точно не заметил) не может занимать в 60 раз больше даже с существенными промахами в плане плана выполнения. Особенно после того как я попробовал сделать delete where id = x в цикле и это заняло примерно только же времени.

Один из администраторов oracle подбросил идею что возможно не хватает ITL сегмента чтобы получить блокировки, но я не уверен в этом, точнее меня смущает то что я могу сделать так:
SQL
1
2
3
4
5
6
7
8
9
10
--3 секунды
SELECT x.* FROM x JOIN buf USING id;
 
--3.5 минуты
DELETE x WHERE EXISTS SELECT 1 FROM buf USING id;
 
ROLLBACK;
 
--3 секунды
DELETE x WHERE EXISTS SELECT 1 FROM buf USING id;
Если оракл действительно долго получает лочки то он бы и повторно стал бы их получать те же 3.5 минуты, разве нет? Ведь после rollback ему пришлось бы отпустить все блокировки, но в моём случае delete (по тем же id конечно же, по новым id опять будет 3.5 минуты) кешируется и повторный delete выполняется в считанные секунды.
0
Gepar
1181 / 537 / 77
Регистрация: 01.07.2009
Сообщений: 3,517
19.09.2014, 11:31  [ТС] #8
Мда, на тестовом я забыл почистить буфер и похоже он просто держал весь индекс в памяти, честный delete с чисткой кеша занял аж 40 секунд и потребовал 20 000 операций чтения, трассировка с боевого показала что там потребовалось 40 000 (индекс больше да и перестраивается не так часто) операций чтения, похоже что действительно упёрся в hdd, даже не знаю что и делать теперь
0
StalkerIQ
18 / 17 / 2
Регистрация: 21.05.2013
Сообщений: 356
02.10.2014, 06:15 #9
А удаление идёт одним запросом который в первом посте или у вас их несколько?
0
Gepar
1181 / 537 / 77
Регистрация: 01.07.2009
Сообщений: 3,517
02.10.2014, 10:11  [ТС] #10
Один запрос. Переписываю потихоньку пока что скрипты с расчётом на то что таблица будет партиционированная и удалять ничего не надо будет, осталось однозначно отсеять старые записи от новых, ато старые ведь теперь будут накапливаться до определённого момента.
0
02.10.2014, 10:11
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
02.10.2014, 10:11

Mac 7.1 ну о-о-очень медленный. Стоит ли апгрейдить?
Всех приветствую! Есть задумчивый iMac. Вот конфигурация: В Маках...

Две сетевухи и очень медленный интернет
На компе две сетевухи, одна провайдер вторая локалка. Интернет расшарен...

IPad 2 A1396 очень медленный заряд
Купил где то с полгода назад iPad 2, в Евросети, последний, с выставочного...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
10
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Рейтинг@Mail.ru