Flashback Data Archive & Total Recall
Bu yazımda bir 11g özelliği olan flashback data archive ve bir veritabanı opsiyonu olan total recall'dan bahsedeceğim. Günümüzdeki birçok organizasyon için verinin ne kadar kıymetli olduğunu ifade etmek kelimelerle biraz zor. Veriler hem kıymetli hem de veriler üzerinde yapılan tüm değişiklikler de bir o kadar önemli. Bir tablo içerisindeki verilerin ne yönde değiştiğini, kim tarafından hangi işlemlerin yapıldığının takibi gibi konular ciddi uygulama mantığı ve iş yükü gerektiren uygulamalar olarak karşımıza çıkabilir. Verinin geçmişini takip etmek ve görüntülemek gerçekten çok zahmetli ve komplike bir işlemdir. Organizasyonlar da bu işi yerine getirebilmek için ciddi masrafların altına girmekte ve verinin geçmişini, tarihini tutabilmek için zaman harcamaktadır. Oracle'ın Total Recall veritabanı opsiyonu ile bu değişimleri tutmak basit ve veritabanı tablolarından sorgulamak da geleneksel sorgulama tipleriyle kıyaslandığı zaman sorunsuz olacaktır.
Geleneksel Yaklaşımlar
Geçmişe ait geçmiş verisinin takip edilebilmesi için bir takım geleneksel yaklaşımlar ve yöntemler bulunmaktadır. Bütün bu yöntemler yüksek maliyet, yüksek kompleksite ve performans limitleri ile mücadele etmektedir.
Uygulama Mantığı: Verinin tarihini tutmak ve görüntüleyebilmek için kullanılabilen bir yöntem uygulama seviyesinde yapılan mantıksal değişikliklerdir. İş tanımını, isteklerini ve çözümlerini iyi bilen bir uygulama geliştiricisi için oldukça faydalı olabilir ama uygulamayı daha kompleks ve içinden çıkılmaz bir hale dönüştürebilir. Hatalı geliştirilecek ya da mantıksal sorunlara sahip bir uygulama ile sahip olduğunuz bütün veriyi bozma ihtimaliniz her zaman bulunmaktadır. Günümüz organizasyonlarındaki uygulama mantığını ve kaç tane uygulamaya sahip olduklarını düşünürseniz bu çözümü işleme almak bile ciddi bir zaman ve maliyete neden olacaktır. Buna ek olarak yapılacak testler de gelmektedir.
Veritabanı Tetikleri (Triggers): Başka bir alternatif veri geçmişi tutma seçeneği de veritabanı tetikleridir. İlgili tablolar üzerinde gerekli tetikleri yaratarak her veri değişiminde, değişimin tarihi elimizde bulundurulabilir. Ancak, tetiklerin kullanılması merkezileştirilmiş bir arayüz ile kullanılabilen bir çözüm olmadığı gibi yönetimsel açıdan kontrolü ve testleri oldukça zordur ve zahmetlidir. Buna ek olarak yaratılan her tetikle birlikte tetiklenen işlem veritabanı performansını etkilemektedir.
Redo Log Mining: Belkide en sık kullanılan çözüm redolog'ların mining işleminin yerine getirilmesiyle verinin değişim tarihinin kontrol edilmesi, sorgulanmasıdır. Log mining işlemi için ayrı bir araç, yaratılması gereken işlemler ve monitör edilmesi gereken bir süreç bulunmaktadır.
Yukarıda bahsettiğim ve geleneksel yaklaşımlar olarak kategorize ettiğim çözümlerin hiçbiri düşük maliyetli ya da yüksek performanslı çözümler değildir. Herbiri kendine göre karmaşık ve zaman alan, maliyetli çözümlerdir. İşte bu noktada devreye 9i ile birlikte aramıza katılan "Flashback" teknolojisi ve Total Recall veritabanı opsiyonu girmektedir.
Flashback Data Archive
Flashback Data Archive (FDA) bir Oracle Veritabanı 11g ve Total Recall özelliğidir. Verinin bütün geçmişini takip etmek için düşük maliyetli ve performanslı bir çözümdür. Bütün kompleksite bariyerlerini ortadan kaldırmaktadır. Bir retention period (koruma süresi) dahilinde ilgili tablo üzerinde aktive edilecek FDA sayesinde bütün değişimler takip edilir.
Bir 11gR2 veritabanındaki FDA kullanım alanlarına birkaç örnek vermek gerekirse;
* Herhangi bir çalışan tarafından gerçekleştirilen veri değişiklikleri.
* Information Life Cycle Management (ILM) ile verinin geçmişinin değiştirilmeden saklanabilmesi.
* Koruma politikasının zorlamasıyla 5 yıldan eski olan bütün kayıtların silinmesi.
* Geçmişe yönelik raporlamayla değişimlerin ve ilgili ürünlerin takip edilmesi.
* Yanlış güncellenen ve girilen kayıtların geri alınması ve düzeltilmesi.
* Envanterden silinen ama hiçbir zaman satılmayan aktiflerin takip edilmesi.
* SecureFile dosyaları ile orijinal kayıtlar yok edilse bile bir kopyalarının barındırılması.
FDA kullanımı ve aktivasyonu oldukça basit bir süreçtir. Flashback verisini saklamak için bir tablespace oluşturuyoruz. Yarattığımız tablespace içinde bir flashback data archive tanımlıyoruz ve bu özelliği kullanmak istediğimiz tablolarda aktive ediyoruz, hepsi bu!
FDA'nın Faydaları
Verinin yönetilmesi ve tarihinin saklanması konusunda FDA bize zaman ve maliyet açısından kazanımlar getirmektedir. FDA ile istediğimiz herhangi bir tablo üzerindeki bütün değişimleri hızlı, güvenilir ve düşük maliyet ile saklayabilir, sorgulayabiliriz. Geçmişe ait verileri dilediğimiz kadar saklayabilir, koruyabiliriz. FDA'nın uygulamaya alınması tamamen uygulama bağımsız bir işlemdir.
Flashback Data Archive
FDA aslında mantıksal bir araçtır ve sürekli bahsettiğim gibi verinin geçmişine sahip olmamız için gereken bir yöntemdir. Temelinde başka bir fonksiyonalitesi bulunmamaktadır. Oracle Veritabanı 11g versiyonu ile aramıza katılan bir dictionary objesidir. FDA birden çok tablespace üzerinde işlem yapabilir. Bir veritabanı yöneticisi
QUOTA anahtar kelimesini kullanarak ilgili tablespace'lerde kullanımak üzere ne kadar FDA verisi ayrılması gerektiğine karar verebilir. Bir tane FDA politikası seçilebileceği gibi birden çok FDA tanımlaması ile işleri daha da kompleks hale getirebilir ve takip edilen tablo sayısını arttırabilirsiniz. Her FDA'nın bir de
RETENTION parametresi bulunmaktadır. Bu parametre ile geçmiş verileri ne kadar süre ile tutmamız gerektiğini belirliyoruz. FDA, RETENTION süresi boyunca geçmişe ait değişikliklerin saklanacağı garanti eder ve bu periyot dışında kalan verilerin silineceğini de ifade eder.
Takip altında alınan her tablo için bir içsel diğer tablo FDA tarafından tanımlanır. Bu tablo tamamen FDA'nın kullanımı ile ilgili olup geçmişi takip edilen tablonun metadata bakımından bir kopyası demektir. Takip edilen tabloya ait bir veya birden çok sütunda yapılan değişikliğin önceki imajı bu replika tabloda barındırılır. UPDATE ve DELETE DML komutları bu tablo üzerinde yeni bir kayıt oluştururken, INSERT operasyonu oluşturmamaktadır. Bunun yerine ilgili satır ana tabloda görünmektedir. Bu içsel takip tablosunun en büyük özelliği partitioned olarak yaratılması ve aynı zamanda sıkıştırılmış olmasıdır (compressed). Bu tablolar üzerinde hiçbir değişiklik kabul edilmemektedir. Bu noktada hemen bir soruyu akıllardan kaldıralım, uygulama ya da kullanıcılar "AS OF" ya da "VERSIONS BETWEEN" özelliklerini kullanarak yine undo uzerinden ilgili tablonun geçmiş verilerini her zaman sorgulayabilirler. Flashback ile ilgili daha detaylı bilgi için günlüğümdeki arşivi biraz kurcalamanız gerekmekte :)
Mimari
Bu yazıyı okuyanlarınızdan birçoğu undo'nun, undo tablespace'in, undo management'ın ne olduğunu biliyor aslında. Tabii bilmeyenler için yine günlüğümde undo ile ilgili açıklayıcı teknik makaleler bulunmakta. Eğer undo'nun bir Oracle veritabanında ne işe yaradığı hakkında hiçbir fikriniz yoksa bu noktadan sonrasını okumaya devam etmeden önce lütfen undo'nun tam olarak ne yaptığını ve ne işe yaradığını okuyunuz. Aksi halde konu askıda kalacaktır ve kafanızda soru işaretleri oluşacaktır.
FDA işte bu undo bilgilerini kullanarak, tıpkı diğer birçok Flashback özelliğinde olduğu gibi çalışmaktadir. Burada mutlaka dikkatinizi çekmiştir, "peki o zaman flashback query ile data archive arasındaki fark nedir?" sorusu. FDA'nın limitleri undo tablespace'in limitleri ile ortak değildir. Undo tablespace'in boyutu ve retention period'u flashback'in diğer özellikleri için (flashback database hariç, onun ayrı bir log'u var) sınırlayıcı niteliktedir. FDA'da böyle bir durum söz konusu değildir! FDA yalnızca undo verilerini kullanır ve bir tablo eğer FDA için seçilmiş ve tanımlanmış ise o tabloya ait bütün undo verileri archival için işaretlenir. Bütün transaction'ların geçmişinin ilgili tablo için tutulduğundan emin olmak için yine ilgili hiçbir undo verisi ezdirilmez, saklanır. Aksi halde zaten tutarlı kelimesini, FDA için kullanamazdık. İşte bütün bu işlemleri yerine getiren arka plan görevinin adı da FBDA'dır.
$ ps -ef | grep fbda
FBDA adını alan ve FDA aktif hale geldiği zaman ortaya çıkan arka plan görevi normalde sürekli uyku halindedir. Sistem tarafından yönetilen aralıklar uyandırılır ve archival olarak işaretlenmiş undo kayıtlarını işlemeye başlar. FBDA arka plan görevi ne zamanki bu işi bitirir ve geçmişi oluşturur, ilgili bütün undo kayıtları yeniden silinebilir konumuna getirilir ve otomatik undo yönetimi tarafından istenilen zamanda ezilir, yerine yenileri yazılır yani silinir. FDA'nın asenkron kullanımı sayesinde sistem üzerinde çok ciddi performans etkileri oluşmaz ve hatta gözardı bile edilebilir.
Çalışma mantığına ait bir şemayı yukarıda paylaşıyorum.
FBDA arka plan görevinin uyku-çalışma süreleri arasında denge içsel ilerleyiş ile kontrol edilmektedir. Transaction'ların yükü ve hızı arttıkça daha sık çalışır, azaldıkça da daha seyrek. Transaction'ların yükü ciddi boyutlara ulaştığı zaman varsayılan olarak her 5 dakikada bir uyanır ve çalışarak archival olarak işaretlenmiş bütün undo verilerini işler ve FDA'yı oluşturur.
Bir Flashback Data Archive Örneği
FDA'nın kullanılabilmesi için önceden tanımlanan işlemler bulunmaktadır. Bunlar;
1) FDA tablespace'leri mutlaka automatic segment space management (ASSM) ile yönetilmelidir. Elle yönetilenleri FDA için kabul edilmemektedir.
2) Automatic undo management mutlaka aktif olmalıdır. Aksi halde FBDA arka plan görevi işlevlerini yerine getiremez.
FDA'yı kullanmak için isterseniz yeni bir tablespace yaratabilir ya da daha önceden var olanını kullanabilirsiniz, burada bir sorun yok. Bu arada Automatic Storage Management (ASM) kullanıyorsanız FDA'nın performansı da artacaktır.
CREATE FLASHBACK ARCHIVE fba1
TABLESPACE tbs1
RETENTION 5 YEAR;
Bu örnekte tbs1 tablespace'i önceden var olan ve
ASSM ile yönetilen bir tablespace'ti ve bu tablespace üzerinde fba1 isminde, 5 yıl koruma periyoduna sahip bir FDA oluşturduk. Dikkat ederseniz daha önce bahsettiğim
QUOTA bilgisini burada kullanmaktadık.
QUOTA argümanını vermezsek varsayılan olarak
UNLIMITED olacaktır, yani sınırsız. Tam bu noktada FDA'nın kullanımı için mantıksal bir konteyner tanımlamış ve yaratmış olduk. Zaten tablespace'ler de mantıksal konteyner'lerdir.
CREATE FLASHBACK ARCHIVE fba1
TABLESPACE tbs1
QUOTA 25G
RETENTION 5 YEAR;
Yukarıdaki işlemi yerine getirebilmek için;
1)
FLASHBACK ARCHIVE ADMINISTER yetkisine sahip olmalıyız.
2)
DBA/USER_FLASHBACK_ARCHIVE sistem görüntülerinin bulunması gerekiyor.
3)
DBA/USER_FLASHBACK_ARCHIVE_TS sistem görüntülerinin bulunması gerekiyor.
Bundan sonra tek yapmamız gereken FDA'yı dilediğimiz tablolar üzerinde aktif halee getirmek ve fda1 ismindeki FDA'yı kullanmak!
ALTER TABLE hr.employees
FLASHBACK ARCHIVE fda1;
Bu aşamadan sonra employees tablosundaki bütün veri değişimleri fda1 ile ilişkilendirilen mantıksal konteyner'de 5 yıl boyunca saklanacaktır. Burada dikkat edilmesi gereken konu daha önce bahsettiğim içsel geçmiş tablosunun henüz yaratılmamış olmasıdır. İlk DML operasyonu ile birlikte ilgili içsel geçmiş tablosu yaratılacaktır.
Geçmiş Verinin Sorgulanması
FDA sayesinde
AS OF veya
VERSIONS BETWEEN kullanarak geçmiş veriyi sorgulayabiliriz. Belirttiğiniz retention period süresince bu komutları, tanımladığınız tablo için dilediğiniz gibi kullanabilirsiniz.
SELECT first_name, last_name, salary
FROM hr.employees
AS OF TIMESTAMP TO_TIMESTAMP('16/08/2009 23:55:00','DD/MM/YYYY HH24:MI:SS')
WHERE employee_id = 100;
Örnekler:
ALTER FLASHBACK ARCHIVE fla1
SET DEFAULT; --> fla1'i varsayılan FDA olarak tanımladık.
ALTER FLASHBACK ARCHIVE fla1
ADD TABLESPACE tbs3
QUOTA 3G; --> fla1FDA'sına tbs3'ü, 3G kota ile ekledik.
ALTER FLASHBACK ARCHIVE fla1
MODIFY TABLESPACE tbs3
QUOTA 5G; --> tbs3 tablespace'inin FDA kotasını 3'den 5 GB'ye çıkarttık.
ALTER FLASHBACK ARCHIVE fla1
PURGE ALL; --> fla1'in bütün geçmiş verisini sildik.
ALTER FLASHBACK ARCHIVE fla1
PURGE BEFORE SCN 32489234; --> 32489234 SCN'sinden önceki bütün geçmiş verisini sildik.
DROP FLASHBACK ARCHIVE fla1; --> fla1 FDA'sını sildik.
ALTER TABLE hr.employees
NO FLASHBACK ARCHIVE; --> employees tablosundaki FDA'yı kaldırdık.
İyi çalışmalar dilerim.
Ogan
Kaynak
