Discussion :

[benoithenry]

Bonjour,

Je m'occupe depuis peu de plusieurs bases de données avec interfaces access et données sur Oracle 9.2 dans ma boite.
Le problème est que régulièrement il y a une table commune à plusieurs programmes qui ne répond plus. Cela dure environ pendant 30 min - 1 heure et elle est de nouveau accessible ensuite.
Je ne comprends pas de quoi cela peut-il venir ? Une requete mal construite peut elle faire rendre inaccessible une table d'Oracle (comme une boucle infinie...) ? (elle n'est plus accessible ni depuis SQL+ ni depuis la console OEM, ni depuis Access, ces programmes se plantent lorsqu'ils tentent d'y accéder).

Cela vous est-il déjà arrivé ?
Si des lumières peuvent m'éclairer....

Cordialement
Benoit

[Jaouad]

Bonjour ,
Votre probléme est pour le moins supremant .

Cependant veuillez à étre précis , que veut dire inacessible , qu'elle est le statut de votre session ....

ëtre factuelle est précis ...

[benoithenry]

Désolé je précise :
J'entendais par inaccessible que le programme à partir du quel je lance une requête sur la table en question (un simple desc ou select) se bloque et ne réponds plus.
J'ai essayé d'accéder à la table avec Access, SQL+, et par OEM en essayant de visualiser le contenu de la table (connecté en tant que "Normal") par clic droit / Afficher modifier le contenu).
Access affiche un message d'erreur : echec appel ODBC au bout d'un certain temps après la requête, 1 à 2 min, (l'accès aux autres tables de la base continuant à fonctionner.)

La base Oracle contient de nombreuses autres tables qui fonctionnent sans problème. Seul l'accès à cette table pose problème pendant des périodes de 30min - 1h. Ensuite tout redevient normal. Je soupsone une requête à partir d'Access mal formulée ou quelque chose du genre qui provoquerait une connexion impossible à la table jusqu'à un timeout , est-ce possible d'obtenir ainsi ce problème ?

Benoit

[Jaouad]

non
pourriez vous nous dire qu'elle est l'état de la session bloqué dans la vue v$session_wait

Jaouad

[benoithenry]

Comment puis-je obtenir l'état de la session bloqué ?

Benoit

[benoithenry]

Correction, la base tourne sous Oracle 8.1.7 :

Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
PL/SQL Release 8.1.7.0.0 - Production
CORE 8.1.7.0.0 Production
TNS for 32-bit Windows: Version 8.1.7.0.0 - Production
NLSRTL Version 3.4.1.0.0 - Production

[Jaouad]

Code :

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

select event from v$session_wait

[LeoAnderson]

est-ce que par hasard il n'y aurait pas un VERROUS sur cette table (calcul des stats par exemple) ? ;-)

[benoithenry]

alors voici ce que j'ai trouvé :

le SID qui accède à la table est en row cache lock et TOTAL_WAITS = 102
TOTAL_TIMEOUTS = 102
SECONDS_IN_WAIT = 218
STATE = WAITING
ces valeurs augmentant au fur et à mesure.

Pourquoi le SID reste en row cache lock ?

Benoit

[benoithenry]

est-ce que par hasard il n'y aurait pas un VERROUS sur cette table (calcul des stats par exemple) ? ;-)

Euh comment fait-on pour voir s'il y a un verrou sur la table?
(désolé je commence l'administation de base Oracle, je ne connais pas tout encore )

Benoit

[LeoAnderson]

Par exemple :

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
SELECT DISTINCT a.object_name,
       a.owner object_owner,
       Decode(b.locked_mode, 0, 'None',
                             1, 'Null (NULL)',
                             2, 'Row-S (SS)    [SELECT FOR UPDATE]',
                             3, 'Row-X (SX)    [INSERT/UPDATE/DELETE]',
                             4, 'Share (S)' ,
                             5, 'S/Row-X (SSX)',
                             6, 'Exclusive (X) [ALTER/DROP/TRUNCATE TABLE/INDEX]',
                             b.locked_mode) locked_mode,
       b.session_id sid,
       b.oracle_username,
       b.os_user_name,
       c.BLOCK AS Sessions_Bloquees
  FROM all_objects a,
       v$locked_object b,
       v$lock C
 WHERE a.object_id = b.object_id
   AND C.SID = B.SESSION_ID
 ORDER BY 1;

[benoithenry]

J'ai en effet un verou de type Row-X (SX) [INSERT/UPDATE/DELETE] sur ma table.
On ne peut donc ni insérer, supprimer ni mettre à jour de données ?
Comment peut-on supprimer ce verrou ?


Benoit

(J'ai aussi un pb similaire sur une autre table, lorsque j'essaye de modifier une donnée sous sql+ ou OEM, ces programmes se gèlent, mais la table en question n'a pas de vérou... je reprends la base telle quelle et l'admin vient de partir et les problèmes arrivent ... )

[LeoAnderson]

Tout d'abord, on ne supprime pas un verrous !
Un verrou cela signifie que quelqu'un a "pris une option" sur les données. On pourra agir uniquement lorsqu'il aura dit "ok, je valide" (COMMIT) ou "tant pis, je fais pas" (ROLLBACK).
C'est le B-A-BA de la gestion des transactions.

Ensuite, le verrous étant un verrous ligne, vous pouvez accéder à la table sauf au(x) ligne(s) "réservées" par une autre sessions.
[edit]
Le plus simple pour vous en assurez, vous faites :

Code :

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

 SELECT * FROM MATABLE WHERE <Condition de clé primaire pour ne prendre qu'une seule ligne> FOR UPDATE NOWAIT;

Si aucune exception n'est levée, ce n'est pas un problème de verrous.
Faites alors un ROLLBACK;
[/edit]

Sinon, combien de sessions étaient indiquées comme "bloquées" ?

Par contre, je me demande si on ne serait pas dans le cas d'une clé étrangère non indexée...

[benoithenry]

J'ai fait un select sur un numero de cle unique avec FOR UPDATE NOWAIT, je n'ai eu aucun message d'erreur j'ai donc efectué un rollback. Il n'y a plus de verou posé sur la table.

question : lorsqu'Access ajoute une donnée dans une base Oracle, il doit faire un COMMIT automatiquement non ?

par contre un autre verou a été posé par un utilisateur à partir d'Access et je ne peux pus faire de select sur la table, sql se freeze....
Cet utilisateur possède deux SID :
un est en library cache lock et l'autre est en row cache lock avec les TOTAL_TIMEOUTS qui augmentent..

Je ne suis pas sorti de mes pbs !

Benoit

[Jaouad]

Bonjour si vous avez un lock sur ces tables il faut killer la session

si vous avez le SID et le serial# que vous récupérez ainsi :

Code :

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

select SID, SERIAL# from v$session where SID=xx

puis sous un compte DBA vous supprimez la session :

Code :

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

alter system kill session 'SID,SERIAL#' ;

SMon s'occupera dans la foulée de libérer la ressource.

NOrmalement ces ressources se libérent également à chaque arrêt redémarrage de la base


Jaouad