Purger les problèmes dans ADRCI

Le souci

J’utilise la commande purge d’adrci mais mes problèmes restent présents

La commande

adrci> delete from PROBLEM

L’autre souci

L’autre souci c’est que ça purge tous les problèmes et que j’aimerais bien garder ceux qui sont “récents”.

C’est pas interdit de demander de l’aide …

adrci> help delete

  Usage: DELETE FROM <relation> [WHERE <predicate_string>]
       Arguments:
         <relation_name>: Name of the relation to delete from.

      [WHERE <predicate_string>]: The predicate string must be double-quoted.

      Examples:
       delete from incident where 'incident_id > 1'
adrci> show problems

ADR Home = /opt/oracle/diag/rdbms/dbun/DBNAME:
*************************************************************************
PROBLEM_ID           PROBLEM_KEY                                                 LAST_INCIDENT        LASTINC_TIME
-------------------- ----------------------------------------------------------- -------------------- ----------------------------------------
1                    ORA 600 [psdnopGetACL-4]                                    81105                2016-03-27 03:53:10.648000 +02:00
2                    ORA 600 [ktcccod-1]                                         3960130              2016-04-22 06:25:53.408000 +02:00
3                    ORA 600 [kdBlkCheckError]                                   8600040              2016-05-24 11:14:17.489000 +02:00

Allons-y essayons

adrci> delete from PROBLEM where lastinc_time < to_date('2016-03-27 04:00:00', 'YYY-MM-DD HH24:MI:SS' )
DIA-48260: Function to_date not found

Mince, c’est pas du vrais SQL Oracle avec les fonctions qui vont bien !

adrci> delete from PROBLEM where lastinc_time < sysdate-60
DIA-48230: Expression arguments must match types
DIA-48249: Type mismatch - lhs = 7, rhs = 6, result = 8, op = 0

Mince, ça ne sait pas transtyper !

adrci> delete from PROBLEM where lastinc_time < systimestamp - 60

1 Row Deleted

adrci> show problems

ADR Home = /opt/oracle/diag/rdbms/dbun/DBNAME:
*************************************************************************
PROBLEM_ID           PROBLEM_KEY                                                 LAST_INCIDENT        LASTINC_TIME
-------------------- ----------------------------------------------------------- -------------------- ----------------------------------------
2                    ORA 600 [ktcccod-1]                                         3960130              2016-04-22 06:25:53.408000 +02:00
3                    ORA 600 [kdBlkCheckError]                                   8600040              2016-05-24 11:14:17.489000 +02:00
2 rows fetched

C’était pourtant pas si compliqué

Tuer une tâche datapump qui n’a plus son fichier dump sur disque

Le souci

Mon export datapump s’est planté, j’ai effacé mon fichier de dump et donc plus moyen de faire l’attachement qui me permettrait de tuer la tâche en faisant kill_job. Pire encore, quand je tente le coup, datapump me donne un message d’erreur qui n’a pas gtrand chose à vois avec la problème réel.

[oracle@serveur ~]$ impdp toto/lolo attach=SYS_IMPORT_TRANSPORTABLE_01

Import: Release 11.2.0.4.0 - Production on Thu Apr 7 09:45:57 2016

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning option
ORA-31626: job does not exist
ORA-06512: at &amp;quot;SYS.DBMS_SYS_ERROR&amp;quot;, line 79
ORA-06512: at &amp;quot;SYS.KUPV$FT&amp;quot;, line 405
ORA-31638: cannot attach to job SYS_IMPORT_TRANSPORTABLE_01 for user TOTO
ORA-31632: master table &amp;quot;TOTO.SYS_IMPORT_TRANSPORTABLE_01&amp;quot; not found, invalid, or inaccessible
ORA-00942: table or view does not exist

(suite…)

Créer un package ADRCI

[oracle@serveur ~/work]$ adrci

ADRCI: Release 11.2.0.4.0 - Production on Thu Jan 7 14:14:24 2016

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

ADR base = "/opt/oracle"
adrci> show incident

ADR Home = /opt/oracle/diag/rdbms/titi/titi:
*************************************************************************
0 rows fetched

ADR Home = /opt/oracle/diag/rdbms/serveur/DB:
*************************************************************************
INCIDENT_ID          PROBLEM_KEY                                                 CREATE_TIME
-------------------- ----------------------------------------------------------- ----------------------------------------
208129               ORA 600 [ktcccod-1]                                         2016-01-05 06:45:45.367000 +01:00
592465               ORA 600 [kdBlkCheckError]                                   2016-01-07 11:27:32.712000 +01:00
592481               ORA 600 [kdBlkCheckError]                                   2016-01-07 11:29:22.188000 +01:00
592466               ORA 600 [kdBlkCheckError]                                   2016-01-07 12:08:52.179000 +01:00
592457               ORA 600 [kdBlkCheckError]                                   2016-01-07 12:11:18.073000 +01:00
592449               ORA 600 [kdBlkCheckError]                                   2016-01-07 12:22:53.246000 +01:00
592467               ORA 600 [kdBlkCheckError]                                   2016-01-07 12:57:21.733000 +01:00
592441               ORA 600 [kdBlkCheckError]                                   2016-01-07 13:20:34.972000 +01:00
592442               ORA 600 [kdBlkCheckError]                                   2016-01-07 13:36:02.718000 +01:00
592443               ORA 600 [kdBlkCheckError]                                   2016-01-07 13:43:26.175000 +01:00



adrci> IPS CREATE PACKAGE PROBLEM 592443
DIA-48448: This command does not support multiple ADR homes


adrci> show homes
ADR Homes:
diag/rdbms/titi/titi
diag/rdbms/serveur/DB

adrci> SET HOME diag/rdbms/serveur/DB
adrci> show incident

ADR Home = /opt/oracle/diag/rdbms/serveur/DB:
*************************************************************************
INCIDENT_ID          PROBLEM_KEY                                                 CREATE_TIME
-------------------- ----------------------------------------------------------- ----------------------------------------
208129               ORA 600 [ktcccod-1]                                         2016-01-05 06:45:45.367000 +01:00
592465               ORA 600 [kdBlkCheckError]                                   2016-01-07 11:27:32.712000 +01:00
592481               ORA 600 [kdBlkCheckError]                                   2016-01-07 11:29:22.188000 +01:00
592466               ORA 600 [kdBlkCheckError]                                   2016-01-07 12:08:52.179000 +01:00
592457               ORA 600 [kdBlkCheckError]                                   2016-01-07 12:11:18.073000 +01:00
592449               ORA 600 [kdBlkCheckError]                                   2016-01-07 12:22:53.246000 +01:00
592467               ORA 600 [kdBlkCheckError]                                   2016-01-07 12:57:21.733000 +01:00
592441               ORA 600 [kdBlkCheckError]                                   2016-01-07 13:20:34.972000 +01:00
592442               ORA 600 [kdBlkCheckError]                                   2016-01-07 13:36:02.718000 +01:00
592443               ORA 600 [kdBlkCheckError]                                   2016-01-07 13:43:26.175000 +01:00
10 rows fetched

adrci> IPS CREATE PACKAGE PROBLEMKEY "ORA 600 [kdBlkCheckError]"
Created package 1 based on problem key ORA 600 [kdBlkCheckError], correlation level typical

adrci> show problem

ADR Home = /opt/oracle/diag/rdbms/serveur/DB:
*************************************************************************
PROBLEM_ID           PROBLEM_KEY                                                 LAST_INCIDENT        LASTINC_TIME
-------------------- ----------------------------------------------------------- -------------------- ----------------------------------------
1                    ORA 600 [ktcccod-1]                                         208129               2016-01-05 06:45:45.367000 +01:00
2                    ORA 600 [kdBlkCheckError]                                   592443               2016-01-07 13:43:26.175000 +01:00
2 rows fetched

adrci> IPS ADD FILE /opt/oracle/diag/rdbms/serveur/DB/trace/DB_s001_217994.trc PACKAGE 2
DIA-49404: No such package [2]

adrci> IPS SHOW PACKAGE
   PACKAGE_ID             1
   PACKAGE_NAME           ORA600kdB_20160107142052
   PACKAGE_DESCRIPTION
   DRIVING_PROBLEM        2
   DRIVING_PROBLEM_KEY    ORA 600 [kdBlkCheckError]
   DRIVING_INCIDENT       592465
   DRIVING_INCIDENT_TIME  2016-01-07 11:27:32.712000 +01:00
   STATUS                 New (0)
   CORRELATION_LEVEL      Typical (2)
   PROBLEMS               1 main problems, 1 correlated problems
   INCIDENTS              6 main incidents, 2 correlated incidents
   INCLUDED_FILES         41

adrci> IPS GENERATE PACKAGE 1 IN /opt/oracle/work
Generated package 1 in file /opt/oracle/work/ORA600kdB_20160107142052_COM_1.zip, mode complete
adrci> exit

Retrouver les informations relatives à ma session

Je veux savoir quelle est ma session au niveau de v$session et à quel processus OS elle correspond

La requête à passer est la suivante :

set pages 0 lines 230 newp none emb on

col machine for a25

select v.SID, v.USERNAME, v.MACHINE, v.PROGRAM, v.TERMINAL, SPID &amp;amp;quot;OS PID&amp;amp;quot;, v.process
from v$session v inner join v$process p on v.paddr=p.addr
where v.AUDSID=USERENV('SESSIONID')
and v.MACHINE=SYS_CONTEXT('USERENV','HOST')
and v.TERMINAL=USERENV('TERMINAL')
/

Son résultat :

       
SID        USERNAME                       MACHINE                   
---------- ------------------------------ ------------------------- 
       633 SYS                            srvorcl.ojo.fr            
       
PROGRAM                                          TERMINAL                       
------------------------------------------------ ------------------------------      
sqlplus@srvorcl.ojo (TNS V1-V3)                  pts/2                          

OS PID                   PROCESS
------------------------ ------------------------  
147476                   147469       

On a OS PID qui correspond à l’identifiant du process de connexion de SQLPLUS à la base de données et process qui correspond l’indentifiant du process sqlplus

ps -edf | grep 147476 | grep -v grep
oracle   147476 147469  0 15:12 ?        00:00:00 oracleTECH (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

ps -edf | grep 147469 | grep -v grep
oracle   147469 197784  0 15:12 pts/2    00:00:00 sqlplus
oracle   147476 147469  0 15:12 ?        00:00:00 oracleORCL (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

Pour tuer la connexion sans tuer sqlplus (et se retrouver en mode nolog) c’est le process 147476 qu’il faut tuer.

C’était pourtant pas si compliqué

Effacer des vieux fichiers

Une commande de base qu’on oublie tout le temps

La commade pour effacer les fichiers de plus de 3 jours d’une sous arborescence.

find . -mtime +3 -exec rm {} \;

Utile pour purger les fichers d’uadit par exemple
C’était pourtant pas si compliqué

Vérifier le paramétrage CBO spécifique à une instance

Normalement on sait comment se comporte l’optimiseur Oracle, mais quand on a des surprises, c’est parfois tout simplement lié au paramétrage CBO, donc avant de sauter aux conclusions un petit check-up n’est pas du luxe.

Deux requêtes pour ça, les premières, basées sur v$sys_optimizer_env, pour vérifier le paramétrage, la dernière, basée sur v$system_fix_control pour voir si on a modifié le patchset :

select NAME
     , VALUE
     , DEFAULT_VALUE 
from v$sys_optimizer_env 
where VALUE &lt;&gt; DEFAULT_VALUE ;

Résultat (pour exemple de pourquoi ce con m’a mis optimizer_index_caching à 100 ? )

NAME                                     VALUE                     DEFAULT_VALUE
---------------------------------------- ------------------------- -------------------------
_pga_max_size                            4194200 KB                2048000 KB
optimizer_index_cost_adj                 10                        100
optimizer_index_caching                  100                       0

Si on a la possibilité d’effectuer la requête en tant que SYS, on peut aller un peu plus loin avec la ‘fixed table’ x$qkscesys :

select pname_qkscesyrow NAME
     , PVALUE_QKSCESYROW VALUE
     , DEFPVALUE_QKSCESYROW default_value
from x$qkscesys 
where PVALUE_QKSCESYROW != DEFPVALUE_QKSCESYROW
union 
select name
     , value
     , default_value 
from v$sys_optimizer_env
where VALUE &lt;&gt; DEFAULT_VALUE ;

Il est à noter que l’on peut aussi travailler au niveau des sessions avec x$qksceses et v$ses_optimizer_env, attention cependant, ces vues renseignent les SID (Session ID) mais pas les valeurs par défaut.

select VALUE
     , DESCRIPTION
     , OPTIMIZER_FEATURE_ENABLE
from V$SYSTEM_FIX_CONTROL
where IS_DEFAULT=0 ;

C’était pourtant pas si compliqué.

Commenter le spfile ou les profiles SQL

Mais pourquoi est-ce que ce paramètre est positionné à cette valeur ? Qui ne s’est pas posé la question devant un optimizer_index_cost_adj qui n’est pas à 100 ou un NLS_SORT qui n’est pas à Binary. Le vilain qui a fait le coup n’a pas commenté. Alors que pour le faire il suffit de passer les bonnes commandes

Pour commenter une valeur que l’on passe au niveau du SPFILE (Commentaire de 255 caractères maximum):

alter system set PARAMETRE=VALEUR 
    comment='Gagne 42 minutes, le 25 mai 2001, D. N. Adams'  
    scope=spfile 
    sid='*' ;

Pour commenter un SQL_PROFILE existant (Commentaire de 500 caractères maximum):

begin
 sys.dbms_sqltune.ALTER_SQL_PROFILE( 'nomDuProfile'
                                   , 'COMMENT'
                                   , 'Souci sur V$OGONS, 
contourne 0RA-1952, 11 mars 2013, Z. Beeblebrox' ) ;
end;
/

C’était pourtant pas si compliqué

Passer un processus déjà actif en nohup

C’est la commande disown sous Linux ou HP-UX qui s’occupe d’effectuer ce travail:

process_long

[ctrl+z]

bg

ps
   PID TTY         TIME CMD
 25098 pts/1       0:00 sh
 25549 pts/1       0:00 ksh
  9605 pts/1       0:00 ps
 25099 pts/1       0:00 process_long

disown -h 25099

Si le processus ne répond pas à [ctrl+z] on peut, à partir d’une autre session effectuer un ps aux pour récupérer son PID et ensuite faire un kill -20 PID suivi d’un kill -18 PID.

Kill -20 a pour effet de stopper le processus
Kill -18 a pour effet de le relancer en tâche de fond

Et si on n’est ni sous Linux, ni sous HP-UX ?
Pour Solaris et AIX la commande nohup -p fait la même chose que disown, le reste fonctionne.

C’était pourtant pas si compliqué

(Dés)activer les taches automatiques

Sous Oracle on ne sait jamais si les tâches automatisées (autotasks en langue de Redwood Shores) sont actives ou non, lesquelles sont-elles et comment les activer ou les désactiver.

Lister les tâches automatiques actives

SELECT client_name, status
FROM dba_autotask_client
/
CLIENT_NAME                         STATUS
----------------------------------- ----------
auto optimizer stats collection     ENABLED
auto space advisor                  ENABLED
sql tuning advisor                  ENABLED

En désactiver une (en l’occurrence l’auto space advisor)

BEGIN
  dbms_auto_task_admin.disable('auto space advisor'
                              , NULL
                              , NULL);
END;
/

PL/SQL procedure successfully completed.

Pour vérifier

SELECT client_name, status
FROM dba_autotask_client
/
CLIENT_NAME                         STATUS
----------------------------------- ----------
auto optimizer stats collection     ENABLED
auto space advisor                  DISABLED
sql tuning advisor                  ENABLED

En activer une (en l’occurrence l’auto space advisor)

BEGIN
  dbms_auto_task_admin.enable( 'auto space advisor'
                              , NULL
                              , NULL);
END;
/

PL/SQL procedure successfully completed.

Vérifier

SELECT client_name, status
FROM dba_autotask_client
/
CLIENT_NAME                         STATUS
----------------------------------- ----------
auto optimizer stats collection     ENABLED
auto space advisor                  ENABLED
sql tuning advisor                  ENABLED

C’était pourtant pas si compliqué.

Trouver les informations basiques d’une base Oracle à laquelle on est connecté

La requête

SELECT SYS.UTL_INADDR.get_host_address      IP_ADDR
     , SYS.UTL_INADDR.get_host_name         HOSTNAME
     , SYS.DBMS_UTILITY.CURRENT_INSTANCE    INST#
     , SYS.DBMS_UTILITY.port_string         OS
     , platform_id
     , platform_name
     , name
     , DB_UNIQUE_NAME
     , DBID
     , current_scn
     , decode ( parallel, 'YES', 'RAC', 'NOT RAC') IS_RAC
from v$database natural join v$instance;

Le résultat (splitté pour une meilleure lecture)

IP_ADDR                      HOSTNAME     INST# OS                   
---------------------------- ------------ ----- -------------------- 
fe80::4b5:7ff9:2cca:6ca8%3   ALPHAORIOJO      1 IBMPC/WIN_NT64-9.1.0 

PLATFORM_ID PLATFORM_NAME                  NAME       DB_UNIQUE_NAME 
----------- ------------------------------ ---------- -------------- 
         12 Microsoft Windows x86 64-bit   OJOTST     ojotst     

        DBID CURRENT_SCN IS_RAC
------------ ----------- --------
  2831882428     8207733 NOT RAC

C’était pourtant pas si compliqué !