Низкая загрузка ЦП ораклом. не выше 25% всегда. / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

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

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Низкая загрузка ЦП ораклом. не выше 25% всегда.

25 сообщений из 105, страница 2 из 5

все

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39463731

lonely_myp

Гость

запрос...
вот "маленький" запрос на 3 минуты.
выполняется при открытии окна с перечнем бригад и графиком работ за выбранный период(месяц).
то есть юзер нажимает кнопку "открыть" и может идти курить, а если за 3 месяца открыть, то может ещё в магазин сбегать.

Код: 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.
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.

select  *
from (select a.idObject id
      ,a.nShiftNumber
      ,a.idDepartment
      ,b.sDepartmentCode sDep
      ,c.slname||nvl2(c.smidname||c.sfname,' ','')||substr(c.sfname,1,1)
       ||nvl2(c.sfname,'.','')||substr(c.smidname,1,1)||nvl2(c.smidname,'.','') sName
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('01.05.2017','dd.mm.yyyy')) as "nManHour[1]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('01.05.2017','dd.mm.yyyy')) as "sWorks[1]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('02.05.2017','dd.mm.yyyy')) as "nManHour[2]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('02.05.2017','dd.mm.yyyy')) as "sWorks[2]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('03.05.2017','dd.mm.yyyy')) as "nManHour[3]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('03.05.2017','dd.mm.yyyy')) as "sWorks[3]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('04.05.2017','dd.mm.yyyy')) as "nManHour[4]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('04.05.2017','dd.mm.yyyy')) as "sWorks[4]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('05.05.2017','dd.mm.yyyy')) as "nManHour[5]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('05.05.2017','dd.mm.yyyy')) as "sWorks[5]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('06.05.2017','dd.mm.yyyy')) as "nManHour[6]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('06.05.2017','dd.mm.yyyy')) as "sWorks[6]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('07.05.2017','dd.mm.yyyy')) as "nManHour[7]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('07.05.2017','dd.mm.yyyy')) as "sWorks[7]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('08.05.2017','dd.mm.yyyy')) as "nManHour[8]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('08.05.2017','dd.mm.yyyy')) as "sWorks[8]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('09.05.2017','dd.mm.yyyy')) as "nManHour[9]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('09.05.2017','dd.mm.yyyy')) as "sWorks[9]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('10.05.2017','dd.mm.yyyy')) as "nManHour[10]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('10.05.2017','dd.mm.yyyy')) as "sWorks[10]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('11.05.2017','dd.mm.yyyy')) as "nManHour[11]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('11.05.2017','dd.mm.yyyy')) as "sWorks[11]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('12.05.2017','dd.mm.yyyy')) as "nManHour[12]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('12.05.2017','dd.mm.yyyy')) as "sWorks[12]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('13.05.2017','dd.mm.yyyy')) as "nManHour[13]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('13.05.2017','dd.mm.yyyy')) as "sWorks[13]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('14.05.2017','dd.mm.yyyy')) as "nManHour[14]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('14.05.2017','dd.mm.yyyy')) as "sWorks[14]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('15.05.2017','dd.mm.yyyy')) as "nManHour[15]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('15.05.2017','dd.mm.yyyy')) as "sWorks[15]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('16.05.2017','dd.mm.yyyy')) as "nManHour[16]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('16.05.2017','dd.mm.yyyy')) as "sWorks[16]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('17.05.2017','dd.mm.yyyy')) as "nManHour[17]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('17.05.2017','dd.mm.yyyy')) as "sWorks[17]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('18.05.2017','dd.mm.yyyy')) as "nManHour[18]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('18.05.2017','dd.mm.yyyy')) as "sWorks[18]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('19.05.2017','dd.mm.yyyy')) as "nManHour[19]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('19.05.2017','dd.mm.yyyy')) as "sWorks[19]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('20.05.2017','dd.mm.yyyy')) as "nManHour[20]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('20.05.2017','dd.mm.yyyy')) as "sWorks[20]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('21.05.2017','dd.mm.yyyy')) as "nManHour[21]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('21.05.2017','dd.mm.yyyy')) as "sWorks[21]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('22.05.2017','dd.mm.yyyy')) as "nManHour[22]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('22.05.2017','dd.mm.yyyy')) as "sWorks[22]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('23.05.2017','dd.mm.yyyy')) as "nManHour[23]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('23.05.2017','dd.mm.yyyy')) as "sWorks[23]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('24.05.2017','dd.mm.yyyy')) as "nManHour[24]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('24.05.2017','dd.mm.yyyy')) as "sWorks[24]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('25.05.2017','dd.mm.yyyy')) as "nManHour[25]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('25.05.2017','dd.mm.yyyy')) as "sWorks[25]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('26.05.2017','dd.mm.yyyy')) as "nManHour[26]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('26.05.2017','dd.mm.yyyy')) as "sWorks[26]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('27.05.2017','dd.mm.yyyy')) as "nManHour[27]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('27.05.2017','dd.mm.yyyy')) as "sWorks[27]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('28.05.2017','dd.mm.yyyy')) as "nManHour[28]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('28.05.2017','dd.mm.yyyy')) as "sWorks[28]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('29.05.2017','dd.mm.yyyy')) as "nManHour[29]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('29.05.2017','dd.mm.yyyy')) as "sWorks[29]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('30.05.2017','dd.mm.yyyy')) as "nManHour[30]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('30.05.2017','dd.mm.yyyy')) as "sWorks[30]"
      ,EAM_SetResponsible.GetManHour(a.idObject,to_date('31.05.2017','dd.mm.yyyy')) as "nManHour[31]"
      ,EAM_SetResponsible.GetWorks(a.idObject,to_date('31.05.2017','dd.mm.yyyy')) as "sWorks[31]"
      ,EAM_SetResponsible.GetAllManHour(a.idObject,:filter$Flt_dBegin,:filter$Flt_dEnd) as nAllManHour
      ,EAM_SetResponsible.GetAllQty(a.idObject,:filter$Flt_dBegin,:filter$Flt_dEnd) as nAllQty
from EAM_ShiftMAP a
    ,Bs_DepartmentMAP b
    ,BS_PersonMAP c
where a.iddepartment = b.idObject(+)
  and a.idPerson = c.idObject(+)) a
where (1=1)

function GetManHour

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

function GetManHour(idpShift in number, dpDate in date) return number as
    result number;
  begin
    select sum(a.nmanhour)
      into result
      from EAM_PlanRepairMAP a,
           (select b.idplanrepair
              from Eam_ShiftrepairMAP b
             where b.idresponsible = idpShift
             group by b.idplanrepair) b
     where a.idobject = b.idplanrepair
       and trunc(a.dbegin) = dpDate;
    return result;
  end;

function GetWorks

Код: 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.

 function GetWorks(idpShift in number, dpDate in date) return varchar2 as
    result varchar2(4000);
  begin
    select replace(straggrd(straggrdargs(to_char(decode(nCount,
                                                        1,
                                                        null,
                                                        nCount)) || t.sCode,
                                         '-')),
                   '-',
                   '')
      into result
      from (select a.idtyperepair, count(*) nCount
              from EAM_PlanRepairMAP a,
                   (select b.idplanrepair
                      from Eam_ShiftrepairMAP b
                     where b.idresponsible = idpShift
                     group by b.idplanrepair) b
             where a.idobject = b.idplanrepair
               and trunc(a.dbegin) = dpDate
             group by a.idtyperepair) a,
           Eam_Typerepair t
     where a.idtyperepair = t.id;
    return result;
  end;

...

Рейтинг:

0 / 0

01.06.2017, 12:16

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39463756

Yo.!

Гость

lonely_myp,

ну да, студенческий дизайн. для каждого сотрдуника, на каждый день, долбишь двумя функциями, которые в свою очередь почти наверняка тоже долбят nested loop. 3 минуты еще по божески с таким дизайном.

...

Рейтинг:

0 / 0

01.06.2017, 12:55

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39463777

lonely_myp

Гость

подобных запросов в базе множество в разных местах, есть шаблон запроса и по необходимости из шаблонов собирается один эпический запрос.

http://www.global-eam.ru/
"система, обобщающая лучшие мировые и отечественные практики ТОиP"

ответ разработчика я приводил, им искренне жаль
вопрос стоит как имея вот это вот всё, ускориться?

я например могу добавить ядер, расшириться с 4 до 12 ядер.
но что толку, если на каждого юзера одно ядро :(

...

Рейтинг:

0 / 0

01.06.2017, 13:13

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39463788

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Yo.!lonely_myp,

ну да, студенческий дизайн. для каждого сотрдуника, на каждый день, долбишь двумя функциями, которые в свою очередь почти наверняка тоже долбят nested loop. 3 минуты еще по божески с таким дизайном.
Лично я особого криминала не вижу

Функции в select листе, т.ч. если там честный nested loop, а не какие нибудь hash join'ы и никто не пытается сделать полный фетч всего результата на клиента - то все будет нормально.

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

...

Рейтинг:

0 / 0

01.06.2017, 13:20

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39463843

Yo.!

Гость

lonely_mypподобных запросов в базе множество в разных местах, есть шаблон запроса и по необходимости из шаблонов собирается один эпический запрос.

http://www.global-eam.ru/
"система, обобщающая лучшие мировые и отечественные практики ТОиP"

ответ разработчика я приводил, им искренне жаль
вопрос стоит как имея вот это вот всё, ускориться?

я например могу добавить ядер, расшириться с 4 до 12 ядер.
но что толку, если на каждого юзера одно ядро :(
посмотри что за индекс на EAM_PlanRepairMAP.dbegin
в функции фигурирует trunc(a.dbegin), если индекс не FBI то это заставляет фуллсканить EAM_PlanRepairMAP.

по хорошему для начала надо пересобрать статистику (exec DBMS_STATS.gather_schema_stats('schema_name') например) и смотреть план, что там эти функции такого cpu интенсив делают. апгрейд железа не поможет.

...

Рейтинг:

0 / 0

01.06.2017, 14:22

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39464033

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Вот я, честно говоря, никаким AWR и прочем премудростям не обучен

Т.ч. делаю по простому, запускаю PL/SQL developer и смотрю current (last) statement в сессии. Тот который там мелькает чаще всего - копи-пастю. По закону вероятности, скопи-пастить удается ровно тот селект, который занимает больше всего времени. Разбираюсь с ним, смотрю его план. Потом копи-пастю следующий....

...

Рейтинг:

0 / 0

01.06.2017, 17:47

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39464080

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Yo.!...
и смотреть план, что там эти функции такого cpu интенсив делают. апгрейд железа не поможет.
+100500

На самом деле, чисто визуально все не выглядит "сильно запущенным". Достаточно элементарные select'ы.

Тут два подозрения:

1) Клиническое и не лечится.
Клиентский софт всегда фетчит все записи из результата, вот здесь может быть печалька. Если данных много, а интерфейс сделан программистами страдающими "hibernate головного мозга" и по принципу "пагинация делается двумя строчками" ( C ), то вполне возможно, что на экран показывается 20-40 записей, а фетчится и обрабатывается чуть ли не вся база
Тут только лечить "hibernate головного мозга" у разработчиков, по методу доктора Жозе́ф Игн́ас Гильоте́на (написание взято из вики).

2) Все не настолько запущено и затыки именно на стороне сервера. Слетели (не хватает) индексы, кривой план... тут мне кажется уже можно пытаться как-то это дело лечить, разбираться и оптимизировать.
Конечно, было бы оптимально, если бы разработчики были бы готовы прислушаться к рекомендациям и переписать запросы в своем приложение.
Запрос на 3-и таблички с тремя подзапросами внутри - выглядит сильно по детски.

Ну и лично я, глядя на запросы, даже могу сходу предложить изменение структуры (создание индексов), которые как минимум в 2-4 раза скорость повысят, а может и больше. Только, конечно, желательно все же систему видеть. AFAIK

Куча мелких запросов, которые оперируют 2-3 полями. Я бы все эти поля (и из where и из select list'а) включил в индексы. Что бы при обработке запроса вообще избавиться от обращения к основной таблице (вся информация из индекса). Больно много в статистике "table fetch by rowid".

Сталкивался с похожей ситуацией (в системе Oracle Customer Care & Billing), где в таблице (CI_FI) были данные по клиентам + дата. И агрегировали данные по клиенту. Получалась полная фигня. Данные по одному клиенту оказывались "размазанными" по всей таблице, фактически таблица получалась жутко фрагментированная. А в отсортированном индексе, все данные по клиенту рядом. Скорость агрегирования возросла в десяток раз. Хотя пришлось городить достаточно жутко выглядящие индексы.

Пытались использовать index organized (cluster) table, но "не взлетело". Просто сделали очень широкие индексы.

IMHO & AFAIK

...

Рейтинг:

0 / 0

01.06.2017, 19:34

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465137

lonely_myp

Гость

Yo.!
посмотри что за индекс на EAM_PlanRepairMAP.dbegin
в функции фигурирует trunc(a.dbegin), если индекс не FBI то это заставляет фуллсканить EAM_PlanRepairMAP.
посмотрел, тип NORMAL

Yo.!по хорошему для начала надо пересобрать статистику (exec DBMS_STATS.gather_schema_stats('schema_name') например) запустил.

...

Рейтинг:

0 / 0

03.06.2017, 13:03

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465140

lonely_myp

Гость

Leonid Kudryavtsevчто на экран показывается 20-40 записей, а фетчится и обрабатывается чуть ли не вся база
при открытии окна программы например с перечнем оборудования происходит селект на несколько тыщ записей, результат кэшируется в клиенте.
при этом на экран юзера влезает максимум первые 20-30 строчек из всего перечня.
зато работает сортировка и фильтры.

...

Рейтинг:

0 / 0

03.06.2017, 13:10

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465180

Yo.!

Гость

lonely_mypYo.!посмотри что за индекс на EAM_PlanRepairMAP.dbegin
в функции фигурирует trunc(a.dbegin), если индекс не FBI то это заставляет фуллсканить EAM_PlanRepairMAP.
посмотрел, тип NORMAL
значит функции фулсканят из-за "and trunc(a.dbegin) = dpDate", если бы индекс был по TRUNC(dbegin) то было бы FUNCTION-BASED NORMAL

можно попробовать сделать FBI индекс

Код: plsql

create index EAM_PlanRepairMAP_dbegin_idx  on EAM_PlanRepairMAP(TRUNC(dbegin)) ;

будет у вас два индекса, чуток тормозов при инсерте может дабавить.

...

Рейтинг:

0 / 0

03.06.2017, 14:47

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465186

Вячеслав Любомудров

Участник

Откуда: Владивосток

Сообщения: 18 655

Рейтинг: 0 / 0

Может у него там ограничение висит dbegin=trunc(dbegin)
Тогда вполне себе сможет подхватиться и обычный индекс по dbegin

...

Рейтинг:

0 / 0

03.06.2017, 14:59

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465198

lonely_myp

Гость

Yo.!, два индекса не даёт сделать, ORA-01408: such column list already indexed

...

Рейтинг:

0 / 0

03.06.2017, 15:17

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465233

Yo.!

Гость

Вячеслав ЛюбомудровМожет у него там ограничение висит dbegin=trunc(dbegin)
Тогда вполне себе сможет подхватиться и обычный индекс по dbegin
может, но похоже не наш случай ...

lonely_mypYo.!, два индекса не даёт сделать, ORA-01408: such column list already indexed
значит FBI индекс с trunc() уже существует.
раз догадались повесить FBI индекс, то совсем детских ошибок вероятно не наделали, надо видеть SQL план, тогда будет диагноз.

...

Рейтинг:

0 / 0

03.06.2017, 16:02

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465264

lonely_myp

Гость

Yo.!,
я посмотрел список всех индексов, такого FB индекса там точно нет
я так понимаю что не даёт создать второй индекс, так как уже есть обычный индекс.

...

Рейтинг:

0 / 0

03.06.2017, 17:34

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465276

Yo.!

Гость

lonely_mypя посмотрел список всех индексов, такого FB индекса там точно нет
я так понимаю что не даёт создать второй индекс, так как уже есть обычный индекс.

не должно, помню я так в 9 или 10 версии выкручивался, только что проверил в 11.2 мне позволил.
смотри все индексы так
select * from all_indexes where table_name = 'EAM_PLANREPAIRMAP'

а вообще давай планы тех запросов.

...

Рейтинг:

0 / 0

03.06.2017, 18:11

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465287

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

lonely_mypпри открытии окна программы например с перечнем оборудования происходит селект на несколько тыщ записей, результат кэшируется в клиенте.
при этом на экран юзера влезает максимум первые 20-30 строчек из всего перечня.
зато работает сортировка и фильтры.
Ну хоть кэшируют и потом сами делают сортировку. А вот фильтры - должна делать БД

Тогда, отправить поздравительную телеграмму разработчиков как сделал Кот Матроскин "Шарик, ты балбес"

То, как они пишут SELECT'ы может быть и допустимо, но не в ситуации "все фетчим, потом сами сортируем и фильтруем". Их подход "не взлетит". Или как минимум писать нормально запросы или БД должна заниматься тем, чем она и должна занимать: обработкой данных, фильтрацией и сортировкой, а клиент тем, чем должен заниматься, отображением данных. Последнее, скорее всего у них вызовет жуткий батхерд и срыв шаблонов: поэтому реально можно предложить только первый способ. Нормально писать SELECT'а...

Поскольку, те расчеты которые они хотят выполнять, одним SELECT'ом делать не удобно, как вариант: временные таблицы, заполнять данные в PL/SQL процедуре, вызывать процедуру + SELECT * из временной таблице. Их портянка из SELECT + PL/SQL функции... IMHO "не взлетит"... Но что бы говорить предметно, нужно знать систему целиком

Пока, судя по тому, что видно: нарезать индексы. Поскольку есть код и пакетах, можно попытаться и сами ф-ции оптимизировать. На мой взгляд, 2-3 кратного ускорения достигнуть можно. База не большая (вроде она у Вас вся в память поместилась), т.ч. расход места под индексы вряд ли будет существенным фактором. IMHO & AFAIK

...

Рейтинг:

0 / 0

03.06.2017, 19:20

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465291

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Yo.!можно попробовать сделать FBI индекс

Код: plsql

create index EAM_PlanRepairMAP_dbegin_idx  on EAM_PlanRepairMAP(TRUNC(dbegin)) ;

....
Нафига?
Для какого запроса?

Индексы нужно строить под запросы, т.ч. начинать вот ровно с этого:
Yo.!а вообще давай планы тех запросов.
+тут полностью плюсуюсь

Если мы говорим про Вот этот запрос (подзапрос):

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.

select a.idtyperepair, count(*) nCount
              from EAM_PlanRepairMAP a,
                   (select b.idplanrepair
                      from Eam_ShiftrepairMAP b
                     where b.idresponsible = idpShift
                     group by b.idplanrepair) b
             where a.idobject = b.idplanrepair
               and trunc(a.dbegin) = dpDate
             group by a.idtyperepair

То лично я бы:
1) его бы переписал и вместо count(*) поставил count(1)
2) нарезал бы индекс на EAM_PlanRepairMAP
idobject + trunc(a.dbegin) + idtyperepair
а не индекс по trunc() без idobject ! смысла в раздельных индексах по двум колонкам нет никакого ! AFAIK
3) нарезал бы индекс на Eam_ShiftrepairMAP
idresponsible + idplanrepair

Не уверен, что нигде не ошибся. Хорошо все же иметь доступ к БД и к системе. Но я бы думал в таком направлении. Для запросов такого вида (к одной-двум колонкам), вообще за счет индексов убрать обращение к таблицам.

IMHO & AFAIK

А вообще, озвучить бюджет. Дать доступ к системе или оплатить командировку. И можно говорить что-то предметно ))) А так... лечение экстрасенсами по фотографии...

...

Рейтинг:

0 / 0

03.06.2017, 19:30

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465945

lonely_myp

Гость

вот этот план имеется в виду?

...

Рейтинг:

0 / 0

05.06.2017, 15:27

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465975

lonely_myp

Гость

GetManHour

...

Рейтинг:

0 / 0

05.06.2017, 15:43

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39465982

lonely_myp

Гость

GetWorks

...

Рейтинг:

0 / 0

05.06.2017, 15:48

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39466066

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Насчет первого ничего сказать не могу

Последний и предпоследний - полный шлак. Индексов нет. От сочетания слов "совсем нет".

...

Рейтинг:

0 / 0

05.06.2017, 16:44

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39466091

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Разработчикам - ссылку на данную тему.
А в данную тему - фотки разработчиков.
Страна должна знать своих героев.

Ну и тем, кто в БД для этой системы нарезал индексы, срочно читать тему:
http://www.sql.ru/forum/941371/studentam-zhelaushhim-pomoshhi

Мое такое мнение. Если я не прав, пусть меня кто нибудь поправит.

p.s.
Про первый план где сплошной Full table scan ничего говорить не буду ))). Тут часто утверждают, что full table scan и hash join это хорошо, и вообще "Oracle умный, ему виднее" ))) Не хожу вступать в полемику по этому поводу )))

Но предпоследний и последний - это шлак, за гранью добра и зла.

...

Рейтинг:

0 / 0

05.06.2017, 16:57

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39466107

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

CREATE INDEX EAM_PlanRepairMAP_z1 ON EAM_PlanRepairMAP ( idobject, trunc(dbegin) );
CREATE INDEX Eam_ShiftrepairMAP_z2 ON Eam_ShiftrepairMAP ( idresponsible, idplanrepair );
CREATE INDEX Eam_Typerepair_z3 ON Eam_Typerepair ON (id);

Странно это, что бы не было по ID индекса на Eam_Typerepair... Странно все как-то. Очень странно (((
Или действительно все так запущенно или "если вдруг увидел люк, не волнуйся это глюк"

...

Рейтинг:

0 / 0

05.06.2017, 17:17

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39466110

Yo.!

Гость

lonely_mypвот этот план имеется в виду?
да, первый. покажи полностью.
ты все интересное обрезал но уже ясно, что там в цикле на каждого работягу, на каждый день долбит фуллсканами.
вместо железа наймите на пару часов ораклойда, 100% можно затюнить без вмешательства в код программки

Leonid KudryavtsevМое такое мнение. Если я не прав, пусть меня кто нибудь поправит.

а я теперь не вижу совсем явного криминала. основные индексы видно есть, IDX_EAM_PLANREPAIRM_DTRBEGIN явно FBI индекс с TRUNC

...

Рейтинг:

0 / 0

05.06.2017, 17:20

| Ответить | Цитировать | Написать

Низкая загрузка ЦП ораклом. не выше 25% всегда.

#39466113

Yo.!

Гость

Leonid KudryavtsevСтранно это, что бы не было по ID индекса на Eam_Typerepair... Странно все как-то. Очень странно (((
Или действительно все так запущенно или "если вдруг увидел люк, не волнуйся это глюк"

не факт. там табличка 1.5 мб, 100% закеширована. обращаться по индексу к такой мелкой может быть просто дороже

...

Рейтинг:

0 / 0

05.06.2017, 17:25

| Ответить | Цитировать | Написать

25 сообщений из 105, страница 2 из 5

все

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Низкая загрузка ЦП ораклом. не выше 25% всегда.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=52&msg=39466113&tid=1885744]:	0ms
get settings:	9ms
get forum list:	16ms
check forum access:	3ms
check topic access:	3ms
track hit:	164ms
get topic data:	11ms
get forum data:	2ms
get page messages:	83ms
get tp. blocked users:	1ms
others:	252ms

total:	544ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы