V$SQL содержит и HASH_VALUE и SQL_ID, но не навсегда.
Согласно блогу Танеля Подера , HASH_VALUE может быть получено из SQL_ID, но обратная операция невозможна. Но преобразование HASH_VALUE в SQL_ID все равно не решит вашу проблему.
Прежде всего, я не уверен, почему у вас будет доступ к HASH_VALUE, но не к SQL_ID. SQL_ID гораздо чаще используется для настройки производительности. Независимо от того, что программа или источник предоставляет, HASH_VALUE следует изменить, чтобы вместо него возвращалось SQL_ID.
Но настоящая проблема здесь, независимо от того, какое значение вы имеете, состоит в том, что данные не хранятся постоянно в V$SQL. По мере старения операторов они устаревают из общего пула и исчезают с V$SQL. Кроме того, если вы используете кластерную систему, убедитесь, что вы используете GV$SQL.
Если вы используете Enterprise Edition и лицензировали Oracle Diagnostic Pack, вы можете найти исторические значения SQL_ID с помощью одного из следующих двух утверждений:
select sql_id
from gv$active_session_history
where sql_full_plan_hash_value = 'XYZ';
select sql_id
from dba_hist_active_sess_history
where sql_full_plan_hash_value = 'XYZ';
Данные в GV$ACTIVE_SESSION_HISTORY обычно длятся около суток. Данные в DBA_HIST_* по умолчанию остаются в течение 8 дней, но их можно настраивать. Вы можете проверить сохранение AWR с помощью этого запроса: select retention from dba_hist_wr_control;
Если HASH_VALUE менее старый, чем период хранения, но все еще не в AWR, то вы, вероятно, можете его проигнорировать. ASH и AWR используют выборку, что означает, что они не захватывают все , что происходит в базе данных. ASH отбирает образец каждую секунду, а AWR - каждые 10 секунд.
Многие люди борются с этой концепцией, но полезно прийти к соглашению с идеей выборки. Системы, которые захватывают всю информации, например, отслеживают все, перегружают и занимают слишком много места и вычислительной мощности. Если мы рассматриваем проблемы с производительностью, то нам не важно, что происходит не более 10 секунд из 8 дней.