dblink / session persistante [Résolu]

[Emmanuel Lecoester]

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.

[LeoAnderson]

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 ?

[Emmanuel Lecoester]

Envoyé par LeoAnderson

http://download.oracle.com/docs/cd/B....htm#sthref479
SQLNET.EXPIRE_TIME ?

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.

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 ?

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. Sans compter que la base distante à ses propres connexions cela commence à faire beaucoup de connexions simultanées...

[LeoAnderson]

j'ai pas de quoi tester sous la main, mais ça me semble un fonctionnement anormal

quelles sont les versions ? (cible et source)

[Emmanuel Lecoester]

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.

[Michel SALAIS]

Envoyé par elecoest

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.

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 :

1
2
ALTER SESSION CLOSE DATABASE LINK db_link_name

[Emmanuel Lecoester]

Envoyé par Michel SALAIS

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 ...

Là va falloir que tu rencontres mes DBA alors . 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.

En plus, il est possible de fermer cette session prématurément avec l'instruction suivante
ALTER SESSION CLOSE DATABASE LINK db_link_name

Ca çà m'interesse par contre . Reste à voir les impacts avec le comiit implicite mais çà m'interesse grandement. Merci l'ami.

[Michel SALAIS]

Envoyé par elecoest

Là va falloir que tu rencontres mes DBA alors . 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.



Ca çà m'interesse par contre . 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?
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.

[Emmanuel Lecoester]

Envoyé par Michel SALAIS

Quelle alternative aurions nous si ça ne fonctionnait pas comme ça?
As-tu pensé par exemple aux transactions? Comment faire des transactions sans session persistante?

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.

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.

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.

[Michel SALAIS]

Envoyé par elecoest

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.

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

[mnitu]

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

[pifor]

Envoyé par Michel SALAIS

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!

Michel

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;

Code :

SELECT * FROM v$transaction

ne retourne rien.

De plus Tom Kyte dit clairement:

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).

Est-ce que le comportement est différent en mode distribué ?

[mnitu]

Envoyé par pifor

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;
...
Est-ce que le comportement est différent en mode distribué ?

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.

[pifor]

Bien vu !