Küçük küçük aldığımız notlarımızdan bu yazımızda da devam edeceğiz.
Tabloların analizini güncel tutmanın önemli oldugunu söylemiştik.
BEGIN
DBMS_STATS.gather_table_stats (
ownname => 'schema_name',
tabname => 'table_name'
);
END;
ile otomatik istatistik aldırabiliriz.Guncel olmali bu yuzden etl ler bittikten sonra bir jobla tetiklenir.
Oracle Hintler :
select /*+first_rows_100*/ * from hr.tablo;---> ilk 100 kaydi cache alir.
tumunu almakla ugrasmaz cunku cacheden sonra da degeri bize donecektir.
/*+ordered*/ -->benim istedigim sirada joinle demek performans sıkıntısı yaratabilir.Normalde da Oracle optimizer karar veriyor.
tabloları tanıyorsak ve cok fazla tablonun oldugu bir senaryoda optimizer a brıkalımdan yazilabilir.Zira Optimizer da bu joinleri yaparken karşılaştırmalar yapıyor ,maaliyet oranları çıkarıyor ona gore azdan çoğa dogru yapıyor joinleme sırasını.
select /*+ordered*/ * from a,b,c,d,e
where a.c=b.d;
/*+leading(a,b)*/:hele bir a ile b yi joinle de gerisini sen halledersin zaten optimizer demek.
Not:
select * from hr.employees where employee_id='100';--> yanlis data tipi costu yukseltir,convert etnekle ugrasmamali,1 kayit için tum kayitlari cast ediyor bu da sorgunun okunma suresini ve costunu artırır.
Örnek senaryo :
create table tip
(
a varchar2(20),
b char(20)
);
insert into tip values ('Ali','Ali');
select * from tip where a=b --->esit çikmiyor biri 3 bytelik Ali digeri 20 bytelik.
select * from tip where a=trim(b) --->esit çikmasi için trim yapılabilir.Trim boşlukları siler.
select /*+use_hash(emp,dept)*/ * from employee emp ,department dept
where emp.dep_id =dept.dep_id;
Tablo büyüdükçe hash join kullanilmalidir./*+use_hash(emp,dept)*/ yapıyorsanız ve explain planda bunu göremiyorsanız memoryde sıkıntı vardır diyebiliriz.
Not:
Oracle da joinlenecek tablolarin sırasi önemli degil optimizer cost maaliyetini otomatik hesapliyor.
Subquerylere gore join yapmak daha iyidir.
Bir sonraki yazıda görüsmek dileğiyle...
Yorum Gönder