Solaris 10 Üzerine Oracle11G R2 Silent Installation Problemi

30/08/2010, 13:00 | Kurulum kategorisinde yayınlandı | Yorum bırakı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 bırakı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

ORA-600 Nedir?

21/12/2009, 13:11 | ORA-600 kategorisinde yayınlandı | Yorum bırakı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

WordPress.com'da Blog Oluşturun.
Entries ve yorumlar feeds.