Neues vom SYSAUX-Tablespace Vol. II

Veröffentlicht am von

Vor einiger Zeit hatten wir ja schon einmal über die Freuden der Objektverwaltung im SYSAUX-Tablespace berichtet (s. HIER).

Heute aus aktuellem Anlass eine kleine Geschichte für all jene, die sich auch darüber wundern, warum Abfragen gegen Data Dictionary Views, hier insbesondere diejenigen, die den Job Scheduler betreffen, immer so lange dauern. Es könnte evtl. an diesem Umstand liegen:

Alle Informationen über existierende Scheduler Jobs sowie deren vergangene Ausführungen werden in der Tabelle SCHEDULER$_EVENT_LOG, auch sichtbar über die View DBA_SCHEDULER_JOB_LOG, gespeichert.

Eigentlich für 30 Tage. Manchmal aber auch FÜR IMMER.

In der Definition der Prozedur DBMS_SCHEDULER.PURGE_LOG() heißt es :

The PURGE_LOG procedure purges rows from the job and window log that were not purged automatically by the scheduler.
By default, the Scheduler automatically purges all rows in the job log and window log that are older than 30 days. The PURGE_LOG procedure can be used to purge additional rows from the job and window log.

Quelle: Oracle PL/SQL Packages and Types Reference 19c, Juli 23

Es existiert in der Tat ein Scheduler Job namens PURGE_LOG in der Default Job Class, dessen Aufgabe genau die Ausführung der o.g. Prozedur ist; der Default ist wie per Dokumentation beschrieben die Löschung der History-Einträge älter als 30 Tage. Aus nicht bekannten Gründen scheint dieser Job u.U. nicht zu laufen – und in diesem Fall entsteht das hier beschriebene Problem. Wir haben bei Kunden Einträge aus 2015 in einer Tabelle mit knapp 2 Mio. Einträgen gesehen. Diese Tabelle muss jedes Mal, wenn eine Abfrage gegen eine View wie z.B. DBA_SCHEDULER_JOBS oder DBA_SCHEDULER_JOB_RUN_DETAILS ausgeführt wird, komplett gelesen werden. Das kann dann schon mal ein paar Dutzend Sekunden (!) dauern.

Abhilfe schafft es tatsächlich, die purge_log Prozedur manuell auszuführen. Als Eingabeparamter kann eine Zahl von aufzubewahrenden Tagen angegeben werden. Ohne Angabe von Tagen wird keine Historie verwahrt.

Ausführung also wie folgt:

SQL> execute DBMS_SCHEDULER.PURGE_LOG();

PL/SQL procedure successfully completed.

Nun möchte man evtl. noch den gewonnenen Platz wieder im SYSAUX-Tablespace freigeben. Das geht so (ggfs. muss man zuvor noch Row Movement für die Tabelle ermöglichen):

SQL> alter table SCHEDULER$_EVENT_LOG shrink space cascade;
alter table SCHEDULER$_EVENT_LOG shrink space cascade
*
ERROR at line 1:
ORA-10636: ROW MOVEMENT is not enabled


SQL> alter table  SCHEDULER$_EVENT_LOG enable row movement;

Table altered.

SQL> alter table SCHEDULER$_EVENT_LOG shrink space cascade;

Table altered.

Zum Schluss noch neue Statistiken für die Tabelle sowie ein Index-Rebuild:

SQL> exec DBMS_STATS.gather_table_stats('SYS','SCHEDULER$_EVENT_LOG');

PL/SQL procedure successfully completed.

SQL> alter index SCHEDULER$_INSTANCE_PK rebuild;

Index altered.

Fertig!

Bei dem Kunden, bei dem das Problem aufgefallen ist, wurde der Scheduler Job PURGE_LOG nach der manuellen Bereinigung auch plötzlich wieder wie vorgesehen automatisch nachts ausgeführt und eingeplant.

Dieses Verfahren ist von Oracle supported und wird im MOS-Artikel

How To Purge DBA_SCHEDULER_JOB_LOG and DBA_SCHEDULER_WINDOW_LOG (Doc ID 443364.1)

beschrieben.

Schreibe einen Kommentar