10g FLASHBACK DATABASE önemli soru #1

Tekrar merhaba,

Bir önceki yazımda detaylı bir şekilde FLASHBACK özelliğinden bahsetmiştim.
Tonguç Hocamın bana yazdığı yorumun ufak bir demosunu hazırladım. Öncelikle soruyu tekrarlayalım.

Truncate veya purge edilen bir tablo, restore point aracılığı ile flashback database yapıldığı zaman geri gelir mi ?

Gerçekten çok güzel bir soru ve görelim geliyorlar mı ?

Herşeyden önce veritabanımızın Archivelog ve flashback modunda olup olmadığını kontrol edelim.
C:\> sqlplus / as sysdba

SQL> archive log list;
SQL> select flashback_on from v$database; YES olması gerekli.
SQL> select open_mode from v$database; --> READ WRITE olması gerekli.
SQL> select active_state from v$instance; --> NORMAL olması gerekli.

Bu aşamada herşey normal ise test tablomuzu yaratalım.

SQL> create table deneme tablespace users
SQL> as select * from user_objects;
SQL> select count(*) from user_objects; --> İçerisindeki toplam verileri kontrol edelim ve not alalım.
SQL> select tablespace_name, bytes, blocks, extents
SQL> from user_segments
SQL> where segment_name = 'deneme'; --> Kapladığı alanları bytes, blocks ve extents olarak görelim.
SQL> create restore point HASARDAN_ONCE; --> Şuanda veritabanımız restore point için hazır. HASARDAN_ONCE isimli restore pointimizi yaratalım.
SQL> truncate table deneme; --> Tablomuzda ki bütün verileri sildikten ve High Water Mark'ıda reset ettikten sonra testimize devam edelim (commit gerekmiyor, truncate bir DDL komutudur).
SQL> shutdown immediate;
SQL> startup mount; --> FLASHBACK DATABASE için mount modda olmalıyız.
SQL> FLASHBACK DATABASE TO RESTORE POINT HASARDAN_ONCE; --> Evet şuanda veritabanımızı o noktaya Flashback logları sayesinde geri alabildik.
SQL> ALTER DATABASE OPEN RESETLOGS; --> Flashback database'den sonra resetlogs ile veritabanımızı açıyoruz.
SQL> SELECT COUNT(*) FROM DENEME;
COUNT(*)
----------
22950
1 row selected.

Evet kilit noktaya geldik. Sonucu alabildiniz mi ? Not aldığınız önce ki sayının aynısını görebildiniz mi ? Sonuç olarak durum budur. Başarılı bir truncate table'dan sonra bütün verilerimizi tekrar alabildik. Bu noktada önemli olan şudur. Flashback logları ile undo'lar aslında farklı şeylerdir. undo bize tablonun truncate edildiğini işaret etsede, aslında flashback loglarında o tablo hala orada duruyor.

Sırada drop table purge komutu ile neler oluyor ona bakalım.

Şuanda veritabanımız zaten istediğimiz noktada. Test tablomuzda aynen yerli yerinde duruyor. Şimdide drop table purge diyelim.

SQL> DROP TABLE DENEME PURGE; --> Bunun ne yaptığını bir daha söyleyelim. Tabloyu recyclebin'e gitmeden düşürür. Bütün loglardan tamamen silinir. Peki, bunu flashback truncate table örneğinde olduğu gibi getirebilecek mi ?
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO RESTORE POINT HASARDAN_ONCE;
SQL> ALTER DATABASE OPEN RESETLOGS;
SQL> SELECT COUNT(*) FROM DENEME;
COUNT(*)
----------
22950
1 row selected.

İşte en kritik noktaya geldik. Truncate table ilede drop table purge ilede olsa fark etmez. İki denememizde de sonuç olumlu ve tablomuz hasardan_once restore pointinde olduğu gibi duruyor. Buna bağlı constraintler veya child recorlarda olsa fark etmeyecekti.

Sonuç olarak FLASHBACK DATABASE kesinlikle bir DBA'in kullanması gereken bir özelliktir. Bunun maliyeti ve sonucu ne olursa olsun. Fakat kullanırken dikkatli olmalıyız, biz bu örnekte bir tablo ile çalıştık. Unutmayalım ki birden çok kullanıcı o sırada sürekli veri giriyor olacak. Onlarıda kaybetme riski her zaman var...

İyi çalışmalar,

Ogan ÖZDOĞAN.
18.02.2008 - ANKARA.