Version imprimable
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.Citation:
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. :roll: Sans compter que la base distante à ses propres connexions cela commence à faire beaucoup de connexions simultanées...Citation:
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 ?
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. :P
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 ...Citation:
Envoyé par elecoest
En plus, il est possible de fermer cette session prématurément avec l'instruction suivante
Code:
2
Là va falloir que tu rencontres mes DBA alors :roll:. J'ai jamais dit que c'était un "écueil", j'ai dit que c'était un "écueil" pour nous. Pour t'assurer de l'écueil pour nous : Tu prends 3 instances sur 3 machines différentes, tu créer les dblink et tu simules 10 sessions sur chaque instances qui font un accès via le dblink. Tu audites la mémoire de chaque machine et le réseau et tu multiples par 50 ton résultat.Citation:
Envoyé par Michel SALAIS
Ca çà m'interesse par contre :king:. Reste à voir les impacts avec le comiit implicite mais çà m'interesse grandement. Merci l'ami.Citation:
En plus, il est possible de fermer cette session prématurément avec l'instruction suivante
ALTER SESSION CLOSE DATABASE LINK db_link_name
Quelle alternative aurions nous si ça ne fonctionnait pas comme ça?Citation:
Envoyé par elecoest
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.Citation:
Envoyé par Michel SALAIS
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.Citation:
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,Citation:
Envoyé par elecoest
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;Citation:
Envoyé par Michel SALAIS
ne retourne rien.Code:SELECT * from v$transaction
De plus Tom Kyte dit clairement:
Est-ce que le comportement est différent en mode distribué ?Citation:
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 transactionCitation:
Envoyé par pifor
Citation:
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.
:king:
Bien vu !