Permanentes Wachstum des ADR Homes
Housekeeping ist ein oft unterschätztes Thema beim Betrieb von Datenbanken. In einem vorherigen Blogbeitrag über die größenbasierte Lösch-Policy habe ich einen neuen Weg beschrieben, um die Größe eines ADR-Homes zu begrenzen. Aber was ist, wenn Oracle Databanken vor Version 12.2 im Einsatz sind? Dann muss man sich auf die vorhandenen zeitbasierten Lösch-Policies verlassen. Das haben wir für unsere Kunden getan. Vor ein paar Wochen hatte einer der Kunden ein Platzproblem im Dateisystem /u01 auf einer seiner ODAs. Die automatische Bereinigung funktionierte gut, aber der Füllstand des Dateisystems nahm immer noch zu. Die Enterprise Manager-Metrik zeigt dieses Verhalten recht deutlich.
Also begannen wir, dieses Verhalten zu untersuchen und landeten dabei im Trace-Verzeichnis einiger Datenbanken. Dies ist ein Beispiel von einer dieser Datenbanken.
[root@odax7-2m trace]# du -hs * | sort -h | tail -6
68M DOMEADD_gen0_82205.trm
69M DOMEADD_mmon_82354.trm
131M DOMEADD_ipc0_82195.trm
419M DOMEADD_gen0_82205.trc
423M DOMEADD_mmon_82354.trc
462M DOMEADD_ipc0_82195.trc
Am Ende des größten Tracefiles kamen immer wieder folgende Einträge hinzu.
[root@odax7-2m trace]# tail DOMEADD_ipc0_82195.trc
2019-03-15 09:23:07.749*:kjuinc(): no cluster database, return inc# KSIMINVL
*** 2019-03-15T09:23:10.913816+01:00
2019-03-15 09:23:10.913*:kjuinc(): no cluster database, return inc# KSIMINVL
Mit einer Suche nach diesen Meldungen in My Oracle Support fanden wir schnell Bug 27989556 Excessive Trace Message: no cluster database, return inc# ksiminvl. Undn natürlich gibt es Stand heute noch keinen Patch dafür.
Ok, nächste Datei, was steht dort drin?
[root@odax7-2m trace]# tail DOMEADD_mmon_82354.trc
AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1
*** 2019-03-15T09:29:55.474098+01:00
AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1
*** 2019-03-15T09:29:58.474092+01:00
AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1
Und wieder hat MOS die Antwort: AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1 Excessive Trace Files were generated on one node after Migration to 12.2 and MMON trace file grows (Doc ID 2298766.1). Zumindest gibt es dafür einen Patch.
Da das Patchen aber Downtime benötigen und ohnehin nur 50% der Probleme lösen würde, haben wir uns dagegen entschieden. Stattdessen haben wir folgenden simplen aber effektiven Workaround gebaut:
for i in $(find /u01/app/oracle/diag/rdbms -type f -name "*mmon*tr*"); do echo "" > $i; done
for i in $(find /u01/app/oracle/diag/rdbms -type f -name "*ipc0*tr*"); do echo "" > $i; done
Nachdem wir das ausgeführt hatten, sank die Auslastung des Dateisystems sofort. Die Bereinigung wird nun regelmäßig ber cron-Job ausgeführt. Im Enterprise Manager sah das am Ende so aus.
Kommentare
Keine Kommentare