19 Kasım 2009 Perşembe
SHUTDOWN: waiting for active calls to complete.
Veritabanınızda "wait event"lerin fazlalığı gözünüze çarptı ve veritabanınızı kontrol ettiniz. Yaptığınız kontroller sonucunda bu durumun neden kaynaklandığı bulamadınız.
v$lock tablosunu incelemenizi tavsiye ederim. Bu tabloda göreceğini kilitlerin wait event'lere yol açma olasılığı yüksek. Wait event'ler arasında göreceğiniz bir diğer bilgi ise "library cache lock" olacaktır. Görebileceğiniz bir başka hata ise çok kayıtlı bir tabloya erişiminizin sıfırlanmış olması. Erişmek istediğiniz her session asılı kalacak ancak bu arada veritabanınızdaki her işlem akıcı bir şekilde devam edecek.
Yukarıda özetlemeye çalıştığım durumun kaynağı DBWR'ın (Database Writer - Arkaplan işlemi) MR, yani Media Recovery'de bir şekilde takılmış olması. Herşeyi denersiniz, örneğin alter system checkpoint, alter system switch logfile, gibi ama hiçbir sonuç alamazsınız. Kısacası veritabanınızın shared pool'u ve hit ratio'ları fakr-u zaruret içinde harap ve bitap düşmüş olabilir :)
Önerilen çıkıl yolunun veritabanını shutdown immediate ile kapatmak olduğunu görebilirsiniz. Shutdown immediate komutunu verirsiniz ve aşağıdaki hatayı alırsınız ve ardından shutdown komutunuzun asılı kaldığını anlarsınız;
Active call for process 10061 user 'oracle' program 'oracle@optprod (J001)'
SHUTDOWN: waiting for active calls to complete.
Yukarıdaki hataları aldıysanız veritabanınızı sağlıklı bir biçimde kapatamazsınız. Yapmanız gereken aşamaları aşağıda listeliyorum;
Öncelikle asılı kalan işlemi sonlandıralım;
# kill -9 10061
Şimdi de veritabanını yeniden ayağa kaldıralım;
# sqlplus / as sysdba
Connected.
SQL> shutdown abort
Oracle instance shutdown.
SQL> startup restrict
Oracle instance started
Database mounted
Database opened
SQL> shutdown normal
Database unmounted
Database closed
Oracle instance shutdown
SQL> startup
Oracle instance started
Database mounted
Database opened
Yukarıdaki işlemleri tamamladığınız zaman bir süre tekrar wait event'leri gözlemleyin. Erişemediğiniz tablo varsa tekrar erişmeye çalışın. Probleminiz büyük ihtimal düzelmiş olacaktır.
Aslında hiçbir zaman "veritabanını kapatın düzelir" gibi bir yorum yapmak istemiyorum ancak bu işin acil olarak çözülmesi ve sistemin devamlılığını sağlam bir şekilde sağlamak için gerekli olacaktır. Benim bilgidiğim en sağlam düzeltme yolu da budur.
İyi çalışmalar,
Ogan
26 Ekim 2009 Pazartesi
ORA-00600: internal error code, arguments: [13013], [5001], ...
Bir diğer Oracle içsel hata kodunu açıklamak istiyorum. Bu hata kodu herhangi bir platform üzerinde oluşabilir ve Oracle 10.2.0.4 "Enterprise" versiyonu için geçerlidir. Bu hatanın sebebi geçersiz konumda bulunan bir indeks olabilir. Başlık ile ilgili eklemek isterim ki İngilizce ve tam kod ile girmemin sebebi arama motorlarında aratılırken daha rahat bulunması ve akabindeki bilginin Türkçe sağlanabilmesi.
Hatanın tam olarak örneğini vermem gerekirse;
ORA-00600: internal error code, arguments: [13013], [5001], [10513], [41961615], [137], [41961615], [17], []
Bu hata kodunun açıklaması ise;
ORA-00600: internal error code, arguments: [13013], [A], [B], [C], [D], [E], [F], []
[A] Argümanı: "Passcount"
[B] Argümanı: Veri Obje Numarası
[C] Argümanı: Güncellenecek satırı içeren DBA blok tablosu (tablespace)
[D] Argümanı: Satır Yuva Numarası
[E] Argümanı: Güncellenmekte olan DBA bloğu (genelde [C] ile aynı oluyor)
[F] Argümanı: Kod
İkinci argüman veri obje kimliği ile ilgili bilgi vermektedir. Bu bilgi ile sorunun kaynağına inilebilir ve hangi objenin 600 hatasına sebep olduğu bulunabilir.
SQL> select object_name, object_type, owner from dba_objects where data_object_id=<[B] Argümanında Raporlanan Sayı>;
OBJECT_NAME OBJECT_TYPE OWNER
ALARM_DEFINITION_ELEMENT TABLE AIRCOM
Yukarıdaki sorgudan probleme sebep olan objenin bir tablo olduğunu algılayabilirsiniz.
Problemin bir tablodan kaynaklandığını gördüğüme göre bu durumu çözebilmek için analiz işlemi yapabiliriz. Ancak 10g ile birlikte desteklenmeyen "analyze table" komutu yerine DBMS_STATS paketini kullanalım;
SQL >EXEC DBMS_STATS.GATHER_TABLE_STATS ('AIRCOM','ALARM_DEFINITION_ELEMENT');
PL/SQL procedure successfully completed.
Çok kritik bir hata sayılmasa da aynı hata kodu ile dönen bir veritabanı blok ya da indeks hatası da alabilirsiniz. Bu durumda indeksi düşürüp yeniden yaratmayı ya da yeniden oluşturmayı deneyebilirsiniz ya da ortada bir blok hatası varsa mutlaka "dbverify" özelliği kullanılmalıdır. dbverify ile bir "datafile"ın sağlamlığını kontrol edebilirsiniz.
Kaynak: Metalink Döküman Numarası: 816784.1
İyi çalışmalar,
Ogan
6 Ekim 2009 Salı
ORA-07445 "CORE DUMP"
Merhaba,
Bir Oracle hata kodu olan ORA-07445 çok fazla karşılaşılmayan bir işletim sistemi hatasıdır ve Oracle'ın alert.log dosyasında yazdırılır.
Hatanın çıktısı aşağıdaki şekilde olabilir;
Errors in file /opt/oracle/product/10.2.0/db_1/admin/opttest/bdump/opttest_ora_28677.trc:
ORA-07445: exception encountered: core dump [$cold_evacpy()+1328] [SIGILL] [Register NAT consumption] [0x40000000038FBC40] [] []
Bildiğimiz üzere core dump'ın sağındaki argümanlar, Oracle destek mühendislerinin probleme daha hızlı ulaşabilmeleri içindir. Eğer sistemde yukarıdaki hata oluşmuş ise mutlaka ve mutlaka Oracle Metalink'te servis talebi açılması gerekmektedir. Oracle destek mühendisleri önermedikçe bu durumu düzeltmek için Oracle'ın internal parametrelerini değiştirmemelisiniz!
Bu hata bir çeşit exception olduğu için SR açmanız gerekmektedir. Genel bir hata değildir.
Ogan