Solaris 10 Üzerine Oracle11G R2 Silent Installation Problemi
30/08/2010, 13:00 | Kurulum kategorisinde yayınlandı | Yorum bırakınEtiketler: at oracle.install.ivw.db.driver.DBInstaller.run(DBInstaller.java:123), java.lang.NoClassDefFoundError, oracle11, Oracle11G R2 Silent Installation, runInstaller -silent -ignoreSysPrereqs, silent installation, Türkçe Oracle
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 YorumEtiketler: logminer, oracle logminer, Türkçe Oracle
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ınEtiketler: NLS_DATE_FORMAT, Türkçe Oracle, Yeni Parametreler
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ınEtiketler: ORA-00600, ORA-600, ORA-600 Nedir, Türkçe Oracle
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.