Arşiv

Yazar Arşivi

TROUG High Availability SIG Meeting 2018 – İstanbul Üniversitesi

Merhaba,

TROUG 2018’in ilk etkinliği High Availability SIG tarafından gerçekleştirilecek. Etkinlikte Data Guard, Backup gibi Oracle’ın High Availability (yüksek erişilebilirlik) konusunda nasıl çözümler getirdiğinden bahsedilecek.

10:30 – 11:00: Açılış Konuşması (Talip Hakan ÖZTÜRK – Oracle ACE)
11:00 – 11:45: High Availability (Güneş Erol – Oracle ACE)
11:45 – 12:00: Ara
12:00 – 12:45: Oracle 12c Dataguard Architecture (Fethullah Çabuk)
13:00 – 14:00: Yemek Arası
14:00 – 14:45: Oracle Veritabanı Backup Best Practices – Yaşanmış Olaylar (Talip Hakan ÖZTÜRK – Oracle ACE)
14:45 – 15:00: Ara
15:00 – 15:45: Understanding Performance in Oracle Active Data Guard Far Sync (Alain Azagury – VP Research & Development, Axxana)
Tarih ve Lokasyon:
27 Şubat 2018, İstanbul Üniversitesi Avılar Kampüsü, Ali Rıza Berkem Konferans Salonu
Etkinlik Kayıt Formu:
http://www.troug.org/haberler/high-availability-sig-meeting-2018/

Üniversite Giriş Kayıt Formu:

https://www.eventbrite.com/e/bilfest18-tickets-42860927187

 

Reklamlar

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

Kayıt için:

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

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?

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!

%d blogcu bunu beğendi: