statistikleri incelerken google üzerinden yapılan bir arama gözüme çarptı. Aramada bir SQL sorgusunun nasıl UNDO üretmemesini sağlayacağımız aranmaktaydı. Kısaca bununla ilgili yazmak istedim.
Öncelikle undo’nun ne olduğunu anlamak için tıklayınız.
Undo okuma tutarlılığı ve eşzamanlılığı açısından olmazsa olmazdır. Her redo üreten işlemin undo üretmeyeceği gibi her undo üreten işlemin redo üreteceğini söyleyebiliriz. Yani redo > undo. Bir transaction, veriyi modifiye ettiği zaman undo üretilir. Rollback operasyonu ve veritabanını kurtartma durumlarında undo gerekmektedir.
Redo değişimleri sembolize ederken, undo geriye dönülmesi muhtemel değişimleri sembolize eder. Örneğin SELECT … FOR UPDATE veya UPDATE gibi ifadeler hem redo hem de undo üretirler. Undo üretimini bypass etmenin bir yolu yoktur. Undo, undo edilmesi gereken yani geri alınması gereken bilgileri içeren segment’lere sahiptir. Redo’nun ise bir log dosyası vardır. Sonuç ne olursa olsa her undo üretimi mutlaka log’lanmalı, redo bilgisi üretilmelidir.
Undo üretimini azaltmak istiyorsanız APPEND hint’ini veya NOLOGGING özelliğini kullanabilirsiniz. Ancak dikkat, bu undo üretimini azaltacağı gibi redo üretimini de azaltacaktır. Redo oluşmasını istiyorsanız undo da oluşacaktır. APPEND veya NOLOGGING özelliklerinin ise undo ile bir ilgisi, direkt olarak yoktur.
Undo ayrıca flashback table ve flashback query için de gerekmektedir. Bu flashback özellikleri undo segment’lerini kullanmaktadır.
Bu konuyla ilgili bir örnek göstermek istiyorum. Bu örnekte undo segment’lerinin nasıl kullanıldığı ve insert – delete arasındaki undo üretim farkının göstermeye çalışacağım.
1
SQL> conn ogan/password;
2
Connected.
–> ogan kullanıcısı ile sisteme bağlandık ve herhangi bir işlem gerçekleştirmedik.
–> Kullandığı undo segment numarası 40, undo blok adresi 785. Kullanılan undo bloklari 1, kullanılan undo kayitlari ise 4. Yaptığı mantıksal I/O 80 ve fiziksel I/O 0. Şimdi commit etmeden veri girişine devam edelim;
–> Hala aynı segment numarası ve undo blok adresini kullanıyoruz ancak kullanılan undo blokları ve kayıtlarında artış var. Ürettiğimiz redo ve undo artmakta ve bununla beraber fiziksel ve mantıksal okuma da kümülatif olarak yükselmekte. Şu anda commit edersek;
Gördüğünüz gibi her insert işleminden sonra rollback operasyonu için yeni undo bloklarına ihtiyaç duyuldu. Bu undo blokları olmasaydı rollback operasyonunu nasıl yapabilecektir?