Oracle 11g Flashback Data Archive Özelliği

Oracle 11g ile birlikte gelen bir özellikten bashetmek istiyorum. Çok kritik tablolar üzerinde yapılan hatalı DML işlemleri zaman zaman ciddi problemlere yol açmaktadır. Oracle 11g versiyonu ile daha fonksiyonel bir şekilde bu soruna bir çözüm buldu. Aslında öncesindede yapılan bu DML işlemlerini tespit etme ve düzeltme şansımız vardı. Örneğin Log_Miner bu tarz işlemler için kullanılan bir package idi. Ancak burada herhangi bir ara operasyona gerek kalmadan, yapılan tüm bu değişiklikleri farklı bir tablespace’ de saklayabiliyor ve istediğiniz bir anda önceki değişiklikleri sorgulayabiliyorsunuz. Bir örnekle açıklamaya çalışalım;

KAMIL scheması altında TEST adında bir tablomuz var ve buradaki verilerinde kritik olduğunu düşünerek, tablo üzerinde yapılan tüm DML işlemlerinin kritik olduğunu düşünelim.

— İlk olarak tablo nun history’ sinin saklanacağı farklı bir tablespace create ediyoruz.
SQL> CREATE TABLESPACE Flashbach_Data_Archive DATAFILE
‘C:\ORACLE\ORADATA\TEST\flash_data_arch_01.DBF’ SIZE 1024M AUTOEXTEND ON NEXT 100M MAXSIZE 10000M
Tablespace created.

— oluşturulan bu tablespace’ i flashback data archive alanı olarak tanıtıp 10G ile sınırlandıralım ve retetionınıda 1 sene olacak şekilde set edelim ;
SQL> create flashback archive flashback_archive tablespace Flashbach_Data_Archive quota 10G retention 1 year
Create flashbackarchive successfully completed.

— historysini tutmak istediğimiz tabloları belirleyelim bu alana tanıtıyoruz;
alter table kamil.test flashback archive flashback_archive;
Table altered.

— tablo üzerinde bir update işlemi yapalım ve sonrasında bir önceki halinin nasıl saklandığına ve nasıl ulaşacağımıza bakalım;

Şu anki durumda ;

select owner, segment_name from test ;

OWNER, SEGMENT_NAME
TEST LOGMNR_I1COL$
TEST LOGMNR_I2COL$
TEST LOGMNR_I3COL$
TEST LOGMNR_I1ATTRCOL$
TEST LOGMNR_I1TS$

Tablomuzu UPDATE edelim;

SQL> update test set owner = ‘USER’
5 rows updated.

SQL> commit
Commit complete.

Şimdi de yapılan bu işlemin hatalı olduğunu kabul ederek eski veriye saklanan archive datası içerisinden ulaşmaya çalışalım;

bu table üzerinde yapılan tüm DML işlemlerinin history’ si artık bu tablespace’ de saklanıyor olacak, test edelim;

select owner, segment_name from kamil.test as of timestamp sysdate-2/1440;

OWNER SEGMENT_NAME
TEST LOGMNR_I1COL$
TEST LOGMNR_I2COL$
TEST LOGMNR_I3COL$
TEST LOGMNR_I1ATTRCOL$
TEST LOGMNR_I1TS$

Eski verilerimize ulaştık. Sysdate değerine vereceğiniz değişkenler ile daha eski verilerede ulaşabilirsiniz.

— tablomuzu flashback modundan tabloyu çıkartmak ve tüm history datasını silmek istersek ;
alter table kamil.test no flashback archive;
Table altered.

Komutundan faydalanabiliriz ;

Bu konu ile ilgili bir dipnot;

Flashback Data Archive opsiyonu açık iken tablo da yapılan değişikliklerin süresini nasıl etkileyeceğine bir bakalım isterseniz;

— öncelikle tablodaki kayıt sayısını biraz artırıyorum(daha anlamlı sonuçlar alabilmek için) ;
select count(*) from test
COUNT(*)
81920

SQL> set timing on;
SQL> update test set owner=’DENEME2′;
81920 rows updated.
Elapsed: 00:00:02.14

SQL> Commit complete.
Elapsed: 00:00:46.15

Update 2 sn sürmesine karşılık commit operasyonu beklenilen aksine 46 sn sürdü. Şimdi aynı işlemi flashback modu disable iken deniyelim ;

alter table kamil.test no flashback archive;
Table altered.

SQL> set timing on
SQL> update test set owner = ‘DENEME’
81920 rows updated.
Elapsed: 00:00:04.84

SQL> commit
Commit complete.
Elapsed: 00:00:00.01

Commit süresinden farkedeceğiniz üzere ciddi bir fark var. Dolayısıyla bu tarz kullanımlarda yapılan her değişikliğin performans üzerine olan etkisinide göz ardı etmemekde fayda olduğunu hatırlatmak isterim.

Be Sociable, Share!

5 comments

  1. Birde burada loglama yaparken bu dml hangi ip den ,hangi tool kullanılarak vs. yapılmış gibi detaylı loglama mümkün olabiliyormu acaba?

  2. Merhaba,

    Yazmiş olduğunuz döküman oldukça net ve kolay anlaşılır. Çok teşekkür ederim. Sormak istediğim kısa bir sorum olacak ilgili tablo üzerinde yapılan değişiklikleri görebiliyoruz. Fakat bu değişiklikleri hangi kullanıcılar tarafından yapıldığını hangi zaman içerisinde yapıldığını görebilirmiyiz ?

    • Selam Murat,

      Database içerisinde yer alan neslerin üzerinde yapılan değişikliklerin takibi aslında auditing’ e giriyor. Bu şekilde istediğin komutları çalıştıranları, sadece belirlediğin kullanıcıları vs gibi case’ leri bu şekilde takip edebilirsin. Burada hiç auditing’ e gitmeden’ de log_miner kullanarak da işini görebilirsin. Veya bir trigger yardımı db üzerinde çalıştırılan ve senin önceden belirlediğin bazı komutları farklı bir tabloya insert edip sonrasında kontrol edebilirsin.

      • Merhaba;
        Biz trigger ile yapıyoruz bu işi.Kamil bey performans açısından siz trigger mı yoksa flashback data archive ımı tavsiye edersiniz ?Bu özelliği kullanmadım ama sanki trigger mantığı daha performanslı gibi geliyor bana.

        • Selam Dilek,

          Data archive özelliğini yularıda belirtmiş olduğum testler sonrasında productionda kullanmamıştık ancak özellikle spesifik bir tablonuz varsa kullanmakta sakınca olmaz diye düşünüyorum. Ama trigger da güzel bir opsiyon ve çoğu yerde bende bu yöntemi kullanıyorum.

          Kolay gelsin.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir


dört × 8 =