Arşiv

Yazar Arşivi

BMO “Oracle Veritabanı Yedekleme Stratejileri” Eğitiminde Buluşalım!

03/01/2018 2 yorum

Kayıt için:

https://www.eventbrite.com/e/oracle-veritaban-yedekleme-stratejileri-talip-hakan-ozturk-tickets-41679079248

Reklamlar

Sakarya Üniversitesi Bilişim Teknolojileri Seminerleri Etkinliğinde Buluşalım!

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

05/11/2017 4 yorum

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.

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.

%d blogcu bunu beğendi: