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

ORA 600 Nedir? / kksfbc-reparse-infinite-loop

Merhaba,



Birçoğunuz hiç karşılaşmamış olmanıza rağmen aslında hepimizin yakından takip ettiği ve bildiği ORA-00600 hataları kimi zaman veritabanı yöneticilerinin gerçek anlamda canını sıkmaktadır. Bir 600 hatası aldığınız zaman ilk ve mutlaka yapmanız gereken çözüm, metalink'i kontrol etmektir. Metalink üzerinde ORA-600 ve ORA-07445 ayrıcalıklı hataları için bir araç bulunmakta ve bu araca ilk argümanları girdiğinizde size yapılması gerekenleri özetleyen bir sonuç listesi vermekte. Onun için ORA 600 ve ORA 7445 hatalarını kendiniz düzeltmek için çok fazla vaktinizi harcamayın. Ayrıca üzerinizdeki baskı gittikçe artacağı için google'a hiç bulaşmamanızı tavsiye ederim zira bu yazıyı aslında google'da arama yaparak buldunuz, öyle değil mi? :). Bu hata, sıradan bir hata olmadığı için google size cevap veremeyecektir çünkü bu hatanın genel çözümü sadece metalink içerisindedir. Metalink içerisindeki bir bilgiyi de dışarıya çıkartmak veya başka bir site altında göstermek, kopyalamak kesinlikle yasaktır. Dolayısıyla önce metalink, eğer çözüm bulamadıysanız mecbur bir SR (Service Request) açacaksınız ve Oracle'dan cevap bekleyeceksiniz.


ORA-600 veya ORA-07445 hatalarının kaynağı kimi zaman bir bug veya içsel bir ayrıcalıklı hatadan kaynaklanmayabiliyor. Sizin geliştirdiğiniz bir uygulama veya yanlışlıkla ayarladığınız bir parametre yüzünden de bu hataları almanız mümkün. Benim size tavsiyem en kısa zamanda eğer yoksa bir metalink hesabı edinmeniz ve buradan gerekli kontrolleri yapmanız. Unutmayın, teknik olarak bu hatalar sizin çözebileceğiniz türde hatalar değildir. Çözüme kendiniz ulaştıysanız eğer yine sizden kaynaklanan bir hatadan olduğunu da eklemem gerekiyor. Tabii bunun bir bug olduğunu varsayarsak yapabileceğiniz hiçbir şey yok demektir.



Geçtiğimiz günlerde ben de bir ORA-00600 hatası ile uğraştım ve gerçekten zor anlar yaşadım. Zor anlar yaşamamın sebebi aslında yöneticiliğini yaptığım veritabanının banka veritabanı olmasından değil, birazcık sorumluluk sahibi olduğumdan diyebiliriz. Bütün bir gün boyunca veritabanının çalışmamış olması, otomatik olarak bağlanan client'larımızın çalıştığı hpux makineyi biraz daha yormasına sebep olmaktan başka bir işe yaramayacaktı. Evet, biraz stresimi azaltan bir durumdu :) Asıl beni germiş olan durum ise, test veritabanında olduğumuz ve ne yazık ki veritabanının hiçbir yedeğinin veya dump'ının olmaması. Hatta ve hatta veritabanı archivelog'da bile değildi :) Nasıl diyelim, kötü ve mutlak mağlubiyetle sonlanacak bir futbol maçı gibi. Sonradan yer sağlandı ve veritabanının archivelog'a geçirip, RMAN ile yedeğini alır hale geldik neyse ki.



Konumuza dönersek eğer, aldığım hata şöyleydi;

ORA-00600: internal error code, arguments: [kksfbc-reparse-infinite-loop],[ ],[ ],[ ],[ ],[ ]



Burada dikkat etmeniz gereken ilk şey, gelen ilk argümandır. Bu argüman, aslında hatanın nerede olduğunu ve doğal olarakta nasıl çözüleceğini anlatmaktadır. Sonrasında gelen argümanlar ise, problemi daha da detaylandırmakta kullanılmaktadır. Yukarıda bahsettiğim gibi, kalın olarak belirtilen ilk argümanı bu "ORA-600 diagnostic tool"a girdiğinizde sonuçlar dökülecektir.

kksfbc-reparse-infinite-loop argümanı ile ne zaman karşılaşırsınız? Bu argüman çıktığı zaman ne yapmalısınız? Ben size burada yazacağım ve metalink ile uğraşma zahmetinden kurtaracağım.



Bu hatayı aldığınız zaman başınıza gelen şey aslında şudur; Veritabanındaki önemli şemalarda, örneğin SYS, SYSTEM, DBSNMP gibi INVALID objeler, yani hatalı, bozuk veya çalışmayan objeler olduğu anlamına gelmektedir. Paniğe gerek yok, bunu toparlamak için Oracle bize bir sql vermiştir ve bu sql damarlarındaki asil kanda mevcuttur :) $ORACLE_HOME/rdbms/admin folder'ının altında UTLRP.SQL isimli bir script bulunmaktadır. Bu script veritabanınızdaki bütün invalid objeleri valid hale getirmeye yaramaktadır. Şu şekilde çalıştırabilirsiniz;



@$ORACLE_HOME/rdbms/admin/utlrp.sql



Çalıştırdıktan sonra karşınıza 4 tane sql sorgusu ve neye yaradıklarını anlatan bir çıktı gelecektir. Başka bir terminal ile bağlanıp, bu sorguları takip edebilir ve scriptininiz ne kadar başarılı olduğunu görebilirsiniz. 2-3 defa çalıştırdığınız takdirde de hiçbir invalid obje kalmayacaktır. Yani bir defa çalıştırıp ohh kurtuldum diyerek rahatlamayın :)



Bu script'in en büyük ve tehlikeli impact'i kesinlikle şudur; sonuç olarak bu bir PL/SQL scripti'dir ve belirli paketler sayesinde çalışmaktadır. Eğer SYS şemanızdaki DBMS_UTILITY paketi invalid olduysa, bu scriptte çalışmayacaktır. Yine paniğe gerek yok, kurtarabilmenin bir yolu daha var. Ancak bu durumu düştüğünüzde kullanabilirsiniz.



$ORACLE_HOME/rdbms/admin folder'ının altında CATUPRGD.SQL isimli bir script var ve bu script yeni bir sürüm için katalog yükseltmesi yapmaktadır. Oracle tarafından internal olarak çağırılır. Kullanımı silent, yani responsefile ile grafik olmadan yapılan kurulumlardan sonra bir upgrade yapılmışsa, veritabanının kataloğunu da o sürüme yükseltmek içindir. Bu scripti çalıştırdıktan sonra sizden utlrp'yi çalıştırmanızı isteyecektir. Çünkü katalog yükseltmesi sırasında da invalid objeler oluşabilir.



Bütün bu yapılanlardan sonra hiçbir şemanızda invalid obje bulunmayacaktır ve veritabanını abort dışında bir yöntem ile kapatın ve temiz olarak açın. Probleminiz gitmiş olacaktır. Birgün boyunca alert_oraclesid.log dosyasını incelemeye (tail -f) devam ederseniz faydalı olacaktır.



İyi çalışmalar,



Ogan

Fixed-Line Performance Management

Merhaba,

Oracle dışında kalan bir konu olacak fakat ucu biraz Oracle'a dokunan bir konu :)

Fixed veya Wire Line operatörler, hatlarındaki performans değerlerini takip etmek ve günlük ve anlık raporlar alabilmek için bir takım yazılımlar kullanırlar. Bu yazılımlardan bir kaçı; Aircom OPTIMA, Ericsson ENIQ, Inforvista INFOVISTA gibi. Bu yazılımların da kendilerinin tercih ettiği ve verilerin tutulduğu veritabanları vardır. Ericsson ENIQ (Ericsson Network IQ) Sybase veritabanı kullanır ve bunun dışında kalan firmalar tercihlerini Oracle'dan yana kullanmaktadırlar.

Performans yönetimi olarak kullanmakta olduğum yazılım Aircom -bir İngiliz firması- firmasının OPTIMA ürünüdür. Optima ile neler yapılabilir?

Optima, back-end ve front-end olmak üzere iki ayrı arayüzden oluşur. Back-end arayüzünde programın arka tarafında çalışacak ve veritabanını güncelleyecek konfigürasyonlar yapılır.

Veritabanına bir arayüz yüklemek istiyorsak önce o arayüze ait bir "interface workbook" oluşturmamız gerekmektedir. Bu bir excel sheet'tir ve içerisinde operatörün istediği bir arayüzden gelen verinin, veritabanına nasıl yükleneceğini barındırır. Bu arayüzü aktive edersekte (Optima OIT Tool aracılığı ile) veritabanına yazılabilmesi için "validator" ve "loader" script'lerini oluşturur.

Optima'da veriyi ftp, snmp, xml gibi yöntemlerle, santral'in, sdh cihazının ya da kiralık hatların bağlı olduğu ve yönetildiği EMS'lerden (Element Management System) çekeriz. Çekilen bu veri arından bize anlamlı bir hale getirip, veritabanına düzenli bir şekilde yazılabilmesi için .CSV uzantılı dosyaya, bir parser aracılığı ile çevrilir.

Bu konfigürasyonların ve scriptlerin aşamaları ise şu şekildedir;

FTP --> PARSER --> VALIDATOR --> COMBINER (Opsiyonel) --> LOADER

Yukarıdaki işlemleri ise şu şekilde açıklayabiliriz;

FTP: Perl ile yazılmış ve bir .ini dosyayı gönderilen ftp scripti sayesinde karşıdaki yönetim sisteminden üreyen performans verileri toplanır. İşlenmek üzere bir folder'ın altına konulur.

PARSER: Parser'ın görevi ftp'nin çektiği veriyi anlamlı ve düzenli bir hale getirmektir. Gelen veri .CSV uzantılı olsa bile üretilen parser bu veriyi düzenleyecektir. Parser ise bize, Aircom tarafından geliştirilmektedir.

VALIDATOR: Validator'ın görevi ise, parse edilmiş veriyi load edilebilecek konuma getirmektir. Dolayısıyla loader, bu veriyi bir takım araçlar sayesinde (sql loader) veritabanına hızlı bir şekilde yükleyecektir.

COMBINER: Opsiyonel olan bu script ise validate edilmiş bir verinin içindeki sayaç gruplarının tekbir grup altında toplanmasını gerçekleştirir. Tekbir grup altında toplanan bu verilerse veritabanında tek ve büyük bir tabloda, partition'lar halinde tutulacaktır.

LOADER: Bulk load ve single insert yapabilme özelliklerine sahip olan loader, çok hızlı bir şekilde veriyi veritabanına yazmakla görevlidir. Bulk insert edilen veri grubu, SGA'i fazla yormadan ve single insert'lere göre kat kat daha hızlı veritabanına yazılırlar.

Yukarıda tanımladığım görevler, Optima'nın back-end görevleridir. Bunun dışında bir de front-end görevleri vardır. Front-end arayüzünün amacı ise back-end'in topladığı veriyi raporlamak, görüntülemek, manipüle etmek vb.

Front-end için Optima Lite adı verilen bir program kullanılır. Programın içinde, Data Explorer, Filters, Element Hierarchy, Module Explorer, Reports, Alarms, Administrative Tools, Help gibi içerikler vardır.

Data Explorer: Veritabanındaki veriyi incelemeye yarar. Herhangi bir programa ihtiyacınız olmadan, hangi tabloda ne var görebilirsiniz.

Filters: Filtreler veriin nasıl gösterileceğine karar veren gruplardır. Yeni bir grup tanımlayabilir ya da varolanı değiştirebilirsiniz.

Element Hierarchy: Verinin hangi kademelerde raporlanayacağını belirleyen hierarşik yapıyı düzenleyen birimdir.

Module Explorer: En çok kullanılan birimdir ve SQL sorguları ile dinamik raporlar üretmeye yarar. Hangi tarihte ve hangi filtrelerle, hangi element hierarşisiyle görmek istiyorsanız, veriyi o şekilde gösterir.

Reports: Klasik raporlardır ve SMS,e-posta veya .txt,.doc,.pdf uzantılı dosya olarak çıktı sunar. Genelde günlük, haftalık, aylık ve yıllık raporları takip etmek isteyen müşteriye sunulabilir. Arayüzünün hazırlanması son derece kolaydır.

Alarms: Fault management kısmına, belirli limitleri tanımladıktan sonra, snmp poller aracılığı ile gönderdiğimiz alarmları yükseltir. Bu alarmlar, müşteri tarafından belirlenebilir ve limitleri aşarsa hata yönetim birimine aktarılır.

Administrative Tools: Optima kullanıcılarını tanımlamaya ve veritabanında oluşturmaya yarar. Bu kullanıcılar 3 ayrı grupta toplanır. Optima_Administrator, Optima_Advanced_User, Optima_Tool_User. Tool_User sadece read-only access'e sahiptir ve yetkileri sınırlıdır. Administrator ise programa tam olarak hakim olabilen kullanıcı grubudur. Yeni kullanıcılar yaratılırken bu gruplar dikkate alınır.

Yukarıdaki bilgiler son derece yüzeysel bilgilerdir ve daha detaylı yazarsam da kitap haline dönüştürülebilirler :) OPTIMA ile uğraşan ve problem yaşayan okuyucular bana e-posta gönderebilirler.

Optima'nın şu anda kullandığı veritabanı ve versiyonu ise Oracle DB 10gR2'dir. Yani gelmiş geçmiş en istikrarlı, tutarlı veritabanıdır.

İyi haftasonları,

Ogan