Zaman zaman test ortamlarında test yapılırken yanlış çalıştırılan bir procedure veya geri alınamayan bir işlemden dolayı test ortamındaki datalarımız işlevselliğini kaybedebilir. Aslında her ne kadar her sistem için çok mümkün gibi gözükmesede production ortamlarda da bu tarz işlemler zaman yapılıyor. Örneğin prod ortamda çalışan uygulama üzerine atılacak olan bir sürüm işleminde ortaya çıkabilecek hataları kestiremiyor ve sonrasında ki çıkabilecek muhtemel hatalardan dolayı bir endişeniz var ise flashback bu konuda size yardımcı olacaktır. İşleme başlamadan önce bir point noktası işaretlersek ve bu noktayı saklarsak sonrasında işlem sırasında alınan bir hatadan dolayı database’ i geriye sarıp işleme başladığımız zamana çok kısa bir sürede dönebiliriz. (Buradaki kısa bir süre kavramı yapılan işlemin detayına göre değişiklik gösterecektir, ama bu tarz bir problemde backupdan dönme ile kıyaslandığında çok ciddi zaman avantajı olacaktır)
Bahsetmiş olduğumuz bu işlemin adımlarının üzerinden geçelim;
* Ön koşul database flashback modda olmak zorundadır. Yani aşağıdaki sorgunun sonucu YES dönmelidir.
select flashback_on from v$database
FLASHBACK_ON
——————
YES
1 row selected.
Test veya yapacağınız işlem her ne ise hemen öncesinde restore point noktamızı create ediyoruz;
SQL> create restore point before_test;
Restore point created.
Kontrol ediyoruz;
SQL> select scn, time,name from v$restore_point ;
SCN TIME NAME
6517128 30.07.2011 20:42:15.000000000 BEFORE_TEST
Restore point noktamızda problem yok. Eğer kritik bir işlem öncesinde bu opsiyonu kullanmak istiyorsanız, yaptığınız tüm adımların sorunsuz tanımlandığını kontrol etmeniz sizin yararınıza olacaktır.
Restore point create işleminden sonra yapılan tüm işlemlere ait flashback logları oluşmaya başlayacaktır.
Bu konu ilgili kendi test ortamımda yapmış olduğum test sonuçlarını aşağıdaki gibi ;
Restore point noktası create ettikden sonra database üzerinde 3 tane user create ettim, her user altına birkaç tablo createdip sonrasında bunları delete ile sildim ve test işlemim bitmiş oldu. Şimdi ilk başladığım noktaya geri dönmek istiyorum;
Geri dönüş işlemi mount modda yapıldığından dolayı, database kapatıp mount modda başlatıyorum.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 419430400 bytes
Fixed Size 1249320 bytes
Variable Size 146804696 bytes
Database Buffers 264241152 bytes
Redo Buffers 7135232 bytes
Database mounted.
Buraya kadar problem yok, şimdi database’i geriye sarmak için komutumuzu çalıştırıyoruz;
SQL> flashback database to restore point before_test;
flashback database to restore point before_test
*
ERROR at line 1:
ORA-38729: Not enough flashback database log data to do FLASHBACK.
Ve yukarıdaki gibi bir hata aldık. Aslında flashback ile ilgili en kritik noktada burası, siz database’ inizi flashback moda aldığınızda database yapılan işlemleri geri alabilmek için (aksi belirtilmedikçe) flashback_recovery_area altına flb uzantılı dosyalar ile ihtiyaç duyacağı log dosyalarını oluşturmaya başlayacaktır. Dolayısıyla logların oluşacağı alanın size’ ının bu işlem için yeterli olması gerekecektir. Benim test ortamımdaki değerler aşağıdaki gibiydi ve size’ ı yeterli olmadığı için logların bir kısmı ezildiğinden dolayı dönüş için gerekli olan tüm loglara ulaşamadığından hata alıyoruz.
SQL> show parameter recover;
NAME TYPE VALUE
db_recovery_file_dest string C:\oracle\10g\flash_recovery_area
db_recovery_file_dest_size big integer 10M
Problemsiz olarak dönüşü gerçekleştirmeyi umut ederken bu tarz bir sürprizle karşılaşmamak için restore pointi create ederken logların ezilmemesini garanti altına alabiliriz, ilk restore point noktasını drop edip yenisini create edelim;
SQL> drop restore point before_test ;
Restore point dropped.
SQL> create restore point before_test_q guarantee flashback database ;
Restore point created.
Şimdi tekrar test yapmaya başlayalım.Dikkat ederseniz flashback recovery area’ nın size’ ına müdahale etmedim hala 10M olarak duruyor. Dolayısıyla birkaç işlemden sonra bu alanın dolmasını ve logları ezemeyeceği için database’ in tepki vermesini bekliyoruz;
Birkaç işlem sonrasında flashback recovery area dolduğu için ve buradaki dosyalarıda silemediği için database hang olmuş durumda, son başlatmış olduğum update kum saatinde takıldı ve bu şekilde kaldı , soruna çözüm bulmak için db_recovery_file_dest_size’ ını artırıp anlık sorunuma çözüm buluyorum. Dolayısıyla bu tarz bir durumla karşılaştığımız da da neler olabileceğini de görmüş olduk.
Şimdi dönüş işlemlerimize başlayalım, database’ i kapatıp mount modda başlatıyoruz ;
SQL> flashback database to restore point before_test_q;
Flashback complete.
Flashback komutumuz başarı ile çalıştı, aslında burada bir incomplete recovery yaptığımızdan dolayı database resetlog opsiyonunu kullanarak açmak durumundayız;
SQL> alter database open resetlogs;
Database altered.
Restore point kullanımı bu şekilde ancak burada şunlar da yapılabilir, elimizde tüm flashbaack loglarımız olduğundan dolayı en başa dönmek yerine 10dak öncesine veya 1 saat önceki durumuda dönülebilir, örneğin;
select oldest_flashback_time from v$flashback_database_log;
scripti ile dönebileceğimiz mimunum zamanı öğrenip, sonrasındaki bir zamana dönmek istersek;
flashback database to timestamp sysdate -1/24;
ile 1 saat öncesine dönebiliriz.
