Oracle Analitik için sorguları ayarlarken veri modeline, rapor tasarımına, kumanda tablosu tasarımına, ağ konfigürasyonuna bakarsınız ve bazen veritabanını araştırmanız gerekir.
V$SQL Tablosu
Veritabanı araştırmaları için belirli sorguyu Etkin Oturum Tarihçesi, Otomatik İş Yükü Veri Havuzu ve Oracle SQLTXPLAIN üzerinden takip edebilmeniz amacıyla SQL komutunun SQL_ID
'sini bilmeniz gerekir.
Bu konuda, Oracle Analitik Kullanım Takibi tablolarını ve Oracle veritabanı sistemi tablosunu V$SQL
(veya bir Gerçek Uygulama Kümeleri veritabanı için GV$SQL
) inceleyerek SQL_ID
'nin nasıl bulunacağı gösterilir.
V$SQL
, bireysel SQL sorgularıyla ilgili istatistikleri takip eden bir Oracle veritabanı sistemi tablosudur. Çalıştırdığınız her SQL komutu için tabloda bir satır bulunur ve her satır SQL_ID
sütunuyla benzersiz bir şekilde tanımlanır. Oracle veritabanında belirli bir SQL komutunu takip etmek için bu SQL_ID
'yi kullanabilirsiniz.
V$SQL
tablosunda (veya bir Gerçek Uygulama Kümeleri veritabanı için GV$SQL
) sorgularınız hakkında birçok yararlı bilgi bulunmaktadır.
Kullanım Takibi Tabloları
Kullanım Takibi tabloları SQL_ID
'yi doğrudan takip etmez ancak SQL_ID
'yi kolayca V$SQL
tablosuna (veya bir Gerçek Uygulama Kümeleri veritabanı için GV$SQL
) kadar izleyebilirsiniz.
Oracle Analitik'te Kullanım Takibini etkinleştirdiğinizde tüm sorgular iki tabloda takip edilir:
S_NQ_ACCT
- mantıksal sorgular içerir.S_NQ_DB_ACCT
- fiziksel sorgular içerir.Mantıksal sorgu mantıksal tabloya kaydedilir ve fiziksel sorgu (veya mantıksal sorgu tarafından oluşturulan sorgular) fiziksel sorgu tablosuna kaydedilir.
Mantıksal sorgu no sütununda mantıksal ve fiziksel tabloları birleştirebilirsiniz. Mantıksal tabloda mantıksal sorgu no sütunu no'dur ve fiziksel tabloda LOGICAL_QUERY_ID
'dir.
SQL_ID
'yi bulmanın önemli noktası, fiziksel tablodaki PHYSICAL_HASH_ID
sütunudur. PHYSICAL_HASH_ID
değeri ayrıca ACTION
sütunundaki V$SQL
'ye (veya GV$SQL
) yazılır.
Oracle İş Zekası Sunucusu, mantıksal SQL sorgusunun metninden ve fiziksel SQL sorgularının metninden bir hash kodu hesaplar. Oracle İş Zekası Sunucusu'ndan çalıştırılan herhangi bir SQL sorgusunun fiziksel SQL hash kodu, V$SQL
'deki ACTION
sütununa kaydedilir. Daha fazla bilgi için bkz. S_NQ_ACCT Kaydını İş Zekası Sorgu Günlüğü ile İlişkilendirme
Çeşitli kullanım takibi sütunları hakkında daha fazla bilgi için bkz. Kullanımı İzleme ve Kullanım İzleme Tablolarını Anlama.
Kurulum
PHYSICAL_HASH_ID
'yi nerede bulacağınızı artık bildiğinize göre, veritabanında çalışan SQL'i Oracle Analitik'te çalışan belirli bir analizle ilişkilendiren bir SQL komutu yazmak nispeten küçük bir görevdir.
Kullanım Takibi tabloları veri ambarıyla aynı veritabanı anında olduğunda SQL_ID
'yi bulmak için tek bir sorgu yazabilirsiniz.
Kullanım Takibi tabloları ve veri ambarınız farklı Oracle veritabanı anlarında bulunuyorsa iki sorgu çalıştırmanız gerekir. Önce araştırmak istediğiniz sorgunun PHYSICAL_HASH_ID
'sini Kullanım Takibi tablolarından çekmek için bir sorgu çalıştırırsınız. Sonra ACTION
sütununu filtrelemek için PHYSICAL_HASH_ID
'yi kullanarak V$SQL
'den SQL_ID
'yi çekersiniz.
Örnekler
Bu örnekte Kullanım Takibi tablolarının ve veri ambarının aynı yerde olduğunu varsayalım. Kullanım Takibi ve V$SQL
tablolarındaki sütunların herhangi biri veya tümü sorguda kullanılabilir ancak bu örnekte aşağıdaki alt kümeyi seçiyorsunuz:
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;
İkinci örnekte Kullanım Takibi tablolarının ve veri ambarının farklı Oracle veritabanlarında olduğunu varsayalım.
Önce PHYSICAL_HASH_ID
'yi almak için Kullanım Takibi tablolarına bir sorgu yazın.
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;
Sonra PHYSICAL_HASH_ID
değerlerini filtre olarak kullanarak SQL_ID
'yi almak için V$SQL
için bir sorgu yazın.
select o.action, o.sql_id, o.sql_text from v$sql o where o.action = ‘<physical_hash_id>’ order by o.sql_id;
Bir Gerçek Uygulama Kümeleri veritabanınız varsa V$SQL
yerine SQL_ID
'yi almak için GV$SQL
tablosunu kullanırsınız.
select o.action, o.sql_id, o.sql_text from gv$sql o where o.action = '<physical_hash_id>' order by o.sql_id;
Başlatma bloğu kullanım takibi tablosu (S_NQ_INITBLOCK
) fiziksel bir hash no içermediğinden, başlatma bloklarında sorun giderme gerçekleştiriyorsanız bu yöntem işe yaramaz.
Sonraki örnekte 'A - Örnek Satışlar' konu alanını kullanıyorsunuz ve Kullanım Takibi tablolarından sadece birkaç sütun seçiyorsunuz.
'A - Örnek Satışlar'dan aşağıdaki sorguyu çalıştırıyorsunuz:
[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 ]]
Kullanım takibi mantıksal tablosundan start_ts, id, hash_id, query_src_cd
ve query_text
sütununu seçtiğinizde ID
değerini E841EBB79217270A660CDD3EFB5D986C alırsınız:
Sonra kullanım takibi fiziksel tablosundan logical_query_id, hash_id, physical_hash_id
ve query_text
sütununu seçin. Burada logical_query_id = E841EBB79217270A660CDD3EFB5D986C
:
Oturum yönetimi günlüğüne baktığınızda, mantıksal sorgu QUERY_TEXT
sütunundaki SQL'i oluşturur:
[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 ]]
Son olarak V$SQL
'den action
, sql_id
ve sql_text
sütununu seçin. Burada action = ‘bd6708b8'
:
sql_text
sütunundaki sorgu, kullanım takibi fiziksel tablosunda görülen SQL'in aynısıdır. Buradan söz konusu sorgunun sql_id
'sinin ‘1gxhc0acmztwk’
olduğunu görürsünüz.
Aynı sorguyu tekrar çalıştırırsanız, kullanım takibi mantıksal tablosuna yeni bir no başka bir satır eklenir ancak hash_id
aynıdır:
Benzer şekilde, kullanım takibi fiziksel tablosuna yeni bir logical_query_id
ile başka bir satır eklenir, ancak hem hash_id
hem de physical_hash_id
aynı kalır:
Aynı mantıksal ve fiziksel modelleri temel alan bir konu alanı için benzer bir mantıksal sorgu çalıştırdığınızda da physical_hash_id
yeniden kullanılır. Örneğin, burada 'C - Örnek Maliyetler' için benzer bir sorgu çalıştırıyorsunuz:
[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 ]]
Bu mantıksal sorgu, 'A - Örnek Satışlar' için çalıştırdığınız sorguda görülen SQL'in aynısını oluşturur:
[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 ]]
Önce no'yu bulmak için kullanım takibi mantıksal tablosunu kullanın. hash_id
değerinin 'A – Örnek Satışlar' için çalıştırılan sorgudan farklı olduğuna dikkat edin:
Kullanım takibi fiziksel tablosunda, mantıksal hash_id
farklı olsa da physical_hash_id
'nin aynı olduğunu görürsünüz:
Başka bir örnekte, yukarıdakilerle aynı sorguları çalıştırıyorsunuz ancak bu kez Yenile'ye tıklıyorsunuz. Yenilemeyi belirtmek için OBIS_REFRESH_CACHE=1
değişkenine dikkat edin. Beklendiği gibi, kullanım takibi mantıksal tablosuna başka bir satır eklenir ancak bu satır farklı bir logical hash_id
'ye sahiptir.
Ancak kullanım takibi fiziksel tablosunu sorguladığınızda tüm sorguların aynı physical_hash_id
'ye sahip olduğunu görebilirsiniz.
Bu dört mantıksal sorgunun tümü aynı physical_hash_id
'ye sahip olduğundan bu sorgu için V$SQL
'de sadece tek bir kayıt görürsünüz:
Bir konu alanına (RPD) veya veritabanı bağlantısına göre veri görselleştirme sorgularında sorun gidermek için aynı yöntemi kullanabilirsiniz. Veritabanı bağlantılarında bu hem veri görselleştirmelerini hem de veri kümelerini doldurmak için kullanılan sorguları içerir.
Sorgu tipini (veri görselleştirme, veri kümesi, analiz, Açık Veritabanı Bağlantısı vb.) QUERY_SRC_CD
sütununun değerinden belirleyebilirsiniz. Örneğin, veri görselleştirmesi sorguları ‘Visual Analyzer’
değerine, bir veri kümesini doldurmak için kullanılan bir sorgu ‘data-prep
değerine, analizler ‘Report’
değerine ve bazı dahili Açık Veritabanı Bağlantısı prosedür çağrılarına ilişkin sorgular ‘Soap’
değerine sahiptir.
Veri görselleştirmesine yönelik bir SQL komutu oluşturmak üzere temel veri kümesi için Veri Erişimini 'Canlı' olarak değiştirmeniz gerekir.
Bu örnekte, Oracle veritabanı bağlantısını temel alan bir veri kümesi için bir veri görselleştirme sorgusu (yukarıdaki sorgulara benzer) oluşturacaksınız.
[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' */
Bu, aşağıdaki SQL'i oluşturur:
[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
Kullanım takibi mantıksal tablosundan, kullanım takibi fiziksel tablosu için filtre olarak kullanılan hash_id
değerini bulabilirsiniz:
Kullanım takibi fiziksel tablosundan physical_hash_id
değerini bulabilirsiniz:
V$SQL
'i sorguladığınızda SQL_ID
'yi tekrar bulursunuz:
Mantıksal hash_id
ve physical_hash_id
değerlerini de Oturum Yönetimi günlüğünde bulabilirsiniz (yukarıdaki günlük bilgi parçacıklarında vurgulanan bölümlere bakın). Bu, SQL_ID
'yi günlüğün kendisinden bulabileceğiniz anlamına gelir. Kullanım takibi tablolarını kullanmanın avantajı Oturum Yönetimindeki günlük girişlerinin geçici olmasıdır. Yani sorguyu çalıştırırken aynı zamanda hash no'larını toplamadığınız sürece bunlar kaybolur.
Bununla birlikte, veriler sadece bir sorgu tamamlandığında kullanım takibi tablolarına yazılır. Yani henüz tamamlanmamış ve uzun süredir devam eden bir sorgunun sorunlarını gideriyorsanız ve sql_id
'yi belirlemek istiyorsanız, Oturum Yönetimi günlüğünden mantıksal hash_id
ve physical_hash_id
'yi alabilirsiniz.
Bir SQL komutunun sorunlarını gideriyorsanız ve veritabanını araştırmanız gerekiyorsa, kullanmakta olduğunuz SQL ifadesinin SQL_ID
değerini hızlı bir şekilde bulmak için kullanım takibi tablolarındaki ve V$SQL
sistem tablosundaki (veya GV$SQL
) bilgileri birleştirebilirsiniz.