Un gros "tracefile" en production - oradebug

Probablement cela a vous déjà arrivé, se retrouver devant d'une situation où un gros fichier trace qui commence à prendre tout l'espace disponible sur votre $ORACLE_HOME.
Si jamais cela arrive et vous ne voulez pas arrêter la BD ou vous ne pouvez pas tout simplement le faire, moins encore penser ;a lancer un kill sur le processus de la BD ...oradebug vient au secours afin de nous permettre reprendre le contrôle de la situation et supprimer ou déplacer ce fichier très volumineux.  

Cet exemple a été exécuté sur une bd 11g en RAC sur Solaris 10.

Solution : 

• Trouver le gros fichier en question

oracle@node1:/xxxx/admin/BD/bdump> ll *13718*

      -rw-rw----   1 oracle   dba         4.0G Mar  9 11:32 bd1_diag_13718.trc

  

• Retracer le processus relié au fichier

oracle@node1:/xxxx/admin/BD/bdump> ps -ef | grep diag | grep BD

      oracle 13718     1   0   Feb 25 ?          30:31 ora_diag_BD1

• Vérifier l'espace disponible   

oracle@node1:/xxxx/admin/BD/bdump> df -h /u01

      Filesystem             size   used  avail capacity  Mounted on

      /dev/dsk/c4t60060E8004570C000000570C00000378d0s6

                              39G    25G    13G    66%    /u01

• Vérifier que la valeur de votre variable ORACLE_SID  

oracle@node1:/xxxx/admin/BD/bdump> echo $ORACLE_SID

      BD1

• Même si le fichier est ouvert, on passe à le renommer. N'essaie pas de le supprimer parce que allez voir le fichier disparaître mais l'espace ne sera pas libéré.

oracle@node1:/xxxx/admin/BD/bdump> mv bd1_diag_13718.trc bd1_diag_13718.trcback

• Attendre en moyenne une minute avant d'exécuter l'oradebug.

oracle@node1:/xxxx/admin/BD/bdump> sqlplus / as sysdba

     

      SQL> oradebug setospid 13718 ;

            Oracle pid: 9, Unix process pid: 13718, image: oracle@node1 (DIAG)

      SQL> oradebug flush ;

            Statement processed.

      SQL> oradebug close_trace ;

            Statement processed.

      SQL> exit

 Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

            With the Partitioning, Real Application Clusters, Oracle Label Security, OLAP

            and Data Mining Scoring Engine options

• Après quelques secondes, un nouveau fichier trace sera créée par  Oracle, si cela n'est pas le cas, répétez une autre fois les commandes oradebug

oracle@node1:/xxxx/admin/BD/bdump> ll *diag*

      -rw-rw----   1 oracle   dba         4.0G Mar  9 11:32 bd1_diag_13718.trcback

      -rw-rw----   1 oracle   dba          732 Mar  9 15:10 bd1_diag_13718.trc         

oracle@node1:/xxxx/admin/BD/bdump> df -h /u01

      Filesystem             size   used  avail capacity  Mounted on

      /dev/dsk/c4t60060E8004570C000000570C00000378d0s6

                              39G    25G    13G    66%    /u01

oracle@node1:/xxxx/admin/BD/bdump> rm bd1_diag_13718.trcback

      rm: remove bd1_diag_13718.trcback (yes/no)? yes

oracle@node1:/xxxx/admin/BD/bdump> df -h /u01

      Filesystem             size   used  avail capacity  Mounted on

      /dev/dsk/c4t60060E8004570C000000570C00000378d0s6

                              39G    21G    17G    55%    /u01

Comme vous voyez, l'instance n'est pas tombée et l'espace a été libéré.

oracle@node1:/xxxx/admin/BD/bdump> srvctl status database -d BD

Instance BD1 is running on node node1

Instance BD2 is running on node node2
Instance BD3 is running on node node3