REDO & ROLLBACK 2

Yaptığımız işlemler ile ne kadar redo üretiyoruz?

Developer olarak yazdığımız kodun ne kadar redo ürettiği ile de ilgilenmeli ve bunu önemsemeliyiz. Çünkü ne kadar çok redo üretirsek kodumuzun yaptığı iş o kadar yavaşlar, performansı düşürür.

Insert, Update, Delete işlemlerinin satır sayısı ile redo üretimi ilişkisi aşağıdaki gibidir. Tabloyu inceleyeck olursak, Update ve Delete işlemlerinin 1 kerede 200 satırın işlem görmesi ile tektek işlem görmesi sırasında üretilen redo miktarı hemen hemen aynı. Ama Insert biraz daha farklı. 200 satırı data bloka yazarken farklı, tek tek yazarken farklı davranır. Bu sebep ile Tek bir satırda yaptığı işlem, satır satır yaptığı işleme göre daha az redo üretir. 

 Ayrıca loop içine commit eklersek  redo miktarı ciddi derecede artar ve 3 kat yavaşlar. 

Bu yüzden mümkün olduğunca az satırda işlemlerimizi yapmalı, commiti ise gerçekten ihtiyacımız olduğunda kullanmalı ve rollback yapmaktan kaçınmalıyız.

Trigger kullanıldığında ise, before trigger deyimi değerlerde bir değişiklik yapmamasına rağmen genellikle redo miktarını arttırmaya eğimlidir. Before ya da After trigger Delete redo miktarını etkilemez, Insert redo miktarı ise her ikisi için de aynıdır, Update redo miktarı ise before’dan etkilenir ama after’dan etkilenmez. 

Redo Log’ları devredışı bırakabilir miyim?

Redo Log’ları devredışı bırakamıyoruz. Çünkü database için redo loglar çok önemlidir. Ama bazı operasyonlar redo log miktarını azaltabilmektedir. Bazı sql deyimleri nologging özelliğini desteklemektedir. Ama bu loglamayı sıfırladığı anlamına gelmez. Normale göre daha az redo log üretilir.

Block CleanOut

Locklar block headerda yer almaktadır. Block’a bir sonraki erişimde header bilgisini yani transaction bilgisini silmemiz gerekebilir. Bu faaliyet redo üretir ve block’un kirlenmesine (dirty data) neden olur.

 Bir tablo yaratttık ve içine veriler ekledik, commit ettik.

 Önce redo_size(Kyte’ın kitabında oluşturduğu bir view)’ımıza bakıp datayı okuduk. Okuma sırasında oluşan redo miktarını aldık. Select sırasında üretilen redo miktarı yaklaşık 30KB. Bu da table full scan sırasında block headerların değiştiğini gösteriyor. İkinci kez run ettiğimizde;

Hiç redo üretilmediğini görmekteyiz, tüm data block headerlar temiz.

Eğer süreç

 Çok miktarda yeni datanın bluk loading ile database’e yüklenmesi

      - Yeni eklenen tüm datanın update edilmesi

      - Dataya sorgu yapılmasına izin verilmesi

     ‘den oluşuyorsa, bu durumdan ciddi anlamda etkilenirsiniz.

Dataya bir sorgu yaptığınızda, data ek processlere maruz kalabilir. Data update edildikten sonra istatistik toplatılması block headerların silinmesini sağlayacaktır.

Temporary Tables ve Redo/Rollback

Temprorary tables Oracle 8.1.5 ile gelmiştir. Bu bölümde sadece logging üzerindeki etkisinden söz edeceğim. Database Tables bir sonraki bölüm o kısımda daha ayrıntılı bahsedeceğimJ.

Temprorary tables data block’ları için redo oluşturmazlar. Yani bu tablo üzerinde yapılan bir değişiklik recoverable değildir. Ama Temprorary tables rollback yaparlar ve bu yüzden rollback loglanır. Bu yüzden az da olsa redo üretirler.

 İki tane tablo yaratalım; biri temprorary table diğeri normal table.

 Tablolar üzerinde birkaç sql yapan bir procedure yazdık. Ve sonuçları analiz ettik.

Normal tabloya yapılan Insert çok fazla redo üretir, temp tanlosu için ise nerdeyse üretmez. İnsert için sadece rollback datası loglanmıştır. 

Normal tabloya yapılan Update temp tabloyadaki redonun iki katı cıvarındadır. Temp tablosu için Update işleminin ilk (before) kısmı loglanırken sonraki(after) kısmı loglanmaz. Bu yüzden aradaki fark iki kattır.

Delete işleminde redo miktarları birbirlerine yakındır. Değişen blokların için yapılan redo az ama rollback için yapılan redo büyüktür. Bu yüzden normal tablo çok az daha fazla redo üretir.

• 
  
       - Temp tablolarında Delete yerine Tuncate kullanılmalıdır.
• 
  
       - Insert ve select işlemleri için daha çok temp tabloları kullanılmalıdır.
• 
  
  Set Transaction
• 
  
  SET TRANSACTION hangi rollback segmentini kullanmak istiyorsak onu seçmemize imkan sağlar.
• 
  
  SET TRANSACTION USE ROLLBACK SEGMENT rb_seg_name;
• 
  
• 
  
  Özellikle çok büyük rollback segmentlerine ihtiyaç duyulduğunda ve tanımlanan rollback segmentinin kullanılacağı her transactionın başında çalıştırılmalıdır.