Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Opti̇mi̇zi̇ng Data Access
Similar to Opti̇mi̇zi̇ng Data Access (20)
Recently uploaded
Recently uploaded (20)
Opti̇mi̇zi̇ng Data Access
- 1. Emrah METE TURKCELL TEKNOLOJİ OPTIMIZING DATA ACCESS
- 2. http://emrahmete.wordpress.com/about/ Marmara Üniversitesi - Bilgisayar Teknolojisi ve Programlama Yıldız Teknik Üniversitesi - Bilgisayar Mühendisliği Turkcell Teknoloji - Yazılım Geliştirme Mühendisi emrahmete.wordpress.com TROUG – Kurucu Üye, Yönetim Kurulu Üyeliği Emrah METE Yahoo OracleTurk Grubu Moderatör
- 3. Agenda - How to find efficient access path? - Logical Reads - Main Causes of Inefficient Access Paths and Solutions - Selectivity - SQL Statements with Weak Selectivity - Full Table Scans - Full Partition Scans - Full Index Scans - SQL Statements with Strong Selectivity - Rowid Access - Index Access - Single Table Hash Cluster Access
- 4. How to find efficient access path? - Resource Consumption - Efficiency / Speed - Resource Utilization
- 5. Logical Reads • CPU bound operation, it reflects CPU utilization very well. • Logical reads might lead to physical reads. • Logical Reads is an operation subject to serialization. • Logical Reads is readily available at athe SQL statement and execution plan operation levels.
- 6. Logical Reads • 5 logical reads per returned row Good • Between 10 and 15 logical reads per returned row Acceptable • Between 15 and 20 logical reads per returned row Inefficient
- 8. Main Causes of Inefficient Access Paths and Solutions Causes • No suitable access structures (for example, indexes) are available. • A suitable access structure is available, but the syntax of the SQL statement does not allow the query optimizer to use it. • The table or the index, or both, is not partitioned. • Query optimizer makes wrong estimations because of a lack of statistics Solutions • Minimize the number of logical reads. • Add new access structers or change pysical layout. • Up to date table statistics. • Selectivity - Operations with weak (high) selectivity - Operations with strong (low) selectivity
- 9. Selectivity Selectivity = number of return rows / total rows
- 10. SQL Statements with Weak Selectivtiy - Full Table Scans - Full Partition Scans - Full Index Scans
- 11. FULL TABLE SCANS • It is possible to perform a full table scan on all tables • the database engine reads all of the table’s blocks below the high watermark sequentially
- 12. FULL TABLE SCANS Total Rows: 10000 N2=19: 24 Rows Case1: Case2: - Alter Table Enable Row Movement - Alter Table Shrink Space
- 13. Partitioning
- 15. FULL INDEX SCANS
- 16. SQL Statements with Strong Selectivtiy - Rowid Access - Index Access - Single Table Hash Cluster Access
- 17. ROWID ACCESS - The most efficient way to access a row is to directly specify its rowid in the where clause. Data Object Number Relative File Number Block Number Row Number ROWID FORMAT 10 Byte ÖR:AAAR5cAAFAAAACfAAA
- 18. ROWID ACCESS
- 19. INDEX ACCESS - Index accesses are by far the most often used access paths for SQL statements with strong selectivity.
- 21. BITMAP INDEXES
- 22. B-TREE vs BITMAP Indexes - Primary Key and Unique Key - Row-Level Locking - Efficient Combination Of Several Indexes - IS NULL Condition - Compression
- 24. SINGLE TABLE HASH CLUSTER ACCESS
- 25. SORULAR/YORUMLAR
- 26. Kaynaklar - docs.oracle.com - TroubleShooting Oracle Performance, Chapter9, Christian Antognini, 2008 - emrahmete.wordpress.com - Expert Oracle Database Architecture, Tom Kyte 2011 - tahiti.oracle.com
- 27. Teşekkürler
Editor's Notes
- Efficiency or Speed: Efficient Access path her zaman en hızlı olan yöntemlerden biri olmayabilir. Parallel processing yeteneklerini kullanıp iyi response time’lar elde edebiliriz ancak, burada önemli olan nokta bu hızı ne kadar kaynak harcayarak yaptığımızıdır. Efficient access path, tüm sistem düşünüldüğünde SQL statementımızın daha az kaynak kullanarak (çünkü kaynaklar sınırlı), daha fazla ölçeklenebilir ve hızlı sonuçlar üretebilmesidir. Resource Utilization: Dönen satır sayısı ile doğrudan ilgilidir. Basit bir mantıkla dönen satır sayısı az ise resource utilization az, dönen satır sayısı çok ise resource utilization çoktur. Ama burada ana metrik dönen 1 satır sonucunda ne kadar kaynak kullanıldığının kontrol edilmesidir. Resource Consumption: İdeal hayatta, database engine tarafından yapılan kaynak tüketimi 4 başlık altında ölçümlenebilir. Bunlar CPU, Disk, Memory, Network ancak bu 4 parametre değerini toplayıp ölçümleyip değerlendirmek her bir SQL statementımız için oldukça zaman alıcı olabilir. Burada CPU’da bir satırın işlem görme süresi kullanılan CPU’ya bağımlı olarak değişkenlik gösterdiğin bu parametre üstünden yorum yapıp efficent access path’e gitmek oldukça zor olabilir (çünkü sistemden sisteme değişkenlik var CPU anlamında). Kullanılan memory miktarı döndürülen satır sayısına oranla değişebilir bazı durumlarda bilgiler doğrudan memory’den okunacağından dolayı network ve disk kaynakları her zaman kullanılmayadabilir. Uzun süren bir SQL’in hiç disk ve network kaynağı kullanmadan mütevazı bir memory kullanarak çalışıp sonuç döndürmesi aslında sıradan bir olaydır. - Database engine’in işi bitirebilmesi için bir çok şey söyleyebilen, toplaması kolay bir parametre var oda logical Read sayısıdır.
- Logical Reads: SQL çalıştığı esnada, buffer cache üzerinde bir block’a erişme olayına logical reads denir. SQL çalıştığı esnada buffer cache’den okunan blok sayısıda o sorgu için yapılan logical read sayısını gösterir. Lojik okuma fiziksel okumalarada neden olabileceğinden dolayı, logical read sayısını düşürmek yapıacak I/O miktarınıda azaltmak anlamına gelebilir.
- Logical Reads, overall Resource consumption bağlamında isabetli tahminlemeler yapmamıza olanak sağlayan bir parametre bu bağlamda Optimizayon un ilk bacağı olarak satır başına düşen yüksek lojik okuma sayılarına neden olan sorgulara odaklanabiliriz.
- Logical Reads, overall Resource consumption bağlamında isabetli tahoracleminlemeler yapmamıza olanak sağlayan bir parametre bu bağlamda Optimizayon un ilk bacağı olarak satır başına düşen yüksek lojik okuma sayılarına neden olan sorgulara odaklanabiliriz. ALTER SESSION SET STATISTICS_LEVEL = ALL; select * from HR.COUNTRIES SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'RUNSTATS_LAST'));
- Logical Reads: Access pathlerden hangileri daha az logical read yapar. Selectivity doğru access path’i seçmek için çok önemlidir.
- Selectivity’nin yüksek olduğu durumda tablo datasının büyük bir bölümünün getirileceği düşünülmelidir. Bu bağlamda Full Table Scan karşımıza ilk çıkan veri erişim yöntemidir. Bunun yanı sıra partitioning yaptığımız tablolarda full parttion scans gibi yöntemler ve sadece index okuma gibi yöntemlerde karşımıza çıkabilir.
- Full table scans de logical read sayısı, blok sayısına eşit olmuş oluyor.
- Selectivitynin çok zayıf olduğu durumlarda full table scan yapmak veriye erişmek için en etkili yöntem ancak selectivitynin düşmeye başladığı durumlarda bir çok blok gereksiz yere okunmaya başlar. Selectivitynin düşük olduğu durumda index kullanmakta efficient bir yöntem değildir. Bu tarz durumlarda logical reads sayısını düşürmek için seçilecek en etkin yöntem partitionlamadır. Optimizer gelen sorguya bakarak ilgili olmayan data barındıran partitionları okumayarak veri erişimini etkin kılar buna partition pruning denir. Range Partition: Doğal olarak sıralı olan durumlarda örneğin belirli bir zaman aralığında öncesinde sonrasında.. List Part. : Distinct değer sayısı limitli olan durumlarda. Örneğin, cinsiyet, status,country,postal_codes gibi Hash Part.:distinct kayıt sayısı çok fazla olan durumlarda kullanılması önerilir. Örneğin customer_id, sales_id ...
- Sorgu geldiğinde optimizer where conditionına bakar ve partition keyin join conditionını inceleyerek ilgili datayı hangi partitionda arayacağını data dictionary ye bakarak karar verir ve ilgisi dışında olan partitionları budar (Partition pruning). Partition pruning yapılabilmesi için partition keylerin where koşulunda mutlak suretle olması beklenir aksi takdirde optimizer’ın datanın hangi partitionda aranacağını bilemez ve tüm partitionları tarayarak full table scan yapmak zorunda kalır.
- Index ler yalnızca, kendileri üzerinden rowid listesi çıkarıp bu rowidlere karşılık kayıtları bulmak için tablolara gitmezler, indexler doğal olarak tablo üzerindeki bir yada birden çok kolonu key olarak aldıklarından ötürü üzerlerinde key olarak aldığı data yıda barındırmaktadırlar. Eğer gelen sorgunun dönüşü index key’in olduğu kolon ise rowid’yi alıp tabloya gitme gereksinimi kalmadan index keyi okuyup geriye sorgu sonucu olarak döndürebilmektedir. Bu sayede çok önemli bir veri erişim optimizasyonunu oracle kullanıcılarına sağlamaktadır. Eğer index querry nin ihtiyaç duyduğu tüm datayı üzerinde barındırıyorsa, full table scan, full partition scan yerine full index scan yapılarak sorgu sonucu döndürülür. Full index scan, full table ve full partition scana göre çok daha efektif ve az lojik okuma yapan bir yöntemdir. Bunun nedenide index segmentlerinin tablo segmentlerinden daha ufak olmasıdır. Eğer index buffer cache de yoksa, index disk üzerinden getirilmeye başlanır. İndexin büyük olduğu durumlarda okunacak blok sayısı artacağından dolayı daha fazla blok okuması yapılacak. Index full scan yöntemi blokları tek tek okuduğundan toplam blok sayısı, toplam okuma sayısına eşit olucak ve yöntem inefficient hale gelicek. Bu tarz durumlarda multiblock read tekniğini kulnnabilen index_fast_full scan yöntemini gerekli hinti verek kullanmak okuma sayısını düşürüp etkin bir yönteme sistemizmizi tekrar çevirebilir.
- Selectivity nin 0 a yakın olduğu durumlar.
- Selectivitynin düşük olduğu koşulda en etkili yöntemdir. Belirli bir satıra erişmenin en etkin ve efektif yolu rowid ile erişmektir. Ancak bu etkin yolu kullanabilmek için ilk başta rowid yi çekip saklamak gerekmektedir. Daha sonra bir sonraki aynı satıra erişimizimizde doğrudan kullanabiliyoruz. Eğer bir satıra 2 kez erişiyorsak herhangi bir durum içerisinde burada ilk erişimimizi yaptığımızda rowid yide çekmek bir sonraki erişimimizi en etkin metod ile yapmamız anlamına gelecektir.
- Selectivity nin strong olduğu durumlarda en sık kullanılan metodlardan biridir.
- Clustering Factor Logical reads sayısını doğrudan etkileyen bir durum.-
- Primary key üzerinden yapılmamalıdır. Distinct value değeri sınırlı olan kolonlar üzerinden yapılmalıdır. Cardinalty si düşük bir kolonum varsa ve tablomda çok büyükse, bitmap index btree index e göre daha performanslıdır. Ancak sorguda birden çok or lu and condition ının birleşmesi gerekliki bitmap indexin performansı artsın.
- Bitmap index her zaman compress dir. B-tree index ancak istenilirse compress edilir.
- Ana fikir tablo segmentlerini okumaktan kaçınmak çünkü index segmentleri tablo segmentlerinden daha küçüktür. Buda daha az lojik okuma yapmamız anlamına gelmektedir. Eğer P.K üzerinden sıkça sorgu yaptığımız bir tablo durumu söz konusu ise ve bu tablodaki data karakteristiği indexli bir şekilde tutulmaya elverişli ise bu tabloyu IOT formatında tutmak performansı artırır. Data hep clustered olarak saklandığından pk üzerinden yapılan range scan sorgulamaları çok efektif ve etkili oluyor. Data primary key üzerinden organize edilmiş bir şekilde tutlduğu için olası bir order by işlemi çok etkin gerçekleşiyor.
- Aynı key’e sahip olan tüm kayıtlar disk üzerinde beraber saklanıyorlar. Özellikle eşitlik içeren sorgularda index li erişime göre çok daha etkin ve efektif bir erişim sağlıyorlar. Cluster key üzerinden bir fonksyon sonucunda hash key oluşturuyor ve bu hash key kayıtların disk üzerinde doğrudan nerede olduğunu gösteriyor. Index gibi extra bir veri yapısına ihtiyacı olmadığından extradan fazla okuma yapmıyor. Eğer cluster key üzerinden sık sorgulama sorgulama yapılıyorsa ve sizing doğru bir şekilde yapıldı ise performansı çok iyidir. Cluster key primary key den farklı bir değer olabilir. Hash collision dan kaçınmak için ve boşa diskten yer kaybetmemek için sizing doğru yapıılmalıdır. Partitioning i desteklemez Lob kolonları desteklemez.