Home / MAKALELER / Veri Tabanı / Partition Exchange Loading

Partition Exchange Loading

Partition Exchange Loading (PEL) kod olarak, veritabanı üzerinde non-partitioned bir tablo ve bir partition data adreslerini değiştirmemizi sağlayan bir DDL işlemidir.

 

Partition Exchange Loading (PEL) kod olarak, veritabanı üzerinde non-partitioned bir tablo ve bir partition data adreslerini değiştirmemizi sağlayan bir DDL işlemidir. Veri ambarı uygulamalarında  çoğunlukla incremental data yüklemek için kullanılır.
Şekil1. SATIS tablosu incremental data yükleme örneği
Incremental yüklemeye örnek verirsek, veri ambarının SATIS tablosuna 21 Şubat 2011  tarihinin satış datalarını PEL ile yükleyelim. İlk olarak SATIS tablosu ile aynı sütun isimlerinde, veri tiplerinde ve sütun sıralamasında olan TMP_SATIS non-partitioned tabloyu yaratırız,  SATIS tablosuna ise P_20110221 ismiyle boş bir partition  ekleriz.  21 Şubat 2011  data dosyasını TMP_SATIS  tablosuna yükleriz. Varsa SATIS tablosundaki constraint ve indexleri, bu adımda TMP_SATIS tablosuna koyabiliriz.  SATIS tablosundaki constraintleri, yapacakları kontroller işlem süresini uzatacağı için “disable” ederiz. Indexleri işlem öncesi “unusable” etmek ETL işlemlerinde süreden kazanmamızı sağlar. TMP_SATIS tablosu  ile boş olan P_20080524 partition ını değiştirdiğimizde yeni data, TMP_SATIS tablosundan P_20110221 partition ına taşınmış olur.  PEL sonrası, TMP_SATIS tablosu  boştur, yeni gelen data SATIS tablosunun P_20110221 partititon ındadır. SATIS tablosundaki constraintleri “enable” hale getiririz, indexleri “rebuild” ederiz. Not olarak ekleyelim, tablomuz interval partition edilmiş olsaydı, “EXCHANGE PARTITION FOR” kodunu kullanarak  yeni partition yaratmadan veri tabanı tarafından yaratılmış partition için işlem yapabilirdik.
PEL yönteminin veri ambarında kullanıldığı başka bir uygulama ise arşivlemedir. Veri ambarları belirli bir süre için data tutmak zorundadır, belli bir süre sonra ise data güncelliğini kaybettiği için, daha çok ise kısıtlı disk alanı ve pahalı donanım nedeniyle yeni data için arşivleme yapılır. Arşivleme, datanın veri tabanından uzaklaştırılıp arşiv dosyalarına dönüştürülerek depolama donanımlarına atılarak yapılır. Arşivleme işleminde datanın tablodan uzaklaştırılması adımında PEL kullanabilir.
Şekil2. SATIS tablosu arşivleme örneği
 
Arşivleme örneği olarak tablespace alanının dolması nedeniyle SATIS tablosunda  1999 yılının Ocak’tan Haziran’a kadar olan verilerinden şimdilik kurtulmak istediğimizi düşünelim. Bu tarih aralığındaki dataları arşivleyeceğiz. Arşiv tablomuz olarak SATIS_19990101 isminde SATIS tablosuyla aynı sütun isimlerinde ve  veri tipinde non-partitioned tablo yaratıyoruz.  SATIS tablosunun P_19990101  partition ını, SATIS_19990101 tablosuyla değiştirdiğimizde, P_199901   partition ını boşalttık, Ocak 1999 datasını ise artık SATIS_199901 tablosundadır.  SATIS_199901  tablosu arşivlenebilir. Aynı işlemleri diğer partition lar için uyguladığımızda SATIS tablosunun 1999 ilk yarısını arşivlemek üzere hazırlamış oluruz.
PEL yönteminin kullanılabileceği başka bir uygulama ise büyük partitioned tablolarda bütün datayı etkileyen değişikliklerin select-insert veya create-insert yerine  PEL ile yapılmasıdır, bu değişiklikler periyodik yapılmaz, genellikle defect nedeniyle bir kez yapılacak işlemlerdir, değişikliklerin bu yöntem ile yapılması basit ve hızlı sonuçlar elde etmemizi sağlayabilir.
Şekil3. SATIS tablosu PEL ile değişiklik öncesi ve sonrası
 
Tarih aralıklarında SATIS tablosunun bir sütunu bütünüyle değişeceğini varsayalım, PEL yöntemiyle bu değişikliği tek partition için şöyle yaparız:  Değiştirilecek SATIS tablosu ile aynı yapıda TEMP_SATIS non-partitioned çalışma tablomuzu yaratırız, P_20110221 partition ı TEMP_SATIS tablosuna değişikliği yaparak insert ederiz, TEMP_SATIS tablosu doğru datayı tutar, sonraki adımda P_20110221  partition ını boşaltırız, TEMP_SATIS tablosunu P_20110221 ile değiştiririz. Data, P_20110221 partition ınında yer alır,  TEMP_SATIS boştur. İlk partition için yaptığımız gibi tablo partition larını döngüye alarak bütün tablo için değişikliği yaparız. PEL yönteminin bu problemde kullanımı, tek partition ın değiştirilme süresi, bütün tablonun süresinden kısa sürdüğü için tabloyu kullanıcıya  en kısa sürede açmamızı sağlar. Son partition ı bitirip kullanıcıya açtığımızda kullanıcı için değişiklik yapılmış sayılır, diğer partition ların değiştirilmesinden kullanıcı minimum etkilenmiş olur.
Exchange Partition kodu şöyle yazılır;
1.ALTER TABLE SATIS
2.EXCHANGE PARTITION P_20110221 WITH  TABLE TMP_SATIS;
Örneklerde PEL yönteminin avantajlarına değindim, özetlersek: Exchange partition tanımında data dictionary (veritabanı bilgileri) tablolarında partition ve tablo adreslerini değiştirdiğini söylemiştik,  fiziksel data taşıma yapmadığını belirtelim, bir DDL işlemi olduğu için kısa sürer. PEL ile büyük tablolara data yükleme süresi, bir partition ile ilgili olduğu için sadece yüklenen data büyüklüğüne göre değişir, DML işlemlerinde olduğu gibi tablo büyüklüğünden etkilenmez. Non-partitioned tablo üzerinde yeni dataya constraint ve index koyulmasına olanak vermesi, kullanıcı erişim süresinin yeni data yüklenmesinden minimum etkilenmesini sağlar. Tablo büyüklüğünden bağımsız olan PEL ile veri ambarında data yükleme veya arşivleme süreleri zamanla orantılı olarak artış göstermez, belli bir noktadan sonra sabit kalır, incremental data yüklemesini PEL ile yapmamız, gelecekte veri ambarı büyüse de development değişikliği gerektirmeyecektir.
Exchange Partition kullanırken dikkat etmemiz gereken bazı durumlar var.  Exchange partition ile yükleyeceğimiz datayı tek bir partition a yüklemeliyiz. Teknik kısıtları sıralarsak, ilk olarak Oracle 11g veritabanında composite *-hash subpartition tablolarda exchange partition yapamayız, bunun dışında hertür partitioned ve subpartitioned tablolarda exchange partition yapabiliriz. Veri ambarlarında kullanımını tavsiye etmesek de PEL yaparken  global index kullanmamız gerekiyorsa update ederek exchange partition yapılmalı, bu detay belirtilmediğinde global index kullanılmaz hale gelir. Index update edilerek işlem yapıldığında işlem sonrası indexin tekrar oluşturulmasına gerek yoktur. Veri ambarında mümkünse global index yerine local index kullanılması gerekir, ETL sırasında indexin update edilmesi yerine öncesinde unusable sonrasında rebuild edilmesi daha kısa sürede ETL işlemleri sonlanır.ODI’de exchange partition yöntemi ile yükleme yaparken ayrı stage tabloları dolduran paketler ayrı ayrı paralel şekilde doldurulabilir ve exchange partition kodu ayrı bir paket olarak son adım olarak eklenirse datanın bir kısmının tekrar yüklenmesi için elverişli olur. Ayrıca stage tabloların yüklendiği paketler,  parametrik olarak exchange partition adımı eklenerek yazılabilir.

About Jale Ozgur

PL/SQL , ETL, BI Developer

İlginizi Çekebilir

SQL Server ile Veri Şifreleme

Bilgi teknolojilerinde verinin güvenliği çok kritik bir öneme sahiptir. Önemli verileri korumak için ekstra bir …

Bir Cevap Yazın