Plötzlich Probleme mit NLS_DATE_FORMAT

[AtWork]

Hallo.

Unsere Umgebung:
SUSE Linux Enterprise Server 11 (x86_64)
Apache 2.2
Oracle 11g
OTRS 2.4.9

Wir haben plötzlich diverse Probleme, daß die 7-Tage-Statistiken im Dashboard nur noch die erstellten Tickets anzeigt und z.B. die Ticketsuche nicht mehr richtig funktioniert.
Das System lief bereits monatelang problemlos. Ich bin mir nicht sicher, ob das seit dem Update von 2.4.8 -> 2.4.9 auftritt.

--------
Fehlermeldung im System Log:
ORA-01861: literal does not match format string (DBD ERROR: error possibly near <*> indicator at char 381 in 'SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND st.user_id IN (3) AND th.create_by IN (3) AND th.history_type_id = 1 AND sq.group_id IN (1, 2, 3, 4, 5, 6, 21, 23, 24, 25, 26, 27, 28, 29) AND th.history_type_id IN (1, 27) AND th.state_id IN (2, 21, 3) AND th.create_time >= <*>'2011-01-22 16:51:27' ORDER BY st.create_time_unix DESC'), SQL: 'SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND st.user_id IN (3) AND th.create_by IN (3) AND th.history_type_id = 1 AND sq.group_id IN (1, 2, 3, 4, 5, 6, 21, 23, 24, 25, 26, 27, 28, 29) AND th.history_type_id IN (1, 27) AND th.state_id IN (2, 21, 3) AND th.create_time >= '2011-01-22 16:51:27' ORDER BY st.create_time_unix DESC'
--------

Das Support Assessment sagt:

Database
Check Kommentar Status
Check "System Time" vs "Current Timestamp". There is no difference between application server time and database server time. OK
Check NLS_DATE_FORMAT. Your NLS_DATE_FORMAT setting is YYYY-MM-DD HH24:MI:SS. OK
Check NLS_DATE_FORMAT by using SELECT statement. 22.06.2010 12:27:09 is not the right format 'yyyy-mm-dd hh:mm::ss' (please check $ENV{NLS_DATE_FORMAT}). Failed
Check NLS_LANG. Your NLS_LANG configuration is american_america.utf8. OK
Check ORACLE_HOME configuration. Your ORACLE_Home configuration is /opt/oracle/product/11g. OK
Check existing framework tables. 69 tables checked. OK
--------

Der OTRS-User hat im ENV fogendes gesetzt:
/etc/profile.local:
-------
ORACLE_BASE=/opt/oracle
ORACLE_HOME=$ORACLE_BASE/product/11g
LD_LIBRARY_PATH=$ORACLE_HOME/lib
NLS_LANG=american_america.utf8
TNS_ADMIN=$ORACLE_HOME/network/admin
NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'

PATH=$PATH:$ORACLE_HOME/bin

export ORACLE_BASE ORACLE_HOME LD_LIBRARY_PATH NLS_DATE_FORMAT PATH TNS_ADMIN NLS_LANG

und in der Config.pm steht auch nochmal:
$ENV{ORACLE_HOME} = '/opt/oracle/product/11g';
$ENV{NLS_DATE_FORMAT} = 'YYYY-MM-DD HH24:MI:SS';
$ENV{NLS_LANG} = "american_america.utf8";


Hat jemand eine Idee ?

[AtWork]

Hallo.

Hat niemand eine Idee ?

mfg
Marcus

[eti]

selbes problem nach umstellung der datenbank von mysql nach oracle.
was bekommst du für ein format zurück geliefert, wenn du

Code: Select all

select sysdate from dual

• direkt im sql/plus
• in der otrs sql box

abfragst?

[VMania]

Hallo in die Runde,

Nach einer Neuinstallation der Version 3.2.8 stellt sich eine, wie beschrieben, identische Situation ein "ORA-01861: literal does not match format string"
Meldungen der Seite 'AdminSupport':
Check NLS_DATE_FORMAT. Your NLS_DATE_FORMAT setting is YYYY-MM-DD HH24:MI:SS. OK
Check NLS_DATE_FORMAT by using SELECT statement. 22.06.2010 12:27:09 is not the right format 'yyyy-mm-dd hh:mm::ss' (please check $ENV{NLS_DATE_FORMAT}). Failed

In meinem Fall liefert sowohl SQL/plus als auch die SQL Box den Wert 'DD-MON-RR' zurück.

Haben sich in der Zwischenzeit Lösungen zu dem Thema ergeben?

Mit bestem Dank im Voraus, VMania

[VMania]

Haben sich in der Zwischenzeit Lösungen zu dem Thema ergeben?

Ich quote mich schon selbst aus Verzweiflung , aber ich wollte an der Stelle zumindest ein gefundenes Workaround posten:

Das folgende Statement bewegte OTRS dazu die Daten korrekt zu verwerten. Zumindest zeigt die "AdminSupport" Seite nun grünes Licht.
# ORA-01861: literal does not match format string
$ENV{NLS_DATE_FORMAT} = 'YYYY-MM-DD HH24:MI:SS';

Offensichtlich wird die "Config.pm" nicht zu im richtigen Moment gelesen oder gar nicht ausgewertet, so dass Apache die Werte nicht in die Laufzeit übernehmen kann. Es sei dahin gestellt, ob es sich dabei um ein Bug oder eine Lücke im "otrs_admin" Handbuch handelt. Weiterhin zu berücksichtigen bleibt die Frage, ob bei einer Aktualisierung der Software die Datei "apache2-perl-startup.pl" überschrieben wird (siehe Umstellung 2.4.8 -> 2.4.9) oder nicht!

Wie auch immer, kann ich diese Lösung als Workaround verwerten bis auf Verständnis der Zusammenhänge.

[johannes3154]

Hallo,
ich stehe im Moment vor dem selben Problem.
Wir setzen Ubuntu und OTRS 3.2.10 ein.
In dem vorigen Post sehe ich keinen Workaround, kannst du den bitte nochmals posten?
Ich habe auch die Datei apache2-perl-startup.pl um den erwähnten Eintrag erweitert, aber Otrs interessiert sich nicht dafür.
Die Variable NLS_DATE_FORMAT wird als umgebungsvariable in der Profile Datei gesetzt und in der Config.pm.