Merhaba Arkadaşlar,

Bu yazımda önceki yazıda başladığım Index konusuna devam edeceğim. Indexle ilgili temel bilgileri bilmeyenlerin bu yazıyı okumadan  önce  önceki yazımı okuması ardından bu yazıyı okuması daha iyi olacaktır. Bu yazımda index ile ilgili örnek bir Musteri tablosu üzerinden kullanımını ve performansını anlatacağım.

index3

Örnek Müşteri tablomu sorguladığımda aşağıdaki gibi 100 milyon kayıt bulunmaktadır.

SQL> select count(*) from msdeveci.musteri;
COUNT(*)
 ----------
 100000000
SQL>

Bu örnek tablonun scripti ve örnek datalarından bazıları aşağıdaki gibidir.

CREATE TABLE MSDEVECI.MUSTERI
 (
 MUSTERI_ID NUMBER,
 ADI VARCHAR2(50 BYTE),
 TEL_NO NUMBER,
 ADRES VARCHAR2(100 BYTE),
 SEHIR VARCHAR2(50 BYTE),
 ABONE_TARIHI DATE,
 YORUM VARCHAR2(150 BYTE)
 )
 TABLESPACE USERS
 RESULT_CACHE (MODE DEFAULT)
 PCTUSED 0
 PCTFREE 10
 INITRANS 1
 MAXTRANS 255
 STORAGE (
 INITIAL 64K
 NEXT 1M
 MINEXTENTS 1
 MAXEXTENTS UNLIMITED
 PCTINCREASE 0
 BUFFER_POOL DEFAULT
 FLASH_CACHE DEFAULT
 CELL_FLASH_CACHE DEFAULT
 )
 LOGGING
 NOCOMPRESS
 NOCACHE
 NOPARALLEL
 MONITORING;

index4

Örnek tablonun yukarıdaki scriptine de baktığımız zaman bu tabloda Index bulunmamaktadır.

Indexi bulunmayan 100 milyon kayıtlık musteri tablosunun musteri_id si 93 olan kaydını aşağıdaki gibi sorguluyorum. Sorgu tamamlandığında aşağıda görüldüğü gibi 1 kayıt çekilmesine  rağmen bu sorgunun cevap süresi 5 dakika 56 saniye şeklindedir. Bu sürede Production sistemlerde çok fazla ve kabul edilemez bir değerdir. Hem sistem kaynakları gereksiz yere tüketilmekte hemde  farklı çalışmalardaki bekleme süreleri ile beraber  kullanıcılar çalışamaz hale gelmektedir.

SQL> set timing on
 SQL> select * from msdeveci.musteri where musteri_id=93;
MUSTERI_ID       ADI             TEL_NO       ADRES        SEHIR      ABONE_TARIH              YORUM
 ---------- -------------------------------------------------- ---------- ------------------------------------------------------------------------------------------
 93            93.MUSTERI      5429999999     Sincan       Ankara      01-JAN-13   ABONELER TEST AMACLI YUKLENMISTIR
Elapsed: 00:05:56.16
 SQL>

Yukardaki sorgunun Execution planı ise aşağıdaki gibidir.

SQL> set autotrace on
SQL> select * from msdeveci.musteri where musteri_id=93;
MUSTERI_ID ADI TEL_NO
---------- -------------------------------------------------- ----------
ADRES
--------------------------------------------------------------------------------
SEHIR ABONE_TAR
-------------------------------------------------- ---------
YORUM
--------------------------------------------------------------------------------
 93 93.MUSTERI 5429999999
Sincan
Ankara 01-JAN-13
ABONELER TEST AMACLI YUKLENMISTIR

Execution Plan
----------------------------------------------------------
Plan hash value: 2659560815
-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 86 | 364K (1)| 01:12:52 |
|* 1 | TABLE ACCESS FULL| MUSTERI | 1 | 86 | 364K (1)| 01:12:52 |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("MUSTERI_ID"=93)

Statistics
----------------------------------------------------------
 0 recursive calls
 2 db block gets
 1341427 consistent gets
 1339007 physical reads
 0 redo size
 1010 bytes sent via SQL*Net to client
 524 bytes received via SQL*Net from client
 2 SQL*Net roundtrips to/from client
 0 sorts (memory)
 0 sorts (disk)
 1 rows processed
SQL>

Şimdi musteri tablomuza index atalım ve index oluştuktan sonra aynı işlemleri yapıp aradaki farklara bakalım.

Indexi atarken sistemin sahip olduğu cpu sayısına bağlı olarak parallelik kullanıp indexi online olarak aşağıdaki script ile oluşturuyorum.

SQL> create index MID_IX on msdeveci.musteri(musteri_id) parallel 4 online;
 Index created.

Bu Indexi oluşturduktan sonra aşağıdaki gibi Indexin oluşup olmadığını sorguluyorum.

SQL> select * from dba_indexes where table_name='MUSTERI';

index5

Index oluştuktan sonra yukardaki musteri_id si 93 olan musteriyi sorgulama scriptini aşağıdaki gibi tekrardan çalıştırdığımda sorgu 1 saniyenin çok çok altında bir sürede çalıştığını görüyoruz.

SQL> select * from msdeveci.musteri where musteri_id=93;
MUSTERI_ID       ADI           TEL_NO       ADRES         SEHIR      ABONE_TARIH             YORUM
---------- -------------------------------------------------- ---------- ------------------------------------------------------------------------------------------
    93        93.MUSTERI    5429999999      Sincan        Ankara       01-JAN-13   ABONELER TEST AMACLI YUKLENMISTIR
Elapsed: 00:00:00.01
SQL>

Bu sorgunun execution planına baktığımız zaman aşağıdaki gibi geliyor.

SQL> set autotrace traceonly
SQL> select * from msdeveci.musteri where musteri_id=93
Elapsed: 00:00:00.00
Execution Plan
----------------------------------------------------------
Plan hash value: 3780290458
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 86 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| MUSTERI | 1 | 86 | 4 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | MID_IX | 1 | | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("MUSTERI_ID"=93)

Statistics
----------------------------------------------------------
 0 recursive calls
 0 db block gets
 5 consistent gets
 0 physical reads
 0 redo size
 1014 bytes sent via SQL*Net to client
 524 bytes received via SQL*Net from client
 2 SQL*Net roundtrips to/from client
 0 sorts (memory)
 0 sorts (disk)
 1 rows processed
SQL>

Yukardaki index kullanılmış execution plan ile index kullanılmamış en üstteki execution plan arasında dağlar kadar fark olduğunu görebiliyoruz. Bu tabloda index kullanıldığı zaman sistem kaynakları çok fazla harcanmadan ve neredeyse 1-2 saniye içerisinde sorgularımız dönmekte halbuki index kullanmadan önce aynı sorgu 5 dakikadan fazla sürmüştü. Index kullanmadan önce sorgunun uzun sürmesinin sebebi yine her iki execution plana baktığımız zaman görebiliriz. Ilk execution plan tabloya Full table access ( Kırmızı kalın harflerle belirtilmiş ) yapmış 2.execution plan ise Index Range Scan ( Kırmızı kalın harflerle belirtilmiş ) yapmış. Tabloya Full yada Index gitmesine paralel olarak ilk sorgunun execution planında sorgunun Cost u ( Yeşil Kalın harflerle belirtilmiş ) 364 iken alttaki indexli sorgunun Costu ( Yeşil Kalın harflerle belirtilmiş ) 4 e inmiş. Diğer yandan index kullanılmadan yapılan ilk sorgunun Consistent gets ve Physical Reads ( Mavi kalın harflerle belirtilmiş ) değerleri sırasıyla  1341427, 1339007 iken aynı parametrelerin değeri index kullanılan 2.execution planda 5,0 a inmiştir.

Yukarıdaki karşılaştırmadanda çok rahat anlaşılacağı üzere index gerektiği yerde performans açısından çok çok işe yaramaktadır. Index olmadan 1 kayıdı 5 dakikada veren Oracle, Index atıldığı zaman 10 milyon kaydı sorguladığım zaman aşağıdaki gibi 3 dakikadan daha az bir sürede döndürmekte ve Cost uda 151 olmaktadır.

SQL> select * from msdeveci.musteri where musteri_id between 1 and 10000000;
10000000 rows selected.
Elapsed: 00:02:24.48
Execution Plan
----------------------------------------------------------
Plan hash value: 3780290458
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10M| 820M| 151K (1)| 00:30:16 |
| 1 | TABLE ACCESS BY INDEX ROWID| MUSTERI | 10M| 820M| 151K (1)| 00:30:16 |
|* 2 | INDEX RANGE SCAN | MID_IX | 10M| | 23791 (1)| 00:04:46 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("MUSTERI_ID">=1 AND "MUSTERI_ID"<=10000000)

Statistics
----------------------------------------------------------
 0 recursive calls
 0 db block gets
 1464595 consistent gets
 151295 physical reads
 0 redo size
 1050778648 bytes sent via SQL*Net to client
 7333850 bytes received via SQL*Net from client
 666668 SQL*Net roundtrips to/from client
 0 sorts (memory)
 0 sorts (disk)
 10000000 rows processed
SQL>

Yukardaki son execution planına baktığımız zaman index atıldığı için 10 milyon kayıt sorgulanmasına rağmen yinede Consistent gets ve Physical Reads değerleri tek 1 kaydın index iz sorgulandığı en üstteki sorgudan daha az gelmektedir. Buda index kullanımının gerektiği yerde ne kadar önemli olduğunu ortaya koymaktadır.

Böylece bu yazının da sonuna gelmiş bulunmaktayım bir sonraki yazıda görüşmek dileğiyle esen kalın.

Reklamlar

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s