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.

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.

12.2.0.1 grid üzerine 11.2.0.4 database kurulumunda PRVF-4037 hatası

PRVF-4037 hatası 11.2.0.3 versiyonundan beri bazı kurulumlarda ve clustera node eklerken yaşanabiliyor. Hatayı aldığınızda benzer semptromlar görüyorsanız bu yazımdaki çözümü uygulayabilirsiniz.

12.2.0.1 grid üzerine 11.2.0.4 database kurulumu yaparken prerequsite  check adımında aşağıda görülen hataları aldık.

More details alanına tıkladığımızda Hata detaylarının aşağıdaki gibi olduğunu gördük.

Error:

PRVF-4037 : CRS is not installed on any of the nodes  – Cause:  Could not identify a CRS installation on any node.  – Action:  Ensure that CRS is installed on all the nodes participating in the operation.

Operation Failed on Nodes: [exadata_node2, exadata_node1]
Verification result of failed node: exadata_node2

Details:

PRVF-7593 : CRS is not found to be installed on node “exadata_node2”  – Cause:  Could not identify CRS installation on the specified node.  – Action:  Ensure that CRS is installed on the specified node.
Back to Top
Verification result of failed node: exadata_node1

Details:

PRVF-7593 : CRS is not found to be installed on node “exadata_node1”  – Cause:  Could not identify CRS installation on the specified node.  – Action:  Ensure that CRS is installed on the specified node.
Back to Top

Hata mesajından yola çıkarak 12.2 grid ortamımızın integrity kontrollerini yaptık.

cluvfy comp crs

cluvfy comp ocr

Komutlar sonucunda crs ve ocr da bir problem olmadığını görüyoruz.

Bunun üzerine installer ın neye takıldığını analamak için oracle inventory altındaki  installActions logunu kontrol ediyoruz. Burada gördüğümüz kadarıyla Cluster nodes parametresi boş olarak gelmiş görünüyor.

Bunun sebebini anlamak için  /u01/app/oraInventory/ContentsXML altındaki inventory.xml dosyasını kontrol ediyoruz. We bu dosya altında da cluster nodeların tanımlı olmadığını görüyoruz.

<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2017, Oracle and/or its affiliates.
All rights reserved. -->
<!-- Do not modify the contents of this file by hand. -->
<INVENTORY>
<VERSION_INFO>
 <SAVED_WITH>12.2.0.1.4</SAVED_WITH>
 <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OraGI12Home1" LOC="/u01/app/12.2.0.1/grid" TYPE="O" IDX="1" CRS="true"/>
<HOME NAME="OraDB12Home1" LOC="/u01/app/oracle/product/12.2.0.1/dbhome_1" TYPE="O" IDX="2"/>
</HOME_LIST>
<COMPOSITEHOME_LIST>
</COMPOSITEHOME_LIST>
</INVENTORY>

Bu hatayı düzeltmek için grid home altında aşağıdaki komutu çalıştırıyoruz.

$GRID_HOME/oui/bin/runInstaller -silent -ignoreSysPrereqs -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={exadata_node1,exadata_node2}" CRS=true

Komutu çalıştırdıktan sonra inventory.xml dosyasını tekrar kontrol ettiğimizde cluster node ların artık burada set edildiğini görüyoruz.

<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2017, Oracle and/or its affiliates.
All rights reserved. -->
<!-- Do not modify the contents of this file by hand. -->
<INVENTORY>
<VERSION_INFO>
 <SAVED_WITH>12.2.0.1.4</SAVED_WITH>
 <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OraGI12Home1" LOC="/u01/app/12.2.0.1/grid" TYPE="O" IDX="1" CRS="true"/>
 <NODE_LIST>
 <NODE NAME="exadata_node1"/>
 <NODE NAME="exadata_node2"/>
 </NODE_LIST>
</HOME>
<HOME NAME="OraDB12Home1" LOC="/u01/app/oracle/product/12.2.0.1/dbhome_1" TYPE="O" IDX="2"/>
</HOME_LIST>
<COMPOSITEHOME_LIST>
</COMPOSITEHOME_LIST>
</INVENTORY>

11.2.0.4 kurulumunu tekrar denediğimizde de bu sefer hiçbir uyarı almadan kurulumumuzu tamamlıyoruz.

Bu komutu oracle support üzerinde   1316815.1  numaralı not içerisinde bulduk. Daha önceki bir versiyonda bir bug için önerilmiş. Siz de kurulumda benzer bir hata ile karşılaşıp aynı semptomları gözlerseniz bu komutu kullanbilirsiniz.