Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
dblink / session persistante
Bonjour,
Soit 2 bases A et B.
Un dblink existe entre A et B (A accès à B au travers du dblink).
Dans une transaction utilisateur sur la base A on doit aller chercher une info sur la base B. Si on passe par le dblink, on ouvre une session persistante sur la base B jq deconnexion de l'utilisateur.
Connaissez vous un moyen ORACLE pour éviter cet écueil de session persistante ?
Merci d'avance.
http://download.oracle.com/docs/cd/B....htm#sthref479
SQLNET.EXPIRE_TIME ?
le problème est quoi ? quand vous faites un select via un dblink, la connexion sur la base remote reste jusqu'à ce que la session sur la base locale se termine ?
en quoi est-ce gênant ?
L'inconvénenient de cette technique c'est que c'est valable quelque soit la connexion (directe ou via dblink). Mais merci pour l'info.Envoyé par LeoAnderson
Ben oui c'est exactement çà. Quand tu as 500 utilisateurs qui ont une connexion persistante sur une autre base via dblink avec 100 curseurs oracle actifs celà fait un peut beaucoup pour un max_open_cursor.le problème est quoi ? quand vous faites un select via un dblink, la connexion sur la base remote reste jusqu'à ce que la session sur la base locale se termine ?
en quoi est-ce gênant ?Sans compter que la base distante à ses propres connexions cela commence à faire beaucoup de connexions simultanées...
j'ai pas de quoi tester sous la main, mais ça me semble un fonctionnement anormal
quelles sont les versions ? (cible et source)
Je t'assure que c'est un fonctionnement tout à fait normal.
Version 9i de chaque coté, bientot 10G.
Application forms => bouton qui déclenche une P/S sur la base distante.
La session sur la base distante reste active jq déconnexion de l'utilisateur ce qui est tout à fait normal. Le but est de réduire la bande passante réseau entre ces deux bases et l'activité autour des deux bases.
Je suis en désaccord total avec la description de la session persistante comme étant un écueil. C'est même un mécanisme indispendable ...
En plus, il est possible de fermer cette session prématurément avec l'instruction suivante
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Là va falloir que tu rencontres mes DBA alors
Ca çà m'interesse par contreEn plus, il est possible de fermer cette session prématurément avec l'instruction suivante
ALTER SESSION CLOSE DATABASE LINK db_link_name. Reste à voir les impacts avec le comiit implicite mais çà m'interesse grandement. Merci l'ami.
Quelle alternative aurions nous si ça ne fonctionnait pas comme ça?Là va falloir que tu rencontres mes DBA alors
Ca çà m'interesse par contre
As-tu pensé par exemple aux transactions? Comment faire des transactions sans session persistante?
En ce qui concerne la fermeture, elle nécessite de terminer explicitement la transaction avant de pouvoir lancer avec succès l'instruction alter session.
J'ai du mal à te suivre. Ce sont des questions concernant l'avantage d'avoir une session persistante ? si oui, je te remercie de me les rappeler malgré le fait que je connaisse ces avantages. Maintenant tu as très bien résumé mon besoin : arreter la session persistante que je n'ai plus besoin de la connexion avec la base distante. Ton ALTER SESSION me convient pleinement.
Sans vouloir jouer sur les mots le alter session etant pour moi un ordre DDL il y aura commit implicite. Mais il va de soi que j'aurais gérer ma transaction de manière explicite.En ce qui concerne la fermeture, elle nécessite de terminer explicitement la transaction avant de pouvoir lancer avec succès l'instruction alter session.
Bonjour,
Ce que j'ai essayé de dire est que la gestion transactionnelle nécessite l'utilisation de session persistente et je ne vois point d'alternative à cette solution.
En ce qui conecrne l'instruction ALTER SESSION, ce n'est pas une instruction LDD (DDL) et donc il n'y a pas de commit implicite. Mais la fermeture du lien ne peut se faire que si la transaction est terminée même si elle ne fait que des instructions SELECT!
En fait, ALTER SESSION fait partie d'une catégorie d'instructions à part et constitue avec SET ROLE la catégorie des instructions de contrôle de session.
J'espère que j'ai réussi à être plus claire cette fois ...
Michel
Je n’ai jamais utilisé, mais il y a aussi une notion de « share database link » que je pense qu’elle pouvait aider dans ce cas. http://download-west.oracle.com/docs...s.htm#i1007763
Est-ce qu'on peut parler de transaction si la session n'exécute que des SELECT (sans clause FOR UPDATE). ? A priori, je dirais non: si je fais un test avec un SELECT COUNT(*) sur un grande table qui dure quelque minutes;
ne retourne rien.
Code : Sélectionner tout - Visualiser dans une fenêtre à part SELECT * from v$transaction
De plus Tom Kyte dit clairement:
Est-ce que le comportement est différent en mode distribué ?a select does not begin a transaction in read committed mode. a modification will. In serializable the "set" command marks the beginning of the transaction (IT would be the first statement).
C'est peut être ça qui induit l'idée de transaction
Oracle9i Database Administrator's Guide Release 2 (9.2)
The connections and sessions established to remote databases persist for the duration of the local user's session, unless the application or user explicitly terminates them. Note that when you issue a SELECT statement across a database link, a transaction lock is placed on the rollback segments. To re-release the segment, you must issue a COMMIT or ROLLBACK statement.
Bien vu !
Répondre avec citation
Partager