Undo Tablespace Yönetimi ve Undo

@ 24 Şubat 2011 tarihinde yazdı. Yazıya yorum yazın.

Merhaba,

Bu yazımda, undo’nun ne olduğunu, nasıl yönetildiğini, undo tablespace’in amacını ve günlük kullanımdaki yerini ve boyutlandırmasını anlatmaya çalışacağım.

Her bir Oracle veritabanının işlenen verinin bakımını yapabilmesi ve ihtiyaç anında ilgili bilgiyi geri alabilmesi için bir method kullanması gerekmektedir. Bahsettiğim bilgiyi henüz commit edilmemiş aktif transaction’lar olarak düşünürsek eğer aslında bu bilgi tiplerine undo

Undo bilgileri aşağıdaki durumlarda;

1) Bir işlemi (transaction) rollback yapabilmek,
2) Veritabanını kurtarmak (recover),
3) Verinin okuma tutarlılığını sağlayabilmek,
4) Flashback query ile önceden kullanılmış bir DML’i yeniden sorgulayabilmek,
5) Oracle Flashback özellikleri ile kayıp veriye yeniden ulaşabilmek için undo kullanılabilir.

Henüz commit edilmemiş bir transaction rollback komutunu koşarsa undo bilgileri kullanılarak veriler geriye çevrilebilir. Veritabanının kurtarılması işleminde redo log’lar tarafından fiziksel datafile’lara yazılmış ancak henüz commit edilmemiş değişikliker için undo yine kullanılabilir.

Otomatik Undo Yönetimi

Undo bilgisini ve boyutlandırmasının yönetilmesini Oracle’a bırakabiliriz zira otomatik undo yönetimini devreye alarak bunu sağlayabilirsiniz. Bu şekilde undo tablespace yaratabilir ve aktif session’ların undo yönetimini otomatik olarak yaptırabilirsiniz. Bunu sağlayabilmek içinUNDO_MANAGEMENT parametresini AUTO konumuna getirmeniz yeterli olacaktır.

Bir veritabanı ilk defa yaratılırken undo tablespace’i de yaratılmaktadır. Yalnız bu noktada unutmamanız gereken birşey var ki; bir veritabanın iki datafile, iki tablespace, iki online redolog ve bir control dosyası ile yaratılması şarttır. Tablespace’lerden birisi system bir diğeri ise sysaux’tur ve iki datafile’da bu iki tablespace’e aittir. Yani bir undo tablespace’i veritabanı yaratılırken yaratmak zorunda değilsiniz. Undo tablespace sonradan elle de yaratılabilir.

Bu konunun önemli notlarından birisi ise bir veritabanı her açılışında undo tablespace’ini aramaktadır. Eğer tahsis edilmiş varsayılan bir undo tablespace’i bulunmuyorsa, undo bilgileri system tablespace’ini yazılır. Bu tavsiye edilen birşey kesinlikle değildir ve veritabanı açıldığı zaman undo tablespace’in yaratılmadığı ve undo bilgilerinin system tablespace’ine yazılacağını bildiren bir bilgi alert.log dosyasına işlenmektedir.

Bir veritabanında birden çok undo tablespace bulunabilir. Bunun bir sakıncası yoktur ancak bir tanesini varsayılan olarak atayabilirsiniz. Bunu sağlayan parametre ise UNDO_TABLESPACE parametresidir.

UNDO_TABLESPACE = UNDOTBS_01

Eğer undo_tablespace parametresinin bir değeri varsa ancak ilgili undo tablespace veritabanında bulunmuyorsa STARTUP komutu hata alacaktır. UNDO_TABLESPACE parametresini RAC (Real Application Cluster) ortamlarında da kullanabilirsiniz. Eğer otomatik undo yönetimi aktive edilmişse elle yapılması için tanımlanmış undo parametreleri göz ardı edilecektir.

Yukarıdaki bilgileri aktarmışken, sırada undonun korunacağı (undo retention) periyotunu tanımlamak var. Veritabanındaki undo tablespace’inde tutulan ve aktif transaction’ların henüz commit edilmemiş bilgilerini içeren undo verileri sadece belirli bir süre undo tablespace’inde tutulmaktadır. Buna da “undo retention” süresi denilmektedir. Bir transaction commit edildikten sonra daha önceki undo bilgilerine gerek kalmamaktadır fakat tutarlı bir okuma sağlayabilmek için, uzun süre alan ve çalışan sorguların eski undo bilgileri und tablespace’inde tutulabilmektedir. Bunun sebebi ise flashback özelliğini kullabilmektir. Flashback özelliklerinin kullanabilmesi içinse undo retention süresini mümkün olduğunca uzun tutmak isteyebilirsiniz.

Eski ve commit edilmiş, undo retention parametresinden eski undo bilgileri “süresi dolmuş” olarak kabul edilmekte iken, eski ve commit edilmiş ancak undo retention parametresinden yeni olan undo bilgileri “süresi dolmamış” olarak kabul edilmektedir.

UNDO_RETENTION parametresini -ki saniye olarak atanmaktadır- değiştirebilirsiniz ancak Oracle bunu otomatik undo yönetiminde kendisi de yönetmektedir. Bunu sistem aktivitesine göre boyutlandırmaktadır. Eğer sizin undo tablespace için tanımladığınız alan, yine tanımladığınız undo_retention periyodunu aşmakta ise Oracle, undo tablespace içerisinde “süresi dolmuş” olarak işaretlenen undo bilgilerini silecektir. Bu da aslında otomatik undo yönetiminin bir parçasıdır.

Bir undo tablespace’ini AUTOEXTEND, yani otomatik genişleyecek şekilde tanımladıysanız eğer Oracle, undo tablespace’i büyütmek istediği zaman daha fazla yere ihtiyaç duyacak ve tablespace alanını AUTOEXTEND doğrultusunda arttıracaktır. Arttıramadığı durumlarda bir hata alacaksınız ve bu hatayı alert.log dosyasında göreceksiniz. İlgili hata nedeniyle çalışmakta olan transaction iptal edilecek ancak rollback yapabilmesi için önceki bilgileri undo tablespace’te tutulmaya devam edecektir. Bu noktada dokümante edilmemiş bir Oracle bilgi mesajından bahsetmek istiyorum. Diyelim bir transaction’ınız var ve çok uzun süren bir sorgu. Aradan 30 dakika geçti ve bağlantınız kötü bir biçimde sonlandırıldı. Alert.log dosyasında göreceğiniz mesaj şudur;

SMON: Parallel transaction recovery tried.

Bu tamamen normal bir mesajtır ve undo bilgileri okunarak, transaction bir anlamda rollback yapılmaktadır. Yani SMON sadece startup seviyesinde çalışan bir arka plan görevi değildir.

Retention Garantisi

Veritabanında uzun süren sorguların undo’dan silinmemesini garanti altına alabilirsiniz. Flashback query için tutarlılığın sağlanmasında kullanılabilmektedir. Eğer retention garantisi aktif hale getirildi ise undo_retention parametresinin saniye değeri kadar olan bilgi undo tablespace’inde saklanacaktır. Tablespace dolsa bile bu bilgiler silinmeyecektir ve “süresi dolmamış” bilgilerin üzerine başka undo verileri girilmeyecektir. Bu opsiyonun varsayılanı kapalı konumdur ve bir komut ile aktif hale getirilir.

UNDO_RETENTION parametresini init parametre dosyasında (9i’den önce pfile veya 9i’den sonra spfile) ya da sistem çalışırken değiştirebilirsiniz;

UNDO_RETENTION = 1800

ALTER SYSTEM SET UNDO_RETENTION = 2400;

Bir undo tablespace’inin sabit bir boyutu olabilir ya da otomatik olarak arttırılacak şekilde tasarlanabilir.

Yeni bir sistem kurmuşsanız ve uygulamanın ne kadar undo yaratacağını tahmin edemiyorsanız AUTOEXTEND özelliğini kullanarak undo tablespace’in boyutlarının nereye kadar gidebileceğini gözlemleyebilirsiniz.

Kararınızı sabit boyutlu bir undo tablespace kullanmaktan yana kullanırsanız da size yardımcı olabilecek bir çok özellik bulunmaktadır. Bunlardan bir tanesi DBMS_ADVISOR paketidir. Enterprise Manager’da kullanılan “undo advisor” AWR tarafından toplanan bilgilerle oluşturulmaktadır. Yeni veritabanı kurulduğu zaman tutarlı bir AWR raporu almak mümkün olmadığı için ilk başta otomatik undo yönetimi ve AUTOEXTEND özelliğinin açık olması önerilmektedir. Zamanlar AWR raporları daha da tutarlı veriler sağlamaya başladığı zaman AUTOEXTEND yerini sabit boyutlandırmalı undo tablespace’e bırakabilir.

Undo advisor’ın bir örnek script’ini vermem gerekirse;

DECLARE

tid NUMBER;
tname VARCHAR2(30);
oid NUMBER;

BEGIN

DBMS_ADVISOR.CREATE_TASK('Undo Advisor', tid, tname, 'Undo Advisor Task');
DBMS_ADVISOR.CREATE_OBJECT(tname, 'UNDO_TBS', null, null, null, 'null', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'TARGET_OBJECTS', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'START_SNAPSHOT', 1);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'END_SNAPSHOT', 2);
DBMS_ADVISOR.SET_TASK_PARAMETER(name, 'INSTANCE', 1);
DBMS_ADVISOR.execute_task(tname);

END;
/

Advisor görevini başarıyla yarattıktan sonra Enterprise Manager’dan ADDM’e bakarak ilgili görevleri inceleyebilirsiniz.

NOT: ADDM, AWR Enterprise Edition ile birlikte satın alınabilecek bir pakettir (Bkz. Diagnostic Pack). Bu paketi satın almadıysanız eğer statspack kullanabilirsiniz.

UNDO TABLESPACE YÖNETİMİ

UNDO TABLESPACE OLUŞTURULMASI

Bir undo tablaspace’i iki ayrı yönetim ile oluşturabilirsiniz. Bunlardan bir tanesi CREATE DATABASE komutudur. Instance otomatik undo yönetimi ile açılacak ve bir undo tablespace’iniz olacaktır. Diğer yönetim ise zaten açık olan ve undo yönetimini system tablespace’i devam ettiren bir veritabanında undo tablespace yaratmaktır. Bunu yapabilmenin komutu da CREATE UNDO TABLESPACE.

Önemli notlardan birisi, undo tablespace üzerinde hiçbir obje yaratamazsınız. Sıradan bir tablespace değildir ve obje yaratılması kabul edilmez. Sadece sistem – undo bilgileri içindir.

Aşağıda CREATE DATABASE komutu ile nasıl undo tablespace yaratabileceğiniz görebilirsiniz;

CREATE DATABASE ORCL
CONTROLFILE REUSE
.
.
.
UNDO TABLESPACE undotbs_01 DATAFILE '/u01/oracle/rbdb1/undo0101.dbf';

Eğer CREATE DATABASE komutu koşarken undo tablespace düzgün bir şekilde yaratılamazsa bütün prosedür sonlanacaktır ve yapılan işlemler boşa gidecektir. Bütün veritabanı dosyalarını silmeniz, hatayı düzeltmeniz ve komutu yeniden koşmanız gerekmektedir.

Undo tablespace’in diğer oluşturulma komutu ise;

CREATE UNDO TABLESPACE undotbs_02
DATAFILE '/u01/oracle/rbdb1/undo0201.dbf' SIZE 2M REUSE AUTOEXTEND ON;

Birden çok undo tablespace yaratabilirsiniz ancak bunlardan sadece bir tanesi aktif olarak çalışabilir.

ALTER UNDO TABLESPACE

Bir undo tablespace’inin özellikleri ALTER TABLESPACE komutu ile değiştirilebilir. Bu komut ile;

1) Yeni bir datafile eklenebilir.
2) Varolan bir datafile yeniden adlandırılabilir.
3) Varolan bir datafile offline ya da online yapılabilir (NOT: UNDO TABLESPACE TAMAMEN OFFLINE YAPILAMAZ).
4) Undo garantisini açmak ya da kapamak için kullanılabilir.

Örnek;

ALTER TABLESPACE undotbs_01
ADD DATAFILE '/u01/oracle/rbdb1/undo0102.dbf'
AUTOEXTEND ON NEXT 1M
MAXSIZE UNLIMITED;

DROP UNDO TABLESPACE

Bir undo tablespace’ini düşürebilirsiniz (drop etmek). Bunu yapabilmeniz için aşağıdaki komutu koşmanız gerekmektedir;

DROP TABLESPACE undotbs_01;

Bir undo tablespace sadece ve sadece hiçbir instance tarafından kullanılmıyorken düşürülebilir. Eğer undo tablespace olağanüstü bir transaction içeriyorsa (ölmüş bir transaction ve henüz kurtarılmamış) o zaman drop işlemi çalışmayacaktır.

Bu konu ile ilgili önceki bir yazımı okumanızı tavsiye ederim. Undo tablespace’i düşürebilmek için dikkatli olmak gerekmektedir. İlgili yazı için –> http://oganozdogan.blogspot.com/2010/07/aktif-rollback-segment-ora-01548.html

UNDO TABLESPACE DEĞİŞTİRİLMESİ

Varsayılan ve aktif olarak işlenecek undo tablespace’in hangisi olacağına dinamik olarak karar verebilirsiniz. Tabii bunu yapabilmek için spfile kullanmak gerekmektedir!

ALTER SYSTEM SET UNDO_TABLESPACE = undotbs_02;

Bu komut ile birlikte bütün aktif transaction’lar artık yeni undo tablespace’i kullanacaklardır. Bunu sağlayabilmek için komutun başarılı olması gerekmektedir.

Aşağıdaki komut geçerli undo tablespace’i hiçbir undo tablespace’ine tanımlamamaktadır;

ALTER SYSTEM SET UNDO_TABLESPACE = '';

Tabii yukarıdaki komut dikkatlice kullanılmalıdır zira bu komut ile geçerli undo tablespace yerini eski undo tablespace’e bırakacaktır. Eski bir undo tablespace yoksa eğer hata alınabilir.

UNDO HAKKINDA BİLGİ GÖRÜNTÜLEMEK

Undo hakkında bilgiye sahip olabilmek için aşağıdaki görüntüler sorgulanabilir;

V$UNDOSTAT
V$ROLLSTAT
V$TRANSACTION
DBA_UNDO_EXTENTS
DBA_HIST_UNDO_STAT

V$UNDOSTAT görüntüsü içerisinde çok faydalı undo bilgileri bulunmaktadır. Bu görüntüde undo alan tüketimi, transaction tutarlılığı ve undo retention parametresinin ayarlanması gibi bilgiler bulunmaktadır. Aşağıdaki sorgu kullanılarak bir bilgiye sahip olabilirsiniz;

SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME,
TO_CHAR(END_TIME, 'MM/DD/YYYY HH24:MI:SS') END_TIME,
UNDOTSN, UNDOBLKS, TXNCOUNT, MAXCONCURRENCY AS "MAXCON"
FROM v$UNDOSTAT WHERE rownum <= 144;

İyi çalışmalar.

Ogan – http://oganozdogan.blogspot.com/