Tablonun boyutunun, bir alanındaki yoğunluktan ötürü gigabytelar seviyesinde büyük olduğu durumlarda, verinin sorgulanmasında ve update edilmesinde yavaşlıklar meydana gelecektir. Bu tür durumlarda, tabloyu bloklara (partition) ayırarak, erişim hızını artırabiliriz. Her partition farklı tablespace veya farklı disklerde oluşturulabilir.

Böyle bir uygulama için veritabanı sunucusu en az 2 işlemcili ve 1 Gbyte RAM´e sahip olmalıdır. Konfigurasyon yapılırken unutulmamalıdır ki, Oracle, diğer bir çok uygulamada olduğu gibi, 2 ve 2 nin katları olan değerlerde daha iyi ve daha sorunsuz çalışır.

Bu uygulamaya ne tür durumlarda ihtiyaç duyacağımızı ve nasıl bir çözüm sunacağımızı bir örnekle açıklamaya çalışalım.

Elimizde uzun yıllardır kullandığımız kişi bilgilerinin bulunduğu bir UYE tablomuz olsun. TC.Kimlik No uygulaması duyurulduğunda, basit bir şekilde TC KimlikNo alanını oluşturmuş olalım. İlerleyen süreçte, bu alanın önemi ve kullanımı gittikçe artacağı açıktır. Bu alan önce zorunlu hale getirildi, eksik olanların bilgileri Nüfus Müdürlüğünden çekilip güncellendi, ve sonunda her şey bu alana bağlı çalışmaya başladı. İlk duruma göre bu bilginin bulunduğu tablo standart bir tablo olarak create edilmişti. Fakat devamında tablo oldukça büyüdü, bütün uygulamalar bu tablodaki TC Kimlik No ile yapılmaya başlandı, dolayısıyla select ve update lerde belirgin performans düşüşü meydana geldi. İşte bu noktada "ne yapmamız lazım?" sorusunun cevabı "PARTITIONAL TABLE" olacaktır.

Bir tabloyu Partitional Table yapmaya karar verdiğimizde, öncelikle var olan tablo ile aynı alanlara sahip bir tabloyu aşağıdaki örnekte görüldüğü şekilde Partitional Table olarak create ederiz.

(Bu örneğimizde, UYE isimli bir tablomuz var, bu tabloyu, KAYIT_TARIHI sutununa göre birkaç partitiona bölmek istiyoruz.)

CREATE TABLE UYE_2(
KISI_ID                  NUMBER(6)               NOT NULL,
ADI                       VARCHAR2(30)         NOT NULL,
SOYADI                 VARCHAR2(30)         NOT NULL,
EPOSTA                 VARCHAR2(30)         NOT NULL,
TELEFON                VARCHAR2(10)         NOT NULL,
KAYIT_TARIHI        DATE                      NOT NULL,
BOLUM                   NUMBER(2)              NOT NULL
)

PARTITION BY RANGE (KAYIT_TARIHI) (

PARTITION KAYIT_TARIHI_1995 VALUES LESS THAN (to_date(´01/01/1996´,´DD/MM/YYYY´)),

PARTITION KAYIT_TARIHI _1996 VALUES LESS THAN (to_date(´01/01/1997´,´DD/MM/YYYY´)),

PARTITION KAYIT_TARIHI _1997 VALUES LESS THAN (to_date(´01/01/1998´,´DD/MM/YYYY´)),

PARTITION KAYIT_TARIHI _1998 VALUES LESS THAN (to_date(´01/01/1999´,´DD/MM/YYYY´)),

PARTITION KAYIT_TARIHI _1999 VALUES LESS THAN (MAXVALUE)

);

Burada PARTITION BY RANGE( ) ile kayıtlarımızı, KAYIT_TARIHI sütununa göre partitionlara böldük. Örneğin ilk satırda;  01/01/2006 dan önceki tüm kayıtlar için bu partition kullanılmasını ve partition adının KAYIT_TARIHI_1995 olduğunu belirttik.

select count(KISI_ID) from UYE_2 partition (KAYIT_TARIHI_1995);

şeklinde bir sorgulama yaptığımızda, sorgu sadece KAYIT_TARIHI_1995 partitionunda çalışacağından, bize oldukça fazla performans ve zaman kazancı sağlayacaktır.

Bundan sonra ise, eski tablomuzdaki verilerin exportunu alıp, eski tabloyu silmemiz, yeni tablomuzun adını düzelttikten sonra, export aldığımız verileri import etmemiz gerekmektedir. Bundan sonraki işlemler bu makalenin konusu olmadığından, kısaca yazarak geçiyoruz.

Export İşlemi :

c:>exp hr/hr file=c:uye.exp log=c:uye.log tables="UYE"

SQLPlus kullanılarak, UYE tablosu drop edilir:

SQL>drop table uye cascade constraints;

UYE_2 tablosunun adı UYE olarak değiştirilir:

SQL>rename UYE_2 to UYE;

Son olarak veriler UYE tablosuna import edilir:

C:> imp system/systempsw fromuser=hr touser=hr file=c:uye.exp log=c:imp.log tables="UYE" ignore=y commit=y

Artık elimizde belirli yıllara göre partitionlara böldüğümüz tablomuz mevcut oldu. Eğer gerekirse; Enterprise Manager Console ile Reorganizing Shema Object ?ten partition tabloyu online olarak normal hale getirebiliyoruz.

Bu makaleye katkılarından dolayı Ertuğrul Komut ´a teşekkürler.

http://www.findikkurdu.com/Article.aspx?ID=107' dan alıntıdır.