18 Aralık 2009 Cuma

NOT NULL CONSTRAINT / NULL VALUE

Merhaba,

Sıklıkla karıştırılan ve bol bol sorular gelen bir konuyu ele almak istiyorum. NULL değer karmaşası ve NOT NULL constraint'i.

Öncelikle aklımızda bulundurmamız gereken bilgi şudur; NULL bir değer değildir! NULL sıfır değer demekte değildir! NULL bir değere sadece değersizdir diyebiliriz.

NOT NULL Constraint ile ilgili olarak;

1) Bir NOT NULL constraint'i sadece sütun seviyesinde tanımlanabilir.
2) Tablo objesinin yaratılışı sırasında CREATE TABLE statement'ı ile birlikte yaratılabilir.
3) Tablo objesi yaratıldıktan sonra ALTER TABLE ... MODIFY ifadesi ile tablo'ya eklenebilir.
Önemli Not: ALTER TABLE ifadesini sadece bir constraint'i drop, enable ve disable etmek için kullanabilirsiniz. Constraint yapısını değiştirmek için kullanılamaz!
4) NOT NULL constraint'ini tanımlayacağımız sütundaki bütün verilerin null dışında bir değer olması gerekiyor ya da tablonun tamamen boş olması.
5) NOT NULL constraint'leri data dictionary'de CHECK constraint başlığı altında saklanırlar. Dictionary sorgulandığı zamansa CHECK constraint'i olduğunu gösteren "C" değeri görünür.

NOT NULL constraint'leri ile ilgili olarak aklıma ilk gelenler ve önemli olanları yukarıdaki gibi sıraladım. Unutmadan ufak bir dip not; ORDER BY ifadesinin DESC, yani büyükten küçüğe doğru sıralama ile kullandığımız zaman ilk karşımıza gelecek değer öbekleri NULL olanlardır. NULL değerler ORDER BY ifadesinde en büyük olarak geçerli sayılırlar. Bu duruma da dikkat etmekte fayda vardır.

İyi çalışmalar,

Ogan

1 Aralık 2009 Salı

SNIPED Oracle Oturumları

Merhaba,

Oracle veritabanındaki v$session görüntüsünde Oracle veritabanına bağlı arkaplan ve kullanıcı oturumları listelenir. Bu oturumların da o anlık durumları ile ilgili bilgiler sağlanır.

Örneğin aktif olarak sorgu koşturan bir kullanıcı oturumu varsa v$session'da "ACTIVE" olarak listenelirken, sorgu koşmayan bir kullanıcı "INACTIVE" olarak görüntülenebilir. Bir veritabanı yöneticisi olarak, aktif kullanıcıların sistem kaynaklarını tüketmelerini ve inaktif kullanıcıların da sistemden çıkartılarak, daha fazla pga tüketmelerini engellemek isteyebilirsiniz. İşte bu inaktif kullanıcılar için bir profil ayarı var ve adı da idle_time. Eğer varsayılan profili kullanıyorsanız ve idle_time parametresine de "unlimited" yerine dakika cinsinden bir değer atadıysanız -ki bunu yapabilmek için resource_limit parametresinin de true olması gerekiyor ve spfile kullanılan bir veritabanında bunları dinamik olarak yapabilirsiniz- atadığınız dakika değeri boyunca işlem yapmayan kullanıcıların oturumları Oracle tarafından sonlandırılacaktır.

Bu sonlandırmanın ardından oturumlar Oracle'da sonlandırılacağı için unix oturumlarının açık kalma ihtimali de mevcuttur. Bu durumda v$session'daki durumları inactive ya da killed yerine SNIPED olarak değiştirilecektir. SNIPED olan bir oturuma Oracle daha fazla müdahale etmez ve sizin bu oturuma ait işletim sistemi seviyesindeki oturumunu sonlandırmanızı bekler.

SNIPED olan oturumları aşağıdaki şekilde listeyebiliriz;

SQL> select * from v$session where status = 'SNIPED';

SNIPED olan bir oturumu öldüremeyiz çünkü oturum Oracle tarafından öldürülmüş durumdadır. SNIPED olan bir oturum yeniden aktif hale getirilemez ve ilgili kullanıcı, kendi kullanıcı adı ve şifresi ile yeniden bağlanmayı denemelidir.

İyi çalışmalar,

Ogan

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

26 Ekim 2009 Pazartesi

ORA-00600: internal error code, arguments: [13013], [5001], ...

Merhaba,

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

4 Eylül 2009 Cuma

Datafile'ların Taşınması ve Disk Alanı Problemi

Merhaba,

Bugün yazacağım konu, Oracle'da bir fiziksel datafile'ı, başka bir dizin altına nasıl taşırız? Taşırken ne gibi şeylere dikkat etmek gerekiyor? Hangi datafile'ları taşırken veritabanını kapatmaya gerek var ya da yok?

Yapı itibariyle genelde karşılaşılan durumlardan birisi de Oracle'ın fiziksel veri dosyaları olan datafile'ların bulunduğu mount point'lerin dolmasıdır. Bu durumda ya yeni bir mount point açılır ve yeni datafile'lar buraya işlenir, ya da var olan datafile'ları başka bir alana taşırız. Bu taşıma işlemi sonrasında da %100'e ulaşmış olan mount point biraz rahat nefes almış olur.

Öncelikle şunu belirtmeliyim ki bir mount point datafile'larla dolmuş işe ve bunun içerisinde system tablespace'ine ait datafile'lar varsa, datafile'ları taşıyabilmek için mutlaka ve mutlaka veritabanını kapatmalıyız. Aynı durum sysaux ve undo tablespace için de geçerlidir. Erişimin Oracle'ın kendisi tarafından olan datafile'ları taşıyabilmenin yolu veritabanını kapatmaktır.

Bir örnek ile devam etmek gerekirse;

SQL> shutdown immediate;
# mv /db/oracle/data01/undotbs1.dbf /db/oracle/undo/undotbs1.dbf
SQL> startup mount --> mount aşamasına taşımamızın nedeni, datafile'lar alter database open komutu geldiği andan itibaren açılırlar. Bu aşamada control dosyamız okunmuş ve spfile içindeki parametrelerle veritabanı mount edilmiş olur.
SQL> alter database rename file /db/oracle/data01/undotbs1.dbf to /db/oracle/undo/undotbs1.dbf;
SQL> alter database open;

Yukarıdaki işlemden sonra sistem tablespace'imize ait datafile, başka bir alana kopyalanmış oldu.

Eğer kopyalayacağımız datafile başka bir tablespace'de ise sadece ilgili tablespace'i offline yaparak işlemimizi gerçekleştirebiliriz.

Örnek olarak;

SQL> alter tablespace USERS1 offline;
SQL> !mv /db/oracle/data01/users01.dbf /db/oracle/data12/users01.dbf
SQL> alter tablespace USERS1 rename datafile /db/oracle/data01/users01.dbf to /db/oracle/data12/users01.dbf;
SQL> alter tablespace USERS1 online;

Biraz daha garanti olsum işin derseniz eğer, mv komutu yerine cp komutu kullanarak, tablespace'i online yaptıktan sonra eski datafile'ı rahatlıkla silebilirsiniz.

Bu aşamada çok kritik bir noktadan bahsetmem gerekiyor. Bazı durumlarda Oracle, disk üzerindeki alanı bırakmaz ve fiziksel olarak datafile'ı taşısakta yerin hala %100 dolu olduğunu görebiliriz. Bu durumun sebebi işletim sistemi değildir. Çünkü dikkat ederseniz, bir datafile'ı shrink yaptığınız zaman yer açılacak ancak yukarıdaki örnekte olduğu gibi taşıdığınız zaman yer açılmayacaktır. Bunun tek sorumlusu olarak control dosyasını görebiliriz. control dosyası bu datafile'ın hala orada olduğu bilgisini tuttuğu için fiziksel olarak taşısakta ne yazık ki istediğimiz alan disk üzerinde açılmıyor. Nedenlerinden birisi ise datafile'ın bağlı olduğu tablespace'in bir takım kullanıcılar tarafından erişiliyor olması. Eğer Solaris kullanıyorsanız lsof 12 ; ile işletim sistemi seviyesinde kontrol ederseniz, farkına varacaksınız. İşletim sisteminiz HPUX, SUSE ya da Red-Hat tarzı bi linux tabanlı işletim sistemi ise program yüklemeniz gerekebilir.

Çözüm olarak veritabanını kapatıp, yeniden başlatmalıyız. Veritabanı yeniden başladığı zaman, bağlanacak yeni kullanıcılar datafile'ların yeni yerine erişebilmiş olacak. Dolayısıyla control dosyası da yenilenmiş olacak ve mount point'in disk alanını kontrol ettiğimiz zaman da açılan alanı görebileceğiz.

Biraz karmaşık olduğundan soru işaretlerinin oluştuğu yerde bana e-posta gönderebilirseniz memnuniyetle cevaplamak isterim.

İyi çalışmalar,

Ogan


19 Ağustos 2009 Çarşamba

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

16 Temmuz 2009 Perşembe

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

6 Mayıs 2009 Çarşamba

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

18 Nisan 2009 Cumartesi

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

13 Nisan 2009 Pazartesi

The best of PL/SQL seminar with Steven Feuerstein

Merhaba,

Bugün sabah İstanbul'a, Steven Feuerstein'ın 2 günlük semineri için gelmiş bulunuyorum. Kısmetse yarın akşam tekrar Ankara'ya dönüyor olacağım.

Steven, PL/SQL konusunda birçok kitap yazmış, dünyanın en iyi PL/SQL developer'ı olarak bilinen bir kişidir. Aslında index organized table nedir? Ya da SGA optimizasyonu nasıl yapılır? gibi sorular yönelttiğiniz zaman cevaplandıramaması da bana göre doğaldır.

2 gün sürecek olan seminerin ilk gününde PL/SQL nedir? PL/SQL bloğu içerisindeki SQL sorgularının davranış biçimi ve PL/SQL bloğunun Oracle tarafından optimizasyonu, "Collection" konusu (Array-like structures, nested tables, Varrays), Virtual Private Database (DBMS_RLS), DBMS_UTILITY, DBMS_STANDARD paketleri, BULK COLLECT, FORALL gibi konulara girdik. Yarınsa daha çok "tricky" konularla ilgileniyor olacağız. Mesela birçok kişinin yakından takip ettiği ve hep merak edilen bir konu olan "SQL Injection". Bunu başarabilme ve injection'dan korunma methodlarından bahsedecek.

Steven Feuerstein hakkında daha fazla bilgi isteyenler; http://www.stevenfeuerstein.com/

Seminerle birlikte Steven, büyük ölçüde kendisinin hazırladığı Oracle PL/SQL Programming Language cep kitabını da ücretsiz olarak katılımcılara dağıttı.

İyi akşamlar.

4 Şubat 2009 Çarşamba

10g TABLESPACE

Merhaba,

Öncelikle tablespace'in tanımından başlayalım.

Tablespace: Mantıksal yapıları bir arada tutan ve gruplayan veritabanı depolama ünitesidir.

Mantıksal Yapılar: Tablespace, schema objeleri, veri blokları, extent'ler ve segmentlerden oluşan yapılardır.

Tablespace yapı itibariyle ikiye ayrılır.

1) Bigfile Tablespace
2) Smallfile Tablespace

Bigfile Tablespace: Oracle 10g versiyonu ile aramıza katılmışlardır. Bu tip tablespace'lerin en büyük özelliği 128 TB'a kadar .dbf (database file) barındırabilirler. Ancak tek bir database file ekleyebilirsiniz. Fiziksel depolamaya yarayan dbf'iniz dolduğu zaman tek yapabileceğiniz boyutunu arttırmaktır. Bigfile tablespace'ler extend olabilirler.

Eğer bir bigfile tablespace'e database file eklemeye çalışırsanız (alter tablespace add datafile ...) alacağınız hata şu olacak;

ERROR at line 1:
ORA-32771: cannot add file to bigfile tablespace


Smallfile Tablespace: 10g'den önce aramızda olan tablespace'dir. Üzerinde birden fazla dbf yaratılabilir.

İyi akşamlar,

Ogan
Takip et: @oganozdogan