[9.2] Table inaccessible

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

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

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

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

Jaouad

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

Benoit

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

Code:

---

select event from v$session_wait

---

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

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

Citation:

---

Envoyé par LeoAnderson

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

Par exemple :

Code:

---

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;

---

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

Tout d'abord, on ne supprime pas un verrous ! :D
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:

---

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

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

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:

---

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

---

puis sous un compte DBA vous supprimez la session :

Code:

---

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