Finne SQL_ID for en Oracle Analytics-spørring
Når du finjusterer spørringer for Oracle Analytics, ser du på datamodellen, rapportutformingen, instrumentpanelutformingen og nettverkskonfigurasjonen, og av og til må du undersøke databasen.
V$SQL-tabell
For databaseundersøkelser må du kjenne verdien for SQL_ID i SQL-setningen, slik at du kan spore den spesifikke spørringen via Historikk for aktive økter (ASH), Automatisk arbeidsmengderegister (AWR), og Oracle SQLTXPLAIN (SQLT).
Dette emnet viser deg hvordan du finner SQL_ID ved å utvinne tabellene for brukssporing i Oracle Analytics kalt V$SQL-systemtabellen for Oracle-databasen (eller GV$SQL for en RAC-database).
V$SQL-tabellen er en systemtabell for Oracle-databasen som sporer statistikk for individuelle SQL-spørringer. Det er én rad i tabellen for hver enkelt SQL-setning du kjører, og hver enkelt rad identifiseres entydig av kolonnen SQL_ID. Du kan bruke denne SQL_ID til å spore en gitt SQL-setning gjennom hele Oracle-databasen.
Du finner mange nyttige opplysninger om spørringene i V$SQL-tabellen (eller GV$SQL for en RAC-database).
Tabeller for brukssporing
Tabellene for brukssporing sporer ikke SQL_ID direkte, men du kan enkelt spore SQL_ID tilbake til V$SQL-tabellen (eller GV$SQL for en RAC-database).
Når du aktiverer brukssporing i Oracle Analytics, spores alle spørringene i to tabeller:
S_NQ_ACCT: inneholder logiske spørringerS_NQ_DB_ACCTinneholder fysiske spørringer
Den logiske spørringen logges i den logiske spørringstabellen, og den fysiske spørringen (eller spørringer som er startet av den logiske spørringen) logger i den fysiske spørringstabellen.
Du kan sammenføye de logiske og fysiske tabellene i kolonnen med ID for logisk spørring. Kolonnen med ID for logisk spørring i den logiske tabellen er ID, og i den fysiske tabellen er det LOGICAL_QUERY_ID.
Nøkkelen til å finne SQL_ID er kolonnen PHYSICAL_HASH_ID i den fysiske tabellen. Verdien for PHYSICAL_HASH_ID skrives også til V$SQL-tabellen (eller GV$SQL-tabellen) i kolonnen ACTION.
Oracle BI Server beregner en hash-kode fra teksten i den logiske SQL-spørringen og teksten i de fysiske SQL-spørringene. Den fysiske SQL-hash-koden for alle SQL-spørringer som kjøres fra Oracle BI Server, registreres i kolonnen ACTION i V$SQL-tabellen. Hvis du vil ha flere opplysninger, kan du se Knytte S_NQ_ACCT-posten til BI-spørringsloggen.
Hvis du vil ha flere opplysninger om kolonner for brukssporing, kan du se Spor bruk og Forstå brukssporingstabellene.
Oppsett
Nå som du vet hvor du finner PHYSICAL_HASH_ID, kan du skrive en SQL-setning som gjør at SQL-spørringen som kjøres i databasen, samsvarer med en spesifikk analyse som kjøres i Oracle Analytics.
Når tabellene for brukssporing er i samme databaseforekomst som datavarehuset, kan du skrive én spørring for å finne SQL_ID.
Hvis tabellene for brukssporing og datavarehuset er i ulike Oracle-databaseforekomster, må du kjøre to spørringer. Først kjører du en spørring for å hente PHYSICAL_HASH_ID for spørringen du vil undersøke, fra tabellene for brukssporing. Deretter henter du SQL_ID fra V$SQL-tabellen ved å bruke verdien for PHYSICAL_HASH_ID til å filtrere kolonnen ACTION.
Eksempel 1
Dette eksemplet forutsetter at tabellene for brukssporing og datavarehuset ligger i samme forekomst. Noen av eller alle kolonnene fra tabellene for brukssporing og V$SQL-tabellen kan brukes i spørringen, men i dette eksemplet velger du følgende delsett:
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;
Eksempel 2
I dette eksemplet forutsettes det at tabellene for brukssporing og datavarehuset ligger i ulike Oracle-databaser.
Skriv først en spørring mot tabellene for brukssporing for å hente 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;
Deretter skriver du en spørring mot V$SQL-tabellen for å hente SQL_ID ved å bruke verdiene for 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;
Hvis du har en RAC-database, bruker du ikke V$SQL-tabellen, men GV$SQL-tabellen til å hente 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;
Denne metoden fungerer ikke hvis du feilsøker initialiseringsblokker, ettersom tabellen for brukssporing for initialiseringsblokker (S_NQ_INITBLOCK) ikke inneholder en fysisk nøkkel-ID.
Eksempel 3
I dette eksemplet bruker du emneområdet "A - Sample Sales" og velger bare noen få kolonner fra tabellene for brukssporing.
Du kjører følgende spørring fra 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 velger start_ts, id, hash_id, query_src_cd og query_text fra den logiske tabellen for brukssporing, får du ID-verdien E841EBB79217270A660CDD3EFB5D986C.
Deretter velger du logical_query_id, hash_id, physical_hash_id og query_text fra den fysiske tabellen for brukssporing, der LOGICAL_QUERY_ID er E841EBB79217270A660CDD3EFB5D986C.
Når du ser på loggen for Administrer økter, starter den logiske spørringen SQL-koden som er i kolonnen 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
]]Til slutt velger du action, sql_id og sql_text fra V$SQL-tabellen, der Action er bd6708b8.
Spørringen i kolonnen sql_text er samme SQL-kode som i den fysiske tabellen for brukssporing. Fra denne ser du at sql_id for den aktuelle spørringen er 1gxhc0acmztwk.
Hvis du kjører den samme spørringen på nytt, legges det til ny rad i den logiske tabellen for brukssporing med en ny ID, men hash_id er den samme.
På samme måte legges det til en ny rad i den fysiske tabellen for brukssporing med ny logical_query_id, men både hash_id og physical_hash_id er uendret.
Eksempel 4
physical_hash_id brukes også på nytt hvis du kjører en lignende logisk spørring mot et emneområde som er basert på de samme logiske og fysiske modellene. For eksempel hvis du kjører en lignende spørring 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 ]]
Denne logiske spørringen starter samme SQL-kode som i spørringen du kjørte 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
]]Bruk først den logiske tabellen for brukssporing til å finne ID-en. Du kan se at logisk hash_id er forskjellig fra spørringen som ble kjørt mot A – Sample Sales.
I den fysiske tabellen for brukssporing ser du at selv om logisk hash_id er forskjellig, er physical_hash_id identisk.
Eksempel 5
I dette eksemplet kjører du de samme spørringene, men denne gangen klikker du på Oppfrisk. Legg merke til variabelen OBIS_REFRESH_CACHE=1 for å angi oppfriskingen. Som forventet settes det inn en ny rad i den logiske tabellen for brukssporing, men den har en annen logisk hash_id.
Når du utfører en spørring i den fysiske tabellen for brukssporing, kan du imidlertid se at alle spørringene har samme physical_hash_id.
Ettersom disse fire logiske spørringene har samme physical_hash_id, ser du bare én post i V$SQL-tabellen for denne spørringen:
Eksempel 6
Du kan bruke den samme metoden til å feilsøke datavisualiseringsspørringer basert på et emneområde (RPD) eller en databasetilkobling. For databasetilkoblinger inkluderer dette både datavisualiseringer og spørringer som brukes til å fylle ut datasett.
Du kan fastsette spørringstypen, det vil si datavisualisering, datasett, analyse, ODBC og så videre, fra verdien i kolonnen QUERY_SRC_CD. Datavisualiseringsspørringer har for eksempel verdien Visual Analyzer, en spørring som brukes til å fylle ut et datasett, har verdien data-prep, analyser har verdien Report og spørringer for enkelte interne ODBC-prosedyrekall har verdien Soap.
Hvis du vil generere en SQL-setning for en datavisualisering, må du endre Datatilgang til Direkte for det underliggende datasettet.
I dette eksemplet oppretter du en datavisualiseringsspørring (som ligner på de forrige spørringene ) mot et datasett basert på en tilkobling til en 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' */
Som starter følgende SQL-kode:
[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 <= 125001Fra den logiske tabellen for brukssporing finner du hash_id som skal brukes som et filter mot den fysiske tabellen for brukssporing.
Fra den fysiske tabellen for brukssporing finner du physical_hash_id.
Når du utfører en spørring mot V$SQL-tabellen, finner du SQL_ID på nytt:
Du kan også finne logisk hash_id og physical_hash_id i loggen for Administrer økter (se de uthevede delene i de forrige loggeksemplene). Dette betyr at du kan finne SQL_ID fra selve loggen. Fordelen med å bruke tabellene for brukssporing er at loggoppføringer i Administrer økter er midlertidige. Så med mindre du samler inn nøkkel-ID-er samtidig som du kjører spørringen, går de tapt.
Data skrives imidlertid bare til tabellene for brukssporing når en spørring er fullført. Det vil si at hvis du feilsøker en langvarig spørring som ikke er fullført ennå, og du vil fastsette sql_id, kan du hente logisk hash_id og physical_hash_id fra loggen for Administrer økter.
Hvis du feilsøker en SQL-setning og må undersøke databasen, kan du sammenføye opplysninger i tabellene for brukssporing og V$SQL-systemtabellen (eller GV$SQL) for raskt å finne SQL_ID for SQL-setningen du undersøker.