Hitta SQL_ID för en Oracle Analytics-fråga
När du justerar frågor för Oracle Analytics tittar du på datamodellen, rapportdesignen, infopanelsdesignen och nätverkskonfigurationen och behöver ibland även undersöka databasen.
Tabellen V$SQL
Om du behöver undersöka databasen måste du känna till SQL-satsens SQL_ID så att du kan spåra den specifika frågan via historiken för den aktiva sessionen (ASH), det automatiska datalagret för arbetsbelastningar (AWR), och Oracle SQLTXPLAIN (SQLT).
I det här avsnittet beskrivs hur du hittar SQL_ID genom att granska användningsspårningstabellerna i Oracle Analytics och Oracle-databasens systemtabell V$SQL (eller GV$SQL om det är en RAC-databas).
Tabellen V$SQL är en systemtabell för Oracle-databaser som spårar statistik för enskilda SQL-frågor. Det finns en rad i tabellen för varje SQL-sats du kör, och varje rad identifieras via kolumnen SQL_ID . Du kan använda SQL_ID-värdet till att spåra en viss SQL-sats genom hela Oracle-databasen.
Du kan hitta mycket användbar information om dina frågor i tabellen V$SQL (eller GV$SQL om det är en RAC-databas).
Användningsspårningstabeller
Användningsspårningstabellerna spårar inte SQL_ID direkt, men du kan enkelt spåra SQL_ID tillbaka till V$SQL-tabellen (eller GV$SQL om det är en RAC-databas).
När du aktiverar användningsspårning i Oracle Analytics spåras alla frågor i två tabeller:
S_NQ_ACCT: innehåller logiska frågorS_NQ_DB_ACCT: innehåller fysiska frågor
Logiska frågor loggas i den logiska frågetabellen och fysiska frågor (eller de frågor som den logiska frågan genererar) loggas i den fysiska frågetabellen.
Du kan koppla de logiska och fysiska tabellerna via ID-kolumnen i den logiska frågetabellen. Kolumnen för den logiska frågans ID heter ID i den logiska tabellen och LOGICAL_QUERY_ID. i den fysiska tabellen.
När du ska hitta SQL_ID använder du kolumnen PHYSICAL_HASH_ID i den fysiska tabellen. Värdet PHYSICAL_HASH_ID skrivs även till tabellen V$SQL (eller tabellen GV$SQL) i kolumnen ACTION.
Oracle BI-servern beräknar en hashkod från texten i den logiska SQL-frågan och texten i de fysiska SQL-frågorna. Den fysiska SQL-hashkoden för SQL-frågor som körs från Oracle BI-servern lagras i kolumnen ACTION i tabellen V$SQL. Mer information finns i Associera S_NQ_ACCT-posten med BI-frågeloggen.
Mer information om kolumnerna i användningsspårningen finns i Spåra användning och Förstå tabellerna för användningsspårning.
Inställningar
Nu när du vet var du hittar PHYSICAL_HASH_ID kan du skriva en SQL-sats som korrelerar den SQL-fråga som körs i databasen med en viss analys som körs i Oracle Analytics.
När användningsspårningstabellerna lagras i samma databasinstans som datalagret kan du skriva en enda fråga för att hitta SQL_ID.
Om användningsspårningstabellerna och datalagret ligger i olika Oracle-databasinstanser måste du köra två frågor. Först kör du en fråga för att hämta PHYSICAL_HASH_ID för den fråga du vill utreda från användningsspårningstabellerna. Sedan hämtar du SQL_ID från V$SQL-tabellen genom att filtrera kolumnen ACTION med värdet för PHYSICAL_HASH_ID.
Exempel 1
I det här exemplet antar vi att användningsspårningstabellerna och datalagret ligger i samma instans. Du kan använda valfria kolumner från användningsspårningen och V$SQL-tabellen i frågan, men i det här exemplet väljer du följande delmängd:
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;
Exempel 2
I det här exemplet antar vi att användningsspårningstabellerna och datalagret ligger i olika Oracle-databaser.
Skriv först en fråga mot användningsspårningstabellerna så att du får fram 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;
Sedan skriver du en fråga mot V$SQL-tabellen för att få fram SQL_ID, med värdena för PHYSICAL_HASH_ID som filter:
select o.action, o.sql_id, o.sql_text from v$sql o where o.action = ‘<physical_hash_id>’ order by o.sql_id;
Om du har en RAC-databas i stället för V$SQL-tabellen använder du GV$SQL-tabellen till att få fram 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;
Den här metoden fungerar inte om du felsöker initieringsblock, eftersom användningsspårningstabellen för initieringsblock (S_NQ_INITBLOCK) inte innehåller något fysiskt hash-id.
Exempel 3
I det här exemplet använder du ämnesområdet A - Sample Sales och väljer några få kolumner från användningsspårningstabellerna.
Kör följande fråga från 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 ]]
När du väljer start_ts, id, hash_id, query_src_cd och query_text från den logiska användningsspårningstabellen får du fram ID-värdet E841EBB79217270A660CDD3EFB5D986C.
Välj sedan logical_query_id, hash_id, physical_hash_id och query_text från den fysiska användningsspårningstabellen där LOGICAL_QUERY_ID är E841EBB79217270A660CDD3EFB5D986C.
När du tittar på loggen Hantera sessioner genererar den logiska frågan den SQL-kod som finns i kolumnen 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älj slutligen action, sql_id och sql_text från V$SQL-tabellen där Action är bd6708b8.
Frågan i kolumnen sql_text är samma SQL-kod som i den fysiska användningsspårningstabellen. Nu kan du se att sql_id för den aktuella frågan är 1gxhc0acmztwk.
Om du kör samma fråga igen läggs en ny rad till i den logiska användningsspårningstabellen med ett nytt ID, men hash_id ändras inte.
På samma sätt läggs en ny rad till i den fysiska användningsspårningstabellen med ett nytt logical_query_id, men varken hash_id eller physical_hash_id ändras.
Exempel 4
physical_hash_id återanvänds också om du kör en liknande logisk fråga mot ett ämnesområde som baseras på samma logiska och fysiska modeller. Om du till exempel kör en liknande fråga mot 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 ]]
Den här logiska frågan genererar samma SQL-kod som du såg i frågan du körde mot A – Sample Sales:
[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
]]Använd först den logiska användningsspårningstabellen till att hitta id-värdet. Du kan se att logiskt hash_id är annorlunda än frågan du körde mot A – Sample Sales.
I den fysiska användningsspårningstabellen ser du att det värdet för logiskt hash_id är annorlunda men att physical_hash_id är oförändrat.
Exempel 5
I det här exemplet kör du samma frågor, men den här gången klickar du på Förnya. Observera att variabeln OBIS_REFRESH_CACHE=1 indikerar förnyelsen. Som förväntat infogas nu en ny rad i den logiska användningsspårningstabellen med ett annat värde för logiskt hash_id.
När du kör en fråga mot den fysiska användningsspårningstabellen ser du dock att alla frågor har samma värde för physical_hash_id.
Eftersom de här fyra logiska frågorna har samma physical_hash_id ser du bara en post för frågan i V$SQL-tabellen.
Exempel 6
På samma sätt kan du felsöka datavisualiseringsfrågor som baseras på ett ämnesområde (RPD) eller en databasanslutning. När det gäller databasanslutningar ingår även de datavisualiseringar och frågor som används till att befolka datamängder.
Du kan fastställa frågetypen, exempelvis datavisualisering, datamängd, analys eller ODBC, från värdet i kolumnen QUERY_SRC_CD. Datavisualiseringsfrågor har till exempel värdet Visual Analyzer, en fråga som används till att fylla på en datamängd har värdet data-prep, analyser har värdet Report och frågor för anrop till interna ODBC-procedurer har värdet Soap.
Om du vill generera en SQL-sats för en datavisualisering måste du ändra dataåtkomsten till Live för den underliggande datamängden.
I det här exemplet skapar du en datavisualiseringsfråga (som liknar de tidigare frågorna) mot datamängden baserat på en anslutning till en Oracle-databas:
[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' */
Då genereras följande SQL-kod:
[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 <= 125001I den logiska användningsspårningstabellen kan du se vilket hash_id som används till att filtrera mot den fysiska användningsspårningstabellen.
I den fysiska användningsspårningstabellen hittar du värdet för physical_hash_id.
När du kör en fråga mot V$SQL-tabellen hittar du SQL_ID-värdet igen.
Du kan även hitta logiska hash_id- och physical_hash_id-värden i loggen Hantera sessioner (se de markerade sektionerna i de tidigare loggexemplen). Det innebär att du kan hitta SQL_ID-värdet i själva loggen. Fördelen med att använda användningsspårningstabellen är att loggposterna i Hantera sessioner är tillfälliga, så de förloras om du inte samlar in hash-id:n samtidigt som frågan körs.
Data skrivs dock bara till användningsspårningstabellerna när en fråga har slutförts. Om du felsöker en långvarig fråga som inte har slutförts ännu och vill fastställa sql_id kan du få fram de logiska hash_id- och physical_hash_id-värdena från loggen Hantera sessioner.
Om du felsöker en SQL-sats och behöver undersöka databasen kan du koppla information i användningsspårningstabellerna och systemtabellen V$SQL (eller GV$SQL) för att snabbt hitta SQL_ID för den SQL-sats du undersöker.