30 Temmuz 2010 Cuma

Undo Tablespace Yönetimi ve Undo

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çin UNDO_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 tıklayınız.

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

Kalın
demekteyiz.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

FLASHBACK_ON Parametresi

Merhabalar,

FLASHBACK_ON isimli bir Oracle parametresi bulunmakta ve bu parametresi veritabanını flashback moduna geçirmeye yaramaktadır. Bu sayade flashback database gibi flashback özellikleri kullanım imkanı kazanmaktadır.

FLASHBACK_ON parametresinin olası değerleri ise;

1) YES: Flashback aktif konumdadır.
2) NO: Flashback pasif konumdadır.
3) RESTORE POINT ONLY: Sadece flashback garantili restore point'ler için geçerli aktif konumdadır.

FLASHBACK_ON parametenizi v$database fixed view'ından öğrenebilirsiniz.

SELECT FLASHBACK_ON
FROM V$DATABASE;

10gR2 ve 11gR2 sürümleri arasında bu konu hakkında çok büyük bir fark bulunmakta. 10gR2 sürümünde flashback_on parametresini YES konumuna getirebilmeniz için veritabanını mount modda açmanız, parametreyi değiştirmeniz ve sonra da veritabanını açmanız gerekmekteydi. Halihazırda açık bir veritabanı için bu değişikliği gönderirseniz eğer;

SQL> alter database flashback on;
alter database flashback on
*
ERROR at line 1:
ORA-38759: Database must be mounted by only one instance and not open.

Archivelog aktif olan bir 11gR2 sürümünde bu değişikliği yaparsak eğer;

SQL> alter database flashback on;

Database altered.

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES

SQL> alter database flashback off;

Database altered.

10gR2'de flashback özelliğini dinamik olarak aktif hale getiremiyorduk ancak 11gR2 için böyle bir durum söz konusu değil. Flashback parametresini YES konumuna getirebilmek için unutmayınız, veritabanınız archivelog modda olmalıdır. 11gR2 kullanıyorsanız, veritabanınızda archivelog pasif durumda ve kullanılmıyorsa ve flashback_on parametresini YES konumuna getirmek istiyorsanız, yine de veritabanınızı yeniden başlatmanız gerekecek zira archivelog modu aktif duruma getirebilmek için veritabanınız mount modda olmalıdır. Aşağıdaki örnek 11gR2 bir veritabanı için geçerlidir.

SQL> shutdown immediate;

Database closed.
Database dismounted.
Oracle instance shut down.

SQL> startup mount;

Oracle instance started.

Total System Global Area 134045849 bytes
Fixed Size 1244940 bytes
Variable Size 157820480 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes

Database mounted.

SQL> alter database archivelog;

Database altered.

SQL> alter database open;

Database altered.

SQL> alter database flashback on;

Database altered.

İyi çalışmalar.

Ogan

Media Recovery Çeşitleri Nelerdir?

Selamlar,

Bir önceki yazımda bir tablespace'i nasıl offline konumuna getirebileceğimizi anlatmıştım. Dikkate alınması gereken bir konu diyebilirim. Bu konunun içerisinde de sıklıkla media recovery'den bahsetmiştim. Peki bu meşhur media recovery nedir?

Media recovery Oracle'ın online dokümantasyonlarında "Backup & Recovery" başlığı altında bulunmaktadır. Bu recovery tipinde Oracle yedeği alır ve redo'ları işler. Bu redo işleme işine media recovery denir. Media recovery aslında datafile'ların recover edilmesi işlemidir de diyebiliriz.

4 çeşit media recovery bulunmaktadır.

* Complete Recovery
* Incomplete Recovery
* Datafile Media Recovery
* Block Media Recovery

COMPLETE RECOVERY

Complete Recovery online redolog'ları ya da bir incremental yedek ile birlikte full veritabanı yedeğini kullanarak datafile'ların recover edilmesi işlemidir. Bunun adına complete (bütün, tamam) denmesinin nedeni ise online redolog'ların da recover işleminde kullanılması. Online redolog'lar dışında tabii ki archivelog'lardan da yararlanılmaktadır. Complete media recovery işlemini genelde datafile hatalarında ya da controlfile problemlerinde kullanılmaktadır.

Eğer complete media recovery'i veritabanı seviyesinde yapmak istiyorsanız;

1) Veritabanı mount modda olmalı.
2) Recover etmek istediğiniz bütün datafile'ların online konumda bulunması gerekiyor.
3) Bütün bir veritabanı yedeğiniz restore ediyorsunuz.
4) Online redolog'ları ve / veya archivelog'ları işliyorsunuz.

Yukarıdaki işleme kısaca restore / recover diyebiliriz. Backup / recover genelde geçen isimlerdir ancak bir yedeği recover etmeden önce restore etmeniz gerekmektedir. Recover komutu ile online redolog veya archivelog'lar işlenerek media recovery tamamlanır ve veritabanı ya da ilgili obje yeniden kullanıma alınır.

Eğer complete media recovery'i tablespace ya da bir datafile'a uygulamak istiyorsanız;

1) Eğer veritabanı açıksa tablespace ya da ilgili datafile'ı offline konumuna getiriniz.
2) Bir yedeği restore ederek datafile'ı recover ediniz.
3) Online redolog'ları ve / veya archivelog'ları işliyorsunuz.

INCOMPLETE RECOVERY

Bir diğer ad olarak "point-in-time recovery" de diyebiliriz. Bu tarz bir media recovery'de elimizdeki yedeğin güncelleği ne yazık ki güncel olmayacaktır. Bir diğer anlamıyla en güncel ancak veritabanı ile birlikte bütün archivelog'ları ya da online log'ların işlenemiyor olması.

Incomplete media recovery'i genelde şu durumlarda kullıyoruz;

1) Bir media hatasından dolayı online redolog'ların tamamen silinmesi ya da bozulması.
2) Kullanıcı hatasına bağlı olarak düşürülmüş ve geri dönülemeyen (bkz. flashback table) hatası.
3) Kaybolan archivelog'lardan dolayı yapılamayan complete media recovery.
4) Control dosyasının kaybolması ya da bozulmasına bağlı olarak yedekle birlikte alınmış control file'dan dönülmesi.

Sonuç olarak redo, archivelog ya da control file'dan herhangi birinin uçması sonucu complete recovery yapma şansınız kalmıyor.

Incomplete recovery ile veritabanını "ALTER DATABASE OPEN" diyerek açamıyoruz çünkü bir complete media recovery gerçekleştirmedik. Bu komut yerine "ALTER DATABASE OPEN RESETLOGS" komutunu göndermemiz gerekmekte. RESETLOGS komutu redolog sıralamasına yeni bir başlangıç vermesi ve sayacını 1 olarak sıfırdan başlatması. OPEN RESETLOGS komutundan önce veritabanını READ ONLY olarak açarak, veritabanının doğru noktada olduğunu kontrol etmemizde fayda olacaktır "ALTER DATABASE OPEN READ ONLY".

Incomplete media recovery başlığı altındaki bir alt başlık;

Tablespace PITR (Point-in-time Recovery)

Bu tipteki bir media recovery'da geçmişteki bir zamana dönerek, tablespace'i kurtarma işlemini gerçekleştiriyoruz.

1) Hatalı bir drop ya da truncate işlemi gerçekleşmiş ise.
2) Bir tablo mantıksal olarak bozulmuş ise.
3) Bir şemanın fiziksel veritabanı ile tutarsız bir zamana döndürülmesinden sonra.
4) Bütün bir veritabanının restore edilmesindense tek bir tablespace'in restore/recover edildiği durumlarda.

TSPITR seçeneğini aşağıdaki durumlarda kullanamayız;

1) SYSTEM ya da UNDO tablespace'ini recover ederken.
2) Herhangi bir şekilde rollback segment içeren tablespace'leri.

Incomplete media recovery seçenekleri arasında;

1) Time-Based Recovery: İlgili veriyi herhangi belirlenen bir zamana döndürerek.
2) Cancel-Based Recovery: Cancel komutunu verdiğiniz zamana kadar döndürerek (Recovery manager ile kullanılmıyor).
3) Change-Based Recovery: Belirlenen bir SCN (System Change Number) döndürerek.
4) Log Sequence Recovery: Verilen bir log sıra numarasına döndürerek (Recovery manager ile kullanılmıyor).

DATAFILE MEDIA RECOVERY

Bu tip media recovery'de datafile ya da controlfile'ın kurtarılması hedeflenmektedir. Bunun dışında bir önceki tablespace konusunda belirttiğim offline methodlarından immediate methodunun kullanımasından sonra shutdown abort gönderilirse datafile media recovery kullanılabilir.

Online redolog'lar dışında archivelog'lar da kullanılabilmektedir. Bu tipte media recovery'de herhangi bir media hatası taranmamaktadır.

BLOCK MEDIA RECOVERY

Block media recovery'nın özelliği veritabanı online ve işlem görmekte iken data bloklarının restore ve recover edilmesidir. Eğer bir datafile'ın sadece birkaç bloğunda hata varsa datafile media recovery yerine block media recovery tercih edilebilir.

Blocke media recovery kullanımı RMAN (Recovery Manager) ile mümkündür.

Media recovery tiplerinden sonra gelen konu ise Recovery Manager ile yedekleme ve yedekten dönme olabilir.

İyi çalışmalar.

Ogan

Bir Tablespace'i Offline Yapmak

Merhaba,

Temporary (geçici), undo ve system tablespace'lerinin ortak bir özelliği bulunuyor. Bu tablespace'leri offline konumuna alamıyoruz ve hatta system tablespace'ini düşüremiyoruz. Bir tablespace'i offline yapmak istememizin en büyük nedenlerinden birisi bünyesinde bulunan bir datafile'ı başka bir alana taşımak veya yeniden adlandırmak olabilir. Ya da offline olarak yedeğini almak isteyebilirsiniz ki online olarak yedeği alınabilmekte.

Bir tablespace'i offline konumuna getirebilmek için kullanabileceğiniz birkaç offline methodu bulunuyor.

1) Normal: Bir tablespace offline normal konumuna eğer herhangi bir datafile'ında bir hata yoksa alınabilir. Bu komutu gönderdiğiniz zaman Oracle ilgili tablespace'in bütün datafile'larına checkpoint göndererek offline konumuna getirir. Normal son ekini sorgunun sonuna eklemezseniz tablespace normal olarak offline yapılacaktır;

ALTER TABLESPACE TBS_01
OFFLINE [NORMAL];

2) Temporary: Bir ya da birkaç datafile'ınında problem ya da hata olan bir tablespace temporary komutu ile offline konuma çekilebilir. Eğer tablodaki bütün datafile'lar zaten offline ise ve bu komutu yine de göndermişseniz, tablespace'i online yaparken media recovery yapmanıza gerek kalmaz. Ancak bir ya da birden çok datafile'da sorun varsa online yaparken media recovery yapmanız gerekecektir.

ALTER TABLESPACE TBS_02
OFFLINE TEMPORARY;

3) Immediate: Bu komut eklentisi ile Oracle, ilgili tablespace'in datafile'larına bir checkpoint göndermeden offline konumuna çeker. Bu şartlar altında datafile'lar için media recovery yapmak zorunda kalırsınız. Buradaki en önemli nokta ve farklılık ise bir tablespace'i immediate olarak offline yapmak istiyorsanız veritabanınız mutlaka archivelog modda olması gerekiyor. Noarchivelog modda çalışmaktaysanız tablespace'i normal olarak offline yapmanız gerekiyor. Aksi halde olmayan archivelog'lar ile media recovery yapmanız söz konusu değil zaten.

ALTER TABLESPACE TBS_03
OFFLINE IMMEDIATE;

Eğer bir tablespace'i offline yapmak amacındaysanız bunu yapmanın en iyi yolu normal ile yapmaktır. Bu sayede tablespace'i media recovery ile yeniden online yapmanıza gerek kalmayacaktır.

Bir tablespace'i yeniden online yapmak için kullanabileceğiniz komut;

ALTER TABLESPACE TBS_04
ONLINE;

Unutmadan eklemem gerekiyor ki "media recovery" dediğimiz konsept archivelog'ların ilgili tablespace'e işlenerek, datafile'ların yeniden tutarlı hale getirilmesi ve kaldığı yerden devam ederek bağlı olduğu tablespace'in online konumuna getirilmesi diyebiliriz. Aslında bu dediğimden daha fazlası ancak şu an konumuzdaki media recovery'dan kastımız budur. Bir sonraki konuda media recovery'i ele alabiliriz bu durumda :)

İyi çalışmalar.

Ogan

26 Temmuz 2010 Pazartesi

ORA-08104: this index object string is being online built or rebuilt

Merhaba,

Bir tablo üzerinde -ki bu tablonun gerçekten çok büyük olduğunu düşünelim- indeks yaratmak istediniz fakat bu işlemin yarısında bağlantınız koptu ya da kötü bir biçimde bağlantınız sonlandırıldı. Oluşturmak istediğiniz indeksin bilgisini indeksler arasında görüyorsunuz fakat kullanmak ya da düşürmek istediğiniz zaman hata alıyorsunuz. Aldığınız hata ise;

SQL> set serveroutput on;
SQL> exec dbms_output.put_line(SQLERRM('-8104'));
ORA-08104: this index object is being online built or rebuilt

PL/SQL procedure successfully completed.

SQL> alter session set nls_language='TURKISH';

Oturum değiştirildi.

SQL> exec dbms_output.put_line(SQLERRM('-8104'));
ORA-08104: bu dizin nesnesi ilk kez veya yeniden çevrimiçi olarak oluşturuluyor

PL/SQL yordamı başarıyla tamamlandı.

Durumu düzeltmek için Oracle'ın önerdiği yöntem basit ve klasik; veritabanını yeniden başlatın! Ancak biraz araştırma yaptığınız zaman aşağıdaki sonuca ulaşıyorsunuz ve eğer bu durumu bir şekilde çözmezseniz ORA-00600 hataları da eklenecektir. Bunun dışında indeksi tamamen unutun, tabloyu bile düşürmek isterseniz hata almaya devam edeceksiniz. FORCE opsiyonu ile de indeksi düşüremeyeceksiniz.

DECLARE

RetVal BOOLEAN;
OBJECT_ID BINARY_INTEGER;
WAIT_FOR_LOCK BINARY_INTEGER;

BEGIN
OBJECT_ID := 931288;
WAIT_FOR_LOCK := NULL;

RetVal := SYS.DBMS_REPAIR.ONLINE_INDEX_CLEAN (OBJECT_ID);
COMMIT;
END;

DBMS_REPAIR paketinin bir parçası olan ONLINE_INDEX_CLEAN fonksiyonu bize, yarıda kalan indeks oluşturma ya da yeniden yaratma işlemlerini, elle tamamlama şansını sağlar. Bunu aslında SMON (System Monitor) arkaplan görevi periyodik olarak sağlamaktadır. Fonksiyonun cevabı "TRUE" ya da "FALSE" olarak dönebilir. Yukarıdaki RetVal fonksiyonunun boolean olarak tanımlanmasındaki amaçta bu yüzdendir.

İlgili indeksin object_id bilgisine dba_object data dictionary görüntüsünden ulaşabilirsiniz.
SQL> SELECT OBJECT_ID FROM DBA_OBJECTS WHERE OBJECT_NAME = 'IDX_01';
İyi çalışmalar.
Ogan


16 Temmuz 2010 Cuma

Aktif Rollback Segment, ORA-01548

Merhabalar,

Başlıkta belirttiğim hatayı bir undo tablespace düşürmek isterken alabilirsiniz. Peki günlük hayatta, undo tablespace'i neden düşürmek (drop) isteyelim? Bunun en büyük nedenini ben tecrübelerime dayanarak söyleyebilirim;

Data Guard kurulumu yapmak için bir veritabanı teslim aldım. Veritabanının toplam boyutu 470 gigabyte olmuş ve data guard replikasyonu için ciddi bir boyut diyebiliriz. Yalnız bu 470G'lik alanın tam 170G kadarını undo tablespace kaplıyordu. Bu undo tablespace'ten kurtulabilirsem ve fragmantasyona uğraşmış olan indeks ve tabloları da küçültebilirsem alanın 200G'lere kadar inebileceğine karar verdim.

İlk iş olarak yeni bir undo tablespace yarattım;

CREATE UNDO TABLESPACE undotbs_02
DATAFILE '/u01/oracle/db_1/undo0201.dbf'
SIZE 2G
AUTOEXTEND ON;

Yarattığım undo tablespace'i geçerli olan undo tablespace olarak tanımladım.

ALTER SYSTEM SET undo_tablespace='undotbs_02' SCOPE=BOTH;

Üzerinde aktif olarak session ve rollback segment'e sahip olan bir undo tablespace'i düşürmek isterseniz eğer düşüremeyecek ve offline da yapamayacaksınız. Bunu yapabilmeniz için veritabanını yeniden başlatmanız gerekiyor. Veritabanını yeniden başlattınız ve undotbs_01'i offline yaptınız. Sırada drop etmek var değil mi? Bu arada birkaç parametre hakkında çıktı göstermem gerekiyor.

SQL> show parameter undo

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 1800
undo_tablespace string undotbs_02

Veritabanınızım undo yönetimi otomatik ve retention saniyesi de 1800 olarak ayarlanmış. Geçerli undo tablespace ise undotbs_02. Şimdi aşağıdaki drop komutunu gönderiyorsunuz;

DROP TABLESPACE undotbs_01
INCLUDING CONTENTS AND DATAFILES
CASCADE CONSTRAINTS;

Aldığınız hata ne olabilir sizce?

ORA-01548: active rollback segment '_SYSSMU44$' found, terminate dropping tablespace

Bu durumda yapmanız gerekenleri aşağıda sırasıyla listeliyorum. Özet olarak belirtmem gerekirse eğer bir undo tablespace'i bu durumda düşürmenin yolu, ilk önce segment'i düşürmektir.

SQL> drop tablespace undotbs_01;
drop tablespace undotbs_01
*
ERROR at line 1:
ORA-01548: active rollback segment '_SYSSMU44$' found, terminate dropping
tablespace

Kullanmakta olduğunuz spfile'dan bir pfile yaratalım;

SQL> create pfile='/home/oracle/initorcl.ora' from spfile;

Yarattığımız pfile dosyasını açalım ve aşağıdaki parametreyi değiştirelim;

undo_management=manual;

Aşağıdaki değişikliği de pfile dosyasına ekleyelim;

*._offline_rollback_segments=(_SYSSMU44$)

Yukarıdaki değişikliği tekbir segment için yaptık ancak birden çok segment ile ilgili problem olabilir. Bunu anlamak için veritabanı açıkken ve undotbs_01 offline konumundayken aşağıdaki sorguyu koşalım;

SQL> select segment_name,status,tablespace_name from dba_rollback_segs;

Status kısmı "needs recovery" olarak geçenlerle ilgili problem yaşayacaksınız demektir. Bu yüzden eğer eklenmesi gereken bir rollback segment varsa, _offline_rollback_segments parametresinin içerisinde "," ile ayırarak ekleyin.

Veritabanını, yeni oluşturduğumuz pfile ile mount modunda açıyoruz;

SQL> startup mount pfile='/home/oracle/initorcl.ora' ;

Ardından undotbs_01'in sahip olduğu datafile'ları düşürüyoruz;

SQL> alter database datafile '/u01/oracle/db_1/undotbs_01.dbf' offline drop;

Bu ve eğer varsa bunun gibi diğer datafile'ları düşürelim.

Şimdi de veritabanımızı açık hale getirelim;

SQL> alter database open;

Veritabanımızı açtıktan sonra da ilgili rollback segment'i düşürebiliriz;

SQL> drop rollback segment '_SYSSMU44$';

Şimdi ise kullanmak istemediğimiz undo tablespace'i düşürelim. Sona çok yaklaştık :)

SQL> drop tablespace undotbs_01 including contents;

including contents'ten sonra "and datafiles" parametresini vermemize gerek yok zira onlar zaten yoklar artık.

Bu durumda veritabanımız bir pfile ile çalışmakta olduğundan spfile'a geri geçebiliriz ancak önce pfile'da yaptığımız değişiklikleri geri almamız gerekiyor. Bunu geri almayı unutmayın!

SQL> create spfile from pfile='/home/oracle/iniorcl.ora';
SQL> shutdown immediate;
SQL> startup;

Bu işlemleri de yaptıktan sonra undo_management, undo_tablespace ve spfile gibi parametrelerinizi "show parameter" komutu ile birlikte kontrol ediniz.

Yukarıdaki işlemleri gerçekleştirirken bir yandan (eğer *nix üzerinde iseniz) tail -f komutu ile alert.log dosyasını takip ediniz. Alert_log. dosyanızın nerede olduğunu öğrenmek içinse;

SQL> show parameter background_dump_dest;

Bu kadar küçük bir ama önemli hatırlatma yapmam gerekiyor. Undo tablespace shrink edilemez diye bir şey yok. Shrink edilebilir ancak aktif segment'e sahip olmaması gerekiyor. Tuttuğu aktif rollback segment'ler bırakıldığı zaman undo tablespace'in boyutu yeniden yapılandırılabilir.

İyi çalışmalar.

Ogan

9 Temmuz 2010 Cuma

Data Guard

Merhabalar,

Yaklaşık işe başladığım günden bu yana (2 sene) Oracle data guard ile zaman zaman uğraşmaktayım. Bu zamana kadar birçok fiziksel ve mantıksal yedek veritabanı oluşturdum ancak birçoğu 100G ve altında alana sahip veritabanlarıydı.

Data Guard kurulumlarını açıklayan inanılmaz sayıda adım adım dokümanları mevcut ve birçoğu oldukça tatmin edici düzeyde. Yalnız şunu unutmamak gerekiyor ki data guard kurulumu bir executable üzerinden olmadığı için ve senkronizasyon problemleri çıkabileceği için sadece adım adım dokümana bakıp, kuruluma kalkışmanın bedelini çok ağır ödeyebilirsiniz. Benim tavsiyem bu dokümanlardaki komutları girerken ve çalıştırırken önce mantığını kavrayın (eğer ilk defa kurulum yapıyorsanız). Örneğin fal_client fal_server parametreleri neden var? log_archive_dest_n neden tanımlanıyor? Control dosyasını fiziksel ya da mantıksal yedek için çıkarttıktan önce yedek alırsam ne olur, sonra yedek alırsam ne olur? Bu yedeği nasıl restore / recover ederim? vs vs.

Data Guard kurulumu ile ilgili çok uzun ve adım adım yapılacak şeyleri, yapılmadığ takdirde alınacak hataları açıklayan bir yazı yazmak istiyorum ancak fırsat bulamadım.

Data Guard kavramları, senkronizasyon problemleri, rol değişikliklerinde oluşabilecek problemler, failover'da neler oluyor gibi konularda bilgi almak isteyenler olursa eğer bana her zaman e-posta gönderebilirler.

İyi çalışmalar,

Ogan

2 Temmuz 2010 Cuma

waiting for snapshot control file enqueue

Selamlar,

Başlıktaki hata ile ilgili çok kısa bilgilendirmede bulunmak istiyorum;

# rman target / catalog rman_backup/backup@oracle_sid

Recovery Manager: Release 10.2.0.4.0 - Production on Fri Jul 2 10:31:15 2010

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: ABC (DBID=1921262300)
connected to recovery catalog database

RMAN> resync catalog;

-- Bu noktaya kadar herşey normal. recovery catalog veritabanına ve ana veritabanına bağlandık ve resync catalog gönderdik. Snapshot control dosyasını güncellemek isterken;

waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue
waiting for snapshot control file enqueue

-- Bu hatanın nedeni bir başka bağlantının, resync catalog komutumuz ile aynı anda resync yapmaya çalışıyor olması. Bu ve bunun gibi hataları genelde çok almayacaksınız ancak eğer bir taraftan tape'ten data guard replikasyonu ile uğraşırken, diğer yandan da resync catalog komutunu gönderirseniz bu hatayı alırsınız. Çözülmesi için diğer bağlantıyı sonlandırdık. Devam edersek;

starting full resync of recovery catalog
full resync complete

RMAN>

İyi çalışmalar,

Ogan
Takip et: @oganozdogan