Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Fehler im Oracle Scheduler
28 views
Skip to first unread message
seiler....@googlemail.com
Jul 19, 2012, 7:31:32 AM7/19/12
to
Hallo Leute,
in unserer DB (Oracle 10gR2) lasse ich alle möglichen Packages und Prozeduren vom Scheduler starten. Seit einiger Zeit bringt mir eine wöchentlich laufende Prozedur immer einen ORA-01722: Ungültige Zahl. Ich habe die Prozedur ewig nicht angefasst und mein DBA schwört Stein und Bein nichts geändert zu haben. Glaub ich auch. So wie was aussieht tritt der Fehler beim Einlesen eines Cursors auf.
Soweit so schlecht, aber der Clou ist folgender :
Ein "exec package.prozedur;" im SQL-Plus und alles läuft ohne Fehler durch.
Hat irgendjemand schon mal davon gehört, dass ein Fehler in Abhängigkeit von der Art des Aufrufes einer Prozedur auftritt?
Danke schon mal für Euren Hirnschmalz.
Reinhard
in unserer DB (Oracle 10gR2) lasse ich alle möglichen Packages und Prozeduren vom Scheduler starten. Seit einiger Zeit bringt mir eine wöchentlich laufende Prozedur immer einen ORA-01722: Ungültige Zahl. Ich habe die Prozedur ewig nicht angefasst und mein DBA schwört Stein und Bein nichts geändert zu haben. Glaub ich auch. So wie was aussieht tritt der Fehler beim Einlesen eines Cursors auf.
Soweit so schlecht, aber der Clou ist folgender :
Ein "exec package.prozedur;" im SQL-Plus und alles läuft ohne Fehler durch.
Hat irgendjemand schon mal davon gehört, dass ein Fehler in Abhängigkeit von der Art des Aufrufes einer Prozedur auftritt?
Danke schon mal für Euren Hirnschmalz.
Reinhard
Peter Schneider
Jul 19, 2012, 7:50:14 AM7/19/12
to
Hallo Reinhard,
> in unserer DB (Oracle 10gR2) lasse ich alle m�glichen Packages und Prozeduren vom Scheduler starten. Seit einiger Zeit bringt mir eine w�chentlich laufende Prozedur immer einen ORA-01722: Ung�ltige Zahl. Ich habe die Prozedur ewig nicht angefasst und mein DBA schw�rt Stein und Bein nichts ge�ndert zu haben. Glaub ich auch. So wie was aussieht tritt der Fehler beim Einlesen eines Cursors auf.
>
> Hat irgendjemand schon mal davon geh�rt, dass ein Fehler in Abh�ngigkeit von der Art des Aufrufes einer Prozedur auftritt?
Das kann an unterschiedlichen NLS_... Session Parametern liegen. Wenn Du
SQL*Plus startest, dann holt es seine NLS Parameter entweder aus dem
Environment (Unix/Linux) oder aus dem Registry Key f�r das entsprechende
Oracle Home (Windows).
Wenn Du auf dem Client, auf dem Du SQL*Plus startest, NLS_LANG / NLS_TERRITORY
f�r Deutsch / Deutschland gesetzt hast, dann ergibt sich daraus implizit ein
Wert von ',.' f�r NLS_NUMERIC_CHARACTERS.
Wahrscheinlich hat nun das Enviroment des Scheduler Jobs ganz einfach ein
Setting von AMERICAN_AMERICA, weil explizit kein anderes Environment
mitgegeben wurde. Daraus ergibt sich dann implizit ein Wert von '.,' f�r
NLS_NUMERIC_CHARACTERS.
Das ganze kann nun dann zu einem Fehler f�hren, wenn deine Prozedur entweder
im PL/SQL Code oder in einem eingebetteten SQL Statement oder Cursor einen
Type Cast von VARCHAR2 nach NUMBER macht mit der Funktion to_number(), und in
den umzuwandelnden Character Daten eine Zeichenkette als Zahlenrepresentation
vorhanden ist, deren Verwendung von Dezimal/Gruppentrennern sich nicht mit der
Sessioneinstellung deckt. Untersuche mal in dem Programm alle Verwendungen von
to_number, und schau dir die Daten an, auf denen die Aufrufe operieren.
L�sungsm�glichkeiten:
1) daf�r sorgen da� alle Daten sich an die gleichen Konventionen halten
2) im Package mittels EXECUTE IMMEDIATE "ALTER SESSION SET NLS_... = ..." das
richtige NLS_ENVIRONMENT setzen
oder
3) in den to_number() Aufrufen den Parameter NLS_NUMERIC_CHARCATERS mitgeben.
Gru�
Peter
--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
> in unserer DB (Oracle 10gR2) lasse ich alle m�glichen Packages und Prozeduren vom Scheduler starten. Seit einiger Zeit bringt mir eine w�chentlich laufende Prozedur immer einen ORA-01722: Ung�ltige Zahl. Ich habe die Prozedur ewig nicht angefasst und mein DBA schw�rt Stein und Bein nichts ge�ndert zu haben. Glaub ich auch. So wie was aussieht tritt der Fehler beim Einlesen eines Cursors auf.
>
> Soweit so schlecht, aber der Clou ist folgender :
> Ein "exec package.prozedur;" im SQL-Plus und alles l�uft ohne Fehler durch.
> Soweit so schlecht, aber der Clou ist folgender :
>
> Hat irgendjemand schon mal davon geh�rt, dass ein Fehler in Abh�ngigkeit von der Art des Aufrufes einer Prozedur auftritt?
Das kann an unterschiedlichen NLS_... Session Parametern liegen. Wenn Du
SQL*Plus startest, dann holt es seine NLS Parameter entweder aus dem
Environment (Unix/Linux) oder aus dem Registry Key f�r das entsprechende
Oracle Home (Windows).
Wenn Du auf dem Client, auf dem Du SQL*Plus startest, NLS_LANG / NLS_TERRITORY
f�r Deutsch / Deutschland gesetzt hast, dann ergibt sich daraus implizit ein
Wert von ',.' f�r NLS_NUMERIC_CHARACTERS.
Wahrscheinlich hat nun das Enviroment des Scheduler Jobs ganz einfach ein
Setting von AMERICAN_AMERICA, weil explizit kein anderes Environment
mitgegeben wurde. Daraus ergibt sich dann implizit ein Wert von '.,' f�r
NLS_NUMERIC_CHARACTERS.
Das ganze kann nun dann zu einem Fehler f�hren, wenn deine Prozedur entweder
im PL/SQL Code oder in einem eingebetteten SQL Statement oder Cursor einen
Type Cast von VARCHAR2 nach NUMBER macht mit der Funktion to_number(), und in
den umzuwandelnden Character Daten eine Zeichenkette als Zahlenrepresentation
vorhanden ist, deren Verwendung von Dezimal/Gruppentrennern sich nicht mit der
Sessioneinstellung deckt. Untersuche mal in dem Programm alle Verwendungen von
to_number, und schau dir die Daten an, auf denen die Aufrufe operieren.
L�sungsm�glichkeiten:
1) daf�r sorgen da� alle Daten sich an die gleichen Konventionen halten
2) im Package mittels EXECUTE IMMEDIATE "ALTER SESSION SET NLS_... = ..." das
richtige NLS_ENVIRONMENT setzen
oder
3) in den to_number() Aufrufen den Parameter NLS_NUMERIC_CHARCATERS mitgeben.
Gru�
Peter
--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
seiler....@googlemail.com
Jul 19, 2012, 8:48:01 AM7/19/12
to
> 1) dafür sorgen daß alle Daten sich an die gleichen Konventionen halten
> 2) im Package mittels EXECUTE IMMEDIATE "ALTER SESSION SET NLS_... = ..." das
> richtige NLS_ENVIRONMENT setzen
Hallo Peter,
danke für Deine schnelle Antwort.
Habe den PL/SQL Block im Scheduler wie folgt geändert, leider ohne Erfolg.
BEGIN
EXECUTE IMMEDIATE 'ALTER Session SET Nls_Numeric_Characters = German';
Package.Prozedur;
END;
Gruß
Reinhard
Peter Schneider
Jul 19, 2012, 3:19:20 PM7/19/12
to
Am 19.07.2012 14:48, schrieb seiler....@googlemail.com:
>
>> 1) daf�r sorgen da� alle Daten sich an die gleichen Konventionen halten
> Habe den PL/SQL Block im Scheduler wie folgt ge�ndert, leider ohne Erfolg.
Das ist kein Parameter, der "macht das alles wieder geht".
Du sollst erst deine Daten analysieren um zu verstehen, was die Ursache des
Problems ist, und warum du das genau jetzt bekommst, und vorher offensichtlich
nicht.
Au�erdem hast du die Syntax f�r den Parameterwert falsch.
Die Fehlermeldung tritt bei der Konvertierung von Character Spalten mittels
to_number auf. Mit der falschen Wahl des Felddatentypes fangen die Probleme
dann halt an, und dann mu� man eben leiden.
Was die Datenkonstellation angeht gibt es mehrere M�glichkeiten:
- du hattest bisher in der/den betroffenen Spalten nur Integerwerte, aber
jetzt auf einmal nicht mehr, sondern neuerdings Dezimalstellen, allerdings
nicht mit dem erwarteten Dezimaltrenner.
- du hattest bisher nur Integerwerte und keine Gruppen/Tausendertrennzeichen,
aber jetzt auf einmal Integerwerte MIT Gruppen/Tausendertrenner
- beides auf einmal
Wenn ja: warum? Darf das, ist das richtig so? Wenn nicht, wo kommen die Daten
her? Kommen irgendwelche Schrottdaten �ber irgendwelche Schnittstellen,
Fremdapplikationen in die DB? Schreibt jemand Daten in die beteiligten
Tabellen der nicht wei� was er da tut? Sabotage?
Wenn das so oder so �hnlich ist, dann besteht auch die Gefahr, da�, obwohl es
sich (von der Intention her) um Integers mit Tausendertrenner handelt, die
Zahlen als solche mit Dezimalstellen fehlinterpretiert werden, und du somit
Daten mit Fehlerfaktor von 3-6 Zehnerpotenzen in deiner DB hast.
Was soll z.B. der String '120,235' repr�sentieren? Das kann genau so gut
einhundert komma zwei drei f�nf darstellen wie auch
einhunderttausendzweihundertf�nfunddrei�ig. Das ist eine Frage der Konvention,
und wenn man die Einhaltung bestimmter Konventionen nicht erzwingen kann, dann
hat man halt zweifelhafte oder inkonsistente Daten in der DB.
Nur wenn du genau wei�t, was Sache ist mit deinen Daten, dann kannst du ggf.
eine der skizzierten L�sungsm�glichkeiten verwenden.
Wenn du z.B. f�r die Session des Scheduler Jobs festlegen willst, da� '.' der
Gruppentrenner ist, und ',' der Dezimaltrenner, dann w�re der richtige Befehl
in deinem PL/SQL Code oben:
BEGIN
...
EXECUTE IMMEDIATE 'ALTER SESSION SET NLS_NUMERIC_CHARACTERS = ",."';
...
END;
Syntax und Semantik siehe
http://goo.gl/EbE9h
http://goo.gl/wxr1Q
http://goo.gl/pZPF8
Besser w�re es allerdings, von vornherein immer den richtigen Felddatentyp zu
w�hlen, und Zahlen auch nur in passend dimensionierten NUMBER-Feldern
abzuspeichern.
Deine Probleme m�cht ich nicht haben ;-)
>
>> 1) daf�r sorgen da� alle Daten sich an die gleichen Konventionen halten
>> 2) im Package mittels EXECUTE IMMEDIATE "ALTER SESSION SET NLS_... = ..." das
>> richtige NLS_ENVIRONMENT setzen
>
> Hallo Peter,
>
> danke f�r Deine schnelle Antwort.
>> richtige NLS_ENVIRONMENT setzen
>
> Hallo Peter,
>
> Habe den PL/SQL Block im Scheduler wie folgt ge�ndert, leider ohne Erfolg.
>
> BEGIN
> EXECUTE IMMEDIATE 'ALTER Session SET Nls_Numeric_Characters = German';
> Package.Prozedur;
> END;
Nein. Neinneinnein.
> BEGIN
> EXECUTE IMMEDIATE 'ALTER Session SET Nls_Numeric_Characters = German';
> Package.Prozedur;
> END;
Das ist kein Parameter, der "macht das alles wieder geht".
Du sollst erst deine Daten analysieren um zu verstehen, was die Ursache des
Problems ist, und warum du das genau jetzt bekommst, und vorher offensichtlich
nicht.
Au�erdem hast du die Syntax f�r den Parameterwert falsch.
Die Fehlermeldung tritt bei der Konvertierung von Character Spalten mittels
to_number auf. Mit der falschen Wahl des Felddatentypes fangen die Probleme
dann halt an, und dann mu� man eben leiden.
Was die Datenkonstellation angeht gibt es mehrere M�glichkeiten:
- du hattest bisher in der/den betroffenen Spalten nur Integerwerte, aber
jetzt auf einmal nicht mehr, sondern neuerdings Dezimalstellen, allerdings
nicht mit dem erwarteten Dezimaltrenner.
- du hattest bisher nur Integerwerte und keine Gruppen/Tausendertrennzeichen,
aber jetzt auf einmal Integerwerte MIT Gruppen/Tausendertrenner
- beides auf einmal
Wenn ja: warum? Darf das, ist das richtig so? Wenn nicht, wo kommen die Daten
her? Kommen irgendwelche Schrottdaten �ber irgendwelche Schnittstellen,
Fremdapplikationen in die DB? Schreibt jemand Daten in die beteiligten
Tabellen der nicht wei� was er da tut? Sabotage?
Wenn das so oder so �hnlich ist, dann besteht auch die Gefahr, da�, obwohl es
sich (von der Intention her) um Integers mit Tausendertrenner handelt, die
Zahlen als solche mit Dezimalstellen fehlinterpretiert werden, und du somit
Daten mit Fehlerfaktor von 3-6 Zehnerpotenzen in deiner DB hast.
Was soll z.B. der String '120,235' repr�sentieren? Das kann genau so gut
einhundert komma zwei drei f�nf darstellen wie auch
einhunderttausendzweihundertf�nfunddrei�ig. Das ist eine Frage der Konvention,
und wenn man die Einhaltung bestimmter Konventionen nicht erzwingen kann, dann
hat man halt zweifelhafte oder inkonsistente Daten in der DB.
Nur wenn du genau wei�t, was Sache ist mit deinen Daten, dann kannst du ggf.
eine der skizzierten L�sungsm�glichkeiten verwenden.
Wenn du z.B. f�r die Session des Scheduler Jobs festlegen willst, da� '.' der
Gruppentrenner ist, und ',' der Dezimaltrenner, dann w�re der richtige Befehl
in deinem PL/SQL Code oben:
BEGIN
...
EXECUTE IMMEDIATE 'ALTER SESSION SET NLS_NUMERIC_CHARACTERS = ",."';
...
END;
Syntax und Semantik siehe
http://goo.gl/EbE9h
http://goo.gl/wxr1Q
http://goo.gl/pZPF8
Besser w�re es allerdings, von vornherein immer den richtigen Felddatentyp zu
w�hlen, und Zahlen auch nur in passend dimensionierten NUMBER-Feldern
abzuspeichern.
Deine Probleme m�cht ich nicht haben ;-)
Peter Schneider
Jul 19, 2012, 3:23:08 PM7/19/12
to
Am 19.07.2012 21:19, schrieb Peter Schneider:
> Was soll z.B. der String '120,235' repr�sentieren? Das kann genau so gut
> einhundert komma zwei drei f�nf darstellen wie auch
> einhunderttausendzweihundertf�nfunddrei�ig. Das ist eine Frage der Konvention,
Fipptehler. Sollte lat�rnich '100,235' hei�en.
> Was soll z.B. der String '120,235' repr�sentieren? Das kann genau so gut
> einhundert komma zwei drei f�nf darstellen wie auch
> einhunderttausendzweihundertf�nfunddrei�ig. Das ist eine Frage der Konvention,
Reinhard Seiler
Jul 20, 2012, 5:15:38 AM7/20/12
to
Hallo Peter,
vielen Dank für Deine Antwort. Du hast natürlich den Finger komplett in der offenen Wunde - und ordentlich Salz drauf. Es ist schon ziemlich dämlich, wenn man selbst vergisst sich seine Daten mal anzusehen :-(
Das Feld aus dem ich die Daten hole ist ein Varchar2 und war ursprünglich mehr zur Verzierung/Info da. Richtig rechnen war nicht von Anfang an vorgesehen und jetzt kommen Daten aus anderen Quellen rein und es muss gerechnet werden. Da ist also Umbaubedarf deutlich zu sehen.
Doch bevor das realisiert werden kann, muss ich mir eben mit regulären Ausdrücken behelfen, um die Daten in sinnvolle Formate vor to_number zu bringen.
Dein korrektes Alter Session hat sofort geholfen.
Die Probleme vermindern sich, wenn man sich um Ordnung in der DB bemüht.
Shit in - Shit out! :-)
Also noch mal Vielen Dank und schönes Wochenende
Reinhard
vielen Dank für Deine Antwort. Du hast natürlich den Finger komplett in der offenen Wunde - und ordentlich Salz drauf. Es ist schon ziemlich dämlich, wenn man selbst vergisst sich seine Daten mal anzusehen :-(
Das Feld aus dem ich die Daten hole ist ein Varchar2 und war ursprünglich mehr zur Verzierung/Info da. Richtig rechnen war nicht von Anfang an vorgesehen und jetzt kommen Daten aus anderen Quellen rein und es muss gerechnet werden. Da ist also Umbaubedarf deutlich zu sehen.
Doch bevor das realisiert werden kann, muss ich mir eben mit regulären Ausdrücken behelfen, um die Daten in sinnvolle Formate vor to_number zu bringen.
Dein korrektes Alter Session hat sofort geholfen.
Die Probleme vermindern sich, wenn man sich um Ordnung in der DB bemüht.
Shit in - Shit out! :-)
Also noch mal Vielen Dank und schönes Wochenende
Reinhard
0 new messages