23 Kasım 2009 Pazartesi

WARNING: inbound connection timed out (ORA-3136)

Merhaba,

ORA-03136 hatasına alert.log dosyasında başlıktaki gibi görebilirsiniz.

WARNING: inbound connection timed out (ORA-3136)

Bu hatanın alınmasındaki sebep, veritabanına bağlanmak isteyen bir kullanıcının kendisine tanımlanmış olan sürede, firewall, bağlantı problemleri gibi sebeplerden ötürü bağlanamamış olması.

Çözüm için listener'da bir parametreyi değiştmemiz ve bir dosya içerisine parametre eklememiz gerekebilir.

vals1:/home/oracle#lsnrctl
LSNRCTL for HPUX: Version 10.2.0.4.0 - Production on 23-NOV-2009 11:38:17
Copyright (c) 1991, 2007, Oracle. All rights reserved.
Welcome to LSNRCTL, type "help" for information.

LSNRCTL> set help
The following operations are available after set An asterisk (*) denotes a modifier or extended command: password rawmode displaymode trc_file trc_directory trc_level log_file log_directory log_status current_listener inbound_connect_timeout startup_waittime save_config_on_stop dynamic_registration

LSNRCTL> show inbound_connect_timeout
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
LISTENER parameter "inbound_connect_timeout" set to 60
The command completed successfully

LSNRCTL> set inbound_connect_timeout 0
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
LISTENER parameter "inbound_connect_timeout" set to 0
The command completed successfully

inbound_connect_timeout'un ilk değeri 60 saniyedir. Bu değeri sıfır yaparsak limitsiz olacağını belirtmiş oluyoruz.

Ardından $ORACLE_HOME/network/admin dizini içerisinde bulunan sqlnet.ora dosyasının içerisine aşağıdaki satırı ekliyoruz;

SQLNET.INBOUND_CONNECT_TIMEOUT 0

Bu işlemleri tamamladıktan sonra, bir süre daha alert.log günlük dosyasını incelemeye devam edin, problemin ortadan kalktığını göreceksiniz.

İyi çalışmalar,

Ogan

19 Kasım 2009 Perşembe

Gözükmeyen ve Silinemeyen RMAN Yedekleri !

Merhaba,

RMAN (Recovery Manager) kullanıyorsunuz ve aldığınız yedekleri göremiyorsunuz. Hatta delete obsolete komutu ile eskileri silmek istiyorsunuz ve onları da silemiyorsunuz. Ancak tanımladığınız retention süresi de örneğin 2 gün. Peki sizde neler duruyor, 2 günden yaşlı yedekler!

Eminim ki hazırladığınız bir script var ve bu script 2 günden eski yedekleri silmeye yarıyor.


İlk önce report obsolete çalıştırırsınız ve sonra delete noprompt obsolete. Sonuç? Silinmemiş yedekler, mezarlığa dönüşmüş! Korkmayın, çözümü aslında çok karmaşık değil.


Delete obsolete; komutunda çıkmayan ancak fiziksel olarak disk ya da tape üzerinde durduğu bilinen bir backupset'i öncelikle crosscheck ederek, Oracle'ın onu görüp görmediğini kontrol edebiliyoruz.

Örneğin; crosscheck backupset;

Ardından gördüğümüz backupset'in expired ya da available olup olmadığını kontrol ediyoruz.
Expired olan backupset varsa onları da aşağıdaki komut ile silebiliyoruz;


Delete noprompt expired backupset;

Eğer tape'e değil, disk'e backup alınıyorsa ve bir katalog işlemesi söz konusu ise, kanalı tahsis etmek gerekebilir. Bunun için de;

allocate channel for maintenance device type disk; --> Sistem üzerinde RAC kurulu ise her node için ayrı ayrı tahsis işlemi yapılmalıdır;

allocate channel for maintenance device type disk connect 'sys/password@ORACLE_SID_1';
allocate channel for maintenance device type disk connect
'sys/password@ORACLE_SID_2';

Yukarıdaki komutları da bir script içine ekleyerek aşağıdaki şekilde, crontab içerisinde çalıştırabilirsiniz çalıştırabilirsiniz;

export ORACLE_HOME=/oracle/product/10.2.0/db_1/ ; /oracle/product/10.2.0/db_1/bin/rman cmdfile /db/optima/archive/OPTPROD/RMAN/delete_obsolete.sh log /db/optima/archive/OPTPROD/RMAN/delete_obsolete.log

delete_obsolete.sh script'inin içerisinde yukarı yazdığım komutlar olacak. export ile Oracle_Home'u işaretlememizin sebebi crontab'ın .profile'ı okumamış olmasına karşı. log dosyası da oluşan işlemlerin takibini yapmak için. Şu andan itibaren, RMAN'a retention policy ne tanımlanmış ise onlar silinecektir.

İyi çalışmalar,

Ogan

SHUTDOWN: waiting for active calls to complete.

Merhaba,

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
Takip et: @oganozdogan