Bekleme Olayı: db file sequential reads

• Yanlış index kullanımı
• Fragmente olmuş indexler
• Belirli disk veya raw partitionlar üzerinde aşırı I/O trafiği
• Kullanılan programda tasarım eksikliği
• Index okuma performansı yüksek oranda ortalama bekleme süresine sebep olan yavaş I/O altsistemi ve/veya veritabanı dosyalarının fiziksel yerleşimindeki eksikliklerden etkilenmektedir.

• Tablodaki indexleri kontrol ederek doğru indeksin kullanıldığından emin olun. Bu noktada tampon bellekte işlem gören işlemlerden hangi indekslerin kullanılmadığını analiz edebilir ve gereksiz indeksleri bu şekilde düzeltebiliriz.
• Top SQL listesinden tabloda kullanılan indekslerin WHERE kısmındaki kolonların order sırasını kontrol ediniz.
• Indeksleri yüksek kümeleme faktöründe tekrar oluşturun.
• Ziyaret edilen blok miktarını azaltmak için bölümlendirme(partitioning) kullanın.
• İyileştirme istatistiklerinin güncel olduğundan emin olun.
• Yüksek I/O trafiğine sahip olan veri dosyalarını farklı veri dosyalarına taşıyın.
• Çoklu bellek havuzlarını kullanmayı düşünün ve sık kullanılan indeks ve tabloları KEEP havuzunda tutun.
• indeksler üzerinden veri erişimi sağlayan SQL cümleciklerinin işlem planlarını araştırın.
• Indeksler üzerinden veri erişimini sağlayın.
• Kullandğınız program OLTP mi veya DSS mi? Full tablo taraması daha verimlimidir? SQL cümleciklerinde doğru “driving” tablolarmı kullanılıyor? sorularının cevaplarını analiz edin.
• İyileştirmenin hedefi hem mantıksal hemde fiziksel I/O trafiğini azaltmaktır. Bu noktada öncelikle yeterli önbelleğin olduğundan ve hızlı fiziksel sistemlerde ve doğru RAID yapısında çalıştığınızdan emin olun.

• Oracle prosesi SGA içinde o an olmayan bloğu ister ve diskten SGA alanına veritabanı bloğunun okunması için bekler.
• Sabit orandaki db file sequential read bekleme zamanını azaltmak için yapılan tüm iyileştirme işlemleri sonucunda bu oran hala yüksekse programınızda iyileştirmeye odaklanmanız gerekir.
• Eğer indeksin DBA_INDEXES.CLUSTERING_FACTOR değeri tablodaki blokların sayısına yaklaşırsa bu durumda tablodaki pekçok satır sıralanmıştır Bu arzulanan bir sonuç olacaktır.
• Ancak, eğer kümeleme faktörü tabloadaki satır sayısına yaklaşırsa bu demektirki tablodaki pek çok satır rastgele sıralanmıştır ve bu sebeple bu operasyonu tamamlamak için çok daha fazla I/O meydana gelecektir. İndeksin kümeleme faktörünü iyileştirmek için  tablo tekrar oluşturulabilir, böylece satırlar indeks anahtarına gore sıralanacak ve sonrasında indeksler tekrar oluşturulacaktır.OPTIMIZER_INDEX_COST_ADJ ve  OPTIMIZER_INDEX_CACHING başlangıç parametreleri “nested loop” işlemlerini desteklemek için iyileştiriciyi etkiler ve full tablo taraması üzerinden indeks erişim yolu seçer.
• I/O tabanlı iyileştirmeler için Metalink Note# 223117.1 a bakınız.
• Daha fazla db file sequential read iyileştirme metotları için Metalink Note# 34559.1 a bakınız.

• Oracle oturumu çoklu komşu veritabanı bloklarını(DB_FILE_MULTIBLOCK_READ_COUNT değerine kadar) disk alanından SGA’ya okunmak için beklemektedir..
• Çok fazla full tablo taramaları (FTS)
• Hızlı full indeks taramaları

• DB_FILE_MULTIBLOCK_READ_COUNT parametresini ayarlayarak çoklu blok I/O işlemlerini optimize edin.
• Bölümlendirmeleri budamak ziyaret edilen bloklarının sayısını azaltır.
• Çoklu tampon havuzları kullanmayı düşünün ve sık kullanılan indeks ve tabloları KEEP pool içinde saklayın.
• En çok bekleme olaylarını başlatan SQL cümlelerini iyileştirin. Burdaki amaç fiziksel ve mantıksal okuma sayısını azaltmaktır.
• SQL sonucu erişilen data indeks FFSmi yoksa full tablo taraması sonucumu gelmeli?
• İndeks aralığı veya unique taramamı en etkili olacaktır ?
• Sorgu doğru “driving” tablomu kullanıyor?
• SQL cümleleri ilgili hash veya ilgili merge birleşmelerinemi dayanıyor?
• Eğer full taramalar uygunsa parallel sorgu cevap süresini iyileştiriyormu?
• Amaç, hem fiziksel  hemde mantıksal I/O lar için istekleri azaltmaktır.Buna erişmek için en iyi yol SQL ve program iyileştirmesi olacaktır.
• LAST_ANALYSED tarihini control ederek tüm istatistiklerin güncel veriyi temsil ettiğinden emin olun.

• LGWR  redo log tampon belleğin içeriklerini online log dosyalarına yazarken bekler.
• I/O, online redo log dosyalarını tutarken sub sistemde bekler.

• Oluşturulan redo miktarını azaltın.
• Çok gerekmedikçe tablespaceleri hot yedekleme modunda bırakmayın.
• Redo log dosyaları için RAID 5 kullanmayın.
• Redo log dosyaları için daha hızlı diskler kullanın.
• İçeriklerin çatışmaması için arşiv redo log dosyaları ve online redo log dosyalarını birbirlerinden farklı disklerde tutulduğundan emin olun.
• SQL cümleciklerinde NOLOGGING veya UNRECOVERABLE seçeneklerini kullanmayı dikkate alın.

• LGWR prosesini disklere doğru iyi çıktı almak için iyileştirin.Örneğin, redo logları RAID 5 te tutmayın, RAID-1 tercih edin.
• İşlemleri yığınlayarak tüm COMMIT sayısını azaltın ki daha az sayıda COMMIT işlemleri tetiklensin.

• Bakınız Metalink Reference Note# 34592.1
• Log dosyası senkronizasyonunda yüksek beklemeleri optimize etmek için bakınız Metalink referans Note# 125269.1
• Redo log tampon bellek iyileştirmesi ve redo latch içeriği iyileştirmesi için bakınız Metalink Referans Note# 147471.1
• kullanmayı dikkate alın.

• Yoğun bellek beklemeleri I/O sekmeli Oracle sistemlerinde olağandır.
• Bu olayın meydana geldiği 2 temel neden vardır:
• Başka bir oturum bloğu bellek içinden okumaktadır.
• Başka bir oturum isteğimize karşılık belleği uyumsuz bir modda tutmaktadır.
• Bu beklemeler okuma/okuma,okuma/yazma veya yazma/yazma içeriklerine işaret eder.
• Oracle oturumu belleğe tutturmak için beklemektedir. Bellek okunmadan veya değiştirilmeden once tutturulmalıdır.Sadece bir proses belleği herhangi bir zamanda tutuştabilir.
• Bu beklemeler daha çok satır içerecek kadar  daha geniş blok büyüklüklerince pekiştirilir.
• Bu beklemeler bir oturum tampon bellek içindeki bir veritabanı bloğuna erişmek istediğinde ancak bellek meşgul olduğunda erişemediğinde meydana gelir.
• Birkaç proses aynı bloğu tekrar tekrar okuduğundan ötürü bu beklemeler sık sık olur. Mesela, farklı kullanıcılar aynı anda aynı bloğa erişim sağlıyorsa...

• Çok fazla erişilen blokları programınızdan çıkartın.
• Tekrarlı tarama/seçimsiz indeksleri kontrol edin.
• Objeleri daha yüksek PCTFREE oranlarında yeniden oluşturun, böylece blok başına satır sayısını azaltmış olursunuz.
• Farklı prosesler tarafından indekslerdeki aynı lokasyona eklenen indeksleri kontrol edin.
• INITRANS ve MAXTRANS değerlerini artırın, PCTUSED değerini azaltın.Bu şekilde tablolar daha az sıkışır.
• Blok başına satır sayısını azaltın.

• buffer busy waits olayında beklemede olan prosesin sebep kodu bekleme olayının P3 parametresinde yayınlanır.
• En sık karşılaşılan bekleme olaylarından olan 130 ve 220 arası referanslar için Metalink Note # 34405.1 bakınız.
• Yoğun ve rastgele bellek bekleme performans problemleri içinResolving intense and ran Metalink Note# 155971.1 bakınız.

• Boş tampon beklenmekte ancak bellekte çok fazla kirli tamponlar yüzünden bellekte yeterli boş tampon yok.
• Ya tampon bellek çok küçük veya DBWR değiştirlmiş tamponları diske yazmak için çok yavaş kalmakta.
• DBWR yazma taleplerini sürdürememekte
• Muhtemelen yetersiz büyüklükte redo log dosyalar veya yüksek veritabanı aktiviteleri sebebiyle çok fazla checkpoint meydana gelmekte.
• Geniş sort ve full tablo taramaları, tamponu DBWR prosesinin diske yazabileceğinden çok daha hızlı şekilde değiştirilmiş bloklarla doldurmakta.
• Eğer kirli tamponların sayısı DBWR prosesinin yığın başına yazabileceği miktardan daha fazla diske yazma ihtiyacı duyarsa, bu beklemeler oluşabilir.

• Checkpoint sıklığını azaltın. Online redo log dosyası büyüklüğünü artırın.
• Tampon bellek büyüklüğünü sorgulayın. SGA alanında tampon belleği artırmayı değerlendirin.
• disk_asynch_io = true
• DBWR prosesi sayısını CPU sayısına bağlı olarak arttırın.
• Veri dosyalarını diskler veya disk controller üzerine serpiştirerek sıcak noktaların olmadığından emin olun.
• Önceden sort işlemleri ve verileri yeniden organize etmek yardımcı olabilir.

• Tampon bellek ve DBWR yi anlamak ve iyileştirmek için bakınız Metalink Note# 62172.1
• Tampon bellek içinde sıcak blokların nasıl  belirleneceği için bakınız Metalink Note# 163424.1

• Genellikle tablo oluşum kaynaklı hatalar veya program oluşumunda kaynaklanan hatalar
• Satır seviye kilitler tarafındaki çakışmaları belirtir.
• Bir işlem başka bir işlem tarafından kilitlenmiş satırları güncellemeye veya silmeye çalıştığından bu bekleme oluşur.
• Bu bekleme olayı genellikle program katmanındaki sorunlardan kaynaklanır.

• Drop, truncate veya coalesce gibi eylemler içeren ST kilidine gereksinim duyan UET$(kullanılmış extent) ve FET$(boş extent) tablolarını değiştiren veritabanı işlemleri.
• ST kilitlerindeki çakışmalar dictionary yönetimli tablespace yapısında birden fazla oturumun aktif olarak dinamik disk alanını paylaştığı yada serbest bıraktığını işaret eder.

• Bekleme ve bekleme sürelerini azaltın. TX Önkuyruk tabanlı enqueue beklemeleri gördüğünüzde ilk adım olarak bloklayanın kim olduğunu bulun ve aynı kaynak için birden fazla bekleyen olup olmadığını araştırın.
• Mod 3 içindeki TM önkuyruk  beklemeleri öncelikli olarak indekslenmemiş yabancı anahtar kolonları olmasından kaynaklıdır.
• Oracle 9i için yabancı anahtarlarda indeks oluşturun.
• ST kilit çakışmalarını azaltmak için alttakileri uygulayın;
• Lokal yönetimli tablespace kullanın.
• Tüm geçici tablespacesleri yeniden oluşturun. CREATE TEMPORARY
  TABLESPACE TEMPFILE…

• Eşzamanlı kilitleyebilmede önkuyruk sayısını maksimum sayıda kontrol etmek için  ENQUEUE_RESOURCES parametresi kullanılır. Bakınız Metalink Reference Note# 34566.1
• Önkuyrukta bekleyen oturumları izlemek için bakınız Metalink Note# 102925.1
• V$LOCK görünümü ve kilitleme modları için bakınız Metalink Note:29787.1

• Bu mandal(latch) data blokları için arama yapılırken elde edilir. Tampon bellek blok sırasıdır ve taramaya ihtiyaç duyulduğunda her bir sıra alt mandal tarafından korunur.
• Bu bekleme olayının bir diğer ortak sebebi ise sıcak bloklardır. Birden fazla oturum bu bekleme olayının alt sırasındaki bir veya daha fazla bloğa tekrar tekrar erişiyorsa bu bekleme olayı meydana gelir.
• EXECUTION başına yüksek BUFFER_GETS(mantıksal okuma-bellekten) değerine sahip SQL cümleleri baş suçludur.
• Birden fazla eşzamanlı SQL oturumu aynı veri setini hedef gösteren yetersiz SQL leri yürütmektedir.

• Bu bekleme olayı için çakışmaları azaltmak genellikle iyileştirme ile mantıkssal I/O oranını azaltmaya ve SQL ilişkili I/O gereksinimini azaltmaya ihtiyaç duymaktadır. Yüksek I/O oranı çok fazla erişilen blokları işaret eder.
• Tabloyu export edin, PCTFREE oranını anlamlı olarak arttırın ve verileri import edin.Bu metot bok başına satır sayısını azaltacak ve bu satırları pek çok blok üzerine dağıtıcaktır. Tabi bu depolama alanı ihtiyacını artıracak ve full tablo taramaları yavaşlayacaktır.
• Tabloda blok başına kayıt sayısını minimize edin.
• Indeksler için bunları daha yüksek PCTFREE değerlerinde yeniden oluşturun, tabi bunun indeksin yüksekliğini artıracağını aklıda tutarak.
• Blok boyutunu azaltmayı gözönünde
• İndex ve buna bağlı tabloların aynı blok boyutunda olduğundan emin olun.
• Hash latch sayısı _DB_BLOCKS_HASH_LATCHES parametresi ile değiştirilebilir.