Oracle veritabanında büyük ölçekteki sort işlemleri için sunucumuzun hafızası (RAM) yetersiz kaldığında, bu işlemlerin sabit disk üzerinde gerçekleştirilmesi gerekmektedir. Bu işlemlerin sabit disk üzerinde gerçekleştirildiği Oracle veritabanı alanına temporary tablespace denilir. Temporary tablespace ‘in diğer tablespace ‘lerden farkı, mantıksal anlamda  datafile değil tempfile kullanmasıdır. O nedenle temporary tablespace ‘e yeni bir datafile ekleneceği zaman komut içersinde datafile değil, “tempfile” ifadesini kullanırız.

Veritabanımızın temporary tablespace alanını resize edemediğimiz durumlarda veya yeni bir temporary tablespace alanına ihtiyacımız duyduğumuzda aşağıdaki yönergeleri takip ederek yeni bir temporary tablespace alanı oluşturabiliriz. Bu konuda dikkat etmemiz gereken husus, default temporary tablespace alanı kullanıcılar tarafından aktif olarak sort v.b işlemler kullanıldığından, eski temporary tablespace alanını drop etmeden önce yeni temporary tablespace ‘in oluşturulmasının gerekliliğidir. Şimdi sırasıyla yeni temporary tablespace alanını oluşturup, eksisini sistemden kaldıralım.

• Öncelikle kendimize yeni bir temporary tablespace alanı oluşturulalım. Tablespace içersindeki datafile ‘ın büyüklüğünü ihtiyacınıza göre ayarlayabilirsiniz. Oluşturacağımız yeni tablespace alanı için aşağıda 16Gb ‘lık bir datafile ekledim fakat, büyük ölçekte kayıtlara sahip tablolar tutuyorsanız buna göre daha geniş temporay tablespace kullanmanız gerekebilir.

SQL> create temporary tablespace YENITEMP tempfile '/oracle/data/yenitemp1.dbf' size 16384M autoextend on next 512M maxsize 32767M;

• Yeni temporary tablespace alanını veritabanına ekledik. Şimdi yeni eklediğimiz temporary tablespace alanını, default tablespace olarak atayalım. Bundan sonra yapılacak olan sort işlemleri artık yeni oluşturduğumuz tablespace ‘de gerçekleştirilecek.
• Yeni default temporary tablespace alanımızı kullanmaya başladık, artık eski temporary tablespace alanını drop etmeye hazırız.

SQL> alter database default temporary tablespace YENITEMP;

SQL> drop tablespace ESKITEMP including contents and datafiles;

Tebrikler.

Alıntıdır --> http://www.boraovali.com/?cat=1

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.

Veritabanında tablo oluştururken primary key’i oluşturmak zorunlu olmamasına karşın, ilişkisel veritabanı mantığına göre her tabloda olması primary key (birincil anahtar) olmalıdır. İlişkisel veritabanın babası sayılabilecek Edgar F. Codd, “The Relational Model for Database Management” kitabında bunu şu şekilde belirtmiştir:
“İlişkisel Veritabanı Yönetim Sistemi, her tablo için bir birincil anahtar tanımına ihtiyaç duyar.”
Ustanın sözüne uyarak, veritabanımızda primary key’i olmayan tabloları bulmak istersek, şu basit sorguyu kullanabiliriz:
SQL> SELECT t.owner || ‘.’ || t.table_name AS tablename
FROM SYS.dba_tables t
WHERE t.owner NOT IN (’SYS’, ‘SYSMAN’, ‘SYSTEM’, ‘XDB’, ‘WMSYS’, ‘OUTLN’, ‘DBSNMP’ )
AND NOT EXISTS (
SELECT 1
FROM SYS.dba_constraints c
WHERE c.owner = t.owner
AND c.table_name = t.table_name
AND c.constraint_type = ‘P’)
ORDER BY t.owner, t.table_name
Sorguda göreceğiniz üzere özellikle SYS, SYSTEM, SYSMAN gibi Oracle’a ait schemalarındaki tabloları listeden çıkardım, siz bu listeyi daha da geliştirip Oracle ait tüm internal schemaları sorguda filtreleyebilirsiniz veya sorguyu sadece sizin belirlediğiniz schemalar için çalıştırabilirsiniz:
SQL> SELECT t.owner || ‘.’ || t.table_name AS tablename
FROM SYS.dba_tables t
WHERE t.owner IN (’HR’, ‘OE’)
AND NOT EXISTS (
SELECT 1
FROM SYS.dba_constraints c
WHERE c.owner = t.owner
AND c.table_name = t.table_name
AND c.constraint_type = ‘P’)
ORDER BY t.owner, t.table_name

Yerli ve yabancı çeşitli forumlarda veritabanındaki bir tablodan rastgele kayıt çekebilmek ile ilgili sorular görüyorum. Bu işin veritabanı üzerinde çözülebileceğini bilmeyenler bunu uygulamalarının ekledikleri kodlarla çözmeye çalışıyorlar. Aslında bu iş veritabanı için çok kolay, çünkü Veritabanı Yönetim Sistemleri random sayı üretmek ile ilgili fonksiyonlara sahiptirler. Bunları kullanarak veritabanından kolaylıkla rastgele kayıt çekebiliriz. Aslında uygulayacağımız yöntem var olan kayıtların arasından rastgele belirlenen bir kayıdı sorgulamak değil, var olan tabloyu sanal bir alana göre sıralayıp ilk (veya istenilen) sayıda kayıdı okumak. Hemen en basit haliyle Oracle’da bu işin nasıl yapılacağını görelim:
SQL> SELECT * FROM hr.employees ORDER BY DBMS_RANDOM.VALUE;
Bu komut ile HR schemasındaki employees tablosundan çekilen kayıtlar DBMS_RANDOM.VALUE fonksiyonunun ürettiği rastgele sayılara göre sıralanacaktır. Bu yüzden bu sorgunun her çağrılışında dönen kayıtların sırası değişik olacaktır. Siz bu dönen kayıtlardan bir veya daha fazlasını okuyarak istediğiniz rastgele kayıda ulaşabilirsiniz.
Aynı sorguyu MySQL için şu şekilde yazabiliriz:
SQL> SELECT * FROM employees ORDER BY RAND();
Microsoft SQL Server’da RAND() fonksiyonu bulunmasına rağmen, MySQL için yazdığımız sorguyu Microsoft SQL Server’da kullanamıyoruz. Çünkü Microsoft SQL Server’daki RAND() fonksiyonu birden fazla kayıt döndüren bir sorgu içerisinde çağrıldığında random olarak hep aynı sayıyı döndürüyor. Bu yüzden random kayıt seçebilmek için RAND() yerine, NEWID() kullanılması gerekiyor:
SQL> SELECT * FROM employees ORDER BY NEWID();
Bu sorgu random sayı üretmek yerine, her satır/kayıt için unique ID’ler üretiyor ve daha sonra bu ID’lerin içeriğine göre kayıtları sıralayarak döndürüyor. Bu sayede istenilen tablodan rastgele kayıtlar seçilebilmiş oluyor.

 

Büyük tablolar için indeks yaratılması çoğu zaman dba ‘lar için problemdir çünkü tablodaki kayıt sayısı fazla olduğunda indeksin yaratılmasıda zaman alır. Bu süreçte veritabanı sunucusu indeksin yaratılmasıyla da meşgul olacağından veritabanının genel performansında bir düşüş meydana gelir. Buna göre indeks oluşturken veritabanının performansını düşüren 3 ana unsur bulunmaktadır. Bunlardan ilki yazının başında da belirtiğim gibi indeks yaratılacak tablodaki kayıt sayısıdır. Tablodaki kayıt sayısı arttıkça oluşturmak istediğiniz indeksin büyüklüğüde artar. İkinci unsur, indeksi oluştururken yapılan işlemin kaydının redolog ‘a yazılmasıdır. 10 milyon kayda sahip bir tabloya indeks oluşturmak istediğinizde, işlem süresince 10 milyon kez redolog dosyalarına yapılan işlemin logu da yazılır. Üçüncü dikkat etmemiz gereken unsur indeksi oluşturulurken bu işlem için kaç tane process ‘in meşgul olacağının belirtilmesidir. Sunucu donanımızın kapasitesine göre process sayısını arttırıp azaltabiliriz.

Yukarıda anlattıklarım haricinde daha hızlı indeks oluşturmak için kendinize session bazlı bir sort area size oluşturabilirsiniz. Böylece indeks oluşturlurken sort işlemi sırasında daha fazla memory alanıyla çalışacağınızdan indeksin oluşturulmasıda buna göre kısa zaman alacaktır. Şimdi aşağıda TEST kullanıcısına ait DENEME isimli tablo üzerinde DENEME_IDX isimli bir indeks oluşturalım.

Öncelikle sqlplus ‘a bağlanalım.

sqlplus / as sysdba

Session bazlı kendimize özel bir work area size oluşturalım.

SQL> alter session set workarea_size_policy=manual;

Daha sonra kendimize 40Mb ‘lık bir memory alanı tanımlayalım.

SQL> alter session set sort_area_size=41943040;

Manuel olarak work area size tanımladıktan sonra artık indeksi oluşturmaya hazırız. Bu noktada dikkat etmemiz gereken nokta indeksi oluşturken sistemin kesintiye uğramaması için ONLINE parametresini vermemiz gerektiği. Eğer komut içersinde ONLINE parametresini vermezsek, indeks oluşturlurken tablo kilitli kalacağından çalışan sisteminiz kesintiye uğrayabilir. (ONLINE parametresi sadece Oracle Database Enterprise Edition ile desteklenmektedir.)

SQL> create index test.deneme_idx on test.deneme(kolon1, kolon2) nologging, parallel, online;

İndeksimiz oluşturuldu. Komut içersinde “nologging” parametresini kullanarak yapılan işlemin redolog ‘da kaydının tutulmasını engelledik. “Parallel” parametresiyle index ‘in birden fazla process tarafından oluşturmasını sağladım, böylece yapılan işlemin süresi daha da kısaldı. Bu noktada veritabanından gerçekleştirilecek işlem için kaç tane paralel process açılması gerektiğine veritabanı parametrelerinden “parallel_threads_per_cpu” karar veriyor. Eğer bu parametre üzerinde herhangi bir değişiklik yapmadıysanız Oracle indeks oluşturulması için arka planda 2 adet thread çalıştıracaktır.