Okuma Tipleri - db file sequential read / db file scattered read

Selamlar,

Bir Oracle veritabanı üzerindeki bekleme olaylardan birisi olan "db file sequential read" ve "db file scattered read" okuma tiplerinden bahsetmek istiyorum.

DB FILE SEQUENTIAL READ

llgili bağlantı (session) ardışık okuma (sequential read) gerçekleşirken beklemektedir. Bu okuma buffer cache içerisindeki bloklardan gerçekleşmektedir. AWR, ADDM veya dinamik performans görüntülerinde bu olayı görüyorsanız şu anlama gelmektedir; bir kullanıcı işlemi veritabanında bulunan buffer cache içerisindeki bloklardan okuma gerçekleştiriyor ve bir fiziksel I/O bekliyor demektir. Ardışık okuma tekli blok okumasıdır. Tekli blok okumaları genelde indeks kullanımı gerçekleştiği durumlarda görülmektedir. "Full table scan" gerçekleştiği durumlarda ise nadiren de olsa ardışık okuma gözlemlenmektedir ve bunun nedeni kimi zaman FTS yapılırken okunması istenen veri/blok tamamen buffer cache'de olabilir ya da FTS tek bir bloğa sığmaktadır (çok minik objelerden bahsediyorum). İşte bu okumalar çok büyük bir oranla "db file sequential read" olayı ile sonuçlanacaktır.

V$SESSION_WAIT dinamik performans görüntüsünde bulunan kolonlardan;

P1 - Gerçek obje numarası

P2 - Okunmakta olunan blok

P3 - Blokların sayısı (1 olmalı)

Şimdi, bekleme olayı demiştim ve eminim aklınıza veritabanını yavaşlatan bir olay olabileceği gelmektedir. Aslında böyle bir şey tam olarak değil. Oracle'a göre sağlıklı bir sistemde durağan beklemelerden (idle waits) sonra gelmesi gereken en büyük bekleme olayı fiziksel okuma beklemeleridir. Aşağıdaki örnekleme ardışık, dağınık ve direkt yol okuma olayları (direct path read) ile SGA - PGA arasındaki ilişkiyi göstermektedir.

Bu görüntüden de anlaşılacağı gibi db file sequential read okumaları SGA'nın içerisindeki belli bir tekil bloğu isterken, db file scattered read yani dağınık okuma yöntemi ile SGA'nın buffer cache'i içerisinde birden çok ve dağınık bloklar okunmakta ve kullanıcı görevi tarafından Oracle veritabanından istenmektedir.

DB FILE SCATTERED READ

db file sequential read'in yaptığı işin aynısını yapmaktadır ancak bunu birden çok veri bloğu için yapmaktadır.

Dağınık okuma bir indeksin "fast full scan" özelliğini ve bir FTS gördüğünüz zaman gerçekleştiğini ifade edebiliriz. Burada bir obje için bütün okumadan kastettiğimiz bütün buffer cache'in okunması değildir. Buffer cache içerisinde bulunan ve bizim sorguda istediğimiz bütün blokların, buffer cache üzerinde ardışık değil ama dağınık olarak bulunması (Bkz. yukarıdaki görüntü).

Sağlıklı bir sistemde db file sequential read ve scattered read'lerin olması gerektiğini ifade etmiştim ancak tabii ki bir yere kadar. Fiziksel okuma yerine buffer cache'de blok bulabilmek oldukça güzel ama bunu bulmanın bu iki tipi arasında da bir kontrol sahibi olabiliriz. db file sequential read > db file scattered read olması gerekirken db file sequential read'lerin de sürekli çoğalması ve bir veritabanının neredeyse bütün bekleme olaylarını oluşturması da iyi bir durum olmayabilir. Böyle bir durumla karşılaşırsanız, v$sqlarea dinamik performans görüntüsünü sorgulayabilir ve SQL_ID'lerini aldığınız yoğun okuma yapan sorguları "sql access advisor" veya "sql tuning advisor"a iletebilirsiniz. 

Dağınık okumaların ardışık okumalardan fazla olduğu durumlarda çok yoğun DML aktiviteleri ve I/O yapılmaktadır denebilir. Bu tarz aktivitelerin kontrolünü sağlayabilmek için;

1) SQL Tuning yaparak anormal I/O'nun azaltılması,

2) İşyükünü dengeleyerek, I/O ihtiyacını azaltmak,

3) Sistem istatistiklerini toplamak ve güncel tutmak (DBMS_STATS),

4) ASM (Automatic Storage Management) kullanımına geçmek,

5) Daha fazla disk ekleyerek, I/O dağılımını dengelemek,

6) Gereksiz index ve parallel hint'lerini sorgudan kaldırmak.

I/O'nun artmasına başka sebep olarak ise;

1) Buffer cache hit ratio (aradığımız bloğu buffer cache'de bulma oranı) düşük.

2) Ardışık ve dağınık okuma o kadar fazladır ki cevap verme (response time) süresi azalır.

Aşağıdaki sorguyu kullanarak hangi bağlantının nasıl beklediğini görebilirsiniz (ardışık ve dağınık okuma için);

SELECT SQL_ADDRESS, SQL_HASH_VALUE

FROM V$SESSION

WHERE EVENT_LIKE 'db file%read';

Dağınık okumaları görüntülemek ve mümkünse ardışık okumalara çevirebilmek için plan yapmadan önce;

SELECT ROW_WAIT_OBJ#

FROM V$SESSION

WHERE EVENT = 'db file scattered read';

Yukarıdaki sorgudan gelen cevap ile;

SELECT OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_TYPE

FROM DBA_OBJECTS

WHERE DATA_OBJECT_ID = $row_wait_obj#;

AWR raporunun en çok görünen bekleme olayları arasında ardışık ve dağınık okumaları görüyorsanız çokta fazla üzülmeyin, bu kötü bir durum olduğunu ifade etmiyor ama fazla I/O varsa da nedenini bulmak ve gereksiz I/O'ları azaltmak gerekmektedir. Bunu yapmazsanız veritabanının cevap verme süresi azalacaktır. Bununla birlikte ben 3 kırmızı diyorum, "Commit, Concurrency, Application" bekleme olaylarını görmekten iyidir çünkü bu tipte bekleme olayları daha fazla veritabanı zamanı tüketmekte ve ciddi beklemelere, zaman kayıplarına neden olmaktadır. Commit redolog'lar ve LGWR ile ilgiliyken, Concurrency ve Application bekleme olaylarında geçen zamanların artması ve AWR raporunda göze batması kötü uyarlanmış ve çalışmakta olan uygulamanız ile ilgili olabilir. Bu arada 3 kırmızı dememin nedeni EM performans sekmesinde kırmızı renk tonlarında gözüküyor olmalarıdır. Dikkat ederseniz CPU ve User I/O daha canlı (yeşil ve mavi) renklerde olup bana kalırsa biraz daha masumluğu sembolize etmektedir :)

İyi çalışmalar.

Ogan