gibt es eine Möglichkeit ‚Task Jobs‘ die laufen bzw. nicht richtig terminieren via Komandozeile abzuschalten (oder ähnlichem). Sprich das was man manuell im OEM mit der Maus machen kann Programm gesteuert.
gibt es eine Möglichkeit ‚Task Jobs‘ die laufen bzw. nicht
richtig terminieren via Komandozeile abzuschalten (oder
ähnlichem). Sprich das was man manuell im OEM mit der Maus
machen kann Programm gesteuert.
meinst du nicht eher db-jobs? ja, mit dem dbms_job-package per sql
grüße,
tomh
meinst du nicht eher db-jobs? ja, mit dem dbms_job-package per
sql
ja db-jobs. Vielen Dank für den Tip mit dem dbms_job package, es sieht zumindest so aus als würde es genau das leisten was ich brauche. Allerdings weigert es sich im Augenblick noch das zu tun was ich möchte.
Bei:
EXEC DBMS_JOB.REMOVE(15013);
oder
EXEC DBMS_JOB.BROKEN(15013,TRUE);
bekomme ich immer nur die Fehlermeldung:
FEHLER in Zeile 1:
ORA-23421: job number 15013 is not a job in the job queue
ORA-06512: at „SYS.DBMS_SYS_ERROR“, line 86
ORA-06512: at „SYS.DBMS_IJOB“, line 514
ORA-06512: at „SYS.DBMS_JOB“, line 240
ORA-06512: at line 1
obwohl ich sicher bin das der job da ist
hi!
zuerst:
in der sys.dba_jobs siehst du alles über die jobs (und der sys.job$ würde ich zumindest nur im äußersten notfall herumprobieren - und nur, wenn ich das ganze auf einer test-db vorher probiert habe)
obwohl ich sicher bin das der job da ist
du mußt als job-owner angemeldet sein, damit du den job auch bearbeiten kannst! das können nicht mal sys oder system machen …
grüße,
tomh
mitlerweile glaube ich das problem liegt an einer anderen stelle.
sys.dba_jobs und sys.job$ sind zwar vorhanden aber leer, obwohl jobs unter OEM erfolgreich erstellt wurden und laufen.
Eine Vermutung ist das es an der Oracle Version 8.1.6 liegt, also an einer etwas älteren Version, den unter 8.1.7 finden sich im I-net viele beschreibungen mit dbms_job die das Problem anscheinend lösen.
Nach weiterer Recherche fand ich die erzeugten Jobs unter kryptischen Tabellen wie SMP_VDJ_JOB und weiteren Tabellen SMP_VDJ_JOB*
Irgendwie wird mir dann auch klar warum dbms_job nicht so funktionierte wie ich mir das vorgestellt habe.
Die Fragen die sich mir nun abschliessend stellen sind:
-wurde die Datenbank nur falsch aufgesetzt?
-und gibt es trotzdem einen Weg diese Jobs zu löschen?
Darnest
hi!
Eine Vermutung ist das es an der Oracle Version 8.1.6 liegt,
also an einer etwas älteren Version, den unter 8.1.7 finden
sich im I-net viele beschreibungen mit dbms_job die das
Problem anscheinend lösen.
bereits ab 8.0.5 konnte mit äußerster unvorsichtigkeit mit den jobs herumgeschupft werden, daran wird’s eher nicht liegen
Nach weiterer Recherche fand ich die erzeugten Jobs unter
kryptischen Tabellen wie SMP_VDJ_JOB und weiteren Tabellen
SMP_VDJ_JOB*
*argh* hierbei handelt es sich um das oem-repository - hab leider grad keines „zur hand“, jedoch sollte das package smp_maintenance bzw. irgendeines, das mit „smp_“ beginnt ev. einige procedures und/oder functions enthalten, mit dem du die jobs los wirst
Die Fragen die sich mir nun abschliessend stellen sind:
-wurde die Datenbank nur falsch aufgesetzt?
nein
-und gibt es trotzdem einen Weg diese Jobs zu löschen?
ja - zumindest lt. oracle-metalink (hast du da schon mal probiert? - du scheinst nicht der einzige mit oem-jobs-problemen zu sein
grüße,
tomh
*argh* hierbei handelt es sich um das oem-repository - hab
leider grad keines „zur hand“, jedoch sollte das package
smp_maintenance bzw. irgendeines, das mit „smp_“ beginnt ev.
einige procedures und/oder functions enthalten, mit dem du die
jobs los wirst
Lösung
-zip-
Jobs launched through the OEM console are managed through the
job system. If you are creating jobs via the OEM console, these
jobs are stored in the repository tables. The tables that you
referred to are not tables used by OEM. The tables in the
repository that contain information about the jobs created in
the OEM console typically start with SMP_ and should NOT be
manually manipulated.
-/zip-
die smp-procedures (namentlich: SMP_MAINTENANCE SMP_VDG SMP_VDP) geben nicht wirklich viel her, zumindest auf den ersten Blick.
Auf Metalink hab ich nicht wirklich hilfreiches gefunden, bis ich auf das oben gepostet gestossen bin, was halt erklärt warum es mit dbms_job nicht geht. Allerdings macht es mir auch wenig hoffung ‚vernünftig‘ die jobs abzuschiessen.
*etwas verzweifelt*
Darnest
hi!
Auf Metalink hab ich nicht wirklich hilfreiches gefunden, bis
ich auf das oben gepostet gestossen bin, was halt erklärt
warum es mit dbms_job nicht geht. Allerdings macht es mir auch
wenig hoffung ‚vernünftig‘ die jobs abzuschiessen.*etwas verzweifelt*
letzte hoffnung: leg einen tar an
grüße,
tomh
gibt es eine Möglichkeit ‚Task Jobs‘ die laufen bzw. nicht
richtig terminieren via Komandozeile abzuschalten (oder
ähnlichem). Sprich das was man manuell im OEM mit der Maus
machen kann Programm gesteuert.
Hallo Darnest
Sind die jobs noch da oder hängen die einfach noch rum und können via
OEM nicht rausgekickt werden?
Ich hatte auch schon einige job-Zombies, aber die wurden
von einem schlecht konfigurierten Intelligent Agent am Pseudo-Leben erhalten.
Läuft der Ping auf den Agent?
Wenn nicht, Agent neu starten.
Wenns nichts nützt, ganze Node aus dem OEM kicken und neu discoveren.
Gruss Protzelle
Hallo Darnest
Sind die jobs noch da oder hängen die einfach noch rum und
können via
OEM nicht rausgekickt werden?
Ich hatte auch schon einige job-Zombies, aber die wurden
von einem schlecht konfigurierten Intelligent Agent am
Pseudo-Leben erhalten.
Läuft der Ping auf den Agent?
Wenn nicht, Agent neu starten.
Wenns nichts nützt, ganze Node aus dem OEM kicken und neu
discoveren.
Gruss Protzelle
Naja manuell lassen sich die Jobs schon noch abschiessen. Es ist eher eine Sicherheitssperre die ich erstellen möchte, falls ein Job während der Ausführung hängt, was durchaus schon vor gekommen ist. Den Job dann zu terminieren würde halt die neu ausführung zum nächsten Zeitpunkt erlauben. Es soll halt automatisch passieren.
Warum sie nicht in dba_jobs erscheinen ist mir mitlerweile auch klar da sie alle mit dem OEM erstellt wurden (Text habe ich schon weiter unten gepostet). An abschiessen des Knoten habe ich auch schon gedacht, allerdings möchte ich erst versuchen alle anderen Möglichkeiten auszuschöpfen bevor ich mit der ganz grossen Keule komme 
Ich werd mal ein TAR absetzen und schauen was die Jungs von Metalink dazu sagen.
für alle die bis hier hin durchgehalten haben.
wie oben schon erwähnt werden Jobs, die unter dem OEM angelegt wurden, im Repository gehalten. Es gibt auch laut Metalink _keine_ Möglichkeit diese anderes als über den OEM zu manipulieren.
Die Antwort die ich erhalten habe ist das es sicherlich möglich ist all diese Tabellen zu modifizieren. Allerdings müste man dann alle anderen Jobs ebenfalls beenden den Agent neu starten und Knoten neu zu erkennen. Dann müste ich allerdings auch alle anderen Jobs neu abschicken und das geht soweit ich weiss auch nur wieder von Hand, das was ich eigentlich gerade verhindern wollte.
DAS IST ALLES NICHT SUPPORTED. Wer es ausprobieren möchte auf eigene Gefahr.
Einzige Möglichkeit die ich sehe ist äquivalente SQL Jobs anzulegen, allerdings bin ich mir nicht wirklich sicher ob diese in der Lage sind das selbe zu leisten, wie z.B. BS-Befehle auszuführen.
Darnest
hi!
Einzige Möglichkeit die ich sehe ist äquivalente SQL Jobs
anzulegen, allerdings bin ich mir nicht wirklich sicher ob
diese in der Lage sind das selbe zu leisten, wie z.B.
BS-Befehle auszuführen.
ja, sind sie! mittels java-procedures in der db
grüße,
tomh