Bir 10g özelliği, FLASHBACK

Merhaba,

Bu yazımda 10gR1 ve 10gR2'de geliştirilen ve sunulan FLASHBACK özelliğinden bahsedeceğim. Bazı özellikleri aslında 9i'de düşünülmüştür ve 11g'de uygulanmıştır. Dikkatlice uygulanması gerekir ve çok kritik durumlarda sizi ve DBA olarak çalıştığınız veri tabanını çok büyük baskı altından kurtarabilir.

FLASHBACK: Kısaca bir 10g özelliği olan "FLASHBACK" belkide bu zamana kadar Oracle'ın geliştirdiği en önemli teknolojilerden birisi. Ne olduğundan bahsedelim sonra da özelliklerine geçelim.

Bir çok çalışmaya göre Oracle'da oluşan hataların büyük bir kısmı kullanıcı hatalarıdır. Tablo düşürmek, içeriğini boşaltmak gibi. Bu tarz beşer hatalarını engellemenin yolları elbette vardır ama sonuçları önemli bir maliyettir. Aynı zamanda da çok zor takip edilebilir.

RESTORE POINT: Bu konuda ilk özelliğimiz yine 10g(release 2) ile gelen "RESTORE POINT" özelliği. PITR(Point In Time Recovery) gereksinimlerinde SCN(System Change Number) numarası veya Timestamp özelliklerinden yararlanılıyordu. DBA olarak SCN notlarını almak istesek içinde kaybolma ihtimalimiz olabilir. Onun yerine kritik zamanlarda kaydedilmiş Restore Pointler olursa, PITR gerçekleştirmemiz çok kolaylaşır. Syntax'i ise şöyledir:

SQL> Create restore point bu_bir_denemedir;
Bu restore point sayesinde az sonra anlatacağım "FLASHBACK DATABASE" konusunda ne kadar rahat dönüldüğünü görebileceğiz. Sonuç olarak Restore pointi çok önemli bir veritabanı uygulamasından önce yaratmak son derece mantıklıdır. Örnek olarak, kritik şema değişimlerinden önce veya flashback yapabilmek için olabilir.

FLASHBACK DATABASE: Oracle'ın bu zamana kadar yarattığı en stabil veritabanı kabul edilen 10g'nin(bir kısım release 1, bir kısım release 2) özelliğidir. Kendi loglarında aktif konuma getirildikten sonra kayıtları tutulan veritabanı değişimleri bu özellik sayesinde tamamen geri alınabilir.
Bütün veritabanını, bütün değişiklikleri ve kullanıcı hatalarını RMAN yedeği almaksızın geriye döndürebiliyoruz. Bu konuda tabii ki çok kritik noktalar vardır. Bütün veritabanını geriye almak, diğer kritik veri güncellemelerininde kaybolmasına sebep olabilir. Aynı zamanda yeni kayıtlarında yok olmasına.En büyük özelliği 10gR2 ile gelmiştir.
Flashback database resetlogs ile gerçektirildiği zaman kendi flashback logların reset olmaması. Restore point ve flashback kayıtları, flashback database gerçekleştirilip redo loglar resetlensede gerçekleştiriliyor ve tekrar dönülebiliyor. Bu bize veritabanı flashback ile geldikten sonrada yine hatalar olduysa geri dönme fırsatı sağlar ki çok avantajları olacaktır.
Gerekli komutlar ise şu şekilde olabilir. Flashback database yapabilmek için veritabanının "ARCHIVELOG" modunda olması gerekir. Ve aynı zaman veri tabanının "MOUNT" modda olması gerekir. Bir kaç tanede parametrenin set edilmesi lazım. Set edilmesi gereken parametrelerin default olarak kullandığını düşünelim.
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE FLASHBACK ON;
SQL> ALTER DATABASE OPEN;
SQL> SHUTDOWN IMMEDIATE; -->Bu noktaya kadar veri tabanı flashback logları üretti. Bir hata oluştu ve geriye dönmek istiyoruz.
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN ;
TO TIMESTAMP ;
TO RESTORE POINT ;
SQL> ALTER DATABASE OPEN RESETLOGS; --> Flashback database'den sonra loglarımızı reset etmeliyiz. Etmek istemezsek recover diyerek bütün yapılan değişiklikleri geri alabiliriz (Flashback database ile).
Flashback database çok hızlı gerçekleşir. RMAN ile alınan yedekle kıyaslarsak aradaki fark gerçekten çok büyüktür. Flashback komutları RMAN ve 11g ile deprecated olan SQL * PLUS ilede çalıştırılabilir. 10g ile gelen Flash Recovery Area'da flashback logları "DB_FLASHBACK_RETENTION_TARGET" parametresinin büyüklüğü kadar saklanır. Bu saklama işlemi veri tabanımızın genel performasını düşürür (yaklaşık %2 kadar). Eğer sistem izin veriyorsa, bir DBA mutlaka FLASHBACK özelliğini aktif hale getirmelidir.
Sonuçta oluşacak kullanıcı hatalarını RMAN ile dönmek her zaman en zor yol olabilir. Bu özellik sayesinde veri tabanını geriye almak dakikalarla ölçülebilir, saatler yerine. Bu durumda %2'lik bir performans maliyetinin aslında çok büyük bir maliyet olmadığınıda düşünmeliyiz. Sonuç olarak saatlerle ölçülen kar kayıpları %2'nin çok üzerinde olacaktır.

FLASHBACK TABLE: Bir kullanıcı hatasını önlemek yerine sonradan yapılabilecek en mantıklı sonuçtur. Çok hızlı ve online olarak yapılabilen FLASHBACK TABLE, şu şekilde gerçekleştirilebilir.
SQL> FLASHBACK TABLE TO TIMESTAMP ;
Bu sürenin uzunluğu ise "UNDO_RETENTION" parametresine bağlıdır. Bu parametre ne kadar çok set edilmişse geriye dönüş saatler, belki günleri bulabilir. Ama Oracle'da her zaman olduğu gibi bunun da disk'te kapladığı alan olarak bir maliyeti olacaktır. Bunun ayarlanması ise DBA'in insiyatifindedir ve son derece kritiktir.
Buda aslında, insalarında dışarıdan göremediği ve anlayamadığı DBA'in en önemli var oluş sebeplerinden biridir.
SQL> FLASHBACK TABLE TO BEFORE DROP;
Bu komut ilede drop edilen (PURGE edilmemesi gerekir yoksa RECYCLEBIN'e gitmez) tablolar "RECYCLEBIN"den aynı şekilde geri getirilir.

FLASHBACK DROP: Kullanıcılar kritik bir DDL komutunu yanlışlıkla çalıştırırlarsa, sonuçları rollback etmek, veri tabanının yapısı değiştiği için mümkün değildir. Kullanıcı bu hatayı yaptığı zaman aslında iş işten geçmiştir ve çok geç kalınmıştır. Kullanıcı bazında sonuç üretmek imkansızdır.Düşürülen tablolar, constrainler, indexler ve triggerlar RECYCLEBIN denen bir alana giderler.
Görmek için.
SQL> SHOW RECYCLEBIN;
Boşaltmak için.
SQL> PURGE RECYCLEBIN;

RECYCLE BIN: Oracle'ın drop edilen objeleri gönderdiği sanal alandır. Burada ki tabloların üzerine herhangi bir query hala çalıştırılabilir. "FLASHBACK QUERY" bile çalıştırılabilir.

SQL> DROP TABLE PURGE; --> Bu komut çalıştırısa, tablo recyclebin'e gitmeden tamamen drop edilir. Recyclebin'e giden objelerin başına BIN$$ getirilir.

FLASHBACK QUERY: Bu özellik bize, geçmişte olan verileri görebilmemizi sağlar. En son commit edilen veriler bile çekilebilir. Undo'lara verilen boyut kadar uzun süre çalıştırdığımız sorgulara ulaşabiliriz.
Eğer "RETENTION GUARANTEE" açıksa ve undo tablespace'in boyutları unlimited ise undo_retention süresi kadar gerçekleştirilen bütün sorgulara ulaşabiliriz. Eğer RETENTION NOGUARANTEE konumunda ve undo tablespace'in boyutları sınırlı ise, bu boyutlar dolduysa, geri dönmemiz artık imkansızdır. Commit edilmemiş bütün veriler rollback edilir ve verilerin geçmişleri undo'dan silinir.
Şu şekilde kullanabiliriz.
SQL> select * from deneme as of timestamp ;
SQL> select * from deneme as of SCN ;

Sonuç olarak, insan hataları her zaman tahmin edilemeyen bir sistem hatası olarak Oracle'da karşımıza çıkacaktır. Bunu engellemek ile uğraşmak, sonuçları için geçerli önemler almaktan çok zordur. Bahsettiğimiz kadar küçük bir performans ve sistem kaybı ile açtığıımz flashback özelliklerini mutlaka kullanmayı gözden olumlu bir biçimde geçirmeliyiz. Flashback komutları yapılan hataların kompleksitesini azaltır ve zamandan kazanmamızı sağlar. Bu özelliği veri tabanının yedeğini alıyoruz, RMAN'e gerek yok gibi bir fikre kapılmadan devam ettirmeliyiz. Hepimiz insanız ve hata yapabiliriz, doğamızda var.

İyi çalışmalar,

Ogan