Amikor az Oracle Analytics lekérdezéseit finomhangolja, meg kell vizsgálnia az adatmodellt, a kimutatástervet, az irányítópulttervet, a hálózati konfigurációt, és néha meg kell vizsgálnia az adatbázist.
A V$SQL-tábla
Az adatbázis-vizsgálatokhoz ismernie kell az SQL-utasítás SQL_ID
azonosítóját, hogy nyomon tudja követni az adott lekérdezést az Active Session History (ASH), az Automatic Workload Repository (AWR), és az Oracle SQLTXPLAIN (SQLT) segítségével.
Ez a témakör bemutatja, hogyan találhatja meg az SQL_ID
azonosítót az Oracle Analytics használatkövető tábláinak és a V$SQL
Oracle adatbázis-rendszertáblának (vagy RAC adatbázis esetében a GV$SQL
táblának) az adatbányászásával.
A V$SQL
-tábla egy Oracle adatbázis-rendszertábla, amely nyomon követi az egyes SQL-lekérdezések statisztikáit. Minden egyes futtatott SQL-utasításhoz egy sor tartozik a táblában, és minden sort egyedileg azonosít az SQL_ID
oszlop. Az SQL_ID
használatával nyomon követheti az adott SQL utasítást az Oracle adatbázisban.
Rengeteg hasznos információt talál a lekérdezésekről a V$SQL
táblán (vagy RAC adatbázis esetében a GV$SQL
táblán).
Használatkövető táblák
A használatkövető táblák nem követik közvetlenül az SQL_ID
azonosítót, de az SQL_ID
könnyen visszakövethető a V$SQL
táblára (vagy RAC adatbázis esetében a GV$SQL
táblára).
Ha engedélyezi a használatkövetést az Oracle Analytics szolgáltatásban, az összes lekérdezést két tábla követi nyomon:
S_NQ_ACCT
: logikai lekérdezéseket tartalmazS_NQ_DB_ACCT
: fizikai lekérdezéseket tartalmazA logikai lekérdezés a logikai lekérdezési táblában, a fizikai lekérdezés (vagy a logikai lekérdezés által generált lekérdezés) pedig a fizikai lekérdezési táblán kerül naplózásra.
A logikai és fizikai táblákat a logikai lekérdezésazonosító oszlopban kapcsolhatja össze. A logikai táblán a logikai lekérdezésazonosító oszlop az ID
, a fizikai táblán pedig a LOGICAL_QUERY_ID.
Az SQL_ID
megtalálásának kulcsa a fizikai tábla PHYSICAL_HASH_ID
oszlopa. A PHYSICAL_HASH_ID
érték a V$SQL
(vagy GV$SQL
) táblába is be van írva az ACTION
oszlopban.
Az Oracle BI Server a logikai SQL-lekérdezés szövegéből és a fizikai SQL-lekérdezések szövegéből hash-kódot számít ki. Az Oracle BI Server kiszolgálóról futtatott bármely SQL-lekérdezés fizikai SQL-kivonatkódja a V$SQL
tábla ACTION
oszlopában kerül rögzítésre. További információkért lásd: Az S_NQ_ACCT rekord társítása a BI lekérdezési naplóval.
A különféle használatkövetési oszlopokkal kapcsolatos további információkért lásd: Használat nyomon követése és A használatkövetési táblák ismertetése.
Beállítás
Most, hogy tudja, hol található a PHYSICAL_HASH_ID
, képes olyan SQL-utasítást írni, amely az adatbázisban futó SQL-lekérdezést összekapcsolja az Oracle Analytics rendszerben futó konkrét elemzéssel.
Ha a használatkövető táblák ugyanabban az adatbázispéldányban vannak, mint az adattárház, akkor egyetlen lekérdezést írhat az SQL_ID.
megkereséséhez
Ha a használatkövető táblák és az adattárház különböző Oracle adatbázispéldányokban találhatók, két lekérdezést kell lefuttatnia. Először futtasson le egy lekérdezést, hogy lekérje a vizsgálni kívánt lekérdezés PHYSICAL_HASH_ID
azonosítóját a használatkövető táblákból. Másodszor, le kell kérnie az SQL_ID
azonosítót a V$SQL
táblából a PHYSICAL_HASH_ID
értékének használatával, hogy kiszűrje az ACTION
oszlopot.
1. példa
Ebben a példában azt feltételezzük, hogy a használatkövetési táblák és az adattárház egy helyen találhatók. A használatkövetés és a V$SQL
táblák bármelyike vagy mindegyik oszlopa használható a lekérdezésben, de ebben a példában a következő részhalmazt kell kiválasztani:
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. példa
Ebben a példában azt feltételezzük, hogy a használatkövető táblák és az adattárház különböző Oracle-adatbázisokban találhatók.
Először írjon egy lekérdezést a használatkövető táblákra a PHYSICAL_HASH_ID
lekéréséhez:
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;
Ezután írjon egy lekérdezést a V$SQL
táblára az SQL_ID
azonosító lekéréséhez, és használja a PHYSICAL_HASH_ID
értékeit szűrőként.
select o.action, o.sql_id, o.sql_text from v$sql o where o.action = ‘<physical_hash_id>’ order by o.sql_id;
Ha RAC-adatbázissal rendelkezik, a V$SQL
tábla helyett a GV$SQL
táblát használja az SQL_ID
lekéréséhez.
select o.action, o.sql_id, o.sql_text from gv$sql o where o.action = '<physical_hash_id>' order by o.sql_id;
Ez a módszer nem működik, ha inicializálási blokkokkal kapcsolatos hibaelhárítást végez, mivel az inicializálási blokk használatkövető táblája (S_NQ_INITBLOCK
) nem tartalmaz fizikai hash-azonosítót.
3. példa
Ebben a példában az A – Mintaértékesítés témakört használja, és csak néhány oszlopot jelöl ki a használatkövető táblákon.
Az A – Mintaértékesítés részben a következő lekérdezést kell lefuttatnia:
[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 ]]
Amikor a start_ts
, id
, hash_id
, query_src_cd
és query_text
elemeket választja ki a használatkövetési logikai táblán, azt kapja, hogy az ID
értéke E841EBB79217270A660CDD3EFB5D986C
.
Ezután válassza ki a logical_query_id
, hash_id
, physical_hash_id
és query_text
értéket a használatkövető fizikai táblán, ahol a LOGICAL_QUERY_ID
értéke E841EBB79217270A660CDD3EFB5D986C
.
Ha megnézi a Munkamenetek kezelése naplót, a logikai lekérdezés a QUERY_TEXT
oszlopban található SQL-kódot generálja:
[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égül válassza ki az action
, sql_id
és az sql_text
elemet a V$SQL
-ben, ahol az Action
= bd6708b8
.
Az sql_text
oszlopban lévő lekérdezés ugyanaz az SQL-kód, amely a használatkövető fizikai táblán is megjelenik. Ebből látható, hogy a kérdéses lekérdezés sql_id
azonosítója 1gxhc0acmztwk
.
Ha ismét lefuttatja ugyanazt a lekérdezést, akkor egy másik sor kerül a használatkövető logikai táblára új azonosítóval, de a hash_id
ugyanaz marad.
Hasonlóan, egy másik sor kerül hozzáadásra a használatkövetési fizikai táblához új logical_query_id
azonosítóval, de mind a hash_id
, mind a physical_hash_id
változatlan marad.
4. példa
A physical_hash_id
azonosítót akkor is újból felhasználja a rendszer, ha hasonló logikai lekérdezést futtat le ugyanazon logikai és fizikai modelleken alapuló témakörben. Például ha egy hasonló lekérdezést futtat le a C – Mintaköltségek oszlopra:
[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 ]]
Ez a logikai lekérdezés ugyanazt az SQL-kódot generálja, mint az A – Mintaértékesítések lekérdezésben futtatott lekérdezésben:
[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 ]]
Először is használja a használatkövető logikai táblát az azonosító megkereséséhez. Láthatja, hogy a logikai hash_id
eltér az A – Mintaértesítések lekérdezéstől:
A használatkövető fizikai táblában azt látja, hogy bár a logikai hash_id
eltér, a physical_hash_id
megegyezik.
5. példa
Ebben a példában ugyanezeket a lekérdezéseket futtatja, de ezúttal a Frissítés gombra kattint. Figyelje meg az OBIS_REFRESH_CACHE=1
változót, amely a frissítést jelöli. Ahogy az várható volt, egy másik sor kerül be a használatkövető logikai táblába, de ennek eltérő a logikai hash_id.
azonosítója.
Amikor azonban lekérdezi a használatkövető fizikai táblázatot, láthatja, hogy minden lekérdezésnek ugyanaz a physical_hash_id.
azonosítója
Mivel ennek a négy logikai lekérdezésnek ugyanaz a physical_hash_id
azonosítója, ezért a lekérdezéshez csak egyetlen rekordot lát a V$SQL
táblában.
6. példa
Ugyanezt a módszert használhatja az adatmegjelenítési lekérdezések hibaelhárítására témakör (RPD) vagy adatbázis-kapcsolat alapján. Adatbázis-kapcsolatok esetében ez magában foglalja az adatmegjelenítéseket és az adatkészletek kitöltésére használt lekérdezéseket is.
A QUERY_SRC_CD
oszlop értékéből meghatározhatja a lekérdezés típusát, azaz az adatmegjelenítést, az adatkészletet, az elemzést, az ODBC-t stb. Például az adatmegjelenítéses lekérdezések értéke Visual Analyzer
, egy adatkészlet feltöltésére használt lekérdezés értéke data-prep
, az elemzések értéke Report
, és egyes belső ODBC-eljáráshívásokra vonatkozó lekérdezések Soap
értékkel rendelkeznek.
Ha SQL-utasítást szeretne generálni egy adatvizualizációhoz, az alapul szolgáló adatkészlet adatelérési beállítását Élő értékre kell módosítania.
Ebben a példában adatmegjelenítési lekérdezést hoz létre (hasonlóan az előző lekérdezésekhez) egy Oracle adatbázishoz fűződő kapcsolaton alapuló adatkészlethez:
[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' */
Ami a következő SQL-kódot generálja:
[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
A használatkövető logikai táblában megtalálhatja a hash_id
azonosítót, amely szűrőként szolgál a használatkövető fizikai táblához.
A használatkövető fizikai táblából megtalálhatja a physical_hash_id.
azonosítót
A V$SQL
tábla lekérdezésekor ismét megtalálja az SQL_ID
azonosítót.
A logikai hash_id
és physical_hash_id
azonosítót a Munkamenetek kezelése naplóban is megtalálhatja (lásd az előző naplópéldák kiemelt szakaszait). Ez azt jelenti, hogy az SQL_ID
azonosítót magában a naplóban találhatja meg. A használatkövető táblák használatának előnye, hogy a Munkamenetek kezelése naplóbejegyzések ideiglenesek, így hacsak nem gyűjti a hash-azonosítókat a lekérdezés futtatásával egyidejűleg, azok elvesznek.
Az adatok azonban csak a lekérdezés befejezésekor kerülnek beírásra a használatkövető táblákba. Tehát, ha egy olyan, régóta futó lekérdezést keres, amely még nem fejeződött be, és meg szeretné határozni az sql_id
azonosítót, a logikai hash_id
és a physical_hash_id
azonosítókat a Munkamenetek kezelése naplóból szerezheti be.
Ha SQL-utasítással kapcsolatos hibaelhárítást végez, és meg kell vizsgálnia az adatbázist, összekapcsolhatja a használatkövető táblákon és a V$SQL
(vagy a GV$SQL
) rendszertáblán található információkat, hogy gyorsan megtalálja az SQL_ID
azonosítót a vizsgált SQL-utasításhoz.