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.
Ö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;
Ö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';
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.
Oracle Exadata SQL Server Goldengate Weblogic EBS ve Linux konusunda aşağıdaki konularda 7×24 Uzman Danışmanlara yada Eğitimlere mi İhtiyacınız var mehmet.deveci@gridgroup.com.tr adresine mail atarak Bizimle iletişime geçebilirsiniz.
– Oracle Veritabanı Danışmanlığı
– Oracle Veritabanı Bakım ve Destek
– Exadata Danışmanlığı
– Exadata Bakım ve Destek
– SQL Server Veritabanı Danışmanlığı
– SQL Server Veritabanı Bakım ve Destek
– Goldengate Danışmanlığı
– Goldengate Bakım ve Destek
– Linux Danışmanlığı
– Linux Bakım ve Destek
– Oracle EBS Danışmanlığı
– Oracle EBS Bakım ve Destek
– Weblogic Danışmanlığı
– Weblogic Bakım ve Destek
– Oracle Veritabanı Eğitimleri
– Oracle VM Server Danışmanlığı
– Oracle VM Server Bakım ve Destek
– Oracle EPPM Danışmanlığı
– Oracle EPPM Bakım ve Destek
– Oracle Primavera Danışmanlığı
– Oracle Primavera Bakım ve Destek
– Oracle Eğitimleri
– SQL Server Eğitimleri
– Goldengate Eğitimleri
– Exadata Eğitimleri
– Linux Eğitimleri
– Oracle EBS Eğitimleri
– Oracle VM Server Eğitimleri
– Weblogic Eğitimleri
– Oracle EPPM Eğitimleri
– Oracle Primavera Eğitimleri