Définition du délai de session Oracle 11g

Question

Après le redémarrage du serveur, la connexion oracle du serveur Tomcat expire toutes les nuits. Avant le redémarrage, la connexion n'a pas expiré. Maintenant, le matin, l'application envoie une erreur de connexion JDBC accédant à la base de données. Redémarrer Tomcat corrige le problème. Je suppose que c'est parce que les connexions sont rétablies. Je pense que cela est dû au fait que la base de données Oracle a dépassé la session. Comment le délai d'attente de session peut-il être désactivé dans Oracle 11g?
Merci!
Steve

Config.groovy avec dev et test omis.

dataSource { 
    pooled = true 
} 

hibernate { 
    cache.use_second_level_cache = true 
    cache.use_query_cache = true 
    cache.provider_class = 'net.sf.ehcache.hibernate.EhCacheProvider' 
} 

// environment specific settings 
environments { 
production { 
    dataSource { 
    driverClassName = "oracle.jdbc.driver.OracleDriver" 
    username = "XXXXX" 
    password = "XXXXXX" 
    dialect = "org.hibernate.dialect.Oracle10gDialect" 
    dbCreate = "update" // one of 'create', 'create-drop','update' 
    url = "jdbc:oracle:thin:@XXXXXX:1521:xxxx" 
    } 
} } 

Answer 1

Ceci est généralement contrôlé par le profil associé à l'utilisateur auquel Tomcat se connecte.

SQL> SELECT PROFILE, LIMIT FROM DBA_PROFILES WHERE RESOURCE_NAME = 'IDLE_TIME'; 

PROFILE      LIMIT 
------------------------------ ---------------------------------------- 
DEFAULT      UNLIMITED 

SQL> SELECT PROFILE FROM DBA_USERS WHERE USERNAME = USER; 

PROFILE 
------------------------------ 
DEFAULT 

Donc, l'utilisateur auquel je suis connecté a un temps d'inactivité illimité - pas de délai.

Answer 2

La base de données sait-elle que la connexion a été interrompue ou la session est-elle toujours répertoriée dans v $ session? Cela indiquerait, je pense, qu'il est abandonné par le réseau. Savez-vous combien de temps il peut rester inactif avant de rencontrer le problème, et si cela ressemble aux valeurs d'inactivité TCP (net.ipv4.tcp_keepalive_time, tcp_keepalive_probes et tcp_keepalive_interval de sysctl si je me souviens bien)? Impossible de se souvenir si les modifications de sysctl persistent par défaut, mais cela peut être quelque chose qui a été modifié puis réinitialisé par le redémarrage.

Vous pouvez également réinitialiser vos connexions JDBC sans faire rebondir le serveur entier; Je peux certainement le faire dans WebLogic, ce que je réalise ne m'aide pas beaucoup, mais je ne connais pas les équivalents de Tomcat.

Answer 3

Adam a déjà suggéré des profils de base de données.

Vous pouvez vérifier le fichier SQLNET.ORA. Il existe un paramètre EXPIRE_TIME, mais il permet de détecter les connexions perdues, plutôt que de terminer les connexions existantes. Etant donné que cela se produit du jour au lendemain, cela ressemble plus à un délai d'attente inactif, qui peut aller jusqu'à un pare-feu entre le serveur d'applications et le serveur de base de données. La définition de l'EXPIRE_TIME peut arrêter cela (car il y aura vérification toutes les 10 minutes pour vérifier que le client est vivant).

Ou peut-être que la base de données est en cours d'arrêt et redémarrée, ce qui détruit les connexions.

Sinon, vous devriez être en mesure de configurer tomcat avec un validationQuery pour qu'il redémarre automatiquement la connexion sans tomcat restart

Answer 4

Ceci est probablement dû à la piscine de connexion de votre application; pas un problème Oracle DBMS. La plupart des pools de connexion ont une instruction de validation qui peut s'exécuter avant de vous donner la connexion. En oracle, vous voulez "Sélectionnez 1 à partir du dual". La raison pour laquelle cela a commencé à se produire après le redémarrage du serveur est que le pool de connexion a probablement été ajouté sans redémarrage et que vous venez juste d'expérimenter l'utilisation du pool de connexions pour la première fois. Quelles sont les dates de modification de vos fichiers de ressources concernant les connexions à la base de données?

Valider par exemple la requête:

<Resource name="jdbc/EmployeeDB" auth="Container" 
      validationQuery="Select 1 from dual" type="javax.sql.DataSource" username="dbusername" password="dbpassword" 
      driverClassName="org.hsql.jdbcDriver" url="jdbc:HypersonicSQL:database" 
      maxActive="8" maxIdle="4"/> 

EDIT: Dans le cas de Grails, il existe des options de configuration similaires pour la piscine de Grails. Exemple pour Grails 1.2 (voir les notes de version pour Grails 1.2)

dataSource { 
    pooled = true 
    dbCreate = "update" 
    url = "jdbc:mysql://localhost/yourDB" 
    driverClassName = "com.mysql.jdbc.Driver" 
    username = "yourUser" 
    password = "yourPassword" 
    properties { 
     maxActive = 50 
     maxIdle = 25 
     minIdle = 5 
     initialSize = 5 
     minEvictableIdleTimeMillis = 60000 
     timeBetweenEvictionRunsMillis = 60000 
     maxWait = 10000  
    } 
} 

Answer 5

Vérifiez applications Paramètres du pool de connexion, plutôt que de modifier les paramètres de TIMOUT session sur l'oracle db. C'est normal qu'ils expirent.

Jetez un oeil ici: http://grails.org/doc/1.0.x/guide/3.%20Configuration.html#3.3%20The%20DataSource

Etes-vous sûr que vous avez correctement le paramètre « mis en commun »?

Salutations, Lars

---

EDIT:
Votre config semble ok sur un premier aperçu. Je suis tombé sur ce numéro aujourd'hui. Peut-être qu'il est lié à votre douleur:
"Infinite loop of exceptions if the application is started when the database is down for maintenance"

Answer 6

Je suis venu à cette question à la recherche d'un moyen d'activer l'expiration de pool de sessions Oracle basée sur la vie totale de la session au lieu du temps de repos. Un autre but est d'éviter que la force se ferme de manière inattendue à l'application.

Il semble qu'il est possible en réglant la piscine validation query à

select 1 from V$SESSION 
where AUDSID = userenv('SESSIONID') and sysdate-LOGON_TIME < 30/24/60 

Cela fermerait des séances de vieillissement plus de 30 minutes de façon prévisible qui ne touche pas l'application.