我知道这似乎是一个简单的问题 - 您可能认为存在现有答案。然而……
理解我希望它在性能上是合理的，所以它允许记录每个执行的查询 - 或者至少是大的查询 - 而没有太多开销。
我的第一个想法是这个查询:
select sid,serial#,prev_sql_id from v$session where audsid=userenv('sessionid');
我的想法是，如果我在目标查询之后立即运行它，我将通过 prev_sql_id 捕获正确的 sql_id。
但是......我不是......我得到了一个不同的SQL......显然在我的目标SELECT语句和prev_sql_id的查询之间，运行了其他东西。在我的例子中，启用了审计，我正在捕获插入到 SYS.AUD$ 表中。不好。
因为我这次尝试的主要目的是捕获查询的执行计划(因为它是由共享池执行和捕获的)，所以我认为我可以简单地运行这个查询:
SELECT *
FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR());
文档指出，使用 NULL SQL_ID 作为参数，它将在最近运行的查询上运行解释计划。我希望这会解决早期的问题。然而……我得到了将完全相同的插入到 SYS.AUD$ 表中的计划。
您可能会说，好吧，那么只需在您的查询中添加一条注释即可轻松捕获 SQL_ID，如下所示:
SELECT /* SQL: 1234-12' */ FROM DUAL;
然后我可以尝试按如下方式查找 SQL_ID:
SELECT * FROM V$SQLAREA WHERE sql_text like '%SQL: 1234-12%';
这将给我几个可能的候选者，其中还包括 V$SQLAREA 查询本身。这里的问题是我需要随机化运行的每个查询，这会导致我总是进行硬解析。
我曾尝试过其他解决方案，但这些解决方案的成本要高得多。我试图搜索其他解决方案。它们似乎都以某种方式滞后。
相关文章:
最佳答案
您可以使用新的 SQL*Plus option :
SET FEEDBACK ON SQL_ID;
SQL_ID returns the sql_id for the SQL or PL/SQL statements that are executed. The sql_id will be assigned to the predefined variable _SQL_ID. You can use this predefined variable to debug the SQL statement that was executed. The variable can be used like any other predefined variable, such as _USER and _DATE.
SQL> SET FEEDBACK ON SQL_ID
SQL> SELECT * FROM DUAL;
D
-
X
1 row selected.
SQL_ID: a5ks9fhw2v9s1
--
SQL> SELECT sql_text FROM v$sql WHERE sql_id = '&_sql_id';
SQL_TEXT
-----------------------------------------------------
SELECT * FROM DUAL
1 row selected.
关于sql - 如何可靠地获取查询的 SQL_ID，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42800041/