12c Veritabanında “ORA-29548: Java system class reported” Hatası Nasıl Çözülür?

Merhaba,

12.1.0.2.0 veritabanımıza PSU uyguladıktan sonra, uygulamamız aşağıdaki hatayı almaya başladı.

[Error] Execution (1: 1): ORA-29548: Java system class reported: release of classes.bin in the database does not match that of the oracle executable
ORA-06512: at “MDSYS.SDO_JAVA_STP”, line 370
ORA-06512: at “MDSYS.SDO_UTIL”, line 3188
ORA-06512: at “MDSYS.SDO_UTIL”, line 3211

Alert log dosyasını kontrol ettiğimde aşağıdaki hata ile karşılaştım.

joxcsys: release mismatch 12.1.0.2.160719 1.6 in database (classes.bin) vs 12.1.0.2.0 1.7 in executable

Veritabanımda INVALID obje olup olmadığını kontrol ettim. Ama herşey yolundaydı. Java ile ilgili küçük bir test yaptım.

SQL> select dbms_java.get_jdk_version() from dual
*
ERROR at line 1:
ORA-29548: Java system class reported: release of classes.bin in the database
does not match that of the oracle executable

Java ile ilgili bir uyumsuzluk vardı. Bu problemi aşmak için aşağıdaki scriptleri SYSDBA ile bağlanıp çalıştıralım.

SQL> @?/javavm/install/update_javavm_db.sql
SQL> SET FEEDBACK 1
SQL> SET NUMWIDTH 10
SQL> SET LINESIZE 80
SQL> SET TRIMSPOOL ON
SQL> SET TAB OFF
SQL> SET PAGESIZE 100
SQL>
SQL> alter session set “_ORACLE_SCRIPT”=true;

Session altered.

SQL>
SQL> — If Java is installed, do CJS.
SQL>
SQL> — If CJS can deal with the SROs inconsistent with the new JDK,
SQL> — the drop_sros() call here can be removed.
SQL> call initjvmaux.drop_sros();

Call completed.

SQL>
SQL> create or replace java system;
2 /

Java created.

SQL>
SQL> update dependency$
2 set p_timestamp=(select stime from obj$ where obj#=p_obj#)
3 where (select stime from obj$ where obj#=p_obj#)!=p_timestamp and
4 (select type# from obj$ where obj#=p_obj#)=29 and
5 (select owner# from obj$ where obj#=p_obj#)=0;

0 rows updated.

SQL>
SQL> commit;

Commit complete.

SQL>
SQL> alter session set “_ORACLE_SCRIPT”=false;

Session altered.

SQL>

Şimdi testimizi tekrar yapalım.

SQL> select dbms_java.get_jdk_version() from dual;

DBMS_JAVA.GET_JDK_VERSION()
——————————————————————————–
1.7.0_51

1 row selected.

SQL> select dbms_java.longname(‘TEST’) from dual
2 ;

DBMS_JAVA.LONGNAME(‘TEST’)
——————————————————————————–
TEST

1 row selected.

SQL>

 

Herşey yolunda. Uygulamamızın da sorunu çözülmüş oldu. Kolay gelsin.

Reklamlar

Kütahya Dumlupınar Üniversitesi “Dev Fest 2017” Etkinliğinde Buluşalım!

Flashback Veritabanı ile OPEN RESETLOGS İşlemi Nasıl Geri Alınır?

Merhaba,

“ALTER DATABASE OPEN RESETLOGS” komutu çalıştırıldıktan sonra Flashback Database ile veritabanımızı “OPEN RESETLOGS” öncesine geri sarabiliriz. Yanlışlıkla çalıştırılan bu komutun bir geri dönüşü var. Elbette bu komutu çalıştırmadan önce mutlaka flashback database özelliğini aktif etmiş olmanız gerekmektedir. Yoksa geçmiş olsun : ) Geri dönebilmek için “FLASHBACK DATABASE TO BEFORE RESETLOGS”  cümlesini kullanacağız.

“OPEN RESETLOGS ” işlemini geri almak için:

1. Veritabanına SQL*Plus ile bağlanalım ve flashback window’unun son OPEN RESETLOGS işlem zamanından önce olup olmadığını doğrulayalım. Bunun için aşağıdaki sorguları çalıştıralım.

SELECT RESETLOGS_CHANGE#
FROM V$DATABASE;

SELECT OLDEST_FLASHBACK_SCN
FROM V$FLASHBACK_DATABASE_LOG;

Eğer ilk sorgudaki RESETLOGS_CHANGE# kolonunun değeri, ikinici sorgudaki OLDEST_FLASHBACK_SCN kolununun değerinden büyük ise ozaman OPEN RESETLOGS  işlemini geri almak için Flashback Database özelliğini kullanabiliriz demektir. Aşağıdaki gibi devam edelim.

2. Veritabanını kapatalım

SHUTDOWN IMMEDIATE;

3. Mount moduna alalım

STARTUP MOUNT;

4. Flashback window’u tekrar kontrol edelim. Resetlogs SCN numarası bu zaman dilimi içindeyse sorun yok devam edebiliriz.

RMAN’e bağlanalım.
rman target /

5. Aşağıdaki komutla OPEN RESETLOGS öncesine veritabanımızı geri saralım.

FLASHBACK DATABASE TO BEFORE RESETLOGS;

FLASHBACK DATABASE özelliğini yukarıdaki komuttan farklı bir şekilde (until SCN, until TIME kullanarak) çalıştırırsak dahi ve target SCN numarası flashback veritabanı window’undan önce ise hata alırız ve geri sarma işlemini gerçekleştiremeyiz. komut başarılı tamamlandığında OPEN RESETLOGS işlemi öncesindeki son SCN ‘e geri dönmüşüzdür.

6. Veritabanımızı SQL*Plus ‘a bağlanığ read-only olarak açalım ve birtakım kontrol sorgularımızı çalıştıralım.

ALTER DATABASE OPEN READ ONLY;

7. Herşey yolunda ve istediğimiz gibi ise veritabanını kapatıp, mount moduna alalım. Aşağıdaki gibi OPEN RESETLOGS ile read-write olarak açabiliriz.

ALTER DATABASE OPEN RESETLOGS;

Kocaeli Üniversitesi Bilişim Teknolojileri Kulübü “IT Fest 2017” Etkinliğinde Buluşalım!

Primary Olarak Aktif Edilmiş Standby Veritabanını, Flashback ile Geri Alma

Merhaba Arkadaşlar,

Primary veritabanımız ulaşılamaz duruma geldiğinde standby veritabanımızı primary olarak aktif edip hayatımıza devam etmek isteyebiliriz. Bu durumda mutlaka flashback database özelliğini enable yapıp yola devam etmek büyük fayda sağlayabilir.

Örneğin tam standby veritabanını primary olarak aktif ettiniz ve bu esnada da önceki primary veritabanındaki problem çözüldü ve açıldı. Yönetimde önceki primary veritabanı ile devam etme kararı aldığını varsayalım. Bu durumda aktif ettiğimiz standby veritabanını eski haline yani standby veritabanına geri çevirmemiz lazım. Bunun için flashback database özelliğini kullanacağız.

Önce aktif edilen standby veritabanında aşağıdaki sorgu ile standby ‘ın aktif edilme anındaki SCN numarasını öğrenelim;

SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;

Aktif edilen standby veritabanını kapatıp mount modunda açalım. Ve yukarıdaki gibi öğrendiğimiz SCN numarasına flashback yapalım.

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn;

Aşağıdaki komutla primary olarak aktif edilen standby veritabanı tekrar standby veritabanına çevirelim.

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Redo transferini başlatmak için aşağıdaki kontrolleri yapalım.

Arşiv gönderilme hedefinin son durumuna aşağıdaki gibi bakalım.

SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;

Bu arşiv hedefi enable değilse, aşağıdaki gibi enable yapalım.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;

Redo ‘nun başarılı iletilip iletilmediğinden emin olduktan sonra, Standby veritabanında redo apply işlemini aşağıdaki gibi başlatabiliriz.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Redo apply işlemi role geçişi esnasında oluşan redoya geldiğinde durabilir. Bu durumda paniklemeye gerek yok. Redo apply işlemini, standby ‘ın primary olarak aktif edilme anını geçene kadar bir kaç kere başlatmak gerekebilir.

Unutulan SYSMAN Şifresini OEM Cloud Control 13c Üzerinde Nasıl Değiştiririz?

Merhaba,

Bu yazımızda unutulan SYSMAN şifresini OEM 13c üzerinde nasıl değiştireceğimizi adım adım öğreneceğiz.

1- SQL*Plus üzerinden SYMAN şifresini aşağıdaki gibi değiştirelim.

alter user sysman identified by “oracle_test”;

2- OEM 13c makinasında Middleware home dizinine gidelim.

cd /u01/app/oracle/middleware/bin/
./emctl config oms -list_repos_details
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
Repository Connect Descriptor : (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=oem13c)(PORT=1521)))(CONNECT_DATA=(SID=emrep)))
Repository User : SYSMAN

3- Yeni SYSMAN şifresini aşağıdaki gibi set edelim.

./emctl config oms -change_repos_pwd -use_sys_pwd -sys_pwd oracle_test -new_pwd oracle_test
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.

Changing passwords in backend …
Passwords changed in backend successfully.
Updating repository password in Credential Store…
Successfully updated Repository password in Credential Store.
Restart all the OMSs using ’emctl stop oms -all’ and ’emctl start oms’.
Successfully changed repository password.

4- OMS servislerini restart edelim.

./emctl stop oms -all
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
Stopping Oracle Management Server…
WebTier Successfully Stopped
Oracle Management Server Successfully Stopped
Oracle Management Server is Down
JVMD Engine is Down
Stopping BI Publisher Server…
BI Publisher Server Successfully Stopped
AdminServer Successfully Stopped
BI Publisher Server is Down

./emctl start oms
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
Starting Oracle Management Server…
WebTier Successfully Started
Oracle Management Server Successfully Started
Oracle Management Server is Up
JVMD Engine is Up
Starting BI Publisher Server …
BI Publisher Server Successfully Started
BI Publisher Server is Up

Oracle Enterprise Manager 13c Top Activity Sayfasında ‘Null Pointer Exception’ Hatası

Merhaba,

Oracle Enterprise Manager 13c ‘ye login olunduğunda Top Activity Sayfasında aşağıdaki şekilde olduğu gibi ‘Null Pointer Exception’ hatası alınmaktadır. Bu durum 25455462 numaralı bug’dan kaynaklanmaktadır. Çözüm için aşağıdaki adımlar takip edilmelidir.

1-OEM 13c makinasında use_pooled_target_connections property’si set edilir.

emctl set property -name use_pooled_target_connections -value false

2-OMS restart edilir.

cd /u01/app/oracle/middleware/bin/

./emctl stop oms -all
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
Stopping Oracle Management Server…
WebTier Successfully Stopped
Oracle Management Server Successfully Stopped
Oracle Management Server is Down
JVMD Engine is Down
Stopping BI Publisher Server…
BI Publisher Server Successfully Stopped
AdminServer Successfully Stopped
BI Publisher Server is Down

./emctl start oms
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.
Starting Oracle Management Server…
WebTier Successfully Started
Oracle Management Server Successfully Started
Oracle Management Server is Up
JVMD Engine is Up
Starting BI Publisher Server …
BI Publisher Server Successfully Started
BI Publisher Server is Up

%d blogcu bunu beğendi: