ADD_MONTHS   Fonksiyonu ve Gün Ekleme

Merhaba arkadaşlar, Bu makalemde add_months() fonksiyonundaki bir takım incelikleri sizlerle paylaşacağım. Tarih bilgisi içeren önemli ve kritik raporlarınızda kesinlikle dikkatinizden kaçmaması gereken bir konu olduğunu düşünüyorum.

SQL tarih fonksiyonlarından biri de add_months fonksiyonudur. Bu fonksiyonun çeşitli kullanım şekilleri vardır. Fakat fonksiyonun temel mantığı; girilen bir tarihten itibaren, verilen ay sayısı kadar geriye veya ileriye gitmektir. Fonksiyonu analiz edersek ;

add_months(‘date’,number)  şeklinde;

-date à girdiğimiz bir tarih,

-number à herhangi bir sayı (3,8,-4 gibi)

Şimdi fonksiyonu birkaç  örnekle inceleyelim :

	İfade	Sonuç
1	ADD_MONTHS('10-APR-2010', 2)	10/06/2010
2	ADD_MONTHS(SYSDATE,2)	07/02/2011 14:00:15 --(çalıştırdığım tarih üzere)
3	ADD_MONTHS('15-JUL-1988',-2)	15/05/1988
4	ADD_MONTHS('31-JAN-2010', 1)	28/02/2010
5	ADD_MONTHS('30-JAN-2010', 1)	28/02/2010
6	ADD_MONTHS('29-JAN-2010', 1)	28/02/2010
7	ADD_MONTHS('28-JAN-2010', 1)	28/02/2010
8	ADD_MONTHS('27-JAN-2010', 1)	27/02/2010
9	ADD_MONTHS('30-JUN-1988',1)	31/07/1988
10	TO_DATE('31-JAN-2010') + 30	02/03/2010

Yukarıdaki tablonun her satırındaki örnekleri dikkatle incelemekte fayda var.

Tablodaki örneklerden ilkinde ; 10 nisan 2010 tarihine , 2 ay ekliyoruz ve sonuç olarak 10 haziran tarihine gidiyoruz. Aynı şekilde 3. Örnekte 15 temmuzdan 2 ay geriye giderek 15 mayıs tarihine geliyoruz fakat dikkat etmemiz gereken önemli bir nokta var : O da 4 ve sonraki satırlardaki örnekler.

4. Örnekte, 31 ocak tarihine bir ay eklediğimizde 28 Şubata gidiyor. Yani bu fonksiyon mantık olarak seçilen tarih üzerine 30 gün eklemiyor. Takvim üzerinde direk belirtilen günden “x ay sonrasına” gidiyor.   4,5,6 ve 7. Satırlardaki ifadelerin aynı sonucu döndürmesinin sebebi budur. 30 ocaktan 1 ay sonra da 28 şubattır; 28 ocaktan 1 ay sonra da 28 şubattır. Burada dikkat edilmesi gereken, ay ekleme işlemini gün bazında değil takvim bazında yapmasıdır.

10. örneğe baktığımızda ise ekleme işlemi tamamen gün bazında yapılmaktadır. Yani verilen tarihin üstüne takvim üzerinden x sayıda gün eklenir ve o sonuç döndürülür.

SQL Server Fast Track Data Warehouse, veri ambarı yol haritanızı SQL Server 2008  için yeni ölçeklenebilir referans mimarileri ile hızlandırır. Veri ambarı işlemleriniz için önceden test edilmiş donanım ve en iyi uygulamalar ile maliyetleri azaltın, zamandan tasarruf edin ve riski azaltın.

  

TEMEL ÖZELLİKLER

 

§  Veri ambarı yol haritanızı önceden test edilmiş donanım konfigürasyonları ile hızlandırın

§  Kullanıma hazır ve daha yüksek Veri Ambarı performansı ile donanım testlerini neredeyse ortadan kaldırın ve ayarlama işlemlerini azaltın

§  SQL Server 2008 Enterprise'daki sıkıştırma özelliklerini kullanarak gereksinim duyduğunuz yer kapasitesini azaltın

§  Daha iyi fiyat performansı, hızlı devreye alma ve endüstri standartlarında donanım ile daha düşük toplam sahip olma maliyetinden yararlanın

§  Dell, HP, Bull, IBM, EMC ve diğer öncü tedarikçilerden endüstri standartlarında donanım seçin

§  Kurumsal ihtiyaçlarınıza uygun olan doğru performans, ölçeklenebilirlik ve fiyatlandırmayı seçin

§  Sağlam bir şekilde geliştirilmiş en iyi uygulamalardan yararlanın

 

SQL Server 2008 Enterprise üzerindeki veri ambarınızı SQL Server Fast Track Data Warehouse ile ölçeklendirin. Geleneksel sistemlerin yüksek maliyeti olmadan yüksek performanslı, kurumsal sınıfta ve 32 terabayt'a kadar büyüklükte bir veri ambarı kullanın.

 

Kullanıma hazır performansı iyileştirirken veri ambarı maliyetlerini azaltın. SQL Server Fast Track Data Warehouse aşağıdakilerden oluşur:

§  Özellikle ambar işlemleri için dengelenmiş ve optimize edilmiş, önceden seçilmiş sunucular, depolama ve ağ bileşenleri

§  Ölçeklenebilir ve kurumsal sınıf bir veri ambarı için SQL Server 2008 Enterprise

 

ZAMANI DEĞERE DAHA HIZLI DÖNÜŞTÜRÜN

 

Yüksek performanslı bir ambarı daha kısa sürede kullanıma alın. Fast Track Data Warehouse donanımı metodik olarak test edilmekte ve ayarlanmaktadır. Böylece deneme yanılmaya gerek kalmaz ve aylar sürecek yapılandırma, kurulum, test ve ayar işlemlerini kısaltabilirsiniz.

§  Tüm ihtiyacınız olan donanımı (sunucu, depolama ve ağ bileşenleri) tek bir tedarikçiden satın alın

§  Veri ambarı oluşturma ve geçiş işlemlerini hızlandırın

§  Kurumsal birimlerin standart bir platformda özel simetrik çoklu işlem yapan (SMP) veri ambarları veya veri pazarları oluşturabilmelerini sağlayın

 

DÜŞÜK MALİYETLİ KURUMSAL VERİ AMBARI İŞLEMLERİ

 

Fast Track Data Warehouse veri ambarları, SQL Server 2008 Enterprise ve endüstri standartlarında donanım sayesinde düşük maliyetle Kurumsal Veri Ambarları oluşturabilmenizi sağlar. Devreye alma süreci hızlanır ve bakım çalışmalarının miktarı tahmin edilebilir.

 

§  Belirli kurumsal ihtiyaçlarınıza uyacak farklı performans, ölçeklenebilirlik ve fiyat seviyelerinden birini seçin.

§  İki, dört veya sekiz işlemci konfigürasyonundan birini seçin

§  Eşdeğer bir Oracle sisteminin üçte bir fiyatından daha düşük maliyetle kurumsal sınıfta bir çözüm kullanın

 

PERFORMANS VE ÖLÇEKLENEBİLİRLİKTE ÇITAYI YÜKSELTİYOR

 

Fast Track Data Warehouse müşterileri daha az çaba ile kullanıma hazır ve daha yüksek performans alırlar, çünkü çözümler Veri Ambarı işlemleri için optimize edilmiştir.

 

Fast Track Data Warehouse ile tipik bir çevrimiçi işlem (OLTP) veritabanı arasındaki fark, tüm bileşenlerin –işlemciden diske kadar- çevrimiçi analitik işlem (OLAP) için dengelenmiş ve ayarlanmış olması ve potansiyel performans darboğazlarını ortadan kaldırmaya odaklanılmış olmasıdır.

 

Rastgele IO yerine dizisel IO için optimize edilmiş olan tüm Fast Track Data Warehouse'lar, işlemci çekirdeği başına 200 MB/sn aktarabilecek şekilde tasarlanmıştır. Bu da diğer öncü Tedarikçilerin fiyatının beşte birinden daha düşük maliyetle benzer performans sağlamaktadır.

 

Microsoft’un teknik rehberliği ve en iyi uygulamalarını kullanan Data Warehouse yöneticileri ve DBA'lar, veri ambarlarının sorunsuz bir şekilde devreye alınmasını ve tutarlı ve tahmin edilebilir bir şekilde çalışmasını bekleyebilirler.

 

 

VERİ AMBARI İŞLEMLERİNE DAHA İYİ BİR YAKLAŞIM

 

Fast Track Data Warehouse çözümleri, veri ambarı işlemlerine sağlam ve bütüncül bir yaklaşım ile tasarlanır, test edilir ve devreye alınır. Windows® konfigürasyonu ve SQL Server veritabanı yönetimindeki en iyi uygulamaları kullanarak müşterilerin tahmin edilebilir performans sunan Veri Ambarları oluşturmalarına yardımcı olurlar.

 

Fast Track yaklaşımı gücünü yalnızca tutarlı ve güvenilir donanımdan değil, ayrıca sıkıştırma, paralel bölümlendirme ve yıldız birleştirme sorgu optimizasyonu gibi SQL Server 2008 Enterprise'da bulunan gelişmiş veri ambarı geliştirmelerinden de almaktadır.

 

Güncellenmiş olan en iyi uygulamalar yaklaşımı, daha iyi performans için uygulayıcılara adım adım teknik kılavuz bilgiler. Bu yeni Fast Track yaklaşımı, hızlı devreye alma ve yapılandırma ile veri ambarı ekibinin becerisini ve tepki verme yeteneğini geliştirir.

 

§  Size özgü iş yükü ve performans ihtiyaçlarınıza uyacak şekilde özelleştirin

§  SQL Server 2008 Enterprise'daki veri ambarı geliştirmeleri ile performans, ölçeklenebilirlik ve yönetilebilirliği arttırın

§  Yerleşmiş veri ambarı en iyi uygulamalarını kullanarak güvenle oluşturun, ayarlayın ve devreye alın

 

İLERİYE BAKMAK

 

Fast Track Data Warehouse'lar, SQL Server üzerinde büyük ölçekli kurumsal veri ambarı işlemleri için sağlam bir yol haritası sunarlar. Verilerinizin büyüklüğü yüzlerce terabayt'lara ulaştıkça Fast Track veri ambarınız SQL Server Parallel Data Warehouse  çözümünün bir parçası haline gelebilir. Günümüzde Fast Track konfigürasyonlarında oluşturulan veri ambarları, bir Madison hub ve bağlı bileşen mimarisindeki tam entegre SMP "bağlı bileşenleri" olabilirler.

 

 

 

"YKB Oracle 8i üzerinde geliştirdiği DataWarehouse uygulamasını yedi hafta içerisinde Sybase IQ ya taşıyarak, on aylık geri ödeme süresi ile yatırım geri dönüş maliyetinde %154 kazanç sağlamış oldu. Türkiye' nin ilk özel bankası olan Yapı Kredi Bankası, 500 şubeye sahip olmakla beraber ve leasing, faktoring, sigorta, Yatırım Bankacılığı gibi çeşitli finans kurumlarında uluslararası iştiraki olan bir bankadır. Aynı zamanda kredi kartları iş hacminde de lider bir banka konumundadır. Bu kredibiliteyi, büyümeyi ve müşteri memnuniyetini sürsürebilmek için bilgi teknolojilerine yatırım yapan lider kurumlardan biridir.

Mevcut datawarehouse larında 25 farklı operasyonel sistemden gelen bir terabyte tan fazla veri mevcut bulunmaktaydı. Önceden tanımlı ve ayarlanmış sorguların sonuçları 24 saatten uzun süren bir süre zarfında alınmakta idi. Data setlerinin büyüklüğü sorgulama işlemini hem güçleştiriyor hem de zaman kaybına yol açıyordu. Ad-hoc sorgular hemen hemen imkansız hale gelmekte idi. YKB bu sistemi performansı artırarak, düşük maliyetler çerçevesinde ihtiyaçlarını karşılamak üzere değiştirmeye karar verdi. Çözüm alternatiflerini değerlendirirken, üç farklı vendor ı üç günlük analiz ve Proof-of-concept çalışması yapmak üzere davet etti. Hedefleri, 8 hafta içerisinde production ortamına geçiş yapmak üzere, en hızlı ve doğru bir şekilde migration planını çıkarabilmek olmuştu. Sorgulama da hızlanma, veri depolamada en düşük kaynaka ve performans önem verdikleri kriterler arasında yer almakta idi. Ve sonuç olarak YKB, Sybase IQ ürününü seçti. YKB uygulama grubu ile iki Sybase danışmanı tarafından oluşturulan bir proje grubu sayesinde, yeni sistem yedi hafta içerisinde hayata geçirildi. Yeni oluşturulan datawarehouse uygulaması, kolon tabanlı çalışma metodolojisine dayalı olup, yüksek bir performans göstermeyi başardı. Sorgu cevap sürelerinde mükemmelliğe erişildi: Sorguların %88.4 bir saniye yada daha az sürede gerçekeşmektedir, %7 si 1-10 saniye içerisinde, %1.7 si 10-30 saniye arasında gerçekleşmektedir.

Ayrıca, yeni kurulan sistem tamamı ile SQL uyumlu olduğu için, veritabanı yönetcilerinin kısa sürede bu sisteme hakim olması oldukça kolay olmuştur. YKB eskiden bir terabyte yer tutan verilerini, artık Sybase IQ üzerinde 350 gigabyte lar seviyesine indirmiştir. 12 CPU lu sistem yerine 3 CPU lu bir sistem üzerinde DW uygulamalarını çalıştırmaktadırlar. YKB bünyesinde satış, pazarlama ve kredi kartları çalışanları kolay ve hızlı bir şekilde yeni sisteme olaşabilmekte ve kompleks ad-hoc sorgular çalıştırabilmektedirler."

Bu makalemizde SQL izleme yöntemlerini ve iyilestirme senaryolarina bakis açimizi irdeleyecegiz.Çogu kez raporlarimizin saatlerce çalistigi durumlar olmustur veya çok kisa sürede çalismasi gereken sorgularimizin neden uzun süre çalistigini merak etmisizdir.Simdi bu tip problemler için çözüm yöntemlerine kisaca bi bakalim

Neden SQL Izleme-Iyilestirme?

SQL iyilestirme islemi ile genel olarak sunlar hedeflenmektedir

 

• Büyük tablolar üzerindeki gereksiz “full-table” erisimlerin indeksli erisime dönüstürülmesi,
• Küçük tablolar üzerindeki “full-table” erisimleri cach’lemek,
• Indeks kullaniminin optimum düzeyde oldugunu garantilemek,
• Optimal JOIN teknikleri kullanmak,
• Tune complex subqueries to remove redundant access

 

Ne Zaman SQL Izleme-Iyilestirme?

 

Bir SQL sorgusunun iyilestirilmesini çesitli kosullar tetikleyebilir. Bunlar arasinda kullanici tarafindan islemin uzun sürdügü seklinde yapilan geri bildirimler olabilecegi gibi, yapilan izleme, istatistik toplama çalismalari kapsaminda sorgunun fazla kaynak kullandiginin tespit edilmesi de yer alabilir. Üzerinde çalisilmasi gereken sorguya karar verildiginde, inceleme ve test çalismalarinin, olabildigi ölçüde uygulamadan ve diger ara katmanlardan bagimsiz olarak gerçeklestirilmesi yararli olacaktir. Buradaki amaç uygulamanin kendi yapisindan kaynaklanan farkli islemleri devre disi birakarak, sadece SQL’in optimizasyonuna yogunlasilmasidir. Bu nedenle, kullanilan izleme araçlari ile, sorunlu oldugu düsünülen SQL sorgusu tespit edildikten sonra dogrudan sorgu üzerinde çalisilmalidir.

 

Sorgularda dikkat edilmesi gereken bir diger husus da, “literal” veya “bind” kullanimidir. “Literal”de, asagidaki örnekte oldugu gibi, where kosulu içinde bir deger (value) belirtilmistir.

 

SQL> select ad,soyad from calisan where calisan_id=765;

 

“Bind”da ise asagida belirtildigi gibi bir parametre kullanimi vardir

 

SQL> select ad,soyad from calisan where calisan_id=:B1;

 

 

“Bind” ve “literal” kullanimda farkli çalisma planlari ortaya çikabileceginden, orijinal sorguda hangisi kullanilmissa, iyilestirme çalismalarinin da bunun üzerinde yogunlasmasi gerekir.

 

Production ortamindaki veritabanlarini olabildigi ölçüde yansitan test veritabanlari mevcut ise, sorgu iyilestirme çalismalarinin test veritabanlarinda yapilmasi daha saglikli olacaktir. Her sorgudan önce buffer cache’in flush edilmesi veya veritabaninin kapatilip açilmasi ile daha dogru ölçüm degerleri elde edilebilecektir.

 

SQL Izleme Yöntemleri

1. TRACE Kullanimi

 

TRACE, bir sorgunun, batch islemin veya tüm sistemin ölçümü için kullanilabilecek bir yöntemdir. Sistem üzerindeki darbogazlarin olustugu noktalarin tespiti için yararli olan genis kapsamli bir yöntemdir. TRACE

 

• Sorguyu çalistirir, çalisan sorguyla ilgili olarak istatistik üretir,
• Uygulama gelistiricilerin sorgunun her bir bölümünü analiz etmesine yardimci olur.

 

TRACE ile yapilan izlemede, user_dump_dest initora parametresi ilen belirtilen dizine ora_nnnnn.trc söz diziminde bir trace dosyasi olusturulur.

 

TRACE’in bulunulan session’dan baslatilmasi mümkün oldugu gibi, bir baska session’in çalismasi da izlenebilir.

 

Bulunulan session için TRACE islemi :

 

SQL> alter system set timed_statistics=true;

SQL> alter session set max_dump_file_size=20000;

 

SQL> show parameter user_dump

 

NAME TYPE VALUE

---------------- ------- --------------------

user_dump_dest string /usr/oracle10/rdbms/log/udump

 

SQL> alter session set SQL_TRACE true;

 

SQL> select MUSTERI_ADI from MUSTERI where MUSTERI_NO=1;

 

…..

 

SQL> select * from dual;

 

SQL> alter session set SQL_TRACE false;

 

Dump dosyasinin olustugu dizinde, ilgili trace dosyasinin içerigi incelenir.

 

 

Dump file /usr/oracle10/rdbms/log/udump/tst1_ora_1105.trc

……

=====================

PARSING IN CURSOR #1 len=32 dep=0 uid=0 oct=42 lid=0 tim=164924072960 hv=789637826 ad='7b4fa270'

alter session set sql_trace true

END OF STMT

EXEC #1:c=1952,e=2048,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=164924072960

*** SESSION ID:(1633.1093) 2007-05-16 13:55:46.154

=====================

PARSING IN CURSOR #5 len=28 dep=0 uid=0 oct=3 lid=0 tim=164932504576 hv=4187904027 ad='7b29b108'

select MUSTERI_ADI from MUSTERI where MUSTERI_NO=1;

……

 

Baska session için TRACE islemi :

 

Izlenmesi istenen sesssion’a ait SID ve SERIAL# bilgileri elde edilir (Örnek olarak TEST kullanicisi seçilmistir).

 

SQL> alter system set timed_statistics=true;

 

SQL> alter session set max_dump_file_size=20000; -- OS block

 

SQL> select SID, SERIAL# from v$session where username=’TEST’;

 

SID SERIAL#

---------- ----------

163 110

 

Elde edilen bu SID ve SERIAL# degerleri, asagidaki sekilde kullanilarak trace baslatilir.

 

SQL>execute dbms_system.set_sql_trace_in_session('163','110',true);

 

 

Trace’in sonlandirilmasi için ayni komut, false parametresi ile çalistirilir (Asagidaki komu isletilmezse izlenen kullanicinin o session’dan çikana kadar yapacagi sonraki islemler de ayni trace dosyasina eklenir).

 

SQL>execute dbms_system.set_sql_trace_in_session('163','110',false);

 

Dump dosyasinin olustugu dizinde, ilgili trace dosyasinin içerigi incelenir.

 

 

Dump file /usr/oracle10/rdbms/log/udump/tst1_ora_1105.trc

……

=====================

PARSING IN CURSOR #1 len=32 dep=0 uid=0 oct=42 lid=0 tim=164924072960 hv=789637826 ad='7b4fa270'

alter session set sql_trace true

END OF STMT

EXEC #1:c=1952,e=2048,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=164924072960

=====================

PARSING IN CURSOR #5 len=28 dep=0 uid=0 oct=3 lid=0 tim=164932504576 hv=4187904027 ad='7b29b108'

select MUSTERI_ADI from MUSTERI where MUSTERI_NO=1;

……

 

2. EXPLAIN PLAN Kullanimi

 

EXPLAIN PLAN ile, sorgu çalistirilmaksizin, Oracle optimizer tarafindan izlenecek plan görüntülenir. Bu yöntem, sorgunun çok uzun sürdügü durumlarda tercih edilebilir. Sorgunun süresine, getirecegi kayitlara ihtiyaç olmadan sadece çalisma planinin elde edilmesi için yararlidir.

 

1. Izleme islemini yapacak kullanicinin öncelikle bir PLAN_TABLE tablosuna sahip olmasi gerekir. Genellikle $ORACLE_HOME/rdbms/admin dizini altina yer alan utlxplan.sql script’i, izleme islemini yapacak kullanici tarafindan SQL*Plus’tan çalistirilir.

 

SQL> @utlxplan

 

1. Izlenecek sorgu SQL*Plus’tan asagidaki sekilde çalistirilir.

 

SQL> explain plan

set statement_id=’MUSTERI’ for

select MUSTERI_ADI

from MUSTERI

where MUSTERI_NO=1;

 

1. Plan, asagidaki sorgu ile görüntülenir.

 

SQL> select lpad(‘ ‘,2*(level-1)) || operation || ‘ ‘

|| options || ‘ ‘ || object_name || ‘ ‘ ||

Decode(id,0, ‘Cost = ‘ || position) “Query Plan”

Arkadaslar bu makalemde sizlere dinamik SQL konusundan söz edecegim.

Dinamik SQL Nedir ?

Dinamik SQL, senaryosu çalisma zamanindan once bilinmeyen SQL cümlecikleri ile program yazma imkani saglayan bir tekniktir. Dinamik SQL’in detaylarina girmeden önce sizlere statik SQL den bahsetmek istiyorum. Böylelikle ikisi arasindaki farki daha net anlayacaginizi düsünüyorum. Statik SQL komutlari çalismadan çalismaya degismez. Komutun tüm senaryosu derlendigi anda bilinir ve herhangi bir alter islemi söz konusu olmadikça öylece sabitlenir ve su avantajlari saglar :

1) Hatasiz derlenmis bir SQL komutunda tüm objelerin veritabaninda geçerli oldugu bilinir,

2) Hatasiz derlenmis bir SQL komutunda tüm yetkilendirmelerin yerli yerinde oldugu bilinir.

3) Statik SQL komutlarinin sagladigi performans dinamik SQL’e göre daha üstündür.

Bu avantajlara baktigimizda dinamik SQL’I ancak, static SQL komutlariyla basaramadigimiz islerde veya static SQL komutlarinin kullanissiz kaldigi durumlarda kullanmayi tercih etmeliyiz.Her ne kadar statik SQL in kisitlamalari olsa da performans bakimindan dinamik SQL e nazaran üstündür. Içinizdeki soruyu duyar gibiyim, “e pekala neden dinamik SQL ?”…

Neden Dinamik SQL ?

Programlarinizda bazi anlarda yazacaginiz SQL komutlarinin full içerigini bilmeyebilirsiniz. Yani SQL sorgunuz, kullanicidan gelecek degisik input degerlerine gore sekillenme ihtiyaci duyabilir. Lafi karistirmadan hemen bir örnek verelim;

Bir datawarehouse ortaminiz var ve siz bu ortamdaki bir raporlama modülünüzdeki tablo isimlerini derlendigi tarihe gore atamak istiyorsunuz. Mesela INV_01_1997, INV_04_1997, INV_07_1997, INV_10_1997 gibi. Böyle durumlarda raporlama modülünüzde dinamik SQL kullanarak tablolarinizi çalisma zamaninda ‘create’ edebilirsiniz.

Veya programinizda bir listeleme modülü var ve siralamayi kullanicinin belirlemesini istiyorsunuz. Böyle bir durumda ‘order by’ fonksiyonu degisken olacaktir. Yani kullanici hangi kritere gore siralama yapmak istiyorsa ‘order by’ o kritere gore sekillenecektir. Böyle bir durumda da dinamik SQL kullanabilirsiniz.

PL/SQL Bloklari Içinde DDL ve SCL Kullanimi

PL/SQL içinde su tipleri static SQL’ e tercihen kullanabiliriz :

- DDL(Data Definition Language) cümleleri. ‘Create’, ‘Drop’, ‘Grant’, ‘Revoke’ gibi…

- SCL(Session Control Language) cümleleri. ‘Alter Session’, ‘Set Role’ gibi..

Bir örnek verecek olursak :

CREATE TYPE t_emp AS OBJECT (id NUMBER, name VARCHAR2(20))

/

CREATE TYPE t_emplist AS TABLE OF t_emp

/

CREATE TABLE dept_new (id NUMBER, emps t_emplist)

NESTED TABLE emps STORE AS emp_table;




INSERT INTO dept_new VALUES (

10,

t_emplist(

t_emp(1, 'SCOTT'),

t_emp(2, 'BRUCE')));

DECLARE

deptid NUMBER;

ename VARCHAR2(20);

BEGIN

EXECUTE IMMEDIATE 'SELECT d.id, e.name

FROM dept_new d, TABLE(d.emps) e -- not allowed in static SQL

-- in PL/SQL

WHERE e.id = 1'

INTO deptid, ename;

END;



Dinamik SQL Kullanim Alanlari

- Kullaniciya çalisma zamaninda sorgu seçimi veya kritere gore siralama v.s islem seçenegi sunan uygulamalar,

- Çalisma aninda veri girisi veya optimizasyon seçenegi sunan uygulamalar,

- Veritabanindaki tablo tanimlamalarinin (DDL statements) sürekli degisken oldugu uygulamalar,

- Istege ve ihtiyaca gore çalisma aninda create edilen tablo vb. objeler içeren uygulamalar.

Konunun basinda vermis oldugumuz datawarehouse örnegine bakarsak, tablo tanimini normalde biliyoruz fakat ismini çalisma aninda vermek istiyoruz. Dinamik SQL bu problemi çözüyor.

CREATE OR REPLACE PROCEDURE query_invoice(

month VARCHAR2,

year VARCHAR2) IS

TYPE cur_typ IS REF CURSOR;

c cur_typ;

query_str VARCHAR2(200);

inv_num NUMBER;

inv_cust VARCHAR2(20);

inv_amt NUMBER;

BEGIN

query_str := 'SELECT num, cust, amt FROM inv_' || month ||'_'|| year

|| ' WHERE invnum = :id';

OPEN c FOR query_str USING inv_num;

LOOP

FETCH c INTO inv_num, inv_cust, inv_amt;

EXIT WHEN c%NOTFOUND;

-- process row here

END LOOP;

CLOSE c;

END;

/