Oracle Database 10g: Der neue Scheduler lohnt der Umstieg?

Transkript

1 17.Deutsche ORACLE-Anwenderkonferenz Database Mittwoch, 10. November h00, Mozartsaal Oracle Database 10g: Der neue Scheduler lohnt der Umstieg? Dierk Lenz Herrmann & Lenz Services GmbH, Burscheid Schlüsselworte: Oracle Database 10g, Scheduler, Jobs, Batches Zusammenfassung Hier werden die Eigenschaften des bekannten, alten Schedulers denen des neuen Schedulers der Oracle Database 10g gegenübergestellt. Obwohl man sich in vielen Fällen mit dem alten Scheduler ganz gut eingerichtet hatte, bietet der neue eine ganze Menge sinnvoller Features. Einleitung Ein neues Feature der Oracle Database 10g, das nicht gerade im Rampenlicht steht, ist der neue Scheduler. Dies hat sicherlich damit zu tun, dass es bereits einen Scheduler gibt (eingeführt mit Oracle7, damals mit dem Hintergrund, den automatischen Refresh von Snapshots, heute Materialized Views, zu unterstützen). Dieser Vortrag beschäftigt sich mit den Unterschieden beider Scheduler, so dass am Ende abgewogen werden kann, ob der Umstieg lohnt. Denn wenn man zum gegenteiligen Ergebnis käme, ist es wie so oft bei den neuen Oracle Features (s.a. cost-based Optimizer, Objektanalyse durch dbms_stats,...): der "Alte" bleibt uns zunächst erhalten! Bemerkung: Im Folgenden werde ich die Bezeichnung "alter Scheduler" und "neuer Scheduler" für die beiden Scheduler verwenden, um diesen Text nicht länger als notwendig werden zu lassen. Weiterhin setze ich die Benutzung des alten Schedulers hier als bekannt voraus; ansonsten würde der Rahmen des Vortrags recht schnell gesprengt werden. Benutzung und Kontrolle Das Konzept zur Benutzung beider Scheduler weist zunächst einmal gewisse Ähnlichkeiten auf: Es existiert jeweils ein Package zur Einrichtung und Administration von Jobs (beim alten Scheduler dbms_job; beim neuen

2 KONFERENZ dbms_scheduler). Weiterhin gibt es einige DD-Views, die das Monitoring der Jobs erlauben. An dieser Stelle ist der erste Unterschied zu beobachten: Für den alten Scheduler gibt es die Views dba_jobs und dba_jobs_running, für den neuen stehen alleine 14 Views zur Verfügung, die alle mit dba_scheduler_ beginnen. Dies bedeutet einerseits, dass viel mehr Informationen zur Verfügung stehen andererseits müssen wir uns mal wieder mehr Viewnamen merken. Einige der Views werden im Folgenden vorgestellt. Bemerkung: Alle Views werden im Text mit dem Präfix dba_ angegeben. Wie bei Oracle üblich, existieren natürlich auch die entsprechenden user_ und all_ Varianten. Programme, Schedules und Jobs Als Einstieg betrachten wir zunächst, was die Scheduler bearbeiten können. Im Falle des alten Schedulers ist dies ein PL/SQL Block oder Ausdruck (vollständig, d.h. inklusive des abschließenden Semikolons!). Zusätzliche Funktionalität (Java, externe C-Routinen usw.) kann über entsprechende PL/SQL Funktionalität erreicht werden. Dies ist zwar recht rudimentär; andererseits lassen sich die meisten administrativen und anwendungsorientierten Tätigkeiten innerhalb der Datenbank recht einfach als PL/SQL Funktionalität darstellen. Beim neuen Scheduler kann zwischen drei Jobtypen gewählt werden: plsql_block (was in etwa dem alten Scheduler entspricht), stored_procedure (als direkte Möglichkeit, eine PL/SQL Prozedur aufzurufen) sowie executable (was erstmalig die Möglichkeit eröffnet, dirket aus dem Scheduler ein externes Programm auf Betriebssystemebene aufzurufen). Letzterer erweitert natürlich sofort die Palette der möglichen Anwendungen; man denke z.b. an regelmäßige Backups. Für Prozeduren und Executables können Parameterlisten definiert werden; an dieser Stelle gehe ich nicht weiter darauf ein. Wie beim alten Scheduler besteht die Möglichkeit, das Programm bei der Definition des Jobs anzugeben. Zusätzlich kann das Programm zunächst als eigene Einheit definiert werden, um dann im Scheduler nur noch referenziert zu werden. Hier ein Beispiel: EXEC dbms_scheduler.create_program (program_name => 'LS', - program_type => 'executable', - program_action => '/bin/ls', - number_of_arguments => 0, - enabled => FALSE, - comments => 'Just to test...') Existierende Programme können über die View dba_scheduler_programs angezeigt werden.

3 17.Deutsche ORACLE-Anwenderkonferenz Database Eine weitere Einheit, die separat definiert werden kann, ist der Schedule. Hierbei ist Schedule wohl am besten mit Zeitplan zu übersetzen. Zunächst auch hierzu ein Beispiel: EXEC dbms_scheduler.create_schedule (schedule_name => 'M_SCHED', - repeat_interval => 'FREQ=MINUTELY;BYSECOND=0', - comments => 'Will it Work?') Zur Abfrage der Schedules dient die View dba_scheduler_schedules. Jeder, der bereits einige Jobs mit Hilfe des alten Schedulers implementiert hat, wird wohl beim Anblick des repeat_interval Parameters erleichtert aufatmen: Die next_date Funktion des alten Schedulers erlaubte zwar durch den Zugriff auf die komplette DATE-Arithmetik des Oracle Kerns die Berechnung praktisch beliebiger Intervalle, die Lesbarkeit der resultierenden Ausdrücke war jedoch nicht immer gegeben. Zum Vergleich die beiden Ausdrücke für "Genau zu jeder Viertelstunde": Alter Scheduler: trunc(sysdate, 'HH24') + ((trunc(to_char(sysdate, 'MI') / 15) + 1) * 15) / (24 * 60) Neuer Scheduler: FREQ=HOURLY;BYMINUTE=0,15,30,45;BYSECOND=0 Die Beschreibung der FREQ-Klausel (nachzulesen im "PL/SQL Packages and Types Reference" Handbuch) nimmt fünf Seiten in Anspruch. Ein grober Eindruck der vielfältigen Möglichkeiten sollte hier entstanden sein (Beispiel: Jobs, die jede Sekunde laufen, sind kein Problem); weitere Details entnehmen Sie bitte direkt der Dokumentation. Nachdem Schedule und Programm definiert sind, kann man zur Definition des Jobs übergehen: EXEC dbms_scheduler.create_job (job_name => 'LS_JOB', - program_name => 'LS', - schedule_name => 'M_SCHED', - enabled => TRUE) Übersicht über Jobs erlangt man durch Abfragen der View dba_ scheduler_jobs. Ähnlich wie beim alten Scheduler findet man Dinge wie last_start_date, next_run_date, nls_env und einige weitere Informationen. Anstelle der Gesamtlaufzeit aller Runs findet man die last_run_ duration sowie die max_run_duration.

4 KONFERENZ Zusätzliche Informationen über jeden einzelnen Start eines Jobs findet man in den Views dba_scheduler_job_log und dba_scheduler_job_run_ details. Diese beiden Views ersparen z.b. bei der Problemanalyse das lästige Suchen nach und in Tracefiles der Job-Prozesse. Vordefinierte Jobs Beim Blick auf die View dba_scheduler_jobs stellt man fest, dass zwei Jobs in jeder 10g Datenbank vordefiniert sind: purge_log und gather_stats_job. Dahinter verbergen sich die Prozeduren dbms_scheduler.auto_purge und dbms_stats.gather_database_stats_job_proc. Dem Job purge_log ist der Schedule daily_purge_schedule zugeordnet. Die FREQ-Klausel hierzu lautet: FREQ=DAILY;BYHOUR=3;BYMINUTE=0; BYSECOND=0; m.a.w.: jede Nacht um drei Uhr. Aufgabe dieses Jobs ist es, die Log-Informationen der Jobläufe zu löschen, die älter sind als der Wert von log_history. Dieser steht per default auf 30 und kann als allgemeines Scheduler-Attribut geändert werden. Der zweite Job kalkuliert Statistiken für die Tabellen und Indizes in der Datenbank. Dies ist ein enormer Fortschritt: Der Oracle cost-based Optimizer begleitet uns seit Oracle7 und scheitert am häufigsten an nicht vorhandenen oder veralteten Statistiken. Diese Zeiten sind vorbei! Ein automatisch angelegter Job übernimmt dies! Bei der Frage, wann er dies tut, stößt man zunächst lediglich auf den Verweis maintenance_window_group. Dies hat mich persönlich zunächst einmal geschockt: Nachdem es mit 10g einen Papierkorb für Tablespaces gibt soll es jetzt auch Fenster in der Datenbank geben? Fenster und Fenstergruppen Glücklicherweise sind mit den Fenstern in Bezug auf den Scheduler lediglich Ausführungsfenster gemeint also regelmäßige Zeitabschnitte mit fester Länge. Grundsätzlich werden Fenster mit zwei Parametern definiert: einer FREQ-Klausel sowie einer Dauer. Die beiden vordefinierten Fenster sind weeknight_ window mit freq=daily;byday=mon,tue,wed,thu,fri;byhour=22; byminute=0;bysecond=0 und einer Dauer von 8 Stunden sowie weekend_ window mit freq=daily;byday=sat;byhour=0;byminute=0;bysecond=0 und einer Dauer von zwei Tagen. Übersetzt heißt das: an Wochentagen nachts zwischen 22:00 Uhr und 6:00 Uhr sowie am Wochende (Samstags 0:00 Uhr bis Sonntags 24:00 Uhr). Diese beiden Fenster sind mit der Fenstergruppe maintenance_window_group verknüpft. Zurück beim Job gather_stats_job heißt dies: es ist kein Schedule sondern eine Fenstergruppe definiert. Diese ist so definiert, dass Maintenance-Arbeiten mit der Datenbank in diesen Zeiten möglich sein sollen. Und genau dann läuft der entsprechende Job!

5 17.Deutsche ORACLE-Anwenderkonferenz Database Natürlich werden sich jetzt einige DBAs beschweren: Unmöglich! Um 22:00 Uhr geht bei unserer XY-DB die Verarbeitung erst richtig los! Und meine Anwender kommen bereits um 4:30 Uhr; um 6:00 Uhr machen die die erste Pause! Keine Sorge: Der gather_stats_job läßt sich löschen bzw. problemlos einem anderen Schedule bzw. einer selbstdefinierten Fenstergruppe zuordnen... Allerdings könnte der Job die Ursache sein, falls tatsächlich schon "Performanceeinbrüche" gegen 22:00 Uhr festgestellt worden sind! Jobklassen Um einige Parameter übergreifend für eine Gruppe von Jobs zu definieren, können diese einer Jobklasse zugeordnet werden. Für die Jobklasse kann z.b. ein eigener Wert für log_history (Anzahl Tage zur Aufbewahrung von Logs) gesetzt werden. Die Zuordnung zu bestimmten Instanzen für RAC-Installationen wird über die Benennung eines service vorgenommen. Nur solche Instanzen, die diesen Service anbieten (im Systemparameter service_names), können Jobs aus der Jobklasse ausführen. Eine weitere Möglichkeit ist die Zuordnung einer Resource Consumer Group zur Jobklasse. Hiermit sind Priorisierungen usw. möglich. Sicherheitsaspekte Ein immer wieder auftauchendes Ärgernis beim alten Scheduler ist die Tatsache, dass Jobs ausschließlich unter dem Account des Job-Erstellers ausgeführt werden können. D.h. die View dba_jobs gibt zwar einen sehr guten Überblick über die vorhandenen Jobs; zur Ausführung von Jobs (z.b. Restart nach Fehlern) muss man sich immer wieder neu anmelden. Beim neuen Scheduler ist eine ganze Reihe neuer Privilegien etabliert worden, so dass die oben genannten Probleme nicht mehr gültig sind. Um Programme, Schedules und Jobs zu erzeugen, benötigt man das Privileg CREATE JOB; um Schema-übergreifend zu arbeiten CREATE ANY JOB. Schedulerobjekte wie Jobklassen, Fenster und Fenstergruppen können mit dem Privileg MANAGE SCHEDULER angelegt werden. Um beliebige Programme (innerhalb eigener Jobs) auszuführen benötigt man EXECUTE ANY PROGRAM; zur Ausfürhrung beliebiger Jobklassen EXECUTE ANY CLASS. Die Rolle SCHEDULER_ADMIN enthält alle diese Privilegien mit ADMIN-Option; sie ist in der DBA-Rolle enthalten.

6 KONFERENZ Weiterhin besteht die Möglichkeit, Objektprivilegien zu vergeben. Für Programme und Jobklassen kann das EXECUTE-Privileg vergeben werden (z.b. zur Erstellung von Jobs im fremden Schema). Für Jobs, Programme und Schedules kann weiterhin das ALTER-Privileg vergeben werden. Hiermit kann u.a. die Jobausführung einem anderen Benutzer erlaubt werden. Voraussetzungen für den ersten Start Die ersten Versuche, den neuen Scheduler in Betrieb zu nehmen, scheitern meist an zwei Dingen: 1. Das allgemeine Scheduler-Attribut Standardzeitzone muss gesetzt sein. Das passiert mit dem Befehl: dbms_scheduler.set_scheduler_attribute ('default_timezone', 'Europe/Berlin') 2. Wahrscheinlich aus dem Grund, dass beim ersten Instanzstart das o.a. Attribut nicht gesetzt ist, muss die Instanz einmal neu gestartet werden. Im Übrigen ist der Wert von job_queue_processes unerheblich für den neuen Scheduler. Die zentrale Koordination wird für beide Scheduler vom Central Job Queue Coordinator (CJQ0) übernommen. Die maximale Anzahl von Prozessen für den neuen Scheduler wird nicht durch den Systemparameter, sondern durch das Scheduler-Attribut max_job_slave_processes gesetzt. Fazit Die Empfehlung lautet ganz klar: Ausprobieren! Bei meinen "Versuchen" habe ich keinerlei Probleme feststellen können. Alleine das ausführliche Logging ist für wichtige Tasks ein guter Grund, Jobs auf den "Neuen" umzustellen. Viel Erfolg! Kontaktadresse: Dierk Lenz Höhestraße 37 D Burscheid Telefon: +49(0) Fax: +49(0) Internet: