Frage zu Oracle-Job

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo,

ich habe mal einen Job eingerichtet

DECLARE
v_jobno BINARY_INTEGER;
BEGIN
DBMS_JOB.SUBMIT(v_jobno,
‚dbms_stats.gather_schema_stats (ownname =>‘‚SCOTT‘’, cascade => true, method_opt => ‚‚FOR ALL INDEXED COLUMNS‘‘, estimate_percent =>20 );’,
SYSDATE,
‚TRUNC(SYSDATE) + 1 + 20/24‘);
COMMIT;
END;
/

mit welchem Befehl kann ich den außer der Reihe starten ?

Gibt es eine schönere Lösung wie man einen Job zu Analyze bauen kann ?

Grüße

Chris

#2

Hallo Chris!

mit welchem Befehl kann ich den außer der Reihe starten ?

So:
DBMS_JOB.RUN (job IN BINARY_INTEGER, force IN BOOLEAN DEFAULT FALSE);
Das steht übrigens leicht auffindbar in der Doku, hättest du also durchaus auch selbst finden können…

Gibt es eine schönere Lösung wie man einen Job zu Analyze
bauen kann ?

Was gefällt dir an deiner derzeitigen Lösung nicht?

Gruß
Martin

#3

Hallo Martin,

DBMS_JOB.RUN (job IN BINARY_INTEGER, force IN BOOLEAN
DEFAULT FALSE);
Das steht übrigens leicht auffindbar in der Doku, hättest du
also durchaus auch selbst finden können…

ja, ich weiß, ich habe mir mittlerweile auch schon ein paar Bücher zugelegt, aber da komme ich gerade nicht dran ich bin nicht in meinem Büro

Gibt es eine schönere Lösung wie man einen Job zu Analyze
bauen kann ?

Was gefällt dir an deiner derzeitigen Lösung nicht?

Es ist nur eine reine Interessensfrage, da ich das nach dem Testverfahren zusammengebastelt habe (Script suchen, anpassen, testen, anpassen…)

Grüße

Chris

#4

Hallo Chris,

Das steht übrigens leicht auffindbar in der Doku, hättest du
also durchaus auch selbst finden können…

ja, ich weiß, ich habe mir mittlerweile auch schon ein paar
Bücher zugelegt, aber da komme ich gerade nicht dran ich bin
nicht in meinem Büro

In dem Fall ist http://tahiti.oracle.com immer recht hilfreich :wink:. Nur um’s nochmal klarzustellen, ich denka ich war vorhin etwas rüde: Ich habe kein Problem damit, solche Fragen zu beantworten, würde aber trotzdem JEDEM, der sich mit Oracle beschäftigt die Lektüre der Doku dringend empfehlen! Da stehen Sachen drin, die auch mich immer wieder einmal überraschen (nach dem Motto: Was, so einfach geht das?).

Gibt es eine schönere Lösung wie man einen Job zu Analyze
bauen kann ?

Was gefällt dir an deiner derzeitigen Lösung nicht?

Es ist nur eine reine Interessensfrage, da ich das nach dem
Testverfahren zusammengebastelt habe (Script suchen, anpassen,
testen, anpassen…)

Damit ich dir helfen kann eine schönere Lösung zu finden, müsste ich aber trotzdem wissen, was deiner Meinung nach die derzeitige Lösung zu einer nicht-schönen macht. DBMS_JOB ist ja nun wirklich nicht so besonders unelegant (und ziemlich genau dafür gedacht).

Gruß,
Martin

#5

Hallo Martin

In dem Fall ist http://tahiti.oracle.com immer recht hilfreich

Ja, stimmt, da hab ich auch schon mal gesucht, aber meißt hilft auch schon eine Suche bei google :wink: den dann geht´s meißt schon.

Mit der Frage ob´s schöner geht brauchst du dich nicht weiter aufzuhalten, wenn du sagst das das so in Ordnung ist, dann glaub ich dir das.

Aber Zusatzfrage, wenn ich jetzt jeden Lauf mitloggen will (hat mir gerade einer gesagt das das gewünscht ist) bekomme ich das noch in dem Job direkt unter, oder muß ich dann eine Funktion basteln die ich mit dem Job starte oder sowas ? Also genauer es ist gewünscht das man irgendwo ein „Erfolgreich beendet“ lesen kann… *grübel*

Grüße

Chris

#6

Aber Zusatzfrage, wenn ich jetzt jeden Lauf mitloggen will
(hat mir gerade einer gesagt das das gewünscht ist) bekomme
ich das noch in dem Job direkt unter, oder muß ich dann eine
Funktion basteln die ich mit dem Job starte oder sowas ? Also
genauer es ist gewünscht das man irgendwo ein „Erfolgreich
beendet“ lesen kann… *grübel*

Grüße

Chris

Hallo Chris,

wir haben das immer so gelöst, dass wir je Projekt / Applikation eine „Job-Logging-Tabelle“ hatten, in die jeder Job bei Ende (ob normal oder explodiert) einen Satz schrieb. Diese Tabelle ist dann immer die Grundlage für Statistiken der Jobs gewesen.

hth,
Guido

#7

Hallo Chris,

Mit der Frage ob´s schöner geht brauchst du dich nicht weiter
aufzuhalten, wenn du sagst das das so in Ordnung ist, dann
glaub ich dir das.

Prinzipiell ist das nur eine Frage des Aufwands, den man betreiben will. Deine Lösung ist sozusagen die Minimalvariante, man kann das aber natürlich bis zum Exzess aufbauschen.

Aber Zusatzfrage, wenn ich jetzt jeden Lauf mitloggen will
(hat mir gerade einer gesagt das das gewünscht ist) bekomme
ich das noch in dem Job direkt unter, oder muß ich dann eine
Funktion basteln die ich mit dem Job starte oder sowas ? Also
genauer es ist gewünscht das man irgendwo ein „Erfolgreich
beendet“ lesen kann… *grübel*

Generell halte ich es für eine gute Idee alle Jobs loggen zu lassen (damit du eine Chance hast nachzuvollziehen, was genau schiefgegangen ist - das tun sie nämlich alle früher oder später…). Wir selbst haben genau für den Zweck eine mehrfach geschachtelte Vorgehensweise. Ganz „unten“ ist der eigentliche gather, der wird ausgeführt von einem package, das generell alle unsere Jobs verwaltet (d.h. im Prinzip ein Wrapper für die DBMS_JOB), darüber gibt’s noch ein Script, das bei DB-Updates und bei der Sicherung nachschaut, ob’s den Job gibt und ihn im Fall des Falles anlegt und ausserdem die Logs vom Job-Wrapper-Package auswertet (das brauchen wir aber eigentlich nur, weil wir nicht auf alle unsere Kunden-DBs online zugreifen können).

Ich hoffe damit wären alle Klarheiten restlos beseitigt :wink:.

Gruß,
Martin

#8

Hallo Martin,

Generell halte ich es für eine gute Idee alle Jobs
loggen zu lassen (damit du eine Chance hast nachzuvollziehen,
was genau schiefgegangen ist - das tun sie nämlich alle früher
oder später…). Wir selbst haben genau für den Zweck eine
mehrfach geschachtelte Vorgehensweise. Ganz „unten“ ist der
eigentliche gather, der wird ausgeführt von einem package, das
generell alle unsere Jobs verwaltet (d.h. im Prinzip ein
Wrapper für die DBMS_JOB), darüber gibt’s noch ein Script, das
bei DB-Updates und bei der Sicherung nachschaut, ob’s den Job
gibt und ihn im Fall des Falles anlegt und ausserdem die Logs
vom Job-Wrapper-Package auswertet (das brauchen wir aber
eigentlich nur, weil wir nicht auf alle unsere Kunden-DBs
online zugreifen können).

Ich hoffe damit wären alle Klarheiten restlos beseitigt :wink:.

ja, hast du hervorragend hinbekommen…

Kannst du das jetzt noch mal für Anfänger erklären ?

Wenn ich das richtig verstanden habe, dann habt ihr ein Package in dem die einzelnen jobs hinterlegt sind und die ruft ihr dann nur noch mit dem Job auf ? so à la „execute job_package.job1“ ?

noch eine Frage, wie entlockt man dem dbms_stats das es nicht wirklich erfolgreich war ? man bekommt ja noch eine „erfolgreich“ Meldung wenn man ein Schema analysiert das nicht existiert… ?

Ich hab´s jetzt erstmal so gemacht das danach eine Loop die last_analyzed Spalte mit dem sysdate vergleicht und wenn´s nicht zusammen paßt dann den Tabellennamen ausspuckt.

Grüße

Chris

#9

Hallo Chris!

Generell halte ich es für eine gute Idee alle Jobs
loggen zu lassen (damit du eine Chance hast nachzuvollziehen,
was genau schiefgegangen ist - das tun sie nämlich alle früher
oder später…). Wir selbst haben genau für den Zweck eine
mehrfach geschachtelte Vorgehensweise. Ganz „unten“ ist der
eigentliche gather, der wird ausgeführt von einem package, das
generell alle unsere Jobs verwaltet (d.h. im Prinzip ein
Wrapper für die DBMS_JOB), darüber gibt’s noch ein Script, das
bei DB-Updates und bei der Sicherung nachschaut, ob’s den Job
gibt und ihn im Fall des Falles anlegt und ausserdem die Logs
vom Job-Wrapper-Package auswertet (das brauchen wir aber
eigentlich nur, weil wir nicht auf alle unsere Kunden-DBs
online zugreifen können).

Ich hoffe damit wären alle Klarheiten restlos beseitigt :wink:.

ja, hast du hervorragend hinbekommen…

Ähm, sorry, ganz so war das nicht gemeint…

Kannst du das jetzt noch mal für Anfänger erklären ?

Ich versuch’s mal:
Annahme: Ich möchte einen Job anlegen, der einen

dbms\_stats.gather\_schema\_stats('SCOTT')

macht.
Durchführung bei mir:

exec my\_pkg.submit('dbms\_stats.gather\_schema\_stats(''SCOTT'')',
 to\_date('31.10.2005 23:00','DD.MM.YYYY HH24:MI'),
 my\_pkg.DAILY);

Das my_pkg tut jetzt Folgendes (eigentlich noch ein wenig mehr, aber das bleibt mein Geheimnis :wink:):

  • Prüfen, ob es den gleichen Job schon gibt (und ob er funktioniert)

  • Erstellen einer Prozedur my_pkg_job[NNNN] wobei NNNN aus einer Sequence kommt.

  • Eintragen der Befehlszeile (also dbms_stats(…)) in eine interne Tabelle (3x darfst du raten wofür :wink:)

  • Einbau einer Logging-Funktionalität in diese Prozedur, sodaß diese den Start und die Beendigung + den Exit-Code in eine andere interne Tabelle schreibt

  • Eintragen dieser Prozedur in die Job Queue

Isses jetzt klarer?

noch eine Frage, wie entlockt man dem dbms_stats das es nicht
wirklich erfolgreich war ? man bekommt ja noch eine
„erfolgreich“ Meldung wenn man ein Schema analysiert das nicht
existiert… ?

Also bei mir ruft

exec dbms\_stats.gather\_schema\_stats('HUDRIWUSCH');

den Fehlerstack:

ORA-20000: Schema "HUDRIWUSCH" does not exist or insufficient privileges
ORA-06512: at "SYS.DBMS\_STATS", line 1618
ORA-06512: at "SYS.DBMS\_STATS", line 13623
ORA-06512: at "SYS.DBMS\_STATS", line 13593
ORA-06512: at line 1

hervor… Den solltest du auch kriegen, wenn du nicht ein

EXCEPTION WHEN OTHERS NULL;

hinschreibst. Beim Aufruf durch den Job musst du das natürlich abfangen, sonst setzt er mW einfach nur den Job auf ‚Broken‘ (wo sollte er denn die Fehlermeldung auch hinschreiben…).

Ich hab´s jetzt erstmal so gemacht das danach eine Loop die
last_analyzed Spalte mit dem sysdate vergleicht und wenn´s
nicht zusammen paßt dann den Tabellennamen ausspuckt.

Geht auch, ist aber nicht besonders hübsch und funktioniert vor allem nur bei DIESEM Job, du brauchst aber etwas, das dir für JEDEN Job sagt, ob er läuft oder nicht - das macht bei mir eben mein Wrapper-Package.

Gruß
Martin

#10

Hallo Martin,

  • Prüfen, ob es den gleichen Job schon gibt (und ob er
    funktioniert)

  • Erstellen einer Prozedur my_pkg_job[NNNN] wobei NNNN aus
    einer Sequence kommt.

  • Eintragen der Befehlszeile (also dbms_stats(…)) in eine
    interne Tabelle (3x darfst du raten wofür :wink:)

  • Einbau einer Logging-Funktionalität in diese Prozedur,
    sodaß diese den Start und die Beendigung + den Exit-Code in
    eine andere interne Tabelle schreibt

  • Eintragen dieser Prozedur in die Job Queue

Isses jetzt klarer?

ja, ich denke schon, du baust die Prozedur um dbms_stats automatisch und startetst diese Prozedur dann per Job.
Ist eine nette Sache, jede Prozedur ist identisch, abgesehen von der eigentlichen Aufgabe. Wahrscheinlich auch noch alle mit einer Globalen Exception.

Also bei mir ruft

exec
dbms_stats.gather_schema_stats(‚HUDRIWUSCH‘);

den
Fehlerstack:

ORA-20000: Schema „HUDRIWUSCH“ does not exist
or insufficient privileges… hervor… Den solltest du auch
kriegen, wenn du nicht ein

EXCEPTION WHEN OTHERS
NULL;

hinschreibst.

das ist ja das interessante, ich bekomme die Fehlermeldung nicht und ich habe EXCEPTION WHEN OTHERS NULL; nicht eingebaut.

Ich hab´s jetzt erstmal so gemacht das danach eine Loop die
last_analyzed Spalte mit dem sysdate vergleicht und wenn´s
nicht zusammen paßt dann den Tabellennamen ausspuckt.

habe ich mittlerweile umgebaut, da ich mit ‚GATHER AUTO‘ analysiere

Geht auch, ist aber nicht besonders hübsch und funktioniert
vor allem nur bei DIESEM Job, du brauchst aber etwas, das dir
für JEDEN Job sagt, ob er läuft oder nicht - das macht bei mir
eben mein Wrapper-Package.

Es gibt nur diesen einen Job in der Datenbank. Ich weiß nicht ob das bei Peoplesoft normal ist, ich bin erst seit Juli in dem Projekt, aber da wird so gut wie alles über externe Programme, Shellscripte, etc. gemacht…

Ich danke dir für deine Hilfe

Grüße

Chris