尋找 Oracle Analytics 查詢的 SQL_ID
當您在調整 Oracle Analytics 的查詢時，需要注意到資料模型、報表設計、儀表板設計、網路組態，有時甚至必須檢查資料庫。
V$SQL 表格
在檢查資料庫時，您必須知道 SQL 敘述句的 SQL_ID，才能透過作用中階段作業歷史記錄 (ASH)、自動工作負載儲存區域 (AWR) 以及 Oracle SQLTXPLAIN (SQLT) 追蹤特定查詢。
本主題描述如何探勘 Oracle Analytics 使用狀況追蹤表格和 Oracle Database 系統表格 V$SQL (若是 RAC 資料庫，則為 GV$SQL)，以取得 SQL_ID。
V$SQL 是 Oracle Database 系統表格，可供追蹤個別 SQL 查詢的統計資料。在此表格中，您執行的每個 SQL 敘述句都會有一列，且以 SQL_ID 資料欄為唯一識別。您可以使用此 SQL_ID 追蹤 Oracle Database 中的指定 SQL 敘述句。
您可以從 V$SQL 表格 (若是 RAC 資料庫，則為 GV$SQL)，取得許多與查詢相關的實用資訊。
使用狀況追蹤表格
使用狀況追蹤表格並不會直接追蹤 SQL_ID，但您可以輕鬆透過 SQL_ID 追溯回 V$SQL 表格 (若是 RAC 資料庫，則為 GV$SQL)。
當您在 Oracle Analytics 啟用使用狀況追蹤後，系統會使用以下 2 個表格追蹤所有查詢：
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 Database 執行處理，您需要執行 2 個查詢。首先，執行查詢以從使用狀況追蹤表格提取想要檢查之查詢的 PHYSICAL_HASH_ID。接下來，使用 PHYSICAL_HASH_ID 的值篩選 ACTION 資料欄，從 V$SQL 提取 SQL_ID。
範例
在本範例中，假設使用狀況追蹤表格和資料倉儲在同一個位置。可以在查詢中使用「使用狀況追蹤」和 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;
在第二個範例中，假設使用狀況追蹤表格和資料倉儲位於不同的 Oracle Database。
首先，針對使用狀況追蹤表格撰寫查詢以取得 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;
接下來，針對 V$SQL 撰寫查詢以取得 SQL_ID，其中使用 PHYSICAL_HASH_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 表格取得 SQL_ID，而不是使用 V$SQL。
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。
在下一個範例中，您使用 ‘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：
當您查看管理階段作業日誌時，邏輯查詢產生的 SQL 會在 QUERY_TEXT 資料欄中：
[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 會維持相同：
如果您對依據相同邏輯和實體模型的主題區域執行類似的邏輯查詢，也會重複使用 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 是相同的：
在另一個範例中，您執行了相同的查詢 (如上)，但這次您按了「重新整理」。請注意，OBIS_REFRESH_CACHE=1 變數代表重新整理。如先前所述，使用狀況追蹤邏輯表格中插入了另一個資料列，但它的 logical hash_id 不同。
但是，當您查詢使用狀況追蹤實體表格時，您會發現所有查詢的 physical_hash_id 都相同。
由於這 4 個邏輯查詢的 physical_hash_id 都相同，所以您在 V$SQL 會看到此查詢只有單一筆記錄：
您可以使用此相同的方法，排解依據主題區域 (RPD) 或資料庫連線之資料視覺化查詢的問題。若為資料庫連線，這包括資料視覺化和用於產生資料集的查詢。
您可以從 QUERY_SRC_CD 資料欄的值判斷查詢類型，亦即資料視覺化、資料集、分析、ODBC 等等。例如，資料視覺化查詢的值為 ‘Visual Analyzer’，用於產生資料集之查詢的值為 ‘data-prep，分析的值為 ‘Report’，而某些內部 ODBC 程序呼叫之查詢的值則為 ‘Soap’。
若要產生資料視覺化的 SQL 敘述句，您必須將相關資料集的資料存取變更為「即時」。
在本範例中，您對以 Oracle Database 連線為依據的資料集建立資料視覺化查詢 (與以上查詢類似)。
[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。