ORA-01882: région de fuseau horaire non trouvée

Question

Je consulte une base de données Oracle à partir d'une application java, lorsque je lance mon application j'obtiens l'erreur suivante:

java.sql.SQLException: ORA-00604: une erreur s'est produite au niveau SQL récursif 1 ORA-01882: région de fuseau horaire non trouvée

Answer 1

Vous pouvez également essayer de vérifier la version du pilote jdbc Oracle et de la base de données Oracle. Aujourd'hui même, j'ai eu ce problème en utilisant ojdbc6.jar (version 11.2.0.3.0) pour me connecter à un serveur Oracle 9.2.0.4.0. Le remplacer par ojdbc6.jar version 11.1.0.7.0 a résolu le problème.

J'ai également réussi à faire en sorte que ojdbc6.jar version 11.2.0.3.0 se connecte sans erreur, en ajoutant oracle.jdbc.timezoneAsRegion=false dans le fichier oracle/jdbc/defaultConnectionProperties.properties (à l'intérieur du jar). J'ai trouvé cette solution ici (lien cassé)

Ensuite, on peut ajouter -Doracle.jdbc.timezoneAsRegion=false à la ligne de commande, ou AddVMOption -Doracle.jdbc.timezoneAsRegion=false dans les fichiers de configuration qui utilisent cette notation.

Vous pouvez également le faire de manière programmée, par exemple avec System.setProperty.

Dans certains cas, vous pouvez ajouter la variable d'environnement sur une base de connexion individuelle si cela est autorisé (SQL Developer permet cela dans les propriétés de connexion "Avancées"; j'ai vérifié que cela fonctionne lors de la connexion à une base de données qui n'a pas le problème et en utilisant un lien de base de données vers une base de données qui l'a).

Answer 2

Dans une installation SQL-Developer standard sous Windows, accédez au répertoire

C:\Program Files\sqldeveloper\sqldeveloper\bin

et ajoutez

AddVMOption -Duser.timezone=CET

au fichier sqldeveloper.conf.

Answer 3

Erreur que j'ai eu :

Erreur de db_connection.java -->> java.sql.SQLException: ORA-00604: une erreur s'est produite au niveau SQL récursif 1 ORA-01882 : région de fuseau horaire non trouvée

ORA-00604: une erreur s'est produite au niveau SQL récursif 1 ORA-01882 : région de fuseau horaire non trouvée

Code précédent :

 public Connection getOracle() throws Exception {
     Connection conn = null;
     Class.forName("oracle.jdbc.driver.OracleDriver");
     conn = DriverManager.getConnection("jdbc:oracle:thin:@127.0.0.1:1521:tap", "nom d'utilisateur", "pw");
     return conn;
}

Nouveau code :

 public Connection getOracle() throws Exception {
     TimeZone timeZone = TimeZone.getTimeZone("Asia/Kolkata");
     TimeZone.setDefault(timeZone);
     Connection conn = null;
     Class.forName("oracle.jdbc.driver.OracleDriver");
     conn = DriverManager.getConnection("jdbc:oracle:thin:@127.0.0.1:1521:tap", "nom d'utilisateur", "pw");
     return conn;
}

Maintenant ça fonctionne!!

Answer 4

Mettez à jour le fichier oracle/jdbc/defaultConnectionProperties.properties dans n'importe quelle version de la bibliothèque (c'est-à-dire à l'intérieur de votre jar) que vous utilisez pour contenir la ligne ci-dessous :

oracle.jdbc.timezoneAsRegion=false

Answer 5

Ce qui se passe, c'est que le client JDBC envoie l'identifiant du fuseau horaire au serveur. Le serveur a besoin de connaître ce fuseau. Vous pouvez vérifier avec

SELECT DISTINCT tzname FROM V$TIMEZONE_NAMES where tzname like 'Etc%';

J'ai des serveurs de base de données qui connaissent 'Etc/UTC' et 'UTC' (version du fichier de fuseau horaire 18) mais d'autres ne connaissent que 'UTC' (version du fichier de fuseau horaire 11).

SELECT FILENAME,VERSION from V$TIMEZONE_FILE;

Il y a également un comportement différent du côté du client JDBC. À partir de 11.2, le pilote enverra les identifiants de zone s'ils sont "connus" d'Oracle, tandis qu'auparavant, il envoyait le décalage horaire. Le problème avec cette "envoi des ID connus" est que le client ne vérifie pas quelle version/de contenu de fuseau horaire est présente sur le serveur mais a sa propre liste.

Ceci est expliqué dans l'article du support Oracle [ID 1068063.1].

Il semble aussi que cela dépende du système d'exploitation du client, il était plus probable que Etc/UTC échoue avec Ubuntu qu'avec RHEL ou Windows. Je suppose que cela est dû à une certaine normalisation mais je n'ai pas encore compris exactement pourquoi.