查找 Oracle Analytics 查询的 SQL_ID
当您微调 Oracle Analytics 的查询时，您需要查看数据模型、报表设计、仪表盘设计和网络配置，有时还需要调查数据库。
V$SQL 表
对于数据库调查，您需要了解 SQL 语句的 SQL_ID，以便通过活动会话历史记录 (Active Session History, ASH)、自动工作量资料档案库 (Automatic Workload Repository, AWR) 和 Oracle SQLTXPLAIN (SQLT) 跟踪特定查询。
本主题介绍如何通过挖掘 Oracle Analytics 使用情况跟踪表和名为 V$SQL 的 Oracle 数据库系统表（对于 RAC 数据库，则是名为 GV$SQL 的系统表）查找 SQL_ID。
V$SQL 表是 Oracle 数据库系统表，用于跟踪单个 SQL 查询的统计信息。对于您运行的每个 SQL 语句，表中都有对应的一行，并且每行都由 SQL_ID 列唯一标识。您可以使用此 SQL_ID 在整个 Oracle 数据库中跟踪给定的 SQL 语句。
您可在 V$SQL 表（对于 RAC 数据库，则为 GV$SQL 表）中找到许多有关查询的有用信息。
使用情况跟踪表
使用情况跟踪表不会直接跟踪 SQL_ID，但您可以轻松地向 V$SQL 表（对于 RAC 数据库，则为 GV$SQL 表）追溯 SQL_ID。
当您在 Oracle Analytics 中启用使用情况跟踪时，将在两个表中跟踪所有查询：
S_NQ_ACCT：包含逻辑查询S_NQ_DB_ACCT：包含物理查询
逻辑查询记录在逻辑查询表中，物理查询（或由逻辑查询衍生的查询）记录在物理查询表中。
您可以联接逻辑查询 ID 列上的逻辑表和物理表。逻辑表中的逻辑查询 ID 列为 ID，在物理表中该列为 LOGICAL_QUERY_ID。
查找 SQL_ID 的关键是物理表中的 PHYSICAL_HASH_ID 列。PHYSICAL_HASH_ID 值也写入 V$SQL表（或 GV$SQL 表）的 ACTION 列中。
Oracle BI Server 根据逻辑 SQL 查询的文本和物理 SQL 查询的文本计算散列代码。从 Oracle BI Server 运行的任何 SQL 查询的物理 SQL 散列代码都记录在 V$SQL 表的 ACTION 列中。有关更多信息，请参见将 S_NQ_ACCT 记录与 BI 查询日志关联。
设置
现在您已了解从何处查找 PHYSICAL_HASH_ID，您可以编写 SQL 语句，以将数据库中运行的 SQL 查询与 Oracle Analytics 中运行的特定分析相关联。
当使用情况跟踪表与数据仓库位于同一数据库实例中时，可以编写单个查询来查找 SQL_ID。
如果使用情况跟踪表和数据仓库位于不同的 Oracle 数据库实例中，则需要运行两个查询。首先，运行查询以从使用情况跟踪表中提取要调查的查询的 PHYSICAL_HASH_ID。其次，使用 PHYSICAL_HASH_ID 的值从 V$SQL 表中提取 SQL_ID 以筛选 ACTION 列。
示例 1
在此示例中，假设使用情况跟踪表和数据仓库位于同一位置。使用情况跟踪表和 V$SQL 表中的任何列或所有列都可以在查询中使用，但在此示例中，选择以下子集：
select o.sql_id, to_char(l.start_ts, 'YYYY-MM-DD HH24:MI:SS'), l.id as l_id, p.logical_query_id, l.hash_id, l.saw_src_path, l.query_src_cd, l.success_flg, l.num_db_query, l.query_text, p.query_text, o.sql_text, p.physical_hash_id, o.action from usage_tracking.s_nq_acct l, usage_tracking.s_nq_db_acct p, v$sql o where l.id = p.logical_query_id and o.action = p.physical_hash_id and l.start_dt > trunc(sysdate - 1) and l.end_dt < trunc(sysdate) order by l.start_ts, l.id, l.hash_id, p.physical_hash_id, o.sql_id;
示例 2
在此示例中，假设使用情况跟踪表和数据仓库位于不同的 Oracle 数据库中。
首先，针对使用情况跟踪表编写查询，以获取 PHYSICAL_HASH_ID：
select to_char(l.start_ts, 'YYYY-MM-DD HH24:MI:SS'), l.id as l_id, p.logical_query_id, l.hash_id, l.saw_src_path, l.query_src_cd, l.success_flg, l.num_db_query, l.query_text, p.query_text, p.physical_hash_id from usage_tracking.s_nq_acct l, usage_tracking.s_nq_db_acct p where l.id = p.logical_query_id and l.start_dt > trunc(sysdate - 1) and l.end_dt < trunc(sysdate) order by l.start_ts, l.id,l.hash_id, p.physical_hash_id;
接下来，使用 PHYSICAL_HASH_ID 的值作为筛选器，针对 V$SQL 表编写查询以获取 SQL_ID：
select o.action, o.sql_id, o.sql_text from v$sql o where o.action = ‘<physical_hash_id>’ order by o.sql_id;
如果您的数据库是 RAC 数据库，则使用 GV$SQL 表（而不是 V$SQL 表）来获取 SQL_ID：
select o.action, o.sql_id, o.sql_text from gv$sql o where o.action = '<physical_hash_id>' order by o.sql_id;
如果您要对初始化块进行故障排除，则此方法不适用，因为初始化块使用情况跟踪表 (S_NQ_INITBLOCK) 不包含物理散列 ID。
示例 3
在此示例中，使用 'A - Sample Sales' 主题区域，并且仅从使用情况跟踪表中选择几列。
从 'A - Sample Sales' 中，运行以下查询：
[2022-02-04T15:11:17.629+00:00] [OBIS] [TRACE:2] [USER-0] [] [ecid: e49b96a8-33c4-4ba7-a877-e564d207eca1-00242531,0:1:38:3] [sik: bootstrap] [tid: dd1bc700] [messageId: USER-0] [requestid: 33e30020] [sessionid: 33e30000] [username: oacadmin] ############################################## [[ -------------------- SQL Request, logical request hash: cee7ec94 SET VARIABLE QUERY_SRC_CD='Report';SELECT 0 s_0, "A - Sample Sales"."Offices"."D1 Office" s_1, "A - Sample Sales"."Base Facts"."10- Variable Costs" s_2, "A - Sample Sales"."Base Facts"."11- Fixed Costs" s_3 FROM "A - Sample Sales" ORDER BY 2 ASC NULLS LAST FETCH FIRST 125001 ROWS ONLY ]]
从使用情况跟踪逻辑表中选择 start_ts、id、hash_id、query_src_cd 和 query_text 时，将会获取 ID 值 E841EBB79217270A660CDD3EFB5D986C。
接下来，从使用情况跟踪物理表中选择 logical_query_id、hash_id、physical_hash_id 和 query_text，其中 LOGICAL_QUERY_ID 为 E841EBB79217270A660CDD3EFB5D986C。
查看管理会话日志时，逻辑查询会衍生 QUERY_TEXT 列中的 SQL 代码：
[2022-02-04T15:11:17.637+00:00] [OBIS] [TRACE:2] [USER-18] [] [ecid: e49b96a8-33c4-4ba7-a877-e564d207eca1-00242531,0:1:38:5] [sik: bootstrap] [tid: dd1bc700] [messageId: USER-18] [requestid: 33e30020] [sessionid: 33e30000] [username: oacadmin] -------------------- Sending query to database named 01 - Sample App Data (ORCL) (id: <<62275>>), client type Oracle Call Interface (OCI), connection pool named Sample Relational Connection, logical request hash cee7ec94, physical request hash bd6708b8: [[
WITH
SAWITH0 AS (select sum(T5398.Cost_Fixed) as c1,
sum(T5398.Cost_Variable) as c2,
T5257.Office_Dsc as c3,
T5257.Office_Key as c4
from
BISAMPLE.SAMP_OFFICES_D T5257 /* D30 Offices */ ,
BISAMPLE.SAMP_REVENUE_F T5398 /* F10 Billed Rev */
where ( T5257.Office_Key = T5398.Office_Key )
group by T5257.Office_Dsc, T5257.Office_Key),
SAWITH1 AS (select 0 as c1,
D1.c3 as c2,
D1.c2 as c3,
D1.c1 as c4,
D1.c4 as c5
from
SAWITH0 D1)
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3, D1.c4 as c4 from ( select D1.c1 as c1,
D1.c2 as c2,
D1.c3 as c3,
D1.c4 as c4
from
SAWITH1 D1
order by c2 ) D1 where rownum <= 125001
]]最后，从 V$SQL 表中选择 action、sql_id 和 sql_text，其中 Action 为 bd6708b8。
sql_text 列中的查询与使用情况跟踪物理表中的 SQL 代码相同。从中可以看到，所讨论查询的 sql_id 是 1gxhc0acmztwk。
如果再次运行相同的查询，则会使用新 ID 向使用情况跟踪逻辑表添加另一行，但 hash_id 是相同的。
类似地，使用新的 logical_query_id 向使用情况跟踪物理表添加另一行，但 hash_id 和 physical_hash_id 保持不变。
示例 4
如果对基于相同逻辑和物理模型的主题区域运行类似的逻辑查询，则也会重用 physical_hash_id。例如，如果针对 'C - Sample Costs' 运行类似的查询：
[2022-02-04T16:10:17.862+00:00] [OBIS] [TRACE:2] [USER-0] [] [ecid: e49b96a8-33c4-4ba7-a877-e564d207eca1-00242ce7,0:1:15:3] [sik: bootstrap] [tid: 58504700] [messageId: USER-0] [requestid: 13c9003c] [sessionid: 13c90000] [username: oacadmin] ############################################## [[ -------------------- SQL Request, logical request hash: 7b5ea9b1 SET VARIABLE QUERY_SRC_CD='Report';SELECT 0 s_0, "C - Sample Costs"."Offices"."D1 Office" s_1, "C - Sample Costs"."Base Facts"."10- Variable Costs" s_2, "C - Sample Costs"."Base Facts"."11- Fixed Costs" s_3 FROM "C - Sample Costs" ORDER BY 2 ASC NULLS LAST FETCH FIRST 125001 ROWS ONLY ]]
此逻辑查询衍生的 SQL 代码与针对 'A - Sample Sales' 运行的查询中的 SQL 代码相同：
[2022-02-04T16:10:17.866+00:00] [OBIS] [TRACE:2] [USER-18] [] [ecid: e49b96a8-33c4-4ba7-a877-e564d207eca1-00242ce7,0:1:15:5] [sik: bootstrap] [tid: 58504700] [messageId: USER-18] [requestid: 13c9003c] [sessionid: 13c90000] [username: oacadmin] -------------------- Sending query to database named 01 - Sample App Data (ORCL) (id: <<52912>>), client type Oracle Call Interface (OCI), connection pool named Sample Relational Connection, logical request hash 7b5ea9b1, physical request hash bd6708b8: [[
WITH
SAWITH0 AS (select sum(T5398.Cost_Fixed) as c1,
sum(T5398.Cost_Variable) as c2,
T5257.Office_Dsc as c3,
T5257.Office_Key as c4
from
BISAMPLE.SAMP_OFFICES_D T5257 /* D30 Offices */ ,
BISAMPLE.SAMP_REVENUE_F T5398 /* F10 Billed Rev */
where ( T5257.Office_Key = T5398.Office_Key )
group by T5257.Office_Dsc, T5257.Office_Key),
SAWITH1 AS (select 0 as c1,
D1.c3 as c2,
D1.c2 as c3,
D1.c1 as c4,
D1.c4 as c5
from
SAWITH0 D1)
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3, D1.c4 as c4 from ( select D1.c1 as c1,
D1.c2 as c2,
D1.c3 as c3,
D1.c4 as c4
from
SAWITH1 D1
order by c2 ) D1 where rownum <= 125001
]]首先，使用使用情况跟踪逻辑表来查找 ID。您可以看到，逻辑 hash_id 与针对 'A - Sample Sales' 运行的查询不同。
在使用情况跟踪物理表中，您可以看到，即使逻辑 hash_id 不同，physical_hash_id 也是相同的。
示例 5
在此示例中，运行相同的查询，但这次单击刷新。请注意，变量 OBIS_REFRESH_CACHE=1 表示刷新。正如预期的那样，另一行被插入到使用情况跟踪逻辑表中，但它具有不同的逻辑 hash_id。
但是，当您查询使用情况跟踪物理表时，可以看到所有查询都具有相同的 physical_hash_id。
由于这四个逻辑查询都具有相同的 physical_hash_id，因此在 V$SQL 表中只能看到此查询的单个记录。
示例 6
您可以使用相同的方法对基于主题区域 (RPD) 或数据库连接的数据可视化查询进行故障排除。对于数据库连接，这包括用于填充数据集的数据可视化和查询。
您可以根据 QUERY_SRC_CD 列的值确定查询类型，即数据可视化、数据集、分析、ODBC 等。例如，数据可视化查询的值为 Visual Analyzer，用于填充数据集的查询的值为 data-prep，分析的值为 Report，而某些内部 ODBC 过程调用的查询的值为 Soap。
要为数据可视化生成 SQL 语句，必须将底层数据集的“数据访问”更改为“实时”。
在此示例中，将基于 Oracle 数据库连接，针对数据集创建数据可视化查询（类似于前面的查询）：
[2022-02-03T19:42:06.564+00:00] [OBIS] [TRACE:2] [USER-0] [] [ecid: f95b5f1b-1e5c-4604-b82a-3eb3717f3aa6-002aa26e,0:1:1:3] [sik: bootstrap] [tid: 58b0a700] [messageId: USER-0] [requestid: ed830023] [sessionid: ed830000] [username: oacadmin] ############################################## [[
-------------------- SQL Request, logical request hash:
3158b05
SET VARIABLE QUERY_SRC_CD='Visual Analyzer',SAW_SRC_PATH='{"viewID":"view!1","currentCanvas":"canvas!1"}',ENABLE_DIMENSIONALITY = 1; SELECT
0 s_0,
XSA('oacadmin'.'BISAMPLE_OfficeRevenue')."SAMP_OFFICES_D"."OFFICE_DSC" s_1,
XSA('oacadmin'.'BISAMPLE_OfficeRevenue')."SAMP_REVENUE_F"."COST_FIXED" s_2,
XSA('oacadmin'.'BISAMPLE_OfficeRevenue')."SAMP_REVENUE_F"."COST_VARIABLE" s_3
FROM XSA('oacadmin'.'BISAMPLE_OfficeRevenue')
ORDER BY 2 ASC NULLS LAST
FETCH FIRST 125001 ROWS ONLY
/* AdditionalDetail='VisualAnalyzer' */
这将衍生以下 SQL 代码：
[2022-02-03T19:42:06.960+00:00] [OBIS] [TRACE:2] [USER-18] [] [ecid: f95b5f1b-1e5c-4604-b82a-3eb3717f3aa6-002aa26e,0:1:1:5] [sik: bootstrap] [tid: 58b0a700] [messageId: USER-18] [requestid: ed830023] [sessionid: ed830000] [username: oacadmin] -------------------- Sending query to database named 'oacadmin'.'BISAMPLE' (id: <<147945>>), client type OCI 10g/11g, connection pool named 'oacadmin'.'BISAMPLE', logical request hash 3158b05, physical request hash c48e8741: [[
WITH
SAWITH0 AS (select T1000005.OFFICE_KEY as c1,
T1000005.OFFICE_DSC as c2
from
BISAMPLE.SAMP_OFFICES_D T1000005),
SAWITH1 AS (select T1000008.OFFICE_KEY as c1,
T1000008.COST_FIXED as c2,
T1000008.COST_VARIABLE as c3
from
BISAMPLE.SAMP_REVENUE_F T1000008),
SAWITH2 AS (select D1.c2 as c1,
D2.c2 as c2,
D2.c3 as c3
from
SAWITH0 D1 inner join SAWITH1 D2 On D1.c1 = D2.c1),
SAWITH3 AS (select D102.c1 as c1,
sum(D102.c2) as c2,
sum(D102.c3) as c3
from
SAWITH2 D102
group by D102.c1)
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3, D1.c4 as c4 from ( select 0 as c1,
D110.c1 as c2,
D110.c2 as c3,
D110.c3 as c4
from
SAWITH3 D110
order by c2 ) D1 where rownum <= 125001从使用情况跟踪逻辑表中，可以找到 hash_id，以用作使用情况跟踪物理表的筛选器。
从使用情况跟踪物理表中，可以找到 physical_hash_id。
当您查询 V$SQL 表时，可以再次找到 SQL_ID。
您还可以在管理会话日志中找到逻辑 hash_id 和 physical_hash_id（请参见前面的日志示例中突出显示的部分）。这意味着您可以从日志本身找到 SQL_ID。利用使用情况跟踪表的好处在于，管理会话中的日志条目是临时条目，因此除非您在运行查询的同时收集散列 ID，否则它们就会丢失。
但是，只有在查询完成时，数据才会写入使用情况跟踪表。因此，如果您要对尚未完成的长时间运行的查询进行故障排除，并且希望确定 sql_id，则可以从管理会话日志中获取逻辑 hash_id 和 physical_hash_id。
如果您要对 SQL 语句进行故障排除，并且需要调查数据库，则可以将使用情况跟踪表和 V$SQL 系统表（或 GV$SQL）中的信息相联接，以快速找到您要调查的 SQL 语句的 SQL_ID。