VT ARACI (ORACLE) ÖZELLİKLER
PARTITION (PARTİSYON) Kullanımı
Bir
tablodaki kayıtlar belli bir alan için anlamsal olarak birden fazla mantıksal
parçaya bölünebilir. Örneğin DOK_KONSIMENTO tablosundaki kayıtların TICARET_TIPI_ID
sadece ithalat veya ihracat değerini alabilir. O Eğer kullandığımız veri tabanı
destekliyor ise bu alana partisyon tanımlanması uygundur.
Partisyon tanımlandığında, veri
tabanı bu tablodaki kayıtları, ticaret tiplerine göre daha hızlı ulaşacak şekilde
yeniden düzenlemektedir. Bu noktada artık partisyon mantıksal değil, tablodaki
fiziksel bölümlerin adı olmaktadır. Partisyonlara ayrılmış tabloları, tablo
içinde küçük tablolar gibi düşünebiliriz. Bu bağlamda küçük tabloları sorgu
yazarken birebir olarak adresleyebiliriz.
Örnek
SELECT
* FROM
DOK_KONSIMENTO PARTITION (T1)
Tablolardaki mevcut partisyonları
kontrol etmeli* ve sorgularımızda o partisyonları kullanmaya çalışmalıyız.
Mevcut tablo yapısındaki partisyon tanımlama fırsatlarını da veri tabanı
yöneticisi ile paylaşıp, yeni partisyon açmayı değerlendirmesini
sağlayabiliriz.
Referans
MATERIALIZED VIEW (MV) kullanımı
Klasik VIEW her çağrıldığında
veriyi tekrar oluşturmakla vakit kaybederken, MATERIALIZED
VIEW (MV) veriyi, önceden kopyaladığı fiziksel tablodan okur. MV ‘yi oluşturan tablolardan bir tanesi bile COMMIT
görürse MV anında tazelenir. MV kullanımı sorgu yazmayı basitleştirdiği gibi,
sorgu performansına da katkısı olur.
Çok sık güncellenmeyen bir biri
ile alakalı verileri toparlayıp MV olarak
hazırlayabiliriz (bu işlemi veri tabanı yöneticisi gerçekleştirir). MV
yapılabilecek potansiyel kullanımları veri tabanı yöneticisi ile paylaşınız.
Referans
Örnek:
Sefer
limanı, sefer numarası, gemi ad bilgileri genelde birlikte kullanılır. Bunlar
GOP_SEFER, GOP_SEF_LOK ve GEMI tablolarında tutulmaktadır. Sefer bilgileri her an değişen operasyon
verisi değildir ve bu nedenle MV olarak tanımlanmıştır. Bu bilgilere ihtiyaç
duyduğumuzda ilgili MV sorgumuzda kullanabilir veya doğrudan bu MV üzerinden
sorgu yazabiliriz.
SELECT
DENIZ.SLOT_SAHIBI_KUMPANYA_ID,
MV.SEFER_GEMI_ADI,
MV.SEFER_NO,
MV.SEFLOK_KOD
FROM dok_deniz_konsimentosu
deniz, gop_sef_lok_mv mv
WHERE DENIZ.GOP_SEFER_LOKASYON_ID
= MV.GOP_SEFER_LOKASYON_ID
AND
DENIZ.DOK_KONSIMENTO_FID
= 518250
DATAGUARD kullanımı
Veri tabanında çalışan her
INSERT, UPDATE, DELETE komutunun, belli aralıkta ikinci bir veri tabanında da
çalıştırılmasıyla mevcut veri tabanının bir kopyasının oluşturma işleminin
ORACLE aracındaki ismidir. Bu kopya VT sadece okunabilir şekildedir. Bu nedenle
raporlar için kullanılabilir. Canlı VT’yi
15 dakika geriden takip ettiği için eğer bu hassasiyette veriye ihtiyacımız yok
ise, kendi kişisel sorgularımızda ve raporlarımızda bu şemayı kullanmamız uygun
olmaktadır. Yeni bir rapor tasarlanırken, raporun kullandığı verinin
çalıştırılmadan 15 dakika öncesindeki verilere ihtiyacı yoksa (dünün X raporu,
sabit tanım değerlerini içeren tabloların raporu gibi) raporun kullandığı
DATASOURCE’ u DATAGUARD şemasını gösterecek şekilde ayarlamamız gerekir.
Bazı karmaşık sorgularda, sorgu
çalışırken arka planda veri tabanı geçici tablo yaratmaya çalışır. Böyle
durumda sadece okunur (READONLY) olan DATAGUARD hata verecektir. Bu tip
raporlarda istesek de DATAGUARD kullanamıyoruz.
Referans
Örnek
Rapor tasarımında SHARED
DATASOURCE ’larda DATAGUARD ’ın referansını görebilirsiniz. TNSNAMES.ORA içinde yer aldığından TOAD aracı
içinde bağlantı eklerken de doğrudan seçebilirsiniz.
RAPOR KULLANIMINA ÖZEL DURUMLAR
Güvenlik / Gizlilik
Bir
rapor veya sayfa tasarlanırken, çekilen verinin gerçekten çeken kullanıcının
görmesinin sakıncası olmadığı veriler olmasına dikkat edilmedir. Başka şirketin
verisini görmüyor olması gerekir veya pazarlama kullanıcısı ise, fatura
bilgilerini görmüyor olması gerekir. Rapor dâhil her türlü veri gösteriminde bu
güvenlik /gizlilik faktörü göz önünde bulundurulmalıdır.
1.
Raporun yetkiyi ilgilendiren (KUMPANYA, LİMAN, ŞİRKET gibi) alanlara göre uygun
veriyi getirmesi gerekiyor mu? Rapor sorgusunda bu alanlar WHERE içinde kullanılmış mı?
2.
Rapor alınan sayfada parametre olarak bu alanlar
seçiliyor ise, seçim kontrollerine sadece yetkili olduğu (liman, kumpanya vs.)
bilgiler gelmelidir. Kullanıcın örneğin hiçbir limana yetkisi yok ise, rapor
çağırıldığında hiçbir kaydın gelmemesini garanti altına almak için liman
parametresine -1 gibi geçersiz bir değer
atanabilir.
Kayıt Sayısı Azaltma
Raporda, sayfada (dolayısıyla SQL’de)
; Kayıt sayısı, tarih aralığı gibi
zorunlu kılabileceğimiz parametreler var mı? Rapor sorgusunda bu alanlar WHERE içinde kullanılmış mı?
Parametre Tipleri
Rapor parametre tiplerinin yanlış
verilmesi, gereksiz “CAST” yapılmasından dolayı raporun işleme süresini
uzatmaktadır.
Örnek
Rapor İşlem Yetkisi
Uygulama içindeki her işlem için
bir TRANSACTION (TXN) yazılmaktadır. Bu TXN çalıştırıldığında kullanıcının o
işleme yetkisi var mı kontrol edilir. Rapor çağırımları için de yetki kontrolü
yapılabilmesi için içi boş bir TXN yazılıp, rapor oluşturan satırın hemen
üstünde bu TXN çağırılır, sonuç başarılı ise rapor alan kod çağırılır.
Rapor yetki kontrol TXN‘ lerinin
isimlendirme standartları için mevcut rapor al TXN’ lerini kontrol ediniz.
Örnek
DATASET Kullanımı
Bir raporda yer alan birden fazla
tablo için ayrı ayrı sorgular yazılıp DATASET oluşturulması istenmeyen bir
durumdur. İş bilgisi (DOMAIN) için
farklı grup tablolar ise, ayrı şeylerse gerekebilir; ancak, genellikle hepsi
aynı veriyi farklı formlarda barındırıyor. O nedenle ufak eklemeler ile tek
DATASET içinde iş genellikle çözülür.
Raporda
istenen gruplama, çevrim (Tarih çevrimleri, NULL kontrolleri) , alt toplam alma
gibi işlevleri sorgunun içine gömmek için sorguyu karmaşıklaştırmak yerine bu
işlemleri TABLIX, MATRIX ve EXPRESSION kullanarak rapor içinde halledebiliriz.
SUBREPORT (Alt Rapor) Kullanımı
Detay kayıtlar üzerinde alt rapor
kullanımı gerçekten gerekli mi? Alt raporlar, içindeki sorguyu her
kullanıldıkları satırda çeker ve performans kaybına yol açarlar. Bu nedenle alt
rapor yerine TABLIX ‘i filtre ile kullanmak daha uygun olacaktır.
Raporun detay kayıtlarını
oluşturan ana DATASET ’i kullanmayan ve başka raporlar içinde de
kullanılabileceğini düşündüğümüz standart bir gösterim varsa örneğin bir
geminin sefer, rota ve diğer bilgilerini gösteren bir SUBREPORT yazımı uygundur
ve farklı raporlarda kullanılabilir.
TABLIX (TABLE) Kullanımı
Rapor tasarımında tek bir TABLE ya da MATRIX istenilen
forma sokulabilecek iken iç içe çok fazla TABLE /
MATRIX kullanmak performansı ve bakımı olumsuz etkileyecektir.
Yanlış Kullanım Örnek:
Sefer_Lokasyon_Id bazında gruplu
bir liste ekleniyor. Onun içerisine de Konşimento gruplu TABLE (TABLIX)
koyuluyor.
Doğru Kullanım Örnek:
Konşimento gruplu TABLIX ’e ,
PARENT GROUP eklenip, grup olarak Sefer_Lokasyon_Id verilebilir (En detaydaki
gruptan başlayarak, ADD PARENT GROUP yaparak ilerleyebiliriz).
CLOB Alanlar
Rapor sorgusunda CLOB ve BLOB
sahaların CHAR tipine CAST yaparak döndürülmesi gerekir. Bu çevirme işlemini
REPORTING SERVICES ‘e bıraktığımızda çok daha yavaş oluyor ve raporun oluşma
(RENDER) süresini çok uzatıyor.
Referans
Örnek
dbms_lob.substr( mal_aciklama,
4000, 1 )
ORDER BY Kullanımı
Raporda TABLE veya grup
içinde “SORT” kullanıyorsa rapor
sorgusunda “ORDER BY” yapılmasına gerek yoktur.
GROUP BY Kullanımı
Rapor içindeki
TABLO/MATRIX/TABLIX ’e gereksiz yere grup eklenmemelidir. Rapor içerisinde
kullanılan kayıt sayısı, sorgudan dönen
kayıt sayısı ile aynıysa (dönen sorgu zaten gruplu ya da grup gerektirmeyen bir
rapor ise) gruplama yapmaya gerek yok demektir.
SQL (SORGU YAZIMI TEKNİKLERİ)
Aşağıdaki hususlar, bir rapor
sorgusu dâhil, yazacağımız tüm sorgular için geçerlidir.
Sadeleşmiş SELECT
SELECT
içinde kullanmadığımız bir saha var mı? Olmamalıdır.
Sadeleşmiş FROM
Herhangi bir sahası
kullanılmadığı halde kullanılan tablolar var mı? Varsa FROM
‘dan kaldırılmalıdır (WHERE kısmındaki
bağlantılar zaten hata verecektir ve silinmelidir)
Kartezyen Çarpım Kontrolü
Her Tabloya ait onu başka bir
tabloya bağlayan bir RELATION eklenmiş mi kontrol edilmelidir. Birden fazla tablodan veri çekiliyorsa (FROM cümlesinde birden fazla tablo var ise) Bu
tablolar en az bir kez diğer bir tablonun bir alanı ile bağlanmalıdır. Yani n
adet tablo için WHERE cümlesinde n-1 adet
bağlantı olmalıdır (PARTİSYON seçilen tablo yoksa) . Herhangi bir alanı ile
sorguya bağlanmayan bir tablo olursa, o tablonun tüm kayıtları için mevcut sorgu
kayıtları çoklanacaktır (Kartezyen çarpım).
Örnek
SELECT
PLAKA.NU, IL.AD
FROM PLAKA, IL
WHERE IL.ID =
PLAKA.IL_ID;
DISTINCT Kullanımı
Sorguda DISTINCT kullanılmış mı?
Gerçekten gerekli değilse ki %90 gereksizdir, kullanılmaktan kaçınılmalıdır.
Satır çoklanıyor ise DISTINCT kullanmak yerine sorgudaki asıl problem
bulunmalıdır ve çözülmelidir.
İpucu
DISTINCT ile yazılmış bir sorgu
ile karşılaştığımızda büyük bir küme için (mümkünse tüm filtreleri iptal edip) hem
DISTINCT kullanarak hem DISTINCT kullanmadan kayıt adetlerini kontrol edelim.
Aynı sonuç geliyor ise DISTINCT ‘i kaldırabiliriz.
Geçerli Kayıt Kontrolü
Yazdığımız sorguda, aslında yer
almaması gereken geçersiz kayıtlar var mı?
Bu kayıtları filtrelemek gerekebilir. Değerlendirilmedir.
Örnek
WHERE
AKTIF_MI
= 1 AND --silmek
yerine pasif edilen kayıtlardır. Genelde gelmemesi gerekir
YUKLENMEYEN_KONTEYNER_MI=0 AND --yüklenmeyen
konteynerler gelmesin
BOOKING_TIPI_ID
<> 57 --57
iptal booking demektir.
AV_KAYIT_TURU_ID = 146 --146
Gerçek Aktif, 147 Correction (Geçici kayıtlardır). Genelde 146lar kendi
arasında 147ler kendi arasında işlem görür
ALT SORGU Kullanımı
Tek bir alan için farklı
tablolara gidiyorsak ve bu alan NULL olabiliyorsa. Yani ana sorgu ile eklenen
tablolar arasında INNER bir bağlantı yok ise. Ana sorgunun FROM’una bu tablo dizisini (LEFT JOIN’leri de göz
önünde bulundurarak eklemek yerine) ana SELECT içinde ALT SORGU yapıp bu değeri
getirebiliriz.
SELECT içerisindeki aynı alt sorguyu farklı
alanlar için 5-6 defa kullanıyorsak, bunun yerine bu alt sorgu, ana sorgunun FROM kısmına alınmalıdır. Burada tablolar arası
bağlantı (LEFT / INNER)
ilişkilerine özellikle dikkat edilmelidir. Ana sorgunun normalde
çalıştırıldığında gelen kayıt adedi, alt sorgunun FROM
a eklenmesinden sonra değişmemelidir.
ANA SORGUNUN FROM’UNDAN BAĞLANTI
|
SUB SELECT BAĞLANTI
|
SELECT
ANA_TABLO.AD
AD , T3.DEGER
DEGER
FROM
ANA_TABLO,
T1,
T2,
T3
WHERE
ANA_TABLO.ID = T1.ANA_TABLO_ID
AND T1.ALAN
= T2.T1_ALAN
AND T2.ALAN
= T3.T2_ALAN;
|
SELECT
ANA_TABLO.AD
AD ,
(SELECT T3.DEGER
FROM T1, T2, T3
WHERE T0.ID = T1.TO_1
AND T1.ALAN = T2.T1_ALAN
AND T2.ALAN = T3.T2_ALAN
)
DEGER FROM
ANA_TABLO
|
VT FUNCTION Kullanımı
WHERE
içinde yer alan, veri tabanında indekslenmiş bir kolon üzerinde yapılan
TRUNC, TO_CHAR gibi işlemler indeksi devre dışı bırakır. Bu da performans kaybına yol açar. Filtre
verirken bu kullanımlardan kaçınılmalıdır.
Çevrim komutları indeks olsun
olmasın sorgu performansı düşürür. O nedenle mecbur kalmadıkça bu
kullanımlardan kaçınılmalıdır.
OKUNABİLİRLİK
·
FROM tablo sırası ile WHERE tablo RELATION ekleme
sırası uyumlu olmalıdır.
Hiç yorum yok:
Yorum Gönder