Борьба с долгими и ресурсоемкими запросами : Oracle

OlegON · █ 27.04.2024 15:45

Столкнулся с ситуацией, когда программисты отказываются выполнять супружзакрывать технический долг, то есть исправлять говнокод, который сами и написали. Бизнес кричит "наш паровод вперед лети", а старый говнокод пополняется новым. В итоге сначала ругался, потом писал в Jira заявки, которые так и не выполнялись, в итоге терпение треснуло, что мертво, умереть не может... Долгие запросы, вымывающие кеш и тормозящие пользователей, будут убиваться так же молча и без согласования, как они молча и без согласования появляются в базе.

SQL код:

 create or replace procedure sys.ok_control_hangs is
begin
for c in (select sid,serial# from v$session where last_call_et>10800 and seconds_in_wait>300 and status='ACTIVE' and type!='BACKGROUND')
loop
begin
execute immediate
'alter system disconnect session ' || c.sid || ',' || c.serial# || ' immediate';
exception when others then null;
end;
end loop;
end;

BEGIN
    DBMS_SCHEDULER.CREATE_JOB(
        job_name        => 'OK_CTRL_HANGS',
        job_type        => 'PLSQL_BLOCK',
        job_action      => 'BEGIN
                                 ok_control_hangs;
                            END;',
        start_date      => systimestamp,
        repeat_interval => 'FREQ=MINUTELY; INTERVAL=1',
        enabled         => TRUE,
        auto_drop       => FALSE);
END;
/
begin DBMS_SCHEDULER.set_attribute (name=> 'ok_ctrl_hangs',attribute => 'logging_level',value => dbms_scheduler.logging_off); end;
/

~Guest~ · █ 03.05.2024 09:11

А может запрос реально тяжелый, объемный, а ты его рубишь по времени )
У меня сейчас знакомые занялись аналогом BI, только не как продукт, а как услугу, т.е. бизнес просит конкретные отчеты с глубоким анализом, ему дают не инструмент, которым один фиг никто не пользуется, а готовый результат, по данным сети. Так вот там объемы данных ого-го, реально неделями можно выгружать )

OlegON · █ 06.05.2024 11:41

Цитата:

~Guest~ ➤ запрос реально тяжелый, объемный

в наше время сервера могут проворачивать чудовищные объемы информации, поэтому если аналитический запрос работает больше 3х минут, то возникают очень большие вопросы, чем, собственно, сервер это время занят. для понимания сути скорости простой пример, гугл тебе за сколько секунд выдает ответ на запрос по тексту? представляешь себе этот объем информации? у него не какие-то сверхпроцессоры, такое же железо, которое ты можешь купить сам, количеством серверов решается только задача обеспечения количества пользователей... так что если сервер неделю что-то выгружает, то это либо они на старых ноутбуках на IDE вместо серверов что-то там поднимают, либо архитектура данных сделана через это самое... а про объемы данных какой-то одной сети мне можно не рассказывать :) у BI одна проблема, индусы, которые его, как правило, пишут, сильно не заморачиваются, а просто поступенчато собирают запрос, к концу сбора благополучно забывая, с чего начинали. Архитектура самих кубов вообще про оптимальность не слышала, главное, чтобы просто было собрать это хоть как-то в кучу потом динамическим запросом. Чтобы оно работало быстро, надо сидеть и долго думать. А это делать никто не хочет, главное - быстро слепить и получить деньги, потому слепили из того, что было, а потом рассказывают, пугая объемами информации...