Im Februar wurden unsere DBs auf Exadata mit dem Januar-Bundle auf Version 19.26 gepatcht. Wir haben Dataguard im Einsatz und nutzen den Enterprise Manager Cloud Control in Version 13.25.
Kurz nach dem Patchen tauchten "ORA-00600: internal error code, arguments: [ktatmkref-rs]" auf den Standby-DBs auf. Ursache ist ein SQL aus dem EM Grid Control:
MODULE NAME:(emagent_SQL_rac_database)
ACTION NAME:(cdbjob_status)
----- Current SQL Statement for this session (sql_id=35k8v3jjhv3k6) -----
WITH cdb_last_failed_jobs AS
(
SELECT CON_ID,OWNER,JOB_NAME,MAX(ACTUAL_START_DATE) AS START_DATE
FROM CDB_SCHEDULER_JOB_RUN_DETAILS
WHERE STATUS = 'FAILED'
GROUP BY CON_ID, OWNER, JOB_NAME
......
Der EM Grid Control setzt das SQL in jeder DB alle 30 Minuten ab, darum bekamen wir über 1000 ORA-600 pro Tag! Natürlich haben wir einen Service Request bei Oracle geöffnet, das Hin und Her erspare ich uns hier.
Als Workaround wurde uns irgendwann empfohlen, die entsprechende Metrik im EM Grid Control auszuschalten:
Cluster Database -> Monitoring -> Metric and Collection Settings -> Reiter 'Other Collected Items' -> Database Job Status (All Pluggable Databases) -> Disabled
Schneller geht es direkt auf dem OMS-Server:
emcli login -username=sysman
emcli get_targets -targets=rac_database
emcli modify_collection_schedule -targetType="rac_database" -targetNames="rac_db1"
-collectionName="cdbjob_status" -collectionStatus=Disabled -preview="N"
Leider hörten die ORA-600 danach nicht auf, denn als Exadata-Kunde haben wir ein Gateway zu Oracle und einen Agenten, der von Oracle verwaltet wird und unter dem User orarom läuft. Dahinter steckt im Grunde ein weiteres EM Grid Control, das die gleichen SQLs absetzt und daher die gleichen ORA-600 produzierte. Tatsächlich ist es uns gelungen, einen Service Request an der richtigen Stelle zu platzieren, so dass Oracle die Metrik auf ihrer Seite ebenfalls disabled hat. Endlich Ruhe!
Dann ging es ans Aufräumen. In der EM Grid Control GUI gab es tausende Incidents vom Typ "Internal error () detected in ...". Statt in der GUI haben wir die Alerts direkt auf dem OMS Server gelöscht:
emcli login -username=sysman
emcli clear_stateless_alerts -older_than=# -target_type=oracle_database -
target_name=… -unacknowledged_only -ignore_notifications
Da auch das DIAG-Verzeichnis langsam volllief, mussten wir Incidents und Problems im adrci löschen und Files unter diag/rdbms/*/*/incident/incdir_##### und diag/rdbms/*/*/incpkg/pkg_### entfernen.
Doch zu früh gefreut. Nach einigen Tagen waren die ORA-600 zurück, und zwar die, die über das Oracle-Gateway kamen. Der Service Request war noch offen und der Bearbeiter so nett, die Metriken nochmals auszuschalten. Leider passiert es alle paar Tage wieder und wir fragen uns, wie lange der Bearbeiter noch bereit ist, die Metriken immer wieder neu zu disablen.
Zu dem Problem gibt es in MOS den Bug 37690446 "ORA-600 [KTATMKREF-RS] ERRORS IN THE ALERT LOG POST-PATCH 37260974" und inzwischen auch ein Dokument "Multiple Databases Impacted With ORA-600 [ktatmkref-rs] From Module: emagent_SQL_rac_database (Doc ID 3081404.1)". Der dort genannte Workaround, "parallel_force_local=true" zu setzen, hatte bei uns nicht den gewünschten Effekt. Wir warten weiter auf eine Lösung.
Dagmar Förster
