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

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

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