Discussion :

[Cerberes]

Bonjour!

J'ai un gros problème...

Une utilisatrice à lancé une grosse requête d'insertion (via une procédure PL/SQL) sur une table. Quelques millions d'enregistrements.
Problème: Depuis le lancement de cette procédure, hier soir, aucun utilisateurs à part votre serviteur ne peut se connecter sur la base. Et même moi, avec des droits de SYSDBA, je ne peux créer aucun objet. Pourtant, la session de l'utilisatrice est killé. Maintenant, même quand je lance un SHUTDOWN IMMEDIATE, la base ne s'arrête pas... Rien ne se passe.
D'ou ma question: Puisque tous les utilisateurs sont sur le même tablespace (je sais, pas très malin), utilisent le même tablespace temporaire et le même tablespace undo, est-ce que c'est cette grosse requête d'insertion qui fait planter tous les autres utilisateurs?

Le gros problème, c'est que lorsqu'un autre utilisateur tente de se connecter à la base, aucun message d'erreur, il attends. Via une console MS/DOS, le prompt disparait, et on attend comme pour une connexion classique, mais nettement plus longtemps... Via sql*plus, idem, PL/SQL Developper idem.

Maintenant, ma question principale (enfin ):
- Comment faire pour bloquer cette insertion (si celle-ci tourne encore)
- Est-ce que c'est possible que ce soit cette insertion qui bloque tous les utilsiateurs?

Merci d'avance pour vos éclaircissements...

[Yorglaa]

à mon avis ta grosses requête d'insertion a généré des ENORMES Redo...

donc quand tu a killé cette session, Oracle a lancé un ENORME Rollback sur toutes les lignes insérées et non commitées...

ceci expliquerait cela...

[LeoAnderson]

Là, il est tout simplement en train de faire les rollbacks à mon avis...

dans v$session, vous voyez quoi ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
SELECT s.sid,
       s.status,
       s.process,
       s.schemaname,
       s.osuser,
       a.sql_text,
       p.program
FROM   v$session s,
       v$sqlarea a,
       v$process p
WHERE  s.SQL_HASH_VALUE = a.HASH_VALUE
AND    s.SQL_ADDRESS = a.ADDRESS
AND    s.PADDR = p.ADDR;

A moins que ce ne soit l'espace de redo log qui soit saturé, mais là, normalement, il balance "archiver error" et le message dit que seul SYSDBA peut se connecter...

<EDIT> Si ce sont les rollback (ce qui est plus que probable), vous pouvez éventuellement arrêté la base par un shutdown abort, mais le temps gagné à l'arrêt, vous le perdrez de nouveau au démarrage....
</EDIT>

[Cerberes]

C'est ce que je pensais... J'ai créé pas mal de dbfile pour le tablespace redo, au cas ou quelque chose comme ça ce produirait...

Donc je ne peux absolument rien faire? Attendre et c'est tout?

[Cerberes]

J'ai réussis! Tout seul, comme un grand... Fier de moi!

Alors... Un petit shutdown abort, puis un startup et la base à lancé une petite récupération... Et tout joue!!!!


Merci tout de même, Yorglaa, pour tes explications...

[Cerberes]

<EDIT> Si ce sont les rollback (ce qui est plus que probable), vous pouvez éventuellement arrêté la base par un shutdown abort, mais le temps gagné à l'arrêt, vous le perdrez de nouveau au démarrage....
</EDIT>

+1

Comme ça, c'est bon.

Désolé, je n'avais pas actualisé, comme toujours...

Cette solution marche parfaitement!

Sinon, dans ma vue v$session, plus aucune session n'était active, à part la session SYS, évidemment...

Merci, en tout cas!

[Marc Musette]

J'ai réussis! Tout seul, comme un grand... Fier de moi!


évidemment, si tu peux faire un shutdown abort et relancer la db ... peu de problème resteront sans solution

tu peux être fier de toi ;

[LeoAnderson]

Y'a pas de mal ! :-)

Et c'est vrai que j'ai oublié de préciser que le startup serait lent SI ET SEULEMENT SI la table incriminée était en LOGGING !

[Cerberes]

En tout cas, merci beaucoup à vous tous... Je dois l'avouer, j'ai eu très peur! Cette base est... comment dire... plutôt utile... Mon boss n'à pas eu à avoir recours au canibalisme, je suis entier et en bonne santé: Cette semaine finis bien.

Y'a pas à dire, c'est le SEUL forum que je connais ou les utilisateurs sont présents et simpas... Merci les gars!