4 Eylül 2009 Cuma

Datafile'ların Taşınması ve Disk Alanı Problemi

Merhaba,

Bugün yazacağım konu, Oracle'da bir fiziksel datafile'ı, başka bir dizin altına nasıl taşırız? Taşırken ne gibi şeylere dikkat etmek gerekiyor? Hangi datafile'ları taşırken veritabanını kapatmaya gerek var ya da yok?

Yapı itibariyle genelde karşılaşılan durumlardan birisi de Oracle'ın fiziksel veri dosyaları olan datafile'ların bulunduğu mount point'lerin dolmasıdır. Bu durumda ya yeni bir mount point açılır ve yeni datafile'lar buraya işlenir, ya da var olan datafile'ları başka bir alana taşırız. Bu taşıma işlemi sonrasında da %100'e ulaşmış olan mount point biraz rahat nefes almış olur.

Öncelikle şunu belirtmeliyim ki bir mount point datafile'larla dolmuş işe ve bunun içerisinde system tablespace'ine ait datafile'lar varsa, datafile'ları taşıyabilmek için mutlaka ve mutlaka veritabanını kapatmalıyız. Aynı durum sysaux ve undo tablespace için de geçerlidir. Erişimin Oracle'ın kendisi tarafından olan datafile'ları taşıyabilmenin yolu veritabanını kapatmaktır.

Bir örnek ile devam etmek gerekirse;

SQL> shutdown immediate;
# mv /db/oracle/data01/undotbs1.dbf /db/oracle/undo/undotbs1.dbf
SQL> startup mount --> mount aşamasına taşımamızın nedeni, datafile'lar alter database open komutu geldiği andan itibaren açılırlar. Bu aşamada control dosyamız okunmuş ve spfile içindeki parametrelerle veritabanı mount edilmiş olur.
SQL> alter database rename file /db/oracle/data01/undotbs1.dbf to /db/oracle/undo/undotbs1.dbf;
SQL> alter database open;

Yukarıdaki işlemden sonra sistem tablespace'imize ait datafile, başka bir alana kopyalanmış oldu.

Eğer kopyalayacağımız datafile başka bir tablespace'de ise sadece ilgili tablespace'i offline yaparak işlemimizi gerçekleştirebiliriz.

Örnek olarak;

SQL> alter tablespace USERS1 offline;
SQL> !mv /db/oracle/data01/users01.dbf /db/oracle/data12/users01.dbf
SQL> alter tablespace USERS1 rename datafile /db/oracle/data01/users01.dbf to /db/oracle/data12/users01.dbf;
SQL> alter tablespace USERS1 online;

Biraz daha garanti olsum işin derseniz eğer, mv komutu yerine cp komutu kullanarak, tablespace'i online yaptıktan sonra eski datafile'ı rahatlıkla silebilirsiniz.

Bu aşamada çok kritik bir noktadan bahsetmem gerekiyor. Bazı durumlarda Oracle, disk üzerindeki alanı bırakmaz ve fiziksel olarak datafile'ı taşısakta yerin hala %100 dolu olduğunu görebiliriz. Bu durumun sebebi işletim sistemi değildir. Çünkü dikkat ederseniz, bir datafile'ı shrink yaptığınız zaman yer açılacak ancak yukarıdaki örnekte olduğu gibi taşıdığınız zaman yer açılmayacaktır. Bunun tek sorumlusu olarak control dosyasını görebiliriz. control dosyası bu datafile'ın hala orada olduğu bilgisini tuttuğu için fiziksel olarak taşısakta ne yazık ki istediğimiz alan disk üzerinde açılmıyor. Nedenlerinden birisi ise datafile'ın bağlı olduğu tablespace'in bir takım kullanıcılar tarafından erişiliyor olması. Eğer Solaris kullanıyorsanız lsof 12 ; ile işletim sistemi seviyesinde kontrol ederseniz, farkına varacaksınız. İşletim sisteminiz HPUX, SUSE ya da Red-Hat tarzı bi linux tabanlı işletim sistemi ise program yüklemeniz gerekebilir.

Çözüm olarak veritabanını kapatıp, yeniden başlatmalıyız. Veritabanı yeniden başladığı zaman, bağlanacak yeni kullanıcılar datafile'ların yeni yerine erişebilmiş olacak. Dolayısıyla control dosyası da yenilenmiş olacak ve mount point'in disk alanını kontrol ettiğimiz zaman da açılan alanı görebileceğiz.

Biraz karmaşık olduğundan soru işaretlerinin oluştuğu yerde bana e-posta gönderebilirseniz memnuniyetle cevaplamak isterim.

İyi çalışmalar,

Ogan


2 yorum:

Ali Vural YILMAZLar dedi ki...

Ogan Bey yoğun teponuz arasında harika yazılar yazıyorsunuz tüm postlarınız için yorum yapamayıyoum bununla birlikte hepsini okuduğumu ve kafamdaki soru işaretlerini hızlı bir şekilde çözdüğünü belirtmek isterim.Teşekkürler.

Ogan Özdoğan dedi ki...

Merhaba Ali Vural Bey,

Çok memnun oldum, ben teşekkür ederim.

İyi çalışmalar.

Takip et: @oganozdogan