Killer une session quel que soit l'OS

Hé oui, ça peut paraître bête, mais j'ai tellement l'habitude de killer les sessions qui m'embêtent sous Unix que je me suis retrouvée comme une conne sous MS-DOS!

Recherche de la session à killer

Cette partie est la même quel que soit l'OS.
Il suffit de jouer cette requête :

SET LINESIZE 100
COLUMN spid FORMAT A10
COLUMN username FORMAT A10
COLUMN program FORMAT A45

SELECT s.inst_id,
       s.sid,
       s.serial#,
       p.spid,
       s.username,
       s.program
FROM   gv$session s
       JOIN gv$process p ON p.addr = s.paddr 
                        AND p.inst_id = s.inst_id
WHERE  s.type != 'BACKGROUND';

Le résultat sera de ce genre :

   INST_ID        SID    SERIAL# SPID       USERNAME   PROGRAM 
---------- ---------- ---------- ---------- ---------- --------------------------------------------- 
         1        150         17 6116       DBSNMP     emagent.exe 
         1         92        120 1384       XXX        SQL Developer 
         1         16         68 6104       DBSNMP     emagent.exe 
         1         32        105 4616       SYS        sqlplus.exe 
         1        124         22 5684       DBSNMP     emagent.exe 

Killer la session

Toujours sous sqlplus, vous pouvez alors killer cette session. La syntaxe est :

ALTER SYSTEM KILL SESSION 'sid,serial#';

Ce qui dans mon exemple donne :

ALTER SYSTEM KILL SESSION '92,120';

SystÞme modifiÚ.

Oui, la console sous MS-DOS affiche toujours des caractères bizarres, mais Oracle n'a visiblement pas l'intention de le corriger.

Pour aller plus loin

Voici le livre Oracle avec la syntaxe du ALTER SESSION : http://docs.oracle.com/cd/E11882_01/server.112/e26088/statements_2013.htm#i2231814

Résoudre l'ORA-00020

Lors d'un import datapump, je me suis retrouvée face à l'ORA-00020.

L'erreur

Voici les insultes proférées par Oracle pour avoir tenté un import datapump sans avoir les ressources processeur nécessaire :

ORA-31626: la tÔche n'existe pas
ORA-31687: erreur lors de la crÚation du processus esclave  avec l'ID de processus esclave 1
ORA-31687: erreur lors de la crÚation du processus esclave DW01 avec l'ID de processus esclave 1
ORA-39106: Le processus esclave DW01 a ÚchouÚ lors du dÚmarrage. Erreur du processus esclave :
ORA-00020: nombre maximum de processus () atteint

(On remarquera au passage les jolis caractères bizarres liés à une mauvaise utilisation par Oracle du jeu de caractères MS-DOS, encore une raison de préférer les bases en anglais : mieux vaut du bon anglais que du mauvais français...)

Ce que ça veut dire

Voilà l'explication Oracle :

ORA-00020: maximum number of processes (string) exceeded

Cause: All process state objects are in use.

Action: Increase the value of the PROCESSES initialization parameter.

Oracle est tout bêtement en train de dire qu'on lui a alloué un certain nombre de processus et qu'il les a tous mangés!

Première solution

Mon import correspondant à une "restore" (oui, je suis obtue, mais pour moi seul rman fait une vraie restore) totale des données, j'ai demandé à mon intégrateur préféré de couper le serveur d'application. ça a permis de libérer des processus pour faire passer mon import.

Deuxième solution

Si vous ne pouvez pas couper de connexion, vous pouvez tout aussi bien augmenter le nombre de processus disponibles pour cette instance :

SQL> select name, value from v$parameter where name = 'processes';

NAME 
-------------------------------------------------------------------------------- 
VALUE 
-------------------------------------------------------------------------------- 
processes 
150 
SQL> alter system set processes=300 scope=spfile; 
 
SystÞme modifiÚ. 
 
SQL> shutdown immediate 
Base de donnÚes fermÚe. 
Base de donnÚes dÚmontÚe. 
Instance ORACLE arrÛtÚe. 
SQL> startup 
Instance ORACLE lancÚe. 
 
Total System Global Area 1073741824 bytes 
Fixed Size                  1300756 bytes 
Variable Size             427820780 bytes 
Database Buffers          629145600 bytes 
Redo Buffers               15474688 bytes 
Base de donnÚes montÚe. 
Base de donnÚes ouverte. 

On remarquera encore la bonne gestion part Oracle des caractères accentués sous Windows

Pour aller plus loin

Le livre des erreurs Oracle : http://docs.oracle.com/cd/E11882_01/server.112/e17766/e0.htm#sthref15