FoxClub Forums > Не фоксом единым > Оптимизация в Оракл ::

• Войти

Оптимизация в Оракл
boba Сообщений: 6269 Откуда: Медвежьи озера- Дата регистрации: 26.03.2001	boba 22.12.21 08:03:19 Есть некая таблица и способ ее пополнения в пакете процедуры. Сначала delete from table Потом Inser. Процедура запускается в цикле где-то 7000 раз Параметр процедуры parorder и тип поля по которому идет стирание -char Недавно увеличили размер этого поля. В процедуре было delete from table norder= parorder Переписали delete from table trim(norder)= trim(parorder) В одном из индексов таблицы через запятую есть trim(norder) Время работы процедуры с 4 минут выросло до 8 часов. Статистика собиралась на днях.

boba

Сообщений: 6269
Откуда: Медвежьи озера-
Дата регистрации: 26.03.2001

boba

22.12.21 08:03:19

Есть некая таблица и способ ее пополнения
в пакете процедуры. Сначала delete from table
Потом Inser. Процедура запускается в цикле где-то 7000 раз
Параметр процедуры parorder и тип поля по которому
идет стирание -char
Недавно увеличили размер этого поля.
В процедуре было delete from table norder= parorder
Переписали delete from table trim(norder)= trim(parorder)
В одном из индексов таблицы через запятую есть trim(norder)
Время работы процедуры с 4 минут выросло до 8 часов.
Статистика собиралась на днях.

Re: Оптимизация в Оракл
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004	PaulWist 22.12.21 08:17:12 boba Есть некая таблица и способ ее пополнения в пакете процедуры. Сначала delete from table Потом Inser. Процедура запускается в цикле где-то 7000 раз Параметр процедуры parorder и тип поля по которому идет стирание -char Недавно увеличили размер этого поля. В процедуре было delete from table norder= parorder Переписали delete from table trim(norder)= trim(parorder) В одном из индексов таблицы через запятую есть trim(norder) Время работы процедуры с 4 минут выросло до 8 часов. Статистика собиралась на днях. 1. План в студию. 2. Пальцем в небо, с вероятностью 99%, скорее всего индекс с trim(norder) выглядит примерно так create index idx on Table (F1, f2, trim(norder), f3) 2.1. Если табличка большая и часто изменяемая и на HDD-дисках, то смотреть на дефрагментацию индекса. 2.2. Смотреть на кардинальность индекса. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет)

Re: Оптимизация в Оракл

PaulWist

Сообщений: 14625
Дата регистрации: 01.04.2004

PaulWist

22.12.21 08:17:12

boba
Есть некая таблица и способ ее пополнения
в пакете процедуры. Сначала delete from table
Потом Inser. Процедура запускается в цикле где-то 7000 раз
Параметр процедуры parorder и тип поля по которому
идет стирание -char
Недавно увеличили размер этого поля.
В процедуре было delete from table norder= parorder
Переписали delete from table trim(norder)= trim(parorder)
В одном из индексов таблицы через запятую есть trim(norder)
Время работы процедуры с 4 минут выросло до 8 часов.
Статистика собиралась на днях.

1. План в студию.

2. Пальцем в небо, с вероятностью 99%, скорее всего индекс с trim(norder) выглядит примерно так


create index idx on Table (F1, f2,  trim(norder), f3)

2.1. Если табличка большая и часто изменяемая и на HDD-дисках, то смотреть на дефрагментацию индекса.
2.2. Смотреть на кардинальность индекса.

------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)

Re: Оптимизация в Оракл
boba Сообщений: 6269 Откуда: Медвежьи озера- Дата регистрации: 26.03.2001	boba 22.12.21 09:49:01 Да, в индексе , где trim еще пара полей. План, конечно смотрели, индексскан там не оказалось

Re: Оптимизация в Оракл
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004	PaulWist 22.12.21 10:07:33 Володь, определение индекса приведи. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет)

Re: Оптимизация в Оракл
boba Сообщений: 6269 Откуда: Медвежьи озера- Дата регистрации: 26.03.2001	boba 22.12.21 10:38:36 Да, я сегодня дома работаю, удаленки нет. На мой Оракл домой это не притащишь. У нас главный Ораклист ушел в ФОРС работать. Все остальные делают вид, что задача полностью моя, что есть бред. Там только один пакет , который я написал от и до сам. Все остальное до сотни пакетов, о содержании большей части я и понятия никакого не имею. Всучили в свое время этот монстр фирме сверху насильно, угробили наши работающие модули, якобы у них все есть, что нужно для отчетности. Некоторые отчеты работали от 40 и больше минут. Я эту часть полностью переписал, сейчас все отчеты укладываются в пару тройку минут даже за срок в один год. А кусок, о котором речь, некий импорт нужных для аналитик из другого сервера Оракл. Я там и близко не стоял.

Re: Оптимизация в Оракл

boba

Сообщений: 6269
Откуда: Медвежьи озера-
Дата регистрации: 26.03.2001

boba

22.12.21 10:38:36

Да, я сегодня дома работаю, удаленки нет.
На мой Оракл домой это не притащишь.
У нас главный Ораклист ушел в ФОРС работать.
Все остальные делают вид, что задача полностью моя,
что есть бред. Там только один пакет ,
который я написал от и до сам. Все остальное до сотни пакетов,
о содержании большей части я и понятия никакого не имею.
Всучили в свое время этот монстр фирме сверху насильно,
угробили наши работающие модули, якобы у них все есть,
что нужно для отчетности. Некоторые отчеты работали от 40 и больше минут.
Я эту часть полностью переписал,
сейчас все отчеты укладываются в пару тройку минут даже за срок в один год.
А кусок, о котором речь, некий импорт нужных для аналитик из другого
сервера Оракл. Я там и близко не стоял.

Re: Оптимизация в Оракл
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004	PaulWist 22.12.21 10:42:07 Ну блиииин, ... я всё понял про твою "тяжёлую" жизнь сам могу такое же рассказать. Ну пусть вышлют DDL индекса и таблички, а то по фотографии могу ошибиться ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 22.12.21 10:42

Re: Оптимизация в Оракл

PaulWist

Сообщений: 14625
Дата регистрации: 01.04.2004

PaulWist

22.12.21 10:42:07

Ну блиииин, ... я всё понял про твою "тяжёлую" жизнь

сам могу такое же рассказать.

Ну пусть вышлют DDL индекса и таблички, а то по фотографии могу ошибиться

------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)

Исправлено 1 раз(а). Последнее : PaulWist, 22.12.21 10:42

Re: Оптимизация в Оракл
boba Сообщений: 6269 Откуда: Медвежьи озера- Дата регистрации: 26.03.2001	boba 22.12.21 11:58:26 в пятницу скажу вечером. Открытая почта запрещена. Жизнь не тяжелая, самая рядовая обычного программиста От большинства других в конторе отличается только тем, что на большинстве висит не более двух тем. На мне полтора десятка абсолютно друг с другом не связанных. И старые программы на фоксе от ушедших людей, и своих 5-6 проектов, и три разных Оракл. В принципе, для знающего человека это не тяжело. Мешает банальный русский бардак. Кроме тройки людей никто толком не знает, что и где, про документацию молчу, она местами есть, но часто не такая как нужна. Можно ли хорошо понимать упомянутый проект, да можно Нужно бы сидеть с разработчиками пока они тут были. Сидеть максимум в двух проектах Оракл хотя бы без дневнефоксовых Раньше был один постановщик, ушли его. Все похоже на сплав по реке на подручных средствах с надеждой на русское авось вынесет.

Re: Оптимизация в Оракл

boba

Сообщений: 6269
Откуда: Медвежьи озера-
Дата регистрации: 26.03.2001

boba

22.12.21 11:58:26

в пятницу скажу вечером. Открытая почта запрещена.
Жизнь не тяжелая,
самая рядовая обычного программиста
От большинства других в конторе отличается только тем, что на большинстве
висит не более двух тем. На мне полтора десятка абсолютно
друг с другом не связанных. И старые программы на фоксе от ушедших людей,
и своих 5-6 проектов, и три разных Оракл.
В принципе, для знающего человека это не тяжело.
Мешает банальный русский бардак. Кроме тройки людей
никто толком не знает, что и где, про документацию молчу,
она местами есть, но часто не такая как нужна.
Можно ли хорошо понимать упомянутый проект, да можно
Нужно бы сидеть с разработчиками пока они тут были.
Сидеть максимум в двух проектах Оракл хотя бы без дневнефоксовых
Раньше был один постановщик, ушли его.
Все похоже на сплав по реке на подручных средствах с надеждой на русское авось
вынесет.

Re: Оптимизация в Оракл
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 22.12.21 18:44:56 boba Да, в индексе , где trim еще пара полей. План, конечно смотрели, индексскан там не оказалось Для того чтобы индекс использовался для доступа к таблице, в выражении WHERE должны наличествовать ведущие поля (или выражения) этого индекса. Т.е. для сферического create index idx on Table (F1, f2, trim(norder), f3) В условиях должно быть указано F1 = ... AND F2 = ... AND trim(norder) = ... Если в условии есть только trim(norder) = ... то для использования индекса это выражение должно быть первым. Т.е. create index idx on Table (trim(norder), F1, f2, f3) ------------------ WBR, Igor

Re: Оптимизация в Оракл

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

22.12.21 18:44:56

boba
Да, в индексе , где trim
еще пара полей. План, конечно смотрели,
индексскан там не оказалось

Для того чтобы индекс использовался для доступа к таблице, в выражении WHERE должны наличествовать ведущие поля (или выражения) этого индекса.
Т.е. для сферического


create index idx on Table (F1, f2,  trim(norder), f3)

В условиях должно быть указано


F1 = ... AND F2 = ... AND trim(norder) = ...

Если в условии есть только trim(norder) = ... то для использования индекса это выражение должно быть первым. Т.е.


create index idx on Table (trim(norder), F1, f2, f3)

------------------
WBR, Igor

Re: Оптимизация в Оракл
boba Сообщений: 6269 Откуда: Медвежьи озера- Дата регистрации: 26.03.2001	boba 22.12.21 19:45:12 Игорь, все верно. Выражение с trim ставили на первое место, встала другая процедура. Тут как матрешка, одно место тронешь, рухнет другое. Толкового паспорта нет

Re: Оптимизация в Оракл
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004	PaulWist 22.12.21 19:56:15 Ну так создай ещё один индекс, в чём проблема. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет)

Re: Оптимизация в Оракл
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 23.12.21 18:49:47 Обычно проблема возникает в поддержании большого количества индексов и накладных расходах на них. Любой дополнительный индекс, это прибавка ко времени операций модификации данных, и к занимаемому БД объёму (и "на диске", и "в памяти"). Поэтому не создают индексы на все возможные комбинации полей, а стараются выяснить наиболее важные/приоритетные сценарии доступа к данным, и оптимизировать только их. Т.е. индексы нужны там где они действительно сильно нужны А то ускорив "месячный отчёт" можно получить неприемлемое замеделние для "текущих операций". Вообще немного странно что разные части ПО на столько по разному осуществляют доступ к этой таблице. Надо выяснять все "критерии поиска" во всех местах, возможно где-то что-то переделать (ну, к примеру, возможно что в этой процедуре вполне можно добавить в условия выражения по полям f1, f2 - или наоборот - в других местах можно добавить условия по этому новоиспечённому trim(norder)). И по итогу уже решают какие именно индексы создавать. Впрочем, само по себе использование char поля с trim() в индексе и в выражениях выглядит несколько странно. Для этих целей (строки разного размера, без ненужных пробелов) предназначен тип varchar. ------------------ WBR, Igor

Re: Оптимизация в Оракл

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

23.12.21 18:49:47

Обычно проблема возникает в поддержании большого количества индексов и накладных расходах на них. Любой дополнительный индекс, это прибавка ко времени операций модификации данных, и к занимаемому БД объёму (и "на диске", и "в памяти").
Поэтому не создают индексы на все возможные комбинации полей, а стараются выяснить наиболее важные/приоритетные сценарии доступа к данным, и оптимизировать только их. Т.е. индексы нужны там где они действительно сильно нужны

А то ускорив "месячный отчёт" можно получить неприемлемое замеделние для "текущих операций".

Вообще немного странно что разные части ПО на столько по разному осуществляют доступ к этой таблице. Надо выяснять все "критерии поиска" во всех местах, возможно где-то что-то переделать (ну, к примеру, возможно что в этой процедуре вполне можно добавить в условия выражения по полям f1, f2 - или наоборот - в других местах можно добавить условия по этому новоиспечённому trim(norder)). И по итогу уже решают какие именно индексы создавать.

Впрочем, само по себе использование char поля с trim() в индексе и в выражениях выглядит несколько странно. Для этих целей (строки разного размера, без ненужных пробелов) предназначен тип varchar.

------------------
WBR, Igor

Re: Оптимизация в Оракл
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004	PaulWist 23.12.21 20:17:38 Igor Korolyov Обычно проблема возникает в поддержании большого количества индексов и накладных расходах на них. Любой дополнительный индекс, это прибавка ко времени операций модификации данных, и к занимаемому БД объёму (и "на диске", и "в памяти"). Поэтому не создают индексы на все возможные комбинации полей, а стараются выяснить наиболее важные/приоритетные сценарии доступа к данным, и оптимизировать только их. Т.е. индексы нужны там где они действительно сильно нужны А то ускорив "месячный отчёт" можно получить неприемлемое замеделние для "текущих операций". 1. Пока не знаем сколько там индексов, в пятницу Вова обещал рассказать. 2. Похоже навесили Delete триггер/каскадное удаление, 8 часов после 4 мин вообще никуда не годится. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 23.12.21 20:18

Re: Оптимизация в Оракл

PaulWist

Сообщений: 14625
Дата регистрации: 01.04.2004

PaulWist

23.12.21 20:17:38

Igor Korolyov
Обычно проблема возникает в поддержании большого количества индексов и накладных расходах на них. Любой дополнительный индекс, это прибавка ко времени операций модификации данных, и к занимаемому БД объёму (и "на диске", и "в памяти").
Поэтому не создают индексы на все возможные комбинации полей, а стараются выяснить наиболее важные/приоритетные сценарии доступа к данным, и оптимизировать только их. Т.е. индексы нужны там где они действительно сильно нужны
А то ускорив "месячный отчёт" можно получить неприемлемое замеделние для "текущих операций".

1. Пока не знаем сколько там индексов, в пятницу Вова обещал рассказать.

2. Похоже навесили Delete триггер/каскадное удаление, 8 часов после 4 мин вообще никуда не годится.

------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)

Исправлено 1 раз(а). Последнее : PaulWist, 23.12.21 20:18

Re: Оптимизация в Оракл
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 23.12.21 22:03:28 Да не, если делать через Ж, то всё вполне возможно и безо всяких триггеров привести к очень печальному исходу Цикл вместо групповой операции (2*7к запросов вместо 2-х). Впрочем, групповые операции реализовывать довольно сложно, и если до того это хозяйство работало 4 минуты и всех всё устраивало, то ябзабил на дальнейшую оптимизацию Замена индексного доступа на FTS - ну к примеру для таблицы в 50Гб и ОЗУ сервера в 10Гб - это значит нужно будет 7к раз считать с диска эти 50Гб, при том вытесняя полезные блоки из кэша. Предположим, что объём модификаций невелик (раз до того оно работало за 4 минуты, значит явно не тысячи записей подпадали под "обновление путём удаления и вставки" - я имею в виду в одной итерации. Возможно, что даже всего 1 запись таким чутка странным способом обновлялась). ------------------ WBR, Igor

Re: Оптимизация в Оракл

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

23.12.21 22:03:28

Да не, если делать через Ж, то всё вполне возможно и безо всяких триггеров привести к очень печальному исходу

Цикл вместо групповой операции (2*7к запросов вместо 2-х). Впрочем, групповые операции реализовывать довольно сложно, и если до того это хозяйство работало 4 минуты и всех всё устраивало, то ябзабил на дальнейшую оптимизацию

Замена индексного доступа на FTS - ну к примеру для таблицы в 50Гб и ОЗУ сервера в 10Гб - это значит нужно будет 7к раз считать с диска эти 50Гб, при том вытесняя полезные блоки из кэша. Предположим, что объём модификаций невелик (раз до того оно работало за 4 минуты, значит явно не тысячи записей подпадали под "обновление путём удаления и вставки" - я имею в виду в одной итерации. Возможно, что даже всего 1 запись таким чутка странным способом обновлялась).

------------------
WBR, Igor

Re: Оптимизация в Оракл
boba Сообщений: 6269 Откуда: Медвежьи озера- Дата регистрации: 26.03.2001	boba 24.12.21 07:36:34 Индексов 4. С выражением на trim(norder) два В первом таком индексе до выражения trim(norder) него поле dcode Во втором поле с trim на другое поле Игорь прав просто все это продукт сторонней фирмы, в который мы только дописывали свои куски. Вчера до ухода запустил поиск имени таблицы чтобы найти все запросы и стирания в ней. Думаю, в понедельник будет ясно, что править. И 4 индекса на такую таблицу многовато, добавление еще одного с голым trim(norder) мне кажется чересчур, хотя проблему со стирание конечно решит.

Re: Оптимизация в Оракл

boba

Сообщений: 6269
Откуда: Медвежьи озера-
Дата регистрации: 26.03.2001

boba

24.12.21 07:36:34

Индексов 4.
С выражением на trim(norder) два
В первом таком индексе до выражения trim(norder) него поле dcode
Во втором поле с trim на другое поле
Игорь прав просто все это продукт сторонней фирмы,
в который мы только дописывали свои куски.
Вчера до ухода запустил поиск имени таблицы чтобы
найти все запросы и стирания в ней.
Думаю, в понедельник будет ясно,
что править. И 4 индекса на такую таблицу многовато,
добавление еще одного с голым trim(norder) мне кажется чересчур,
хотя проблему со стирание конечно решит.

Re: Оптимизация в Оракл
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004	PaulWist 24.12.21 08:14:54 Ну так приведи DDL индексов и ещё нужна кардинальность и селективность на поле norder и ведущих полей этих 2-х индексов. И план на 4 мин и 8 часов приведи (хотя на 8 часов вроде и так понятно Table/Index Scan) PS 4 индекса - это нормально, даже 5 шт вполне допустимо - ну это так из общих соображений. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 24.12.21 08:15

Re: Оптимизация в Оракл

PaulWist

Сообщений: 14625
Дата регистрации: 01.04.2004

PaulWist

24.12.21 08:14:54

Ну так приведи DDL индексов и ещё нужна кардинальность и селективность на поле norder и ведущих полей этих 2-х индексов.

И план на 4 мин и 8 часов приведи (хотя на 8 часов вроде и так понятно Table/Index Scan)

PS 4 индекса - это нормально, даже 5 шт вполне допустимо - ну это так из общих соображений.

------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)

Исправлено 1 раз(а). Последнее : PaulWist, 24.12.21 08:15

Re: Оптимизация в Оракл
Гулин Федор Сообщений: 4640 Откуда: Минск Дата регистрации: 24.10.2002	Гулин Федор 05.01.22 15:29:27 boba Есть некая таблица и способ ее пополнения в пакете процедуры. Сначала delete from table Потом Inser. Процедура запускается в цикле где-то 7000 раз Параметр процедуры parorder и тип поля по которому идет стирание -char Недавно увеличили размер этого поля. В процедуре было delete from table norder= parorder Переписали delete from table trim(norder)= trim(parorder) В одном из индексов таблицы через запятую есть trim(norder) Время работы процедуры с 4 минут выросло до 8 часов. Статистика собиралась на днях. Проще всего сначала проверить Скорость между 2 запросами на селект Select from table trim(norder)= trim(parorder) Select from table norder= parorder 4 мин vs 8 часов как-то очень много если кусок удаления мал (а судя по тому что удаление одного документа) то проблем при удаленни не должно быть ps ну и да DDL хотя бы таблицы позволило сразу меньше гадать. pps и поддержу Игоря что лучше все таки как-то писать в бд без trim (хотя ясно что это в СВОЕМ приложении можно а тут крутиться приходится ) PPPS есть еще предположение про parameter sniffing если это SP (то в мс-скл сохраняется план) Если вдруг большинство norder имеет мало записей то скорей может выбратьсяя nested loops и план сохрантися и если вдруг потом будет norder скажем с 100 000 записями и nested loops применится из сохраненного плана то запрос уйдет в астрал. И вот туд да может и 8 часов и до бесконечности В MS-SQL есть опция recomplile для SP В оракле точно не скажу ( я бороля с этой проблемйо хинтом NO_NL по моему - No nested loops ) Исправлено 1 раз(а). Последнее : Гулин Федор, 05.01.22 15:35

Re: Оптимизация в Оракл

Гулин Федор

Сообщений: 4640
Откуда: Минск
Дата регистрации: 24.10.2002

Гулин Федор

05.01.22 15:29:27

boba
Есть некая таблица и способ ее пополнения
в пакете процедуры. Сначала delete from table
Потом Inser. Процедура запускается в цикле где-то 7000 раз
Параметр процедуры parorder и тип поля по которому
идет стирание -char
Недавно увеличили размер этого поля.
В процедуре было delete from table norder= parorder
Переписали delete from table trim(norder)= trim(parorder)
В одном из индексов таблицы через запятую есть trim(norder)
Время работы процедуры с 4 минут выросло до 8 часов.
Статистика собиралась на днях.

Проще всего сначала проверить Скорость между 2 запросами на селект
Select from table trim(norder)= trim(parorder)
Select from table norder= parorder
4 мин vs 8 часов как-то очень много
если кусок удаления мал (а судя по тому что удаление одного документа) то проблем при удаленни не должно быть

ps ну и да DDL хотя бы таблицы позволило сразу меньше гадать.
pps и поддержу Игоря что лучше все таки как-то писать в бд без trim (хотя ясно что это в СВОЕМ приложении можно а тут крутиться приходится )
PPPS есть еще предположение про parameter sniffing если это SP (то в мс-скл сохраняется план)
Если вдруг большинство norder имеет мало записей то скорей может выбратьсяя nested loops
и план сохрантися и если вдруг потом будет norder скажем с 100 000 записями и nested loops применится из сохраненного плана
то запрос уйдет в астрал. И вот туд да может и 8 часов и до бесконечности

В MS-SQL есть опция recomplile для SP
В оракле точно не скажу ( я бороля с этой проблемйо хинтом NO_NL по моему - No nested loops )

Исправлено 1 раз(а). Последнее : Гулин Федор, 05.01.22 15:35

Re: Оптимизация в Оракл
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004	PaulWist 10.01.22 11:39:39 Володя, попробуй с хинтом delete /+ opt_param('_optimizer_skip_scan_enabled','true') / from table norder= trim(parorder) либо так alter system set "_optimizer_skip_scan_enabled"=true delete from table norder= trim(parorder) ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 3 раз(а). Последнее : PaulWist, 10.01.22 11:44

Re: Оптимизация в Оракл

PaulWist

Сообщений: 14625
Дата регистрации: 01.04.2004

PaulWist

10.01.22 11:39:39

Володя, попробуй с хинтом


 delete /*+ opt_param('_optimizer_skip_scan_enabled','true') */ from table norder= trim(parorder)

либо так


alter system set "_optimizer_skip_scan_enabled"=true
delete from table norder= trim(parorder)

------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)

Исправлено 3 раз(а). Последнее : PaulWist, 10.01.22 11:44

Re: Оптимизация в Оракл
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 10.01.22 22:30:31 Внутренний параметр дёргать, при том что он по умолчанию и так должен быть установлен в TRUE... Если уж охота вручную порулить оптимизатором, то для этого конкретного пути доступа нужен хинт index_ss(table_name, index_name). Т.к. сам оракл его не выбрал, значит в "ведущих" полях уникальных комбинаций значений дофига и трошки, и потому от index skip scan не будет никакой пользы кроме вреда Впрочем, проверить это на реальных данных реального сервера (конечно же не с delete а с select) не сложно и не больно. ------------------ WBR, Igor

Re: Оптимизация в Оракл

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

10.01.22 22:30:31

Внутренний параметр дёргать, при том что он по умолчанию и так должен быть установлен в TRUE...
Если уж охота вручную порулить оптимизатором, то для этого конкретного пути доступа нужен хинт index_ss(table_name, index_name). Т.к. сам оракл его не выбрал, значит в "ведущих" полях уникальных комбинаций значений дофига и трошки, и потому от index skip scan не будет никакой пользы кроме вреда

Впрочем, проверить это на реальных данных реального сервера (конечно же не с delete а с select) не сложно и не больно.

------------------
WBR, Igor

Re: Оптимизация в Оракл
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004	PaulWist 11.01.22 08:12:31 Igor Korolyov Внутренний параметр дёргать, при том что он по умолчанию и так должен быть установлен в TRUE... Ммм, в доступных мне инстансах Oracle 19 (4 шт) этот параметр установлен в FALSE, причем ДБА его не менял (он вообще об этом параметре не знал, пока ему не рассказал), а один из тестовых инстансов (Enterprise) установлен 2 мес назад. Igor Korolyov Если уж охота вручную порулить оптимизатором, то для этого конкретного пути доступа нужен хинт index_ss(table_name, index_name). С хинтом - была бы вторая серия, если не получилось бы с сессией Igor Korolyov Т.к. сам оракл его не выбрал, значит в "ведущих" полях уникальных комбинаций значений дофига и трошки, и потому от index skip scan не будет никакой пользы кроме вреда Впрочем, проверить это на реальных данных реального сервера (конечно же не с delete а с select) не сложно и не больно. Если оптимизатор "вчера" выбирал и выполнял 4 мин, а сегодня перестал и выполняет 8 часов, такое возможно если перезалили почти всю таблицу, а если модификация таблицы идёт в "час по чайной ложке", то вполне возможно, что превышен порог выбора плана и хинтом это можно подправить. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 11.01.22 08:15

Re: Оптимизация в Оракл

PaulWist

Сообщений: 14625
Дата регистрации: 01.04.2004

PaulWist

11.01.22 08:12:31

Igor Korolyov
Внутренний параметр дёргать, при том что он по умолчанию и так должен быть установлен в TRUE...

Ммм, в доступных мне инстансах Oracle 19 (4 шт) этот параметр установлен в FALSE, причем ДБА его не менял (он вообще об этом параметре не знал, пока ему не рассказал), а один из тестовых инстансов (Enterprise) установлен 2 мес назад.

Igor Korolyov
Если уж охота вручную порулить оптимизатором, то для этого конкретного пути доступа нужен хинт index_ss(table_name, index_name).

С хинтом - была бы вторая серия, если не получилось бы с сессией

Igor Korolyov
Т.к. сам оракл его не выбрал, значит в "ведущих" полях уникальных комбинаций значений дофига и трошки, и потому от index skip scan не будет никакой пользы кроме вреда
Впрочем, проверить это на реальных данных реального сервера (конечно же не с delete а с select) не сложно и не больно.

Если оптимизатор "вчера" выбирал и выполнял 4 мин, а сегодня перестал и выполняет 8 часов, такое возможно если перезалили почти всю таблицу, а если модификация таблицы идёт в "час по чайной ложке", то вполне возможно, что превышен порог выбора плана и хинтом это можно подправить.

------------------
Есть многое на свете, друг Горацио...
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)

Исправлено 1 раз(а). Последнее : PaulWist, 11.01.22 08:15

Re: Оптимизация в Оракл
Igor Korolyov Автор Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 11.01.22 22:27:56 Если тип поля char и "вчера" он был одного размера а "сегодня" его увеличили - это приведёт к существенной физической реорганизации таблицы. Кроме того индекс был вообще переделан, т.е. совершенно точно "вчерашние" планы никак не могут использоваться. И да, как я понял речь идёт не про одиночный запрос исполняемый 8 часов, а про вызов ХП в цикле на 7000 итераций. По настройке ничего не скажу, оракла под рукой уже давно нет, а документация (не совсем официальная, т.к. описан сей параметр "официально" лишь там куда доступ есть лишь у владельцев активной лицензии с саппортом) говорит что по умолчанию оно должно быть включено. Это и логично, т.к. было бы крайне странно "по умолчанию" отключать один из путей доступа, при том существующий в СУБД уже чёрт-те сколько лет, сам этот флажок появился ещё в 9-й версии (опять же согласно той инфы что я нашёл - доступа к металинку у меня вообще никогда не было )... ------------------ WBR, Igor

Re: Оптимизация в Оракл

Igor Korolyov
Автор

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

11.01.22 22:27:56

Если тип поля char и "вчера" он был одного размера а "сегодня" его увеличили - это приведёт к существенной физической реорганизации таблицы. Кроме того индекс был вообще переделан, т.е. совершенно точно "вчерашние" планы никак не могут использоваться.

И да, как я понял речь идёт не про одиночный запрос исполняемый 8 часов, а про вызов ХП в цикле на 7000 итераций.

По настройке ничего не скажу, оракла под рукой уже давно нет, а документация (не совсем официальная, т.к. описан сей параметр "официально" лишь там куда доступ есть лишь у владельцев активной лицензии с саппортом) говорит что по умолчанию оно должно быть включено. Это и логично, т.к. было бы крайне странно "по умолчанию" отключать один из путей доступа, при том существующий в СУБД уже чёрт-те сколько лет, сам этот флажок появился ещё в 9-й версии (опять же согласно той инфы что я нашёл - доступа к металинку у меня вообще никогда не было

)...

------------------
WBR, Igor

:: Список Форумов•Список тем•Поиск•Войти

Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 7 (Гостей: 7)