ORA-10631: SHRINK clause should not be specified for this object

Selamlar,

Başlıktan da anlaşılabileceği üzere ORA-10631 hatası üzerine çok kısa yorum yazacağım. 2005 yılında 9i ile tanıştığım zamandan bu yana bu hata ile karşılaşmamıştım. Halbuki çok fazla sayıda shrink komutu koşmuşluğum var.

Geçtiğimiz günlerde Oracle Forumlarını okurken bir okurun sorusuna shrink komutunun kullanması gerektiğini söylerek cevap vermiştim. Ancak başlıktaki hatayı aldığını söyledi ve çok ilginç bir neden çıktı arkasından...

Kullanıcı, tabloyu yaratırken FUNCTION BASED INDEX yaratmış. Function based index'in yapısından dolayı shrink space ya da shrink space compact komutları çalışmıyor ancak tablo üzerinde enable row movement komutu koşturulabiliyor! Bu durumda yapılabilecek en mantıklı çözüm yolu da indeksi kaldırıp yeniden yaratmak. Yeniden yaratmadan önce de High Water Mark'ı sıfırlayabilmek için shrink space komutunu göndermek. Bu noktada eklemem gerekiyor ki eğer tablodaki HWM sıfırlandıktan sonra tahsis ettiği alanları da boşaltmak isterseniz shrink space compact göndermeniz gerekiyor. Yalnız unutmamak gerekiyor ki compact ile birlikte tablo kilitlenecek, erişileyemecek ve clustering factor artacaktır. Aynı zamanda rowid üzerinde oluşturulmuş trigger'lar da geçersiz kılınacaktır.

Yukarıda sözü geçen sorguları aşağıda bulabilirsiniz;

alter table enable row movement;
alter table disable row movement;
alter table shrink space;
alter table shrink space compact;

Deallocate Edilemeyen Datafile

Merhaba,

Unix tabanlı işletim sistemlerinde karşılaşılabilecek bir ufak hata ile ilgili çözüm sunmak istiyorum.

Oracle veritabanınızda bir datafile'ın fiziksel olarak yerini değiştirmek istiyorsunuz ve yapmanız gerekenleri de biliyorsunuz ya da bilmiyorsunuz. Ben aşağıda bu listeyi tekrar hatırlatmak istiyorum;

İlk önce veritabanının fiziksel parçası olan datafile'ın bulunduğu tablespace'i buluyorsunuz;

SQL> select a.name tablespace, b.file#, b.name datafile
from v$tablespace a, v$datafile b
where a.ts#=b.ts#
and b.name = '/usr/db/data01.dbf';

Karşınızdaki listede yerini değiştirmek istediğiniz datafile'ın hangi tablespace'de olduğunu gördünüz. Şimdi ise önce tablespace'i offline konumuna getirerek, datafile'ın fiziksel olarak taşınması işlemine başlayabilirsiniz;

SQL> alter tablespace TS_1 offline normal;

Bu aşamada fiziksel olarak datafile'ın taşınmasını gerçekleştirebilirsiz (unix'te mv yerine cp komutunu koşmanız daha yararlı olacaktır;

# cp /usr/db/data01.dbf /usr/db_1/data01.dbf

Ardından datafile'ın adının değiştiğini Oracle'a iletmemiz gerekiyor;

SQL> alter datafile '/usr/db/data01.dbf' rename '/usr/db_1/data01.dbf';

Son olarak tablespace'i online durumuna getiriyoruz;

SQL> alter tablespace TS_1 online;

Bu aşamalardan geçtiğimiz zaman Oracle artık bu datafile'ın fiziksel olarak yerinin değiştiğini biliyor. Peki unix tarafındaki durum nedir?

Bir datafile'ı kullanmakta olan bir kullanıcı ya da bir background process'i varsa eğer bu datafile fiziksel olarak taşınsa bile kullandığı alanı unix bırakmayacaktır. Sizin cp ya da mv komutu ile taşıdığınız datafile aslında o datafile'ın inode girişi olacaktır. inode taşınmış olacak ve yeni yeri hem unix hem de oracle tarafından biliniyor olacak ancak eski işlemlerin üzerinde işlem yapıyor olmasından dolayı bu datafile'ın kapladığı alanın hala bırakılmadığını göreceksiniz. Bu duruma bir açıklık getirebilmek için kullanabileceğiniz unix programının adı "lsof", yani list of files.

Root kullanıcısı ile aşağıdaki komutu koşalım;

# lsof grep "/usr/db/data01.dbf"

lsof yazılımı bize bu datafile üzerinde hangi session'ın işlem gerçekleştirdiğini gösterecektir. Eğer bir ya da birden çok satır dönüyorsa, bu datafile'ın alanının bırakılmadığını farkedeceksiniz. Eğer hiçbir satır dönmüyorsa da datafile'ın hem fiziksel olarak taşınması gerçekleştirilmiş olacak hem de kullanmakta olduğu alan bilgisi güncellenmiş.

shutdown komutunu gönderirseniz eğer bütün bağlı kullanıcıların ve arkaplan görevlerinin çalışmaları durdurulacağından dolayı unix datafile'ın kapladığı alan bilgisini güncelleyebilecektir çünkü artık bu datafile için işlem sırasında olan ya da işlem yapan bir kullanıcı olmayacaktır.

İyi çalışmalar dilerim,

Ogan

ORA-01476: divisor is equal to zero

Selamlar,

Başlıktan da anlaşıldığı üzere ORA-01476 hatası ile ilgili çok kısa bilgilendirme yazısı yazıyor olacağım.

Divisor is equal to zero hatasının nedenini biliyoruz aslında ve DIV gibi fonksiyonlar kullanıldığı zaman bu hatanın kaybolacağını da. Ancak bu hatayı dbms_stats paketini kullanırken aldığınız zaman durum biraz daha farklı oluyor. Bu hata ile dbms_stats paketini kullanırken ve şema istatistikleri toplamak istediğiniz zaman karşılaşma ihtimaliniz var. 9i ve 10g'de ortayan çıkan bir bug'dan kaynaklandığını eklemem gerekiyor.

Kısaca hatanın oluşum örneğini göstermem gerekirse;

SQL> exec dbms_stats.gather_schema_stats('HR', cascade => TRUE);
BEGIN dbms_stats.gather_schema_stats('HR', cascade => TRUE); END;

*
ERROR at line 1:
ORA-01476: divisor is equal to zero
ORA-06512: at "SYS.DBMS_STATS", line 13591
ORA-06512: at "SYS.DBMS_STATS", line 13937
ORA-06512: at "SYS.DBMS_STATS", line 14015
ORA-06512: at "SYS.DBMS_STATS", line 13974
ORA-06512: at line 1

Çözümü için metalink'te bir döküman mevcut ve ID'si: 464440.1

Kısaca, önerdikleri çözüm ise;

sql> connect / as sysdba
sql> alter system set events '38041 trace name context forever, level 16';

İyi çalışmalar,

Ogan