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!

• 
•