Discussion :

[de LANFRANCHI]

bonjour,

nous sommes en train de developper une appli intranet en jsp avec le driver jdbc et oracle 8i.

on essai de mettre en place un pool de connexions et on nage un peu dans le potage.


sans mettre en place le pool, je vois a travers la vue v$session la demande connexion de l'utilisateur à travers Apache.

mais une fois le pool active, je n'arrive pas à visualiser les historiques pour verifier si une demande a ete faite.

j'ai 2 questions :
comment fonctionne un pool avec jdbc ?
comment visualiser les historiques des sessions oracle ?

merci de votre reponse.

[rouardg]

Bonjour,

Il n'y a pas d'historique de sessions sous Oracle. En fait, la vue v$session vous montre toutes les connexions à la base de données à l'instant t.

Par session, on entend aussi bien toutes les connexions utilisateurs (que ce soit du SQL*Plus, du Toad, du client, des batchs, du pool de connexion) que les processus d'arrière plan Oracle (PMON, SMON, DBWR, LGWR...) Pour les distinguer, il faut regarder la colonne TYPE de v$session (les premiers figurent en USER, les autres en BACKGROUND).

Au niveau du pool, je ne connais pas Apache, mais sous Weblogic on donne l'URL de connexion à la base de données, et on indique combien on veut de connexions créées au lancement du serveur J2EE, quel est le nombre max de connexions, de quelle manière il s'étend, et sa période de rafraîchissement).

Enfin pour finir, pour savoir à quelle heure une session a été créée, il faut regarder la colonne LOGON_TIME de v$session

[LeoAnderson]

Bonjour

Pour le fonctionnement du pool, avez-vous pris connaissance de cette doc ?
http://download-east.oracle.com/otn_...kage-tree.html
Cependant, étant donné que c'est le JDBC qui gère ce pool, vous aurez sûrement plus de chances du côté du forum Java.

Sinon, en ce qui concerne les sessions, il y a deux cas de figure :

• soit la session existe toujours sur le serveur Oracle, dans ce cas, c'est simple : DBA Studio vous permet de connaitre les dernières commandes
• soir la session n'existe plus et dans ce cas, il vous faudra mettre en place l'audit...

Leo.

[de LANFRANCHI]

peut on verifier la connexion par l'historique des requetes alors.

est-ce enregistre dans les REDO log et si oui comment les vusualiser en 8i

merci

[LeoAnderson]

peut on verifier la connexion par l'historique des requetes alors.

est-ce enregistre dans les REDO log et si oui comment les vusualiser en 8i

merci

Si votre requête est simple à isoler, vous pouvez commencer par chercher dans v$SQLText.
Par contre, les redo log sont les journaux internes à Oracle qui servent à journaliser les transactions; de toute façon, il n'existe pas de manière de les lire comme ça, simplement.

Mais pourquoi votre produit ne réalise tout simplement pas une insertion dans une table bidon ? vous saurez alors si la connection a eue lieue ou pas ?

[bouyao]

Dans les Redo on n'enregistre pas les conexions ,
Oracle enregistre les données modifiées de la base dans les Redos.

[de LANFRANCHI]

merci à tous

je vais me servir de la solution de l'insert.

[LeoAnderson]

Vous pouvez même perfectionner un peu ceci avec un trigger after logon on database qui vous permettra de journaliser les connections....

[de LANFRANCHI]

j'ai trouve un exemple de trigger à mettre en place mais j'ai une erreur
sur le sys.v_$session

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
CREATE OR REPLACE TRIGGER LOGON_GRILLE
AFTER LOGON ON DATABASE
DECLARE
	PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
	IF ( sys_context('userenv','sessionid') != 0 ) then
	INSERT INTO system.logon_grille
		( SELECT USER,
		sys_context('userenv','sessionid'),
		sys_context('userenv','os_user'),
		sys_context('userenv','host'),
		sys_context('userenv','ip_address'),
		program,
		sysdate
		FROM sys.v_$session
		WHERE AUDSID = sys_context('userenv','sessionid') );
	COMMIT;
END IF;
END;

je me connecte en tant que system, et je cree le trigger
à la compile l'objet sys.v_$session n'est pas reconnu

et lorsque qu'un utilisateur se connecte , la session est refusee du fait de l'erreur sur le trigger

1) je pensais que le trigger n'etait pas actif tans qu'il y avait des erreurs
2) manque t-il un grant sur l'utilisateur sur le trigger , sur la table

merci de votre reponse

[LeoAnderson]

Il vaut mieux utiliser v$session.

pour vous en sortir, une connection AS SYSDBA permet d'éviter le déclenchement des triggers AFTER LOGON