TOAD verileri göstermiyor mu?

Merhaba,

Öncelikle yazımda bahsedeceğim hataların ne olduğundan bahsedeyim. Oracle'da alınabilecek hatalar arasında;

ORA-03120: iki görevli dönüştürme yordamı: tamsayı taşması
ORA-03116: dönüştürme yordamına geçersiz arabellek uzunluğu geçirildi
ORA-03115: desteklenmeyen ağ veri türü ya da temsilcisi
ORA-03106: teklikeli iki görevli iletişim protokolu hatası

Şimdi sorabilirsiniz, yukarıdaki oracle hatalarını neden yazdın diye. Birincisi ve en önemlisi bu hatalarla karşılaştığınız zaman google ya da metalink size çok fazla cevap veremeyecektir. Veremeyecektir çünkü aynı hataları ben de aldım ve Oracle'a SR açmama rağmen sonuca gidemediler.

Hataların anlamlarına baktığımız zaman bize çok fazla birşey ifade etmiyor. Bu hataları aldığınız zaman da hiçbir trace dosyası ya da alert.log'da herhangi sıradışı birşey görmüyor olacaksınız. Hatta ve hatta, listener.log, sqlnet.log vs. baktığınız zaman da herşey doğal görünecek. Ama siz TOAD veya 3ncü parti bir yazılımda verilerinizi göremek istediğinizde bu hataları alıyor olacaksınız. Evet, çıldırmamak elde değil, örneğin TOAD'da data kısmına tıklarsınız, bekler, bekler, bekler ve sonunda bu dört hatadan birisini yapıştırır. İşin kötü yanı, belli bir denemeden sonra da Oracle sizin bağlantınızı zorla düşürür ve tekrar bağlanmanız gerekir. Bu böyle sürer durur. Oracle'a SR açarsınız, sizden binlerce trace dosyası isterler, onu yap, bunu dene, olmadı mı? o zaman şunu da deneyelim derler. Ayrıca bu hatayı da sqlplus ile bağlandığınız zaman ve grafiksel bir arayüz kullanmadığınız zaman almayacaksınız da. Ne zaman grafiksel bir arayüz ile veri çekmek isterseniz ya da grafiksel arayüzünüz veritabanına bağlanmaya çalışırsa, bu hatalar gelebilir. Bu, sorunun 3ncü parti yazılımlarda olmadığını da gösteriyor denebilir.

Benim karşılaşdığım durum için, cevabı söylüyorum: VPN! Evet, VPN bağlantısı. VPN versiyon yükseltmesi olmadan önce çok güzel çalışan TOAD'ımız, versiyon yükseltmesinin ardından bu hataları vermeye başladı. İlk başta heryere baktık, herşeyi yaptık ancak sonuç alamayınca başka yerlere yöneldik. Sonuçta hatayı aldığımız zaman ile VPN'in versiyonunun yükseltildiği zaman aynı çıktı! Bağlantı methodumuzu "SSL VPN" ile web üzerinden bağlanacak şekilde değiştirdiğimiz zamansa problem kalmadı!

Benim bu hatalarla karşılaştığım yegane durum VPN ile ilgili olduğu için umarım bu sorun ile karşılaşıyorsanız, sizin de probleminiz VPN olur. Versiyon yükseltmesi yapıldıktan sonra hiçbir VPN parametresi veya kuralı değiştirilmeli, değiştirilecekse de mutlaka Oracle veritabanı yöneticisine bildirilmelidir. VPN dışında bu sorun ile karşılaşan ve hala aynı sorunu yaşanlar olabilir, onlara da benimle irtibata geçmeleri konusunda ricada bulunmak istiyorum.

Bu hataları google ya da metalink'te arattığınız zaman çıkan sonuçların genelinde bir cevap yok ya da Oracle desteği ile irtibata geçin cevabı var. Bu yazıyı okuyan ve aynı sorunlara sahip olan insanlar varsa, lütfen Oracle'a SR falan açmadan önce bağlantı ayarlarını kontrol ediniz, VPN ayalarına, kurallarına ve parametrelerine bakınız.

Bu konu ile ilgili çok fazla Türkçe forum ya da cevap olmadığı ve Türkiye'de başka insanlarında mustarip olduğunu bildiğim için yazı yazdım. Daha detaylı soru sormak ya da danışmak isterseniz; oganozdogan@gmail.com adresine mail atabilirsiniz.

İyi çalışmalar,

Ogan

Oracle Görevleri Sonlanıyor!..

Merhaba,

Oracle'da pek sık rastlanmasa da birgün başımıza gelme olasılığı yüksek ancak geldiği zaman da son derece can sıkıcı olabilen bir hatadır Oracle görevlerinin zamanla sonlanması.

Örneğin 10gR2 veritabanımız var ve job_queue_process parametremiz de 50 olarak tanımlanmış. Bir takım görevler yaratıyoruz ve bu görevler rutin olarak her gece, her saat ve hatta her dakika çalışıyor. Ancak birgün bakıyorsunuz ki, tanımladığınız görevler 2 gündür çalışmıyor! Elle çalıştırıyorsunuz, o zaman çalışıyor ama otomatik olarak tetiklenmiyor. Hemen dönüp unix sisteme "ps -ef grep ora" yazıyorsunuz ve karşınıza hiç "ora_j001" ya da "ora_j***" tipinde çıktılar gelmiyor. Bütün arka planda çalışan görevleriniz şu anda ölmüş durumda! Şunu da belirtmeliyim ki bu sorun 9i ve 10g'de ortaya çıkmaktadır ve herhangi bir OS platformunda gerçekleşebilir.

Yapılabilecek çözümleri sıralıyorum;

1) Veritabanınız restricted modda olabilir mi?
select instance_name, logins from v$instance;
eğer logins=restricted ise:
alter system disable restricted session;

2) job_queue_processes > 0 mı?
show parameter job_queue_processes;
job_queue_processes parametresi 0 ise hiçbir görev çalışmayacaktır.

3) _system_trig_enable=false durumda mı?
select a.ksppinm parameter,b.ksppstvl value from x$ksppi a,x$ksppcv bwhere a.indx=b.indx and ksppinm='_system_trig_enabled';
eğer bu değer "false" ise:
alter system set "_system_trig_enable"=TRUE scope=both;

4) Görev kullanım dışı olmuş olabilir mi?
select job, broken, from dba_jobs where job=;
eğer kullanım dışı kalmış ise, alert log dosyasını ve trace dosyalarını incelemenizde fayda olacaktır.

5) Görev commit edilmiş mi?
Yarattığınız görevin script'inin içinde commit; aşaması yoksa, eklemeniz gerekebilir.

6) UPTIME > 497 ?
eğer OS uptime parametresi 497'den büyükse bu bir bug olabilir.(Metalink unpublished bug: 3427424)

7) DBA_JOBS_RUNNING
select * from dba_jobs_running;
görevin koşup, koşmadığına bakabilirsiniz.

8) LAST_DATE ve NEXT_DATE
select Job,Next_date,Last_date from dba_jobs where job=;
last_date ve next_date değerleri anlamsız olabilir.

9) NEXT_DATE ve INTERVAL
select Job,Interval,Next_date,Last_date from dba_jobs where job=;
Bu değerin de doğru olup olmadığını incelemek gerekiyor.

10) JOB_QUEUE_PROCESSES
En mantıklı ancak geçici sonuç olarak:
alter system set job_queue_processes = 0 scope=both;
alter system set job_queue_processes = 10 scope=both;
yaparsak eğer, bütün görevler baştan ve otomatik olarak başlayacaktır. Bu işleme CJQ işleminin yeniden başlatılması da denebilir.

11) DBMS_IJOB
Veritabanını yeniden başlatabilir ya da:
exec dbms_ijob.set_enabled(true); yapabilirsiniz.

Bu arada yukarıda sıralanmış bilgiler metalink'te 313102.1 döküman id'si aratılarak İngilizce olarak bulunabilir.

Bu durumda da hala otomatik olarak çalışmıyorsa -ki 10nuncu maddeden sonra çalışması gerekiyor- mutlaka ve mutlaka SR (Service Request) açmanız gerekiyor. SR aşamasında oluşan trace dosyaları ve alert dosyasını da isteyebilirler, muhafaza edilmesi çok önemli.

İyi akşamlar,

Ogan

ORA-12549 Çözümü Mevcut!

Merhabalar,

Çok sıklıkla gerçekleşmese de, kısmen büyük çaptaki veritabanların başına gelebilen bir hatadır ORA-12549 hatası.

Veritabanına bağlanmak istediğiniz zaman ise şu şekilde hatalar alabilirsiniz;

ORA-12549: TNS: operating system resource quota exceeded

TNS-12518: TNS:listener could not hand off client connection

Ve veritabanına bağlanmanız reddedilir. İlk bakışta sıradan bir Oracle hatası ya da TNS hatası gibi gözüksede aslında bu bir İşletim sistemi kernel parametresi hatasından kaynaklanmaktadır.

Unix tabanlı işletim sistemlerinde bildiğiniz üzere belirli bir dökümantasyona göre Oracle kurulumları gerçekleştirilir, gerçekleştirilmesi tavsiye edilir. Gerçekleştirilmediği durumlarda ise, bir takım eksikliklerle Oracle veritabanı kurulacaktır ve ileride bir zaman karşınıza hata çıkma ihtimali olacaktır. Bu tarz işletim sistemlerinde kernel parametreleri vardır ve bağlı olan kullanıcılar ile ilgili işletim sistemi bazında bilgiler ve tanımlamaları içerir. Bu tanımlamalar belirli sayılarla temsil edilebilir.

Kernel parametrelerinin arasında "maxuproc" isimli bir parametre vardır. Default olarak 256 olarak belirlenir. Bu parametre her bir kullanıcı için azami işlem sayısını belirler. Oracle işletim sisteminden işlem tüketmek istediği zaman bu sayı sürekli artar ve 256'ya dayandığı zaman sisteme bağlantı dahil, veritabanı girişleri de sonlanabilir. Oracle'ın kurulum dökümantasyonlarında bu kernel parametrelerinin tavsiye edilen sayılarını görebilmek mevcut.

Bu parametreyi değiştirebilmek için root kullanıcısı ile bağlanmak şart. root ile bağlandıktan sonra "sam" yazarak parametremizi ayarlayacağımız Unix programına giriyoruz. Ardından "k" tuşuna basarak kernel parametrelerinin ayarlanması işlemine başlıyoruz. "Tunables" başlığının altında bir dizi parametre göreceksiniz. Burada "maxuproc" parametresini görebilirsiniz. Ayarlama olaraksa "(nproc*9)/10" yazarsanız, toplam nproc (işlem sayısı) sayısının %90'ını alabilir kullanıcılar demiş olursunuz. Bu sayede Oracle kullanıcınız daha fazla işlem tüketebilecek ve işlem sınırlamasından dolayı veritabanınız geçici süre kullanım dışı kalmayacaktır.

Unix/Linux işletim sistemlerine kurulum yaparken eğer kernel parametrelerinin kontrolünü atlarsanız kurulum aşamasında sorunlarla karşılaşmayabilirsiniz ancak ileride oluşabilecek sorunları da kabul etmiş olursunuz. Proaktif bir veritabanı yöneticisi olmak istiyorsanız ve sonradan başınızın ağrımasını istemiyorsanız unix tabanlı işletim sistemlerine Oracle veritabanı kurulumu yaparken mutlaka, mutlaka kernel parametrelerini kontrol edin!

maxuproc ile ilgili olarak google'da bir takım kısa çözümler mevcut. Örneğin;

Action: Acquire more operating system resource, or perform a different function.

Çok kısa ve anlaşılmayan bir çözüm değil mi? Daha fazla işletim sistemi kaynağı ayırmak ya da başka bir fonksiyon uygulamak ne demektir? Yukarıda yazdıklarımın çok fazla özeti olarak düşünüyorum ve maxuproc'u değiştirin diyorum :)

İyi akşamlar,

Ogan