Nous avons une configuration de déclenchement de sorte que lorsqu'un utilisateur spécifique se connecte, leurs paramètres de session NLS sont modifiés. Cela travaillait pour travailler sur Oracle 10G. Nous venons de migrer vers Oracle 11G RAC, et les paramètres de session ne persistent plus. Pour expliquer, j'ai collé une session qui montre le NLS_Date_Format n'étant pas utilisé correctement.
C'est la gâchette que nous utilisons:
create or replace
TRIGGER schmea.nls_tr
AFTER logon ON DATABASE
BEGIN
execute immediate 'ALTER SESSION SET NLS_DATE_FORMAT = ''YYYY-MM-DD HH24:MI:SS'' NLS_TIMESTAMP_FORMAT = ''YYYY-MM-DD HH24:MI:SS.FF'' NLS_TERRITORY = ''AMERICA''';
END;
Les formats ci-dessus ne sont pas par défaut, ils semblent donc changer de connexion.
SQL> select * from nls_session_parameters where parameter = 'NLS_TIMESTAMP_FORMAT' or parameter = 'NLS_DATE_FORMAT';
PARAMETER
--------------------------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
NLS_DATE_FORMAT
YYYY-MM-DD HH24:MI:SS
NLS_TIMESTAMP_FORMAT
YYYY-MM-DD HH24:MI:SS.FF
SQL> select count(*) from TABLE where start_date > '2012-06-10 00:00:00';
select count(*) from TABLE where start_date > '2012-06-10 00:00:00'
*
ERROR at line 1:
ORA-12801: error signaled in parallel query server P024, instance
[domain.com]:[instance] (1)
ORA-01861: literal does not match format string
SQL> alter session set NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
Session altered.
SQL> select count(*) from TABLE where start_date > '2012-06-10 00:00:00';
COUNT(*)
----------
4901
SQL> select * from nls_session_parameters where parameter = 'NLS_TIMESTAMP_FORMAT' or parameter = 'NLS_DATE_FORMAT';
PARAMETER
--------------------------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
NLS_DATE_FORMAT
YYYY-MM-DD HH24:MI:SS
NLS_TIMESTAMP_FORMAT
YYYY-MM-DD HH24:MI:SS.FF
S'il vous plaît aider. J'ai déchiré mes cheveux pendant 13 heures, 7 minutes et 4 secondes. Des idées?
Merci.
Changer l'ordre de l'ensemble semblait faire une différence, car cela fonctionne maintenant.
create or replace
TRIGGER schema.Django_nls_tr
AFTER logon ON DATABASE
BEGIN
execute immediate 'ALTER SESSION SET NLS_TERRITORY = ''AMERICA'' NLS_DATE_FORMAT = ''YYYY-MM-DD HH24:MI:SS'' NLS_TIMESTAMP_FORMAT = ''YYYY-MM-DD HH24:MI:SS.FF''';
END;
Je n'aime pas vraiment cette solution, car je ne comprends toujours pas exactement pourquoi changer l'ordre devrait être important. Peut-être que le territoire n'est pas défini correctement, mais c'était déjà la valeur par défaut, donc nous ne sommes pas trop inquiets en ce moment.
En outre, Django fait un TO_TIMESTAMP
. Il s'attend à ce que la plupart des champs de date soient horodatastaques (6), mais nous étions dirigés par une DB héritée avec des champs de type de date. Le NLS ne devrait pas avoir d'importance trop considérablement dans les déploiements standard.
Une recherche de 'My Oracle Support' (MOS) a montré qu'il s'agissait d'un bogue signalé dans au moins les versions 11.1.0.6 et 11.1.0.7. L'un des rapports de bugs, semble indiquer qu'il a été fixé en 11,2 Bien que de juger par l'une de vos balises, [Oracle-11G-R2], ce qui pourrait ne pas être le cas. Je vous suggère d'ouvrir un billet avec MOS.