12c upgrade sonrası ORA-600 [qkebCreateColById:1] ORA-00600 hatası

Mevcut bir tablo üzerinde sonradan eklenen bir kolon hem not null consraint hem de defult value ile birlikte eklenirse.  O kolonun property değeri  1073741824 olarak set ediliyor. Bu değer bu buga benzeyen birçok farklı buga neden oluyor.

Bizim sorumunuzda mevcut bir tablodaki bir kolonda bu problem bulunuyordu. Bu durumdan etkilenen kolonunuz olup olmadığınız aşağıdaki sorgu ile görebilirsiniz.

select a.obj#,c.name table_name,a.intcol#,a.name column_name,a.property,b.guard_id
from col$ a,ecol$ b,obj$ c
where a.obj#=b.tabobj#
and a.intcol#=b.colnum
and a.obj#=c.obj#
and a.property=1073741824
and a.null$=0
and b.guard_id is null;

Tablodaki problemli kolon haricinde select çektiğimizde tablo düzgün sonuç veriyordu ama ilgili kolonu sorguya eklediğimizde ora-600 hatası alıyorduk.

Aynı zamanda bu tablo üzerinde gece çalışan istatistik jobının da hata aldığını alert logda gördük.aldığımız hata aşağıdaki gibiydi.

ORA-00600: internal error code, arguments: [qksvcGetGuardCol:2], [16408], [0], [], [], [], [], [], [], [], [], []

 

Bu hatanın çözümü için oracle supporta sr açtık. Ve benzer bugda uygulanan aşağıdaki işlemler ile problemimiz çözüldü.

Note 17325413.8 – Bug 17325413


 

Compatible parametresi set edilir.

ALTER SYSTEM SET compatible=’12.2.0.1′ SCOPE=SPFILE;

Database stop start ediyoruz. bizim veritabanlarımız cluster olduğu için aşağıdaki komutları kullandık.

Srvctl stop database –d prod

Srvctl start instance –d prod–i prod1,prod2

ilgili constraint kaldırılıp yeniden eklendi.

 

alter table vpef.T_BRANCH_ACCOUNTANT modify (IDENTIFIER_AUTHORITY_CODE null);

alter table vpef.T_BRANCH_ACCOUNTANT modify (IDENTIFIER_AUTHORITY_CODE not null enable novalidate);

 

ve problemimiz çözüldü

12c upgrade catalog hatası

11.2.0.4 veritabanlarımızı 12.2.0.1 versiyonuna upgrade etmeye başladığımızda backuplar için mevcut kataloğumuzu da upgrade etme ihtiyacımız oluştu. Katalog veritabanı versiyonumuz 11.2.0.4 olarak kalırken üzerindeki catalog veritabanının versiyonunu 12.2 olarak upgrade edecektik. Ama bu işlemi yaparken.  bir hata ile karşılaştık. Upgrade işlemi yaparken aşağıdaki support dökümanındaki adımları takip ettik. Catalog veritabanında iki adet prosedür çalıştırtıyor.

How to upgrade RMAN catalog SCHEMA from 11g to 12.1.0.2 without upgrading the catalog database (Doc ID 1970049.1)

İlgili nottaki işlemleri tamamladıktan sonra , catalog veritabanına bağlanıp upgrade komutunu verdiğimizde aşağıdaki hatayı aldık.

RMAN>
RMAN> upgrade catalog;
PL/SQL package RMANUSER.DBMS_RCVMAN version 11.02.00.04 in RCVCAT database is too old
recovery catalog owner is RMANUSER
enter UPGRADE CATALOG command again to confirm catalog upgrade
RMAN> upgrade catalog;
PL/SQL package RMANUSER.DBMS_RCVMAN version 11.02.00.04 in RCVCAT database is too old
error creating modify_bdf_pdb_key_not_null
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-02296: cannot enable (RMANUSER.) - null values found

ilgili hatayı supportta incelediğimizde bir bug a benzediğini gördük ( Bug 20861957. ) . Ama bizdeki durum biraz farklıydı.  Normalde bu bug, incarnation kaydı bulunmayan( orphan ) controlfile backupları için geçerliydi ve 12.2 de bu bug fixed olarak görünüyordu. Biz 12.2 versiyonu kullandığımızdan çözülmüş olması gerekirdi.

Aşağıdaki komut ile orphan controlfile kaydımız olmadığını doğruladık.

select * from RMANUSER.bcf where not exists (select 1 from RMANUSER.dbinc where dbinc.dbinc_key = bcf.dbinc_key);

Ancak catalogdaki orphan kayıtlara bakarken. Datafile backupları için birçok orphan kayıt olduğunu gördük.

select * from RMANUSER.bdf where not exists (select 1 from RMANUSER_RESTORE_TEST.dbinc where dbinc.dbinc_key = bdf.dbinc_key);

Aşağıdaki komut ile eski incarnationlardan kalan orphan kayıtları sildik. Öncelikle ilgili kayıtları select ederek kontrol etmekte fayda var. bizde eski restore testlerinden kalan kullanılmayan incarnationlardan kayıtlar vardı ve bu kayıtları sildik.

delete bdf where not exists (select 1 from RMANUSER_RESTORE_TEST.dbinc where dbinc.dbinc_key = bdf.dbinc_key);

Daha sonra upgrade katalog komutunu çalıştırdığımızda catalog başarılı bir şekilde upgrade oldu. Hem 11.2.0.4 hem de 12.2.0.1 veritabanlarımızdan bu catalog’a backup alabilir hale geldik.

Veritabanlarınızın, rman client ve catalog versiyonu uyumluluklarına (Doc ID 73431.1) notundan bakabilirsiniz.

Sequence Row cache lock incelemesi

Row cache lock inceleme:

Sistemde bir sequence den yapılan selectlerin çok uzun sürmeye başladığını gözlemledik. Bunun birden fazla nedeni olabilir.

 

Problem yaşadığımız sequence nocache bir sequence, cache miktarını arttırmanın problemimizi çözüp çözmeyeceğini incelemek  ve kök nedeni bulmak için aşağıdaki adımları gerçekleştirdim.

Öncelikle aşağıdaki sorgu ile shared pool boyutunun yeterli olup olmadığı incelenir.

select parameter ,
getmisses "MISS",
gets "READ",
100 - (100 * (sum(getmisses)/sum(gets))) "% Success"
from v$rowcache
where gets > 0 and
parameter = 'dc_sequences'
group by
parameter, getmisses , gets
order by 4 desc;

 

sorgu sonucunda miss oranımızın çok düşük olduğunu görüyoruz bu da bize shared pool size değerimizin yeterli olduğu fikrini veriyor.


Bundan sonra sequence’i cache leme işlemini deneyeceğiz.

Örnek sequence ve tablo oluşturdum.

CREATE TABLE TAHSINC.TEST_TABLE ( ID NUMBER(38));

CREATE SEQUENCE TAHSINC.TEST_SEQUENCE
 START WITH 1
 MAXVALUE 9999999999999999999999999999
 MINVALUE 1
 NOCYCLE
 NOCACHE
 NOORDER
/

Tabloyu doldurmak için. Aşağıdaki gibi bir loop yazıyoruz. Tek bir session açarak aşağıdaki sorguyu çalıştırıyoruz.

 

set lines 10000;
set pages 10000;
set timing on;

ALTER SESSION SET TRACEFILE_IDENTIFIER = "SEQUENCE_TEST_SESSION";

ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';

begin
for i in 1..1000000 loop
insert into TAHSINC.TEST_TABLE (ID) values (TAHSINC.TEST_SEQUENCE.nextval);
end loop;
commit;
end;
/

ALTER SESSION SET EVENTS '10046 trace name context off';

1.000.000 adet insert işlemimiz 5 dakika sürüyor.

Diagnostic destten trace dosyamızı buluyoruz. Set ettiğimiz trace identifier ile dosyayı kolayca buluyoruz

cd /u01/app/oracle/diag/rdbms/testdb/testdb2/trace/

trace dosyamızın ismi testdb2_ora_387821_SEQUENCE_TEST_SESSION.trc

Trace dosyamızı okunabilir hale getirmek için tkprof tool’unu kullanıyoruz.

tkprof testdb2_ora_387821_SEQUENCE_TEST_SESSION.trc translated.txt explain=tahsinc/your_password  table=sys.plan_table sys=no waits=yes

 

tkprof dosyasının içeriğine baktığımızda tek session üzerinden yapılan insert işlemlerinde bir row cache lock waiti olmadığını görüyoruz.

Bunun ardından üç ayrı sessiondan insert işlemini simultane olarak çalıştırmayı deniyoruz.

Sessionlardan sadece birini yine aşağıdaki gibi traceliyoruz.

lines 10000;
set pages 10000;
set timing on;

ALTER SESSION SET TRACEFILE_IDENTIFIER = "SEQUENCE_TEST_SESSION2";

ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';

begin
for i in 1..1000000 loop
insert into TAHSINC.TEST_TABLE (ID) values (TAHSINC.TEST_SEQUENCE.nextval);
end loop;
commit;
end;
/

ALTER SESSION SET EVENTS '10046 trace name context off';

3 session olarak çalıştırdığımızda. Bir session ortalama 13 dakikada tamamlanıyor.

Yeni oluşan trace dosyamızı tkprof ile okunabilir hale getiriyoruz.

tkprof testdb2_ora_387821_SEQUENCE_TEST_SESSION2.trc translated.txt explain=tahsinc/your_password  table=sys.plan_table sys=no waits=yes

bir önceki denememizden farklı olarak işlem yoğunluğunun row cache lock üzerinde oluştuğunu görüyoruz. 6 dakikanun üzerinde beklemeye neden oluyor.


Şimdi aynı işlemi sequence cache miktarını arttırdıktan sonra deniyoruz.

Alter sequence TAHSINC.TEST_SEQUENCE cache 1000;

 

set lines 10000;
set pages 10000;
set timing on;

ALTER SESSION SET TRACEFILE_IDENTIFIER = "SEQUENCE_TEST_SESSION3";

ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';

begin
for i in 1..1000000 loop
insert into TAHSINC.TEST_TABLE (ID) values (TAHSINC.TEST_SEQUENCE.nextval);
end loop;
commit;
end;
/

ALTER SESSION SET EVENTS '10046 trace name context off';

 

Cache miktarını 1000 olarak arttırdığımızda 1 dakika 20 saniyede işlem tamamlanıyor.

Trace dosyasını incelediğimizde. Cache miktarını arttırmamız 3 simultane bir milyonluk insert işlemindeki 380 saniyelik wait’ i 7 saniyeye düşürüyor.

 

Sonuç olarak düşük cache li ya da cache siz sequencelerinizde row cache lock wait görüyorsanız. Ve shared pool boyutunuz yeterliyse. sequence e cache ekleme ya da cache arttırma işlemi yapmanız performansınızı arttıracaktır.

 

Exadata database and grid home manuel sıralı patch geçme EXADATA(Aug2017 – 11.2.0.4.170814)


Oracle Versiyon: 11.2.0.4.8

OS : Oracle Linux 6 (Linux x86-64)

patch number:26610265

patch: Oracle Database Patch For EXADATA(Aug2017 – 11.2.0.4.170814)


Yazının devamında Exadata X3-2 Full rac için database ve grid home a 11.2.0.4.170814 patch inin manuel rolling olarak geçilmesi anlatılmıştır. Exadata genel patch bilgileri için Doc ID 888828.1 incelenebilir.

Öncelikle patch geçilecek database ve grid home daki Opatch en güncel seviyeye getirilir. En güncel opatch versiyonu için oracle supporttan Doc ID 274526.1 yi takip edebilirsiniz.

Burada dikkat etmeniz gereken nokta database versiyonunuza uygun opatch i indirmeniz.

NOT: Patch geçmeden önce patch dosyası içerisinden çıkan readme dosyasını dikkatli şekilde okuyunuz. Bilinen hatalar (known issues) alanını öncelikle kontrol ediniz.

Daha sonra versiyonumuza uygun olarak indiriğimiz opatch dosyasını database ve grid home altına kopyalıyoruz. Full exadata üzerinde çalıştığımız için tek tek uğraşmamak adına bu işlemleri dcli ile yapacağız. Öncelikle bir ftp programıyla tüm nodelara indirdiğimiz opatch dosyasını kopyalıyoruz. biz /u02/source/patch/ dizini altına kopyaladık.

Opatch Güncelleme

  1. dcli ile tüm nodelarda zipli dosyayı açıyoruz.
  2. Eski OPatch klasörümüzü sonuna tarih ekleyerek yedekliyoruz.
  3. Yeni opatch klasörümüzü oracle home altına kopyalıyoruz.
  4. Grid  home altında da kopyalama işlemini gerçekleştiriyoruz.
cd /opt/oracle.SupportTools/onecommand/

 dcli -g dbs_group -l oracle "unzip /u02/source/patch/p6880880_112000_Linux-x86-64.zip -d /u02/source/" 
 dcli -g dbs_group -l oracle "mv /u01/app/oracle/product/11.2.0.4/dbhome_1/OPatch /u01/app/oracle/product/11.2.0.4/dbhome_1/Opatch_14_10_2017"
 dcli -g dbs_group -l oracle "cp -R /u02/source/OPatch /u01/app/oracle/product/11.2.0.4/dbhome_1/"
 dcli -g dbs_group -l oracle "cp -R /u02/source/OPatch /u01/app/11.2.0.4/grid/"

kontrol için aşağıdaki komutu çalıştırabiliriz.

dcli -g dbs_group -l oracle "/u01/app/oracle/product/11.2.0.4/dbhome_1/OPatch/opatch version"
dcli -g dbs_group -l oracle "/u01/app/11.2.0.4/grid/OPatch/opatch version"

Patch Dosyasını Kopyalama

bir ftp programıyla tüm nodelara indirdiğimiz patch dosyasını kopyalıyoruz. ardından.

  1. md5sum ile dosyanın düzgün kopyalandığını kontrol ediyoruz.
  2. patch dosyasını unzip ediyoruz.
  3. kontrol ediyoruz.
dcli -g dbs_group -l oracle "md5sum /u02/source/patch/p26610265_112040_Linux-x86-64.zip"

dcli -g dbs_group -l oracle "unzip /u02/source/patch/p26610265_112040_Linux-x86-64.zip -d /u02/source/patch/11204_170814/" 
 
dcli -g dbs_group -l oracle "ls -lrt /u02/source/patch/11204_170814/"

PREPATCH

Enterprise manager agent’ı  stop edilir.

dcli -g dbs_group -l oracle "/u01/agent/agent_13.2.0.0.0/bin/emctl stop agent"

Oracle userı ile db home üzerinden çalışan tüm prosesler stop edilir. Bunun için servisleri açarken kullanılacak bir status.txt dosyası üretilir.  aşağıdaki scripti 1. node olan exadatanoe1 üzerinde çalıştırıyoruz.

/u01/app/oracle/product/11.2.0.4/dbhome_1/bin/srvctl stop home -o /u01/app/oracle/product/11.2.0.4/dbhome_1 -s /u02/source/status.txt -n exadatanoe1

Sonrasında aşağıdaki scripti çalıştırarak grid proseslerini durdurarak grid home u patch geçmeye hazır hale getiriyoruz.

/u01/app/11.2.0.4/grid/crs/install/rootcrs.pl -unlock

grid proseslerinin kapandığını kontrol etmek için diskmon prosesini grepleyebiliriz.

ps -ef | grep diskmon

PATCH

Grid PATCH

Unzip edilen patch dosyasının içine girilerek. Grid home ownerı ile aşağıdaki scriptler çalıştırılır. Bizde grid home userı oracle

 

cd /u02/source/patch/11204_170814/

/u01/app/11.2.0.4/grid/OPatch/opatch napply -oh /u01/app/11.2.0.4/grid -local /u02/source/patch/11204_170814/26610265/26609769

/u01/app/11.2.0.4/grid/OPatch/opatch napply -oh /u01/app/11.2.0.4/grid -local /u02/source/patch/11204_170814/26610265/26609929

/u01/app/11.2.0.4/grid/OPatch/opatch napply -oh /u01/app/11.2.0.4/grid -local /u02/source/patch/11204_170814/26610265/22502505

aşağıdaki komut ile kontrol edilebilir. Örnek çıktısı aşağıdaki gibi olmalıdır.

/u01/app/11.2.0.4/grid/OPatch/opatch lsinventory -detail -oh /u01/app/11.2.0.4/grid | grep 11.2.0.4.170814
Patch description: "OCW Patch Set Update : 11.2.0.4.170814 (26609929)"
Patch description: "DATABASE PATCH FOR EXADATA (Aug 2017 - 11.2.0.4.170814) : (26609769)"

Database PATCH

Database home owner ile aşağıdaki script çalıştırılır.

/u02/source/patch/11204_170814/26610265/26609929/custom/server/26609929/custom/scripts/prepatch.sh -dbhome /u01/app/oracle/product/11.2.0.4/dbhome_1

Burada bizim önceden geçtiğimiz bir one of patch ile çakışma yaşandığını gördük. Öncelikle böyle bir conflict durumu ile karşılaşırsanız conflict olan patch i aşağıdaki gibi kaldırabilirsiniz.

opatch rollback -id 19995869

Sonrasında yine database home owner ile aşağıdaki komutlar çalıştırılarak patch geçilir.

/u01/app/oracle/product/11.2.0.4/dbhome_1/OPatch/opatch napply -oh /u01/app/oracle/product/11.2.0.4/dbhome_1 -local /u02/source/patch/11204_170814/26610265/26609769

/u01/app/oracle/product/11.2.0.4/dbhome_1/OPatch/opatch napply -oh /u01/app/oracle/product/11.2.0.4/dbhome_1 -local /u02/source/patch/11204_170814/26610265/26609929/custom/server/26609929

POST PATCH

patch işlemi tamamlandıktan sonra aşağıdaki script çalıştırılır. oracle user ile

/u02/source/patch/11204_170814/26610265/26609929/custom/server/26609929/custom/scripts/postpatch.sh -dbhome /u01/app/oracle/product/11.2.0.4/dbhome_1

Root user ile aşağıdaki scriptler çalıştırılır. Bu scriptler grid proseslerini de ayağa kaldırıyor.

/u01/app/11.2.0.4/grid/rdbms/install/rootadd_rdbms.sh
/u01/app/11.2.0.4/grid/crs/install/rootcrs.pl -patch

Oracle user ile aşağıdaki script çalıştırılarak patch öncesi node üzerinde çalışan prosesler tekrar start edilir.

/u01/app/oracle/product/11.2.0.4/dbhome_1/bin/srvctl start home -o /u01/app/oracle/product/11.2.0.4/dbhome_1 -s /u02/source/status.txt -n exadatanoe1

Sonrasında aynı işlemler diğer db nodelar üzerinde tekrarlanır. tüm node lar bittiğinde em agent da yeniden açılır.

dcli -g dbs_group -l oracle "/u01/agent/agent_13.2.0.0.0/bin/emctl start agent"

ROLLBACK

patch geçisinde en başta yapılan stop işlemleri tekrarlanır. (srvctl stop home ve rootcrs.pl -unlock).

Grid home rollback

###ROLLBACK######
/u01/app/11.2.0.4/grid/OPatch/opatch rollback -local -id 26609769 -oh /u01/app/11.2.0.4/grid 
 
/u01/app/11.2.0.4/grid/OPatch/opatch rollback -local -id 26609929 -oh /u01/app/11.2.0.4/grid 
 
/u01/app/11.2.0.4/grid/OPatch/opatch rollback -local -id 22502505 -oh /u01/app/11.2.0.4/grid 
###ROLLBACK######

Database home rollback

#### ROLLBACK #####
/u01/app/oracle/product/11.2.0.4/dbhome_1/OPatch/opatch rollback -local -id 26609769 -oh /u01/app/oracle/product/11.2.0.4/dbhome_1

/u01/app/oracle/product/11.2.0.4/dbhome_1/OPatch/opatch rollback -local -id 26609929 -oh /u01/app/oracle/product/11.2.0.4/dbhome_1
####ROLLBACK #####

 

postpach scripti tekrar çalıştırılır.

/u02/source/patch/11204_170814/26610265/26609929/custom/server/26609929/custom/scripts/postpatch.sh -dbhome /u01/app/oracle/product/11.2.0.4/dbhome_1

patch sonrası çalıştırılan start scriptleri tekrarlanır. (rootcrs.pl -patch , srvctl start home )

Oracle database jvm componenti kaldırma


Oracle Versiyon: 11.2.0.4.8

OS : Oracle Linux 6 (Linux x86-64)


Oracle yayınladığı bundle patchlerde jvm patchlerini bundle a katmıyor, bu durum patch geçme işlemlerinde eksta iş yükü anlamına geliyor. Birçok veritabanında JVM kullanılmıyor olmasına rağmen bazen belki lazım olur diye bazen de bilgisizlikten kurulabiliyor.

JVM DBCA üzerinden kaldırılamadığından deinstall edilmesi  için birtakım manuel işlemler gerekiyor.

Öncelikle JVM in kullanılmadığından emin olmak gerekiyor. Spatial, Multimedia gibi özellikler kullanılıyorsa JVM ön gereksinim olarak kurulması gerekiyor. Yani Oracle veritabanının spatial ya da multimedia gibi özellikleri kullanıyorsanız JVM i kaldıramazsınız.

Öncelikle JVM in yüklü olup olmadığını tespit etmek için aşağıdaki scipti kullanabilirsiniz.

set line 1000;
set pagesize 1000;
col COMP_ID format a15;
col COMP_NAME format a40;
select COMP_ID,COMP_NAME,STATUS from dba_registry;

Ayrıca aşağıdaki sorgu ile veritabanında JVM option kullanan bir obje olup olmadığını kontrol etmek için de aşağıdaki sorguyu kullanabiliriz.

SELECT owner, object_type, status, COUNT(*)
 FROM dba_objects
 WHERE object_type LIKE '%JAVA%' and owner NOT IN ('EXFSYS','SYS')
 GROUP BY owner, object_type, status
 ORDER BY owner, object_type, status;

Bu sorguda JVM kurulu olduğunda default olarak gelen objeleri exclude etmek için EXFSYS ve SYS alıntaki objeleri exclude  ettik. Bizde informatica ve spatial kurulu sunucumuzda sorgu sonucu aşağıdaki gibi geliyor.

 

Kaldırma işlemine başlamadan önce aşağıdaki notu incelemekte fayda var. Burada kaldırma işlemi esnasında ya da sonrasında yaşayabileceğiniz problemleri önceden kontrol edebilirsiniz.

How to Reload the JVM in 11.2.0.x (Doc ID 1112983.1)

İşleme başlamadan önce bir tur utlrp çalıştırıp sonrasında mevcut invalid obje sayınızı bir yere not etmeniz faydalı olabilir.

Kaldırma işlemi için öncelikle vi ile full_rmjvm.sql isimli bir dosya oluşturuyoruz ve içeriğini aşağıdaki şekilde dolduruyoruz. ( sciprt 1112983.1 nolu dökümandan alınmıştır.)

-- Start of File full_rmjvm.sql
spool full_rmjvm.log
set echo on
connect / as sysdba
startup mount
alter system set "_system_trig_enabled" = false scope=memory;
alter system enable restricted session;
alter database open;
@?/rdbms/admin/catnoexf.sql
@?/rdbms/admin/catnojav.sql
@?/xdk/admin/rmxml.sql
@?/javavm/install/rmjvm.sql
truncate table java$jvm$status;
select * from obj$ where obj#=0 and type#=0;
delete from obj$ where obj#=0 and type#=0;
commit;
select owner, count(*) from all_objects
where object_type like '%JAVA%' group by owner;
select obj#, name from obj$
where type#=28 or type#=29 or type#=30 or namespace=32;
select o1.name from obj$ o1,obj$ o2
where o1.type#=5 and o1.owner#=1 and o1.name=o2.name and o2.type#=29;
shutdown immediate
set echo off
spool off
exit
-- End of File full_rmjvm.sql

Scripti çalıştırmadan önce veritabanını shutdown komutu ile kapatmanız gerekiyor. Sciprti oluşturduğumuz path e giderek. kapalı veritabanına sqlplus ile bağlandıktan sonra @full_rmjvm.sql yazarak enter a basıyoruz ve script çalışmaya başlıyor.

Ve aşağıdaki gibi yeniden veritabanını shutdown ederek sonlanıyor.

Sqlplus ile veritabanına tekrar bağlanarak veritabanını açıyoruz.

@?/rdbms/admin/utlrp.sql ile tekrardan objeleri derleyip invalid obje olup olmadığını kontrol ediyoruz.

select * from dba_objects where status='INVALID';

Sonrasında option kontrol scriptini tekrar çalıştırıyoruz.

set line 1000;
set pagesize 1000;
col COMP_ID format a15;
col COMP_NAME format a40;
select COMP_ID,COMP_NAME,STATUS from dba_registry;

işlem sonrası çıktı aşağıdaki gibi olmalıdır. JVM ile birlikte yüklenen diğer komponentlerin de kaldırıldığını görebiliriz. JAVAVM XML ve CATJAVA componentleri kaldırılıyor. Buradaki XML’i XML DB ile karıştırmamak lazım. ORACLE XDK isimli XML paketi kaldırılıyor sadece.  Kaldırılan componentlerin statüleri removed olarak görünüyor.

Aşağıdaki sorguyu tekrar çektiğimizde de hiçbir sonuç dönmemesi lazım.

SELECT owner, object_type, status, COUNT(*)
 FROM dba_objects
 WHERE object_type LIKE '%JAVA%' and owner NOT IN ('EXFSYS','SYS')
 GROUP BY owner, object_type, status
 ORDER BY owner, object_type, status;

İşlem tamamlandıktan sonra işlemin yapıldığı path te oluşan full_rmjvm.log dosyası incelenebilir.

 

CELL-02578 CELL-05503 exadata cell validate mail Hatası

Exadata Cell node üzerinde smtp configürasyonunu test ederken aşağıdaki gibi bir hata ile karşılaştık.

CellCLI> alter cell validate mail 

CELL-02578: An error was detected in the SMTP configuration: CELL-05503: An error was detected during notification. The text of the associated internal error is: Invalid Addresses. 
The notification recipient is BTVeritabani@tahsincan.com.tr. 

Cell üzerindeki mail konfigürasyonumuz aşağıdaki gibiydi. Ve address doğru görünüyordu.

smtpFrom: exadatacell2
 smtpFromAddr: exadatacell2@tahsincan.com.tr
 smtpPort: 25
 smtpServer: mail.tahsincan.com.tr
 smtpToAddr: BTVeritabani@tahsincan.com.tr
 smtpUseSSL: FALSE

Bunun üzerine aşağıdaki yöntem ile smtp sunucumuza bağlanarak ayarlarda belirtilen adresler ile mail atıp atamadığımızı control ettik. Aşağıda yapılan testi farklı durumlarda da smtp sunucunuzdaki relay haklarınızı kontrol etmek için yapabilirsiniz.

[root@exadatacell2celadm01 log]# curl telnet://mail.tahsincan.com.tr:25
 220 ESG Service is ready.
 ehlo x
 250-Websense email protection service
 250-SIZE 26214400
 250-STARTTLS
 250-AUTH PLAIN LOGIN
 250-ENHANCEDSTATUSCODES
 250 8BITMIME
 mail from:exadatacell2@tahsincan.com.tr
 250 2.1.0 Ok
 rcpt to:tahsincan@tahsincan.com.tr421 4.4.2 mail.tahsincan.com.tr Error: timeout exceeded
 [root@exadatacell2celadm01 log]# rcpt to:tahsincan@tahsincan.com.tr
 -bash: rcpt: command not found
 [root@exadatacell2celadm01 log]#
 [root@exadatacell2celadm01 log]#
 [root@exadatacell2celadm01 log]# curl telnet://mail.tahsincan.com.tr:25
 220 ESG Service is ready.
 ehlo
 501 Syntax: EHLO hostname
 mail from:exadatacell2@tahsincan.com.tr
 250 2.1.0 Ok
 rcpt to:tahsincan@tahsincan.com.tr
 554 5.7.1 Error: need authentication from xxx.xxx.xxx.xxx
 421 4.4.2 mail.tahsincan.com.tr Error: timeout exceeded

Error: need authentication from xxx.xxx.xxx.xxx hatası bize exadata cell node ip mizin, smtp sunucumuzda relay izni olmadığını gösteriyor.

Smtp suncuda ilgili ip ye relay izni verdikten sonra kontrol ettiğimizde mailin başarılı bir şekilde atıldığını görüyoruz.

CellCLI> alter cell validate mail
Cell exadatacell2celadm01 successfully altered

 

Silinen bir şemayı backup tan geri döndürme

Hata sonucunda silinen ya da datalarının bir kısmı bozulan bir şemayı, aldığımız düzenli backuplardan ya da aldığımız bir export dosyasından geri döndürebilirz.

Bu yazıda rman backup ile geri döndürme işlemlerini anlatacağız.

12c versiyonunda bir tabloyu direk backuptan dönme imkanımız var ama 11g de tablo restore işlemini direk olarak yapamıyoruz. 11g versiyonunda birçok şema içerisinde sadece bir şemamızda bozulma varsa ve sadece bu şemayı geri döndürmek istiyorsak db yi başka bir yere restore etmemiz gerekiyor. Aksi taktirde db deki diğer şemaları da eski haline döndürmemiz gerekir. Aynı sunucu üzerinde farklı bir instance olarak ya da doğrudan farklı bir sunucuya restore işlemini gerçekleştirmemiz gerekiyor. Biz örneğimizde farklı bir sunucuya restore edeceğiz ve restore ettiğimiz veritabanından ilgili şemayı export import işlemi ile canlı veritabanına aktaracağız.

Restore işlemini yaparken de şema boyutumuzun, db nin toplam boyutuna oranına göre tüm veritabanını ya da belirli datafile ları restore edebiliriz. Örneğimizde restore ettiğimiz veritabanının adı castprd. Restore işlemini yaparken canlı sunucuda ve dbrestore sunucumuzda 11.2.0.4 database imiz kurulu olduğundan kurulum admınlarını anlatmadan sadece yeni veritabanı oluşturarak restore etme adımlarını anlatacağım.

Bu yazıda veritabanının tamamını restore etme işlemini anlatacağız. Şemamız database toplam boyutuna göre çok küçükse ve ayrı bir tablespace üzerinde bulunuyorsa sadece belirli talbespaceleri restore ederek, veritabanının tamamını restore etmeden de şemamızı kurtarabiliriz. Eğer şemanız dbnin toplam boyutuna göre çok küçükse ilgili yazımızı inceleyebilirsiniz.

Öncelikle canlı veritabanına bağlanarak bir pfile oluşturmamız gerekiyor.

sql> create pfile from spfile;

Normal durumda bir lokasyon vermediğimiz için pfile dosyamız $ORACLE_HOME/dbs dizini altında oluşur.

cat komutu ile init ora dosyamızın içeriğine bakabiliriz. Bu içeriği bir notepad dosyasına atarak gereksiz parametreleri sileceğiz.

Aşağıdaki parametreler database i restore etmemiz için yeterli olacaktır.

*.audit_file_dest='/u01/app/oracle/admin/castprd/adump'
*.audit_trail='db'
*.compatible='11.2.0.4.0'
*.control_files='/u02/oradata/castprd/control01.ctl','/u02/oradata/castprd/control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='castprd'
*.db_unique_name='castprd'
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=castprdXDB)'
*.filesystemio_options='SETALL'
*.local_listener='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dbgensrv3)(PORT=4551)))'
*.log_archive_dest_1='LOCATION=/u02/archive/castprd'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_format='archcastprd_%t_%s_%r.arc'
*.log_archive_max_processes=10
*.open_cursors=300
*.pga_aggregate_target=536870912
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=450
*.sga_target=1073741824
*.undo_tablespace='UNDOTBS1'

Restore edeceğimizi sunucuda $ORACLE_HOME/dbs dizini altında initcastprd.ora isminde bir dosya oluşturuyoruz. Ardından gerekli folderları oluşturuyoruz.

[oracle@DBRESTORE dbs]$ vi initcastprd.ora

Audit dest’i oluşturmazsak veritabanı açılırken aşağıdaki gibi bir hata alabilir.

SQL> startup nomount;
ORA-09925: Unable to create audit trail file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 9925

Bu hatayı almamak için aşağıdaki komutlarla klasörleri oluşturuyoruz.

[oracle@DBRESTORE dbs]$ mkdir -p /u02/oradata/castprd/
[oracle@DBRESTORE dbs]$ mkdir -p /u01/app/oracle/admin/castprd/adump

Oracle SID set ederek sqlplus ile veritabanımızı açıyoruz.

[oracle@DBRESTORE dbs]$ export ORACLE_SID=castprd
[oracle@DBRESTORE dbs]$
[oracle@DBRESTORE dbs]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Tue May 9 11:31:51 2017
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size 2260088 bytes
Variable Size 381682568 bytes
Database Buffers 679477248 bytes
Redo Buffers 5517312 bytes
SQL>

Backup loglarımızdan db yi dönmek istediğimiz tarihteki backup ın loguna bakarak backup sonunda alınan controlfile ın hangi piece içerisinde olduğunu kontrol ediyoruz.

Ekran görüntüsünde de gördüğümüz gibi conrolfile qfs362iu_1_1 isimli piece içerisinde. Buna göre restore scriptimizi aşağıdaki gibi yazıyoruz. Biz backuplarımızı IBM tivoli tape ler üzerinde tutuyoruz. Bu nedenle backup için channel açarken bu tape tanımlarının ayarlarını yaptık. Siz burada channel açarken backupları tuttuğunuz ortama göre configürasyon yapmanız gerekiyor.

set until time “to_date(‘2017-05-01:20:00:11’, ‘yyyy-mm-dd:hh24:mi:ss’)”; komutunu veritabanımızı dataların bozuk olmadığını bildiğimiz.  ‘2017-05-01 saat gece 01:20 ye kadar restore edebilmek için kullanıyoruz.

run
{
allocate channel ch1 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_castprd.opt)';
restore controlfile from 'qfs362iu_1_1';
sql 'alter database mount';
set until time "to_date('2017-05-01:20:00:11', 'yyyy-mm-dd:hh24:mi:ss')";
RESTORE DATABASE;
recover database;
release channel ch1;
}

restore logunun bir kısmını aşağıdaki ekran görüntüsünde görebilirsiniz.

Bu komut ile restore ve recover işlemini tamamladıktan sonra eğer catalog kullanıyorsak  veritabanını sqlplus a geçerek açmamız gerekiyor.  Aksi taktirde canlıdan yeni backup almaya çalıştığımızda aşağıdaki gibi hata verecektir.

RMAN-20011 "target database incarnation is not current in recovery catalog"

Sqlplus a geçerek aşağıdaki komutla db yi açıyoruz.

alter database open resetlogs;

Restore ortamında açtığımız db de ihtiyacımız olan şemayı aşağıdaki komut ile export ediyoruz.

expdp \'/ as sysdba\'schemas=2017_DIGIPLATFORM_CENTRAL dumpfile=cast_digi_yedek_09_05_2017.dmp logfile=cast.log directory=DUMP_DIR

Bundan sonra canlıdaki ilgili şemayı drop ederek boş bir şekilde oluşturabiliriz. Sadece tablo datalarını değiştirmek istiyorsak da aşağıdaki komuttaki gibi. TABLE_EXISTS_ACTION=REPLACE parametresini kullanabiliriz. Bu parametre import ederken mevcutta olan tabloları drop create etmenizi sağlayacaktır.

impdp \'/ as sysdba\'schemas=2017_DIGIPLATFORM_CENTRAL dumpfile=cast_digi.dmp logfile=cast_imp.log directory=DUMP_DIR TABLE_EXISTS_ACTION=REPLACE

Bu şekilde veritabanı içerisindeki  2017_DIGIPLATFORM_CENTRAL şemamızı 1 mayıs tarihine döndürmüş olduk.

Yazı ile ilgili sorularınızı comment olarak sorabilirsiniz. Kapsamlı bir konu olduğundan bazı kısımların bilindiğini farzederek yazdım.

Oracle 12.2 ile Online tablespace şifreleme TDE (Transparent Data Encryption)

Oracle 12c release 2 versiyonuyla gelen özellik sayesinde artık tablespaceleri canlı olarak şifreleyebiliyoruz(ENCRYPT).

Öncelikle bir tablespace’i encpt etmediğimiz durumlarda karşılaşabileceğimiz durumları inceleyelim.

12.2 veritabanımıza bağlanarak users tablespace üzerinde bir tablo oluşturup, bu tabloya bir kayıt ekleyeceğiz. Sonrasında da sadece işletim sisteminde read yetkisi olan birinin, tabloya yazdığımız bu datayı görüp göremediğini kontrol edeceğiz.

[oracle@exadata_node1 ~]#sqlplus / as sysdba
SQL*Plus: Release 12.2.0.1.0 Production on Tue Apr 11 15:59:28 2017
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
SQL> create table tahsinc.very_important_data
( name varchar2(50),
 kimlik varchar2(20)
)
tablespace users; 2 3 4 5
Table created.
SQL> insert into tahsinc.very_important_data values ('Tahsin','12345678901234567890');
1 row created.
SQL> commit;
Commit complete.
SQL> alter system checkpoint;
System altered.

Checkpoint komutu çalıştırarak yaptığımız insert işleminin datafile a yazıldığına emin oluyoruz. Sonrasında ilgili datafile’ı asmden normal bir dizine kopyalarak strings komutu ile içeriğine bakıyoruz.

Ekran görüntüsünde de gördüğümüz üzere Tabloya insert olarak attığımız değerleri açık olarak görebiliyoruz. Bu durumda datafilelarımızı bir şekilde kötü ellere düşerse veritabanı kurmadan bile verilerimize erişme şansı oluyor.

Bunun önüne geçmek için Oracle ın sağladığı TDE özelliği ile artık online olarak da tablespacelerimizi encrypt edebiliyoruz.

Tabloyu encrypt etmek için öncelikle bir ketstore oluşturmamız gerekiyor.  v$encryption_wallet  tablosundan veritabanının mevcutta gördüğü wallet lokasyonunu kontrol ediyoruz. Bizim veritabanımızda bu alan default olarak  /u01/app/oracle/admin/TESTDB/wallet olduğundan aşağıdaki işlemleri bu dizine göre yapacağız. Sırasyıla aşağıdaki komutları çalıştırıyoruz.

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/oracle/admin/TESTDB/wallet' identified by Deneme123;
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY Deneme123;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY Deneme123 with backup;

Keystore’u tanımladıktan sonra aşağıdaki şekilde talbespace imizi online olarak encrypt edebiliyoruz. Bizde datafile asm üzerinde tutulduğundan db file name management auto olduğundan yeni tablespace ismi vermiyoruz. Ama datafile’ınız asm üzerinde değilse komut sonuna FILE_NAME_CONVERT=(‘users’,’users_enc_ts’)  komutunu ekleyerek tablespace’in adını da değiştirebilirsiniz.

alter tablespace users ENCRYPTION ONLINE USING 'AES192' ENCRYPT;

Bu işlem sonrasında tekrar işletim sistemi üzerinden  strings komutu ile datafile’ın içeriğine bakıyoruz. eklediğimiz kayıtları datafile içerisinde grepliyoruz ancak bir sonuç alamıyoruz. Bu da datafile’ımızın başarılı bir şekilde encrypt edildiğini gösteriyor.

 

ORA-28040 – no matching authentication protocol

ORA-28040 – no matching authentication protocol. ORA-28040 Eşleşen doğrulama protokolü yok.

12.2.0.1 upgrade işlemini yaptıktan sonra 11g client ile 12.2.0.1 veritabanına bağlanmaya çalıştığımızda  ORA-28040 hatası aldık.

Bu hatanın çözümü için database ve grid home altında sqlnet.ora dosyasına aşağıdaki parametrelieri ekledik.

vi /u01/app/oracle/product/12.2.0.1/dbhome_1/network/admin/sqlnet.ora

SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 8
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
vi /u01/app/12.2.0.1/grid/network/admin/sqlnet.ora

SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 8
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8

Parametreleri cluster’ın tüm node’larında ekledikten sonra, SCAN listener dahil tüm listenerları restart ettik.

Support üzerindeki dökümanda  SEC_CASE_SENSITIVE_LOGON parametresi FALSE olarak set edildiyse parametreyi  8 e olarak set edilmesi

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8

SEC_CASE_SENSITIVE_LOGON parametresi TRUE ise de 10 olarak set edilmesi gerektiği belirtilmiş.

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 10

Biz SEC_CASE_SENSITIVE_LOGON parametresi TRUE olan  12.2.0.1 veritabanı ve 11g client için  “8”   olarak set ettik ve hatadan kurtulduk. Eğer tüm uygulama ve clientlarınızda 11g üzeri client kullanıyorsanız bu parametreyi 11 olarak de set edebilirsiniz.

Eğer  E-BUsiness Suite 12.0kullanıyorsanız   sqlnet_ifile.ora dosyasını da SEC_CASE_SENSITIVE_LOGON parametresine göre set etmeniz gerekiyor.

Exadata db node üzerinde yeni disk oluşturma

Exadata db nodelar üzerindeki fisiksel diskler ilk kurulumda bir logical volume e atanmış olarak geliyor. Bu nedenle disk eklerken ve büyütürken linux logical volume yönetme komutlarını kullanacağız. Öncelikle mevcut sistem durumuna bakmak için aşağıdaki komutları kullanabiliriz.

Exadata X6-2 quarter rac üzerinde komutların çıktıları aşağıdaki gibidir. pvdisplay komutu ile fiziksel diskleri görebiliriz.

root@exadata_node1 ~]#pvdisplay
 --- Physical volume ---
 PV Name /dev/sda2
 VG Name VGExaDb
 PV Size 114.00 GiB / not usable 4.00 MiB
 Allocatable yes
 PE Size 4.00 MiB
 Total PE 29184
 Free PE 7424
 Allocated PE 21760
 PV UUID mExRS4-yLkj-8mq6-LTug-d4xZ-fwHl-2kYob3

 --- Physical volume ---
 PV Name /dev/sda3
 VG Name VGExaDb
 PV Size 1.52 TiB / not usable 1.95 MiB
 Allocatable yes
 PE Size 4.00 MiB
 Total PE 399124
 Free PE 347924
 Allocated PE 51200
 PV UUID HWptgO-6DEq-P2Tf-IJlK-tHyH-wnzn-8NoO8F

vgdisplay komutu ile bu fiziksel diskler üzerinde tanımlanmış logical volume grupları görebiliriz. Mevcut sistemde VGExaDb isminmde bir adet volume grubumuz var. Free PE alanında gördüğümüz VGExaDb  volume grubumuzun üzere de 1.3 TB boş alan var. Bu alan gerektiği anlarda mevcut disklerin snapshotlarını alabilmemiz veya yeni disk ekleyebilmemiz için boş olarak geliyor.

root@exadata_node1 ~]#vgdisplay
 --- Volume group ---
 VG Name VGExaDb
 System ID
 Format lvm2
 Metadata Areas 2
 Metadata Sequence No 17
 VG Access read/write
 VG Status resizable
 MAX LV 0
 Cur LV 6
 Open LV 4
 Max PV 0
 Cur PV 2
 Act PV 2
 VG Size 1.63 TiB
 PE Size 4.00 MiB
 Total PE 428308
 Alloc PE / Size 72960 / 285.00 GiB
 Free PE / Size 355348 / 1.36 TiB
 VG UUID V4rqmL-Efaq-ASFt-jo6a-46Cs-VS9B-uTaUPr

lvdisplay komutu ile de volume gruplarımız üzerindeki lofical volumeleri listeleyebiliriz. tek bir logical volume listelemek için lvdisplay LV Path olarak da çalıştırabiliriz. Liste uzun olduğundan sadece LVDbOra1 için çıktıyı paylaşıyorum.

root@exadata_node1 ~]#lvdisplay /dev/VGExaDb/LVDbOra1
 --- Logical volume ---
 LV Path /dev/VGExaDb/LVDbOra1
 LV Name LVDbOra1
 VG Name VGExaDb
 LV UUID W6gknw-WoKo-LuzB-G1Ov-aIBP-uNlZ-L9yeo9
 LV Write Access read/write
 LV Creation host, time exadata_node1.kkbdomain.com, 2017-03-07 14:30:19 +0300
 LV Status available
 # open 1
 LV Size 100.00 GiB
 Current LE 25600
 Segments 1
 Allocation inherit
 Read ahead sectors auto
 - currently set to 256
 Block device 251:3

Sistemde bu kontrolleri yaptıktan sonra adım adım yeni diskimizi oluşturabiliriz. Bunun için kullanacağımız komut lvm lvcreate komutu. Bu komuta -n parametresi ile logical volume ismini -l parametresi ile size bilgisini ve volume grup bilgisini ileteceğiz. Biz mevcut sistemimizde bir adet /u02 oluşturduğumuz için örnekte yeni diskimizi /u03 olarak oluşturacağız.

lvm lvcreate -n LVDbOra3 -L100G VGExaDb

,

Oluşturduğumuz logical volume’u aşağıdaki gibi kontrol edebiliriz.

/u01 diskgrubumuz ext4 olarak formatlandığı için yeni disk grubumuzu da ext4 olarak formatlayacağız.

formatladığımız diske label atamak için e2label komutunu kullanacağız.

e2label /dev/VGExaDb/LVDbOra3 DBORA3

Sunucu reboot olduğunda yeni diskimizin otomatik mount olması için gerekli bilgileri fstab a yazmamız gerekiyor. Burada her ihtimale karşı fstabın bir yedeğini alabilirsiniz. eklenecek satır LABEL=DBORA3 /u03 ext4 defaults,nodev 1 1

root@exadata_node1 ~]#vi /etc/fstab

Root dizini altında bir adet /u03 dizini oluşturarak diskimizi buraya mount ediyoruz. Ve /u01 diskinin owner’ı root:oinstall olduğu için yeni diskimizin owner’ını da bu şekilde düzenliyoruz.

mkdir /u03

mount -t ext4 /dev/VGExaDb/LVDbOra3 /u03 
ya da 
mount -a

chgrp oinstall /u03

İşlemler bir db node üzerinde tamamlandığında diğer nodelar üzerinde de aynı işlemleri tekrarlamamız gerekiyor. Eklediğimiz bu yeni disklerde farklı versiyonlarda oracle home lar kullanarak ihtiyaca göre birbirinden yalıtabiliriz.