Oracle Kurulumunda Alınan ‘Error In Writing To Directory /tmp/Orainstall’ Hatasının Olası Nedenleri

18/01/2011, 10:01 | Kurulum kategorisinde yayınlandı | Yorum yapın
Etiketler: ,

Oracle ürünlerinden birinin kurulumu yapılırken veya patch uygulanırken  bu hata ile karşılaşılabilirsiniz. Ben de daha önce kurulum yapmış olduğum bir sunucu üzerinde yeniden kurulum yapmak istediğimde aşağıdaki gibi bir hata ile karşılaştım.

Error in writing to directory /tmp/OraInstall2011-01-15_12-00-06PM

İlk görünüşte bu hata yetersiz /tmp alanı veya yetki problemi gibi görünmesine rağmen yetki ve disk alanını  kontrol ettiğimde bunlardan kaynaklanan bir problem olmadığını gördüm . Sunucu üzerinde de daha önceden kurulum yapılmış olduğundan kullanıcıya verilmesi gereken yetki eksikliği veya sunucuya kurulmamış eksik paket olamazdı.

runInstaller -debug  ile tekrar kurulum yapmayı denedikten sonra yine faklı bir hata göremedim ve oracle supportda biraz araştırma yaptım. Oracle note #407095.1 de belirtilen hata sebeplerinin üzerinden hızlıca geçtikten sonra hatanın nedeninin kurulum için kullandığım kurulum dosyalarının bozuk olduğu ortaya çıktı.  Kurulum dosyalarını tekrar sunucuya gönderdim ve kurulumu tamamlayabildim.

Bu hata ile karşılaşırsanız kontrol etmeniz gerekenlerin bir listesi:

a) /tmp de yeteri kadar boş alan olduğunu kontrol ediniz.

 b) /tmp dizinine okuma, yazma ve çalıştırma yetkisi var mı ?

c) Oracle 9.2.0.5 – 9.2.0.8  versiyonlarının kurulumunda  5614628 numaralı bug kontrol edilmelidir.

d) Kurulumda sunucunun lokal konsolu kullanılmıyorsa , lokal konsol kullanmayı deneyiniz.

e) Kurulumun yazılımları bozulmuş olabilir. Sunucuya tekrar kopyalayınız veya gerekiyorsa tekrar download ediniz. Dosyaları sunucuya taşırken binary olarak ftp yapınız.

 f) Kurulum dosyaları , kurulumu yapacak oracle kullanıcısına ait olmalı ve bu kullanıcı ile unzip edilmelidir. 

g) Yanlış Unzip programı kullanılıyor olabilir. kullanıcı profil dosyasındaki tanımlı PATH değişkeninden farklı versiyondaki unzip programını kullanıyor olabilir. Kullanılan unzip 5.4 versiyon numarasından daha güncel olması gerekebilir.

h) Unzip programı için çalıştırma yetkisi olmayabilir.

i) /tmp de 2Tb dan daha fazla boş alan var ise temp alanı olarak farklı klasöre yönlendirme yapılmalıdır.  

export TMP=/yeni_tmp_klasörü

j) Kurulum dosyaları açık (unzip edilmiş) olarak bulunan DVD/CD’den Unix sunucuya ftp yapılırsa, sunucudaki stage area dizinleri küçük olarak oluşturulur. 

Caner Baştürk

ORA-22992 cannot use lob locators selected from remote tables

22/12/2010, 12:06 | 1 kategorisinde yayınlandı | Yorum yapın
Etiketler: ,

LOB tipindeki dataların DB link üzerinden sorgulanması desteklenmediği için , DB link üzerinden LOB tipindeki bir data sorgulanmaya çalışıldığında bu hata alınmaktadır.

Fakat bir şekilde bu tip verilere başka veritabanları üzerinden  erişmemiz gerekiyorsa farklı çözüm yolları uygulayarak bunu başarabiliriz.

Öncelikle      select * from owner.my_table@dblink;

şeklinde çalıştırdığımız sorgu için bu hatayı alıyorsak ve LOB tipindeki datalara erişmeye ihtiyacımız yoksa  , sorgumuzdan LOB tipindeki kolonları çıkararak sorgumuzu revize edip çalıştırabiliriz.

select Col1, Col2  , .. from owner.my_table@dblink;    şeklinde düzenleyebiliriz.

Bunun mümkün olmadığı ve LOB tipindeki verileri görmemiz gerekiyorsa kullanılacak alternatif yöntemlerden biri erişmeye çalıştığımız veritabanı üzerinde view oluşturmak olabilir. Eğer sorgulanacak LOB verimizin tipi CLOB ise işimiz kolay bu durumda CLOB olan kolonlarımızı  to_char() ile char tipine çevirerek view oluşturup , sorgularımı bu view üzerinde yapabiliriz.

Remote database üzerinde view oluşturulur.

create or replace view my_view

as select Col1, Col2 , to_char(CLOB_Col1) , to_char(CLOB_Col2) … from my_table;

View oluşturulduktan sonra ihtiyacımız olan CLOB tipindeki verileri bu view sorgulanarak görülebilir.

select owner.my_view@dblink;

Kullanabileceğimiz alternatif yöntemleri yapmak istediğimiz işlem ve veri tipine göre değiştirebiliriz.  pl/sql ile ile kod yazabilir veya temporary tablolardan yararlanabiliriz.

asktom da bu konu ile alakalı güzel bir thread var.  İlgilenenler buradan erişebilirler.

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5322964030684

Caner Baştürk

ORA-00600: internal error code, arguments: [kkslrpl1], [8]

20/12/2010, 13:46 | ORA-600 kategorisinde yayınlandı | Yorum yapın
Etiketler: , , , ,

Daha önce karşılaştırğım ORA-00600 hatasının bu versiyonu :) ile yakın zamanda tekrar karşılaşınca ve yazmak için de fırsat bulunca , bu hatayı sizlerle paylaşmak istedim.  Bu hata ile sadece Oracle 9 veritabanlarında karşılaştım ve yeni versiyonlarda düzeltildiği söyleniyor. Oracle’ın yeni versiyonlarında karşımıza çıkana kadar bunu doğru kabul etmek gerek.  Çünkü daha önce yaşadığım ve hatta devam eden bir SR ( Service Request  ) da daha önceki versiyonlarda düzeltilmış olan bug’ın Oracle 11.2.0.2 de geri geldiğini gördüm ve bunu oracle tarafına kabul ettirene kadar 45 günlük yazışma ve test aşamalarından geçmek zorunda kaldım.

Gelelim asıl konumuza, Bu hata kritik bir hata değil . Uygulama mantığı açısından kritik bir uygulamanın çalışmamasına neden olabilir fakat veritabanı tarafında birşeyler bozulmuyor. Veritabanında çalıştırılan sorguların in-list değeri olarak çok fazla sayıda bind değişken kullanıldığında bu hata alınmaktadır ve sadece çalışan sql’ in kesilerek ORA-00600: internal error code, arguments: [kkslrpl1], [8]  hatası vermesine neden olmaktadır.  Benim gördüğüm sql’in  in-list  listesinde onbinlerce değişken bulunmakta idi.  Normal şartlarda böyle bir sorgu elle yazılmaz , buradaki durum da uygulama tarafından otomatik olarak oluşturulmuş bir sorgu idi.

Benim durumumda sorgunun düzeltilmesi için yazılım geliştirme ekibine bilgi verildi ve düzeltilmesi istendi. Yazılımsal olarak sql’in düzeltilme imkanı yoksa CURSOR_SHARING= EXACT olarak set edilerek hatanın alınması engellenmeye çalışılabilir. Tabi budurumda cursor sharing özelliği kullanılamayacağı için daha fazla shared pool alanına ihtiyaç doğabilir.

Oralce support üzerinde de bu konu ile alakalı  987963.1 numaralı dökümana bakabilirsiniz.

Herkese ORA-600 süz günler dilerim.

Caner Baştürk

Ayrıca  Ora-600 Nedir?    konulu yazıma ulaşabilirsiniz.

Oracle 11 Release 2 PatchSet 1 (11.2.0.2) Çıktı

15/09/2010, 10:34 | ORACLE 11g R2, Yeni parametreler kategorisinde yayınlandı | Yorum yapın
Etiketler: , , ,

13 Eylül itibariyle Oracle 11G’nin ilk patchset’i Linux işletim sistemi için çıktı. Bu haber diğer  işletim sistemleri için olan patchsetlerin de habercisi aynı zamanda.

Bu patchset veritabanı işleyişinde önemli bir değişiği de beraberinde getirmektedir. Oracle 11.2.01 ve daha önceki sürümlerde , SYSTEM Tablespace’i dışında kalan datsafile’larında oluşan yazma ( I/O ) hataları ve problemlerinde ilgili datafile offline moda alınmakda iken yeni patchset 11.2.0.2 ile birlikte datafile’lara  yazma problemi yaşandığında INSTANCE CRASH olacak.  Bunun iyi bir gelişme olup olmadığı  tarşılır.

Bu özellik yeni eklenen “_DATAFILE_WRITE_ERRORS_CRASH_INSTANCE”  parameresi ile sağlanacak.  PatchSet 1 (11.2.02 ) kurulumu ile birlikte  “_DATAFILE_WRITE_ERRORS_CRASH_INSTANCE=TRUE”  parametresi  set edilmiş olacak ve datafile’lara  yazma hatalarında instance crash yaşanması sağlanacaktır.

Parametre _datafile_write_errors_crash_instance = FALSE  olarak tanımlanırsa eskiden olduğu gibi datafile’lara yazma hataları yaşandığında adece ilgili datafile offline olarak kalacaktır.

Caner BAŞTÜRK

Solaris 10 Üzerine Oracle11G R2 Silent Installation Problemi

30/08/2010, 13:00 | Kurulum kategorisinde yayınlandı | Yorum yapın
Etiketler: , , , , , ,

Solaris 10 Üzerine Oracle11G R2 Silent Installation Problemi

Şu sıralar yoğun olarak ilgilendiğim konu veritabanlarının Oracle 11g release 2 ye yükseltilmesidir.

Bunu yaparken de karşılaştığım ilginç ve sinir bozucu bir hatadan bahsedeceğim.

Solaris 10 işletim sistemi üzerinde Oracle11G R2  yi silent  moda reponse file kullanarak  software only kurulum yapmak istediğimde aşağıdaki hatayı  alarak kurulum yapamamaktaydım.

Alınan Hata:

Initializing Java Virtual Machine from /tmp/OraInstall2010-08-02_04-00-36PM/jdk/jre/bin/java. Please wait…

oracle11@MYHOST7:~/kur/database$ Exception in thread “main” java.lang.NoClassDefFoundError

        at java.lang.Class.forName0(Native Method)

        at java.lang.Class.forName(Class.java:164)

        at java.awt.Toolkit$2.run(Toolkit.java:821)

        at java.security.AccessController.doPrivileged(Native Method)

        at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:804)

        at javax.swing.UIManager.initialize(UIManager.java:1262)

        at javax.swing.UIManager.maybeInitialize(UIManager.java:1245)

        at javax.swing.UIManager.getUI(UIManager.java:851)

        at javax.swing.JPanel.updateUI(JPanel.java:104)

        at javax.swing.JPanel.<init>(JPanel.java:64)

        at javax.swing.JPanel.<init>(JPanel.java:87)

        at javax.swing.JPanel.<init>(JPanel.java:95)

        at oracle.sysman.oii.oiif.oiifo.OiifoOCMUI.<init>(OiifoOCMUI.java:125)

        at oracle.sysman.oii.oiif.oiifo.OiifoOCMInterfaceManager.<init>(OiifoOCMInterfaceManager.java:79)

        at oracle.sysman.oii.oiif.oiifo.OiifoOCMInterfaceManager.getInstance(OiifoOCMInterfaceManager.java:124)

        at oracle.install.ivw.db.driver.DBInstaller.run(DBInstaller.java:123)

        at oracle.install.commons.util.Application.startup(Application.java:869)

        at oracle.install.commons.flow.FlowApplication.startup(FlowApplication.java:164)

        at oracle.install.commons.flow.FlowApplication.startup(FlowApplication.java:181)

        at oracle.install.commons.base.driver.common.Installer.startup(Installer.java:265)

        at oracle.install.ivw.db.driver.DBInstaller.startup(DBInstaller.java:114)

        at oracle.install.ivw.db.driver.DBInstaller.main(DBInstaller.java:132)

Kurulumu aşağıdaki her başlattığımda yukarıdaki hata alınmakta ve kurulum tamamlanmamaktadır.

./runInstaller -silent -ignoreSysPrereqs -ignorePrereq -noconfig -force -responseFile /vol/oracle11/kur/database/parameters.rsp -debug

Yaptığım testlerde hiçbir hata almadan ve tüm prerequestler sorunsuz geçilmektedir.

  • Aynı sunucu üzerine grafik modda kurulum yapılabilmektedir.
  • Xserver üzerinden silent kurulum yapılabilmektedir.
  • Telnet üzerinden bağlantı oluşturulup ,yapılan silent kurulumlarda ise hata alınmaktadır.

 

Çözüm:

Yaptığım incelemede DISPLAY değişkenine set edilen IP de, sunucuya bağlı bir xsession mevcut ise yapılan kurulum başarılı bir şekilde tamamlanmaktadır, aksi halde hata alınmaktadır.

Metalink de yaptığım incelemede bu hatanın DISPLAY değişkeni set edilmediğinde alındığı söylenmekte , Solaris 10 üserine yapılan kurulum da ise durum tam tersi çıkmaktadır.

Hatayi gidermek ve kurulumu tamamlamak için DISPLAY değişkeni boş bırakılmalıdır.

unset  DISPLAY

edildikten sonra ,kurulumdan önce

echo DISPLAY    ile boş bırakıldığı görüldükten sonra kurulum yapılırsa hatasız tamamlanmaktadır.

Caner BAŞTÜRK

LOGMINER (Hayat Kurtarmanın Hızlı Yolu)

28/08/2010, 10:53 | RECOVERY kategorisinde yayınlandı | 1 Yorum
Etiketler: , ,

LOGMINER (Hayat Kurtarmanın Hızlı Yolu)

 Oracle’da veri kurtarmak için kullanılabilecek ,kullanımı oldukça kolay olan ve hızlı bir şekilde sonuç alabileceğiniz bir yöntem; LOGMINER.

Kullanımı bu kadar basit olmasına  rağmen çok fazla bilinmediğini ve kullanılmadığını düşünüyorum.

Aslında bu yazıyı yaklaşık bir ay önce yazmaya karar vermiştim. Çünkü iki gün üst üste iki farklı canlı veritabanında kullanmak zorunda kaldım. Her iki durum da, müşteri uygulamalarından yanlışlıkla kayıt sildiklerini ve silinen bu kayıtları kurtarmak için farklı bir  ortama veritabanını Point In Time (PIT) recovery yapmak için benden destek istemeleri ile başladı.

         Olayı inceledikten sonra kayıtları silen personeli dinledikten sonra buna gerek olmadığını çok uzun sürecek Point In Time recovery yerine logminer kullanacağımı ve kısa sürede silinen kayıtları kurtarabileceğimizi anlattım.

         Bu yöntemi kullanabilmek için öncelikle bir takım ön koşullar var .

Bunlar;

1-işlemin hangi tablodan yapıldığı bilmek;  

Bu olmazsa olmaz değil fakat işimizi hızlandıracaktır. Sorgulama yaparken seg_name ‘e göre arama yapabiliriz.

2-ilgili tablonun logging mode’unun enabled olması.

Tablo’nun logging modu’ enabled değilse o tablo üzerinde yapılacak delete , insert ve update işlemleri redo.log lara  yazılmayacağı için logminer kullanamayız.

3-işlemin yaklaşık olarak ne zaman yapıldığının bilinmesi,

Bize  hangi redo.log veya arşiv logları kullanacağımız hakkında fikir verecektir ve arama alanımızı kısıtlayacağı için daha hızlı sonuç alabiliriz.

LOGMINER ile kurtarma:

Veritabanına yapılan tüm değişiklik işlemleri redolog.lara oradan da arşiv.loglara aktarılmaktadır. Logminer ile de bu loglardaki yapılan işlemlere bakarak işlemleri geri alabiliriz.

İşlemin hangi saat aralığında yapıldığını tespit ettikten sonra alert.loga bakarak o saatler arasında işlemlerin hangi arşiv.loglarda veya redo.log da olduğu bulup bir kenara not ediyoruz.

Veritabanında hangi schema ait işlem yapıldığını ve tablo adını da aldıktan sonra işleme başlayabiliriz. İşlemlerimiz elbette yetkili bir kullanıcı ile yapıyoruz. Ben sys kullanıcısını kullandım.

Log dosyalarının logminer’a tanıtılması;

Bu kısımda  aradığımız işlemi barındırdığını düşündüğümüz redo.log ve arşiv.log dosyaları logminer’a tanıtılır.

BEGIN

  dbms_logmnr.add_logfile(‘/oracle/oradata/TEST/redo03.log’);

END;

/

Benim örneğimde kayıtların silinmesi redo03.log dosyasında olduğu düşünülerek sadece bu eklenmiştir.

Lomgminer işlemi başlatılır.

EXEC dbms_logmnr.start_logmnr(options=> dbms_logmnr.dict_from_online_catalog);

Aradığımız kayıtların bulunması;

Tanıtmış olduğumuz redo03.log dan sorgulama yapılır. Burada benim kullandığım yöntem sorgulama yaparken bulunan kayıtların , tekrar sorgulama için bir tabloya yazdırılmasıdır.

Create table verikurtar as SELECT * FROM v$logmnr_contents  WHERE seg_owner=’SCHEMA_USER’ AND seg_name=’TABLO_ADI’   and operation =’DELETE’ ;

Buarada asıl amaç v$logmnr_contents in sorgulanmasıdır.

seg_owner=’SCHEMA_USER’      , tablonun sahibi olan kullanıcı

seg_name=’TABLO_ADI’            , kaydın silindiği tablo adı  

operation =’DELETE’ ;                , aradığımız işlem

sorgulama işlemi tamamlandıktan sonra

SQL_REDO  kolonunda yapılan delete işlemi bulunur.

SQL_UNDO  kolonunda ise yapılan delete işlemini geri almak için kullanacağımız INSERT işlemi bulunur.

Sql_redo kolonundaki kayıtlar incelenerek yanlışlıkla silinen kayıtlar bulunur, bu Kayıların sql_undo sütünündaki insert cümleleri alınarak veritabanına uygulanır ve silinen kayıtlarınızı kurtarırız.

Logminer işlemi sonlandırılır.

exec dbms_logmnr.end_logmnr;    

Komutu çalıştırılarak işlemimiz sonlanmış olur.

Anlattığım örnekten de anlaşılacağı gibi , logminer yöntemi kullanılabiliyorsa Point In Time recovery kullanarak verilerimizi kurtarmak için harcayacağımız zaman ile kıyaslanamayacak  kısa ve kolay bir yöntemdir.

Caner BAŞTÜRK

NLS_DATE_FORMAT Parametresi

22/01/2010, 18:26 | Yeni parametreler kategorisinde yayınlandı | Yorum yapın
Etiketler: , ,

NLS_DATE_FORMAT

Date tipindeki verilerin default olarak kullanacakları gösterim şeklini belirlemek için kullanılan ve Oracle 11 ile gelen  yeni bir parametre.  Bu parametre instance bazında ve session bazında set edilebiliyor.

Alter session set nls_date_format= “DD/MM/YYYY HH24:MI:SS” ;

Alter system set nls_date_format= “DD/MM/YYYY HH24:MI:SS”  scope=both;

Bu parametre set edildikten sonra to_char() ile yapılan sorgulamalarda tarih alanları bu formata uygun olarak gösterilirler. Sorgulanan tarih alanlarını ayrıca formatlı göstermek için surgunuzda tarih formatını belirtmenize gerek yoktur.

 Select to_char(tarih , ‘DD/MM/YYYY HH24:MI:SS’) from dummy;

Şeklindeki bir sorgu yerine,

 Select to_char(tarih) from dummy;

Kullanılabilir ve tarih formatını şu şekilde gösterir: “11/01/2010 15:25:11”

Caner Baştürk

INDEXLERDE NULL TUNING

26/12/2009, 21:45 | TUNING kategorisinde yayınlandı | Yorum yapın
Etiketler: , , ,

TABLODA NULL DEĞER ARAMA

Bir tabloda değer girilmemiş olan bir alana ait kayıtları bulunmak istendiğinde tüm tablo baştan sona okunur “full table scan”. İstediğimiz koşula uyan kayıtlar bu şekilde bulunur. Bu tip bir sorgulama yapmak hem disk I/O hem de CPU için çok pahalı bir işlemdir.  Pahalı olmasının nedeni de full table scan yapılarak index kullanılmamasıdır. Indexlerde null değerler tutulmazlar, sadece veri girilmiş olan alanlar indexlerde tutulurlar.
Burada tabloda NULL değeri olan kayıtları daha hızlı bir şekilde ve index kullanarak sorgulama yapmanın 2 yolunu anlatacağım.

 Where X IS NULL  da index kullanma 

SELECT id 

    FROM my_table

    WHERE seq IS NULL

Şeklinde çalışan sorgu tablonun seq kolonunda index olmasına rağmen her defasında full table scan yapmaktadır.

Bu sorgunun index kullanmasını zorlamak için 2 alternatif yol izlenebilir.

a)     My_table tablosunun seq  kolonuna uygulamanız için bir anlami olmayan  default bir değerin verilmesini sağlamak ve kolonu not null yaparak seq kolununda null değer kalmaması sağlandıktan sonra sorgumuzu aşağıdaki gibi değiştirip, daha hızlı sorgulama yapabiliriz.

Örneğin : tablomuza seq  değeri null olan bir kayıt insert edildiğinde seq değerinin default olarak “-1” verilmesi sağlanmalıdır.

alter table my_table modify seq default (-1);

Şimdi sorgumuzu aşağıdaki gibi değiştirmeliyiz.

SELECT id

    FROM my_table

    WHERE seq = -1

b)     My_table tablosundaki seq kolonu üzerinde mevcut olan index drop edilir. Bunun yerine function based index eklenerek istenen sonuç sağlanır. Bunun için yapılması gerekenler;

query_rewrite_enabled  parametresinin değeri TRUE

query_rewrite_integrity parametresinin değeri TRUSTED yapılmalıdır.

Yeni index oluşturulur.

CREATE INDEX NDX_MY_TABLE_1 ON MY_TABLE (NVL(“SEQ”,(-1)));

Burada kullanılan “-1” değeri uygulama tarafından kullanılmayacak olan dummy bir değerdir.

Sogumuz aşağıdaki gibi değiştirilir.

SELECT id

    FROM MY_TABLE

    WHERE nvl(seq , -1) = -1

 Caner BAŞTÜRK

DDL_LOCK_TIMEOUT Parametresi

22/12/2009, 15:47 | Yeni parametreler kategorisinde yayınlandı | Yorum yapın
Etiketler: , , ,

DDL_LOCK_TIMEOUT Parametresi

 Oracle 11g ile birlikte gelen bu parametre birçok DBA’nın işini kolaylaştıracağını düşünüyorum.  Hangimiz canlı bir veritabanında kullanılan bir tablo üzerine index oluşturmaya veya bir constraint enable etmeye çalışmamışızdır. Genellikle de “ORA-00054 resource busy and acquire with NOWAIT  specified” hatası almışızdır. DDL komutları uygulandığında uygun exclusive lock’ı alamazlarsa hiç beklemeden bu hatayı almaktaydı. İstediğimiz işlemi gerçekleştirebilmek için de DDL komutunu peşpeşe deniyorduk.

 Oracle 11g ile birlikte DDL_LOCK_TIMEOUT parametresi getirilmiş. Bu parametre ile uygulanan DDL komutlarının bu hatayı almadan önce kaç sn. bekleyeceğini belirleyebiliyoruz. Bu parametreye  0-1000000 arasında değer verilebilmekte ve 0 değeri hiç beklemeden, eski versiyonlarda olduğu gibi, hatanın alınmasını  sağlamaktadır. ddl_lock_timeout parametresine değer atadığımızda ise DDL komutumuz ilk etapta lock alamaz ise paramtreye set ettiğimiz süre kadar bekleyecek, bu süre içerisinde lock alabilirse işlemini tamamlayacaktır. Süre dolduğunda ise “ORA-00054 resource busy and acquire with NOWAIT  specified” hatası alınacaktır.

 Bu parametreyi instance bazında ayarlayabileceğimiz gibi session bazında da ayarlayabiliriz.

Alter system set ddl_lock_timeout=30 ;

Alter session set ddl_lock_timeout=30 ;

 Bu parametrenin destekledi bazı DDL komutları aşağıdaki gibidir:

Alter table drop column
Drop table
Truncate table
Create index

 Belkide en çok kullanılan DDL işlemi olan, bir tabloya kolon ekleme işlemi için ddl_lock_timeout parametresi etkisizdir. Fakat bu “Alter table add” komutu ile  bir kolon eklemeye çalıştığımızda ise  hemen “ORA-00054 resource busy and acquire with NOWAIT  specified” hatası alacağımız anlamına gelmiyor. Aslında Oracle 11g ile birlikte artık tabloya kolon eklemek isterken hiçbir zaman “ORA-00054 resource busy and acquire with NOWAIT  specified”  hatası almayacağız gibi duruyor. Çünkü Oracle tabloya kolon ekleme için gerekli olan lock tipini değiştirmiş ve artık normal DML’ler gibi TX tipi lock alıyor. Tablo üzerinde devam eden transaction var ise bunun tamamlanmasını bekliyor. Oracle 11g de tabloya kolon ekleme işlemlerinde çok uzun süre bekleyebiliriz. Bu gibi durumlarda varsa blocking session’ları kontrol etmenizi öneririm.

 Caner BAŞTÜRK

ORA-600 Nedir?

21/12/2009, 13:11 | ORA-600 kategorisinde yayınlandı | Yorum yapın
Etiketler: , , ,

ORA-600 Nedir?

Error:  ORA 600

Text:   internal error code, arguments: [%s], [%s], [%s], [%s], [%s], [%s], [%s]

Bu hata mesajı birçoğumuzun başına gelmiştir ve sabit bir hata tanımı olmamasından karşılaşmayı isteyeceğimiz en son hatadır. Aslında bu hata mesajı  için  “Ele alınmayan bir hata oluştu!” denilebilir. Çünkü bu hatayı aldığımızda, aslında veritabanımızda hiçbir hata oluşmamış olabileceği gibi (örneğin komut satırından oracle yazılıp enterlanması) , bir oracle bug’ına rastlamış ,veritabanımızda fiziksel veya mantıksal bozulma oluşmuş veya donanım hatalarından kaynaklanan bozulmalar yaşıyor olabilirsiniz.

 ORA-00600 Hataları çok dikkatli bir şekilde ele alınmalı ve  Metalink’te araştırma yapmadan ezbere yöntemlerle müdahale edilmemelidir. Hatta Metalink’de yapılan incelemeden tam emin olunamıyorsa mutlaka SR (Service Request) oluşturulmalı ve buradan verilecek çözüm önerileri ışığında devam edilmelidir. Bu arada yeri gelmişken Metalinkte söylenen herşeyi peşin peşin kabul edip sorgulamadan, sizin durumunuza uygunluğundan emin olmadan kesinlikle uygulamayın. Şüphe ettiğiniz konular olursa yaptırılmak istenen işlemlerin nedenini açıklamalarını isteyiniz.

 ORA-600 Hataları alertlog’a yazılmakla birlikte bir de trace dosyası oluşturabilirler. Bu trace dosyası da yine alertlogda belirtilmektedir.

Ör:

ORA-00600: internal error code, arguments: [6749], [3], [33613043]

Errors in file /vol/oracle/OraHome1/admin/DXX1/udump/dxx1_ora_23870.trc

 ORA-600 Hatası tek başına birşey ifade etmemektedir. Hata mesajını biraz daha anlamlı hale getirmek için hata ile birlikte alınan parametrelere bakılmalıdır. Yukardaki örneğimizde [6749], [3], [33613043]  parametreleri hata ile ilgili araştırma yaparken kullanılmalıdır. Hatanın asıl nedeni bu parametrelerde saklıdır. Özellikle ilk 2 parametre hatanın hangi işlem yapılırken alındığı gösterebilmektedir.

 Umarım karşılaşmazsınız ama karşılaşırsanız acele etmeden ve soğukkanlılığınızı kaybeymeden çalışamanızı, karşılatığınız ORA-600 leri dökümante edip ileride tekrar  bir ORA-600 aldığınızda önce kendi dökümanlarınızdan kontrol edip , daha önce karşılaştığınız bir hata ise çözüm için aynı işlem adımlarınızı uygulamanızı öneririm. Bu sizin çok daha kısa bir sürede çözüm bulmanızı sağlayacaktır.

İleriki yazılarımda bu konuda biraz daha detay bilgiler vermeye çalışacağım ve karşılaştığım bazı ORA-00600 hatalarının çözümlerinden bahsedeceğim.

Herkese ORA-600’süz günler dilerim.

 Caner Baştürk

Sonraki Sayfa »

WordPress.com'dan blog alın. | The Pool Theme.
Entries ve yorumlar feeds.

Takip Et

Her yeni yazı için posta kutunuza gönderim alın.