Oracle’da birçok farklı blok yapısı ile çalışma performansı ölçümü

Bu yazıda Oracle’nın 8k ve 16k büyüklüğündeki veri blokları ile ilgili performans testlerini yapacağım. Hem 8k hemde 16k büyüklüğündeki veri blokları üzerinde DML işlemleri yapacağım. Bu amaçla; 8k lık veri bloğuna sahip “tbs_8k” adlı tablespace içinde bir  tablo, 16k lık veri bloğuna sahip “tbs_16k” adlı tablespace içerisinde başka bir tablo oluşturacağım. Sonuçta yapacağım test işleminde, büyük bloğa sahip tablolarda UPDATE işlemlerinin daha uzun sürede tamamlanmasına rağmen, INSERT işlemlerinin ise daha kısa zamanda tamamlandığını gözlemleyeceğiz.

A) OMF(Oracle Managed File) dosya sistemi kullanacağım. Veritabanı olarak Oracle 10g R2 sürümünü ve host OS olarak ise Solaris 10 kullanmaktayım. İlk işlem olarak  db_create_file_dest parametresi ile OMF dizinini tanımlıyorum.

SQL> show parameter db_create_file_dest
NAME                         TYPE               VALUE
------------                  ------------      ------------
db_create_file_dest      string                /oradata2


B) 8K ve 16K blok büyüklüğündeki tablespace’leri oluşturuyorum.

SQL> create tablespace tbs_8k blocksize 8k;
Tablespace created.

SQL> alter system set db_16k_cache_size=20M;
System altered.

SQL> create tablespace tbs_16k blocksize 16k;
Tablespace created.

C) Hem 8K’lık tablespace içerisinde hemde 16K’lık tablespace içinde birer tane tablo oluşturuyoruz ve rastgele toplu veri girişi yapıyoruz.

SQL> create table table_8k (n number ,k varchar2(15)) tablespace tbs_8K;
Table created.

SQL> begin
for i in 1 .. 100000
loop
insert into table_8k values(i,'pc-'||round(dbms_random.value(1,20000),0));
end loop;
end;
/
PL/SQL procedure successfully completed.
Elapsed: 00:00:12.51

SQL> create table table_16K (n number ,k varchar2(15)) tablespace tbs_16k;
Table created.

SQL> begin
for i in 1 .. 100000
loop
insert into table_16k values(i,'pc-'||round(dbms_random.value(1,20000),0));
end loop;
end;
/

PL/SQL procedure successfully completed.
Elapsed: 00:00:09.42

Yukardaki ilk testte INSERT işlemi 16K lık veri bloğuna sahip tabloda daha hızlı tamamlanmıştır.

D) flush.sql adında bir sql scripti oluşturup içerisine öne belleği ve paylaşımlı havuzu boşaltması amacıyla komutları ekliyorum ve SELECT testini yapıyorum.

SQL> !vi flush.sql
alter system flush buffer_cache;
alter system flush shared_pool;

SQL> @flush
System altered.
Elapsed: 00:00:00.03

System altered.
Elapsed: 00:00:00.03

SQL> select * from table_8k where k like '%888%';
176 rows selected.
Elapsed: 00:00:00.14

SQL> select * from table_16k where k like '%888%';
195 rows selected.
Elapsed: 00:00:00.04


E) Şimdi UPDATE test işlemine başlıyoruz.Yukardaki sonuca gore 16K lık veri bloğunda saklanan tabloya çekilen SELECT sorgusu, 8 K lık veri bloğunda saklanan tabloya çekilen sorguya göre daha hızlı kayıt dönmektedir. Tabii bunu referans kabul edemeyiz, zira bu tablonun hangi sıklıkla kullanılacağı ve ön bellekte ne kadar bulunacağı, parsing ratingi gibi pek çok kriter bu cevap süresine blok büyüklüğünden daha fazla şekilde etki edecektir. Ancak, aynı şartlarda büyük blok tercih edilebilir.

SQL> @flush
SQL> update table_16k set k='Testing';
100000 rows updated.
Elapsed: 00:00:06.88

SQL> @flush
System altered.
Elapsed: 00:00:00.24
System altered.
Elapsed: 00:00:00.02

SQL> update table_8k set k='Testing';
100000 rows updated.
Elapsed: 00:00:01.91

Yukardaki testtede görüldüğü üzere eşit şartlarda(indeks ve ksııtlamaların olmadığı) UPDATE işlemi 8K lık tablo üzerinde daha hızlı olmaktadır.

SQL> delete from table_8k;
100000 rows deleted.
Elapsed: 00:00:09.53
SQL> delete from table_16K;
100000 rows deleted.
Elapsed: 00:00:09.27

DELETE işleminde 8k ve 16k veri bloklarında zaman bazında pekbir farklılık bulunmamaktadır.