Как лучше всего исправить производительность запроса Oracle в рабочей среде? Меняете код приложения? Используете базовый план плана?

Question

Предположим, что существует приложение C ++, выполняющее определенный c SQL запрос к Oracle базе данных.

Этот запрос работал нормально последние пару лет в производственной среде в среде клиента, но внезапно в один прекрасный день запрос стал выполняться примерно в 10 раз больше. (Предположим, что в таблицы, с которыми работает этот запрос, постоянно добавляются данные).

При проведении анализа эксперты обнаружили, что оптимизатор Oracle не генерирует оптимальный план из-за возможных причин, связанных со статистикой БД / перекосом данных / всеми другими параметрами, которые могут повлиять на оптимизатор для создания неоптимального плана.

Принудительное использование оптимизатора путем размещения подсказок в запросе для создания хорошего плана выполнения работает отлично.

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

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

Данный клиент не желает нанять администратора базы данных , который может выполнить команду SQL для настройки запроса с использованием функции базового плана.

Какие варианты действий у команды разработчиков приложений в этом случае?

Answer 1

Создайте ручной профиль SQL, чтобы вводить подсказки без изменения приложения SQL. Хотя это все еще задача «администратора базы данных», она требует выполнения только одной команды и намного проще, чем SQL Plan Baselines.

Используйте приведенный ниже блок PL / SQL. Замените SQL_ID, имя, описание и список подсказок, а затем отправьте клиенту полную команду.

--Large SQL statements are better loaded from SQL_ID.
declare
    v_sql_id constant varchar2(128) := '2z0udr4rc402m';  --CHANGE ME
    v_sql    clob;
begin
    --Find the SQL, it should be in one of these.
    begin
        select sql_fulltext into v_sql from gv$sql where sql_id = v_sql_id and rownum = 1;
    exception when no_data_found then null;
    end;

    if v_sql is null then
        begin
            select sql_text into v_sql from dba_hist_sqltext where sql_id = v_sql_id and rownum = 1;
        exception when no_data_found then
            raise_application_error(-20000, 'Could not find this SQL_ID in GV$SQL or DBA_HIST_SQLTEXT.');
        end;
    end if;

    --Create profile.
    dbms_sqltune.import_sql_profile
    (
        sql_text    => v_sql,
        name        => 'Some_Meaningful_Name',  --CHANGE ME
        description => 'Add useful description here.',  --CHANGE ME
        force_match => true,
        profile     => sqlprof_attr('full(a)', 'parallel(8)')  --CHANGE ME
    );
end;
/

«Лучшим» решением было бы покопаться в системе клиента и выяснить, почему они отличается от всех остальных. У них есть какой-то странный параметр оптимизатора, они отключили задание статистики и т. Д. c. Но если это единственная проблема, с которой сталкивается клиент, я бы просто использовал профиль SQL и назову это готовым.