What happens if you delete the ORACLE_HOME?

Somebody asked me about what happens if the binary files stored in the ORACLE_HOME are deleted with the Database Instance up. Here I show you what happens when this deletion is made.

First we must see which database’s instances are running in the current server. Here we can see that in my laboratory I have two, one corresponding to the ASM and the other, to a database called orcl:

oracle|laboratory|orcl$ ins
SINCE INSTANCE USER
13:30 +ASM     grid
16:16 orcl     oracle

Based on this, we can query the operating system processes that are running in the server and belong to the orcl database:

oracle|laboratory|orcl$ ps -fe | grep orcl
oracle 10446 1 0 16:16 ? 00:00:00 ora_pmon_orcl
oracle 10448 1 0 16:16 ? 00:00:00 ora_psp0_orcl
oracle 10468 1 2 16:16 ? 00:00:01 ora_vktm_orcl
oracle 10472 1 0 16:16 ? 00:00:00 ora_gen0_orcl
oracle 10474 1 0 16:16 ? 00:00:00 ora_diag_orcl
oracle 10476 1 0 16:16 ? 00:00:00 ora_dbrm_orcl
oracle 10478 1 0 16:16 ? 00:00:00 ora_dia0_orcl
oracle 10480 1 0 16:16 ? 00:00:00 ora_mman_orcl
oracle 10482 1 0 16:16 ? 00:00:00 ora_dbw0_orcl
oracle 10484 1 0 16:16 ? 00:00:00 ora_lgwr_orcl
oracle 10486 1 0 16:16 ? 00:00:00 ora_ckpt_orcl
oracle 10488 1 0 16:16 ? 00:00:00 ora_smon_orcl
oracle 10490 1 0 16:16 ? 00:00:00 ora_reco_orcl
oracle 10492 1 0 16:16 ? 00:00:00 ora_rbal_orcl
oracle 10494 1 0 16:16 ? 00:00:00 ora_asmb_orcl
oracle 10496 1 1 16:16 ? 00:00:00 ora_mmon_orcl
oracle 10498 1 0 16:16 ? 00:00:00 ora_mmnl_orcl
...

Then I go the the ORACLE_HOME, there you can see its different directories and files:

oracle|laboratory|orcl$ cd $ORACLE_HOME
oracle|laboratory|orcl$ pwd
/u01/app/oracle/product/11.2.0/dbhome_1
oracle|laboratory|orcl$ ls
apex       cfgtoollogs css    deinstall   EMStage instantclient jdev log     nls    opmn    owb     racg      slax         suptools usm
assistants clone       ctx    demo        has     inventory     jdk  md      oc4j   oracore owm     rdbms     sqldeveloper sysman   utl
bin        config      cv     diagnostics hs      j2ee          jlib mesg    odbc   oraInst.loc     perl      relnotes     sqlj     timingframework wwg
ccr        crs         dbs    dv          ide     javavm        ldap mgw     olap   ord     plsql   root.sh   sqlplus      ucp      xdk
cdata      csmig       dc_ocm emcli       install jdbc          lib  network OPatch oui     precomp scheduler srvm         uix

Now we must review which processes are using an important percentage of memory and processor, besides that confirm which of them have something related with the ORACLE_HOME files. Here at this moment, we can see that there is one process with 10468 number related with and executable called oracle and lives in the ORACLE_HOME. The 6371 doesn’t count because it belongs to the grid user, so its oracle belongs to the Grid Home:

oracle|laboratory|orcl$ top

top - 16:18:40 up 2 days,  4:20,  5 users,  load average: 0.72, 0.49, 0.36
Tasks: 230 total,   1 running, 229 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.4%us,  0.4%sy,  0.0%ni, 67.7%id, 31.6%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   6123156k total,  2068792k used,  4054364k free,   165572k buffers
Swap:  6290428k total,        0k used,  6290428k free,  1176108k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 6371 grid      -2   0 1306m  14m  12m S  3.0  0.2   4:27.92 oracle
10468 oracle    -2   0 2045m  16m  14m S  2.7  0.3   0:03.15 oracle
 3146 root      20   0 50192 3008 2240 D  1.0  0.0   0:57.85 devkit-power-da
  421 root      20   0     0    0    0 D  0.3  0.0   0:08.38 jbd2/sda1-8
 3314 oracle    20   0  204m 1392  980 S  0.3  0.0   6:31.49 VBoxClient
 3779 grid      20   0  679m  40m  16m S  0.3  0.7  11:03.53 oraagent.bin
 4132 oracle    20   0  444m  19m  11m S  0.3  0.3   1:52.90 gnome-terminal
10498 oracle    20   0 2047m  24m  21m S  0.3  0.4   0:00.07 oracle
10651 oracle    20   0 15172 1344  940 R  0.3  0.0   0:00.06 top
    1 root      20   0 19356 1556 1228 S  0.0  0.0   0:03.13 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
    4 root      20   0     0    0    0 S  0.0  0.0   0:15.69 ksoftirqd/0
    5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 stopper/0
    6 root      RT   0     0    0    0 S  0.0  0.0   0:00.54 watchdog/0
    7 root      20   0     0    0    0 S  0.0  0.0   1:34.92 events/0
    8 root      20   0     0    0    0 S  0.0  0.0   0:00.00 events/0
    9 root      20   0     0    0    0 S  0.0  0.0   0:00.00 events_long/0
   10 root      20   0     0    0    0 S  0.0  0.0   0:00.00 events_power_ef
   11 root      20   0     0    0    0 S  0.0  0.0   0:00.00 cgroup
   12 root      20   0     0    0    0 S  0.0  0.0   0:00.01 khelper
   13 root      20   0     0    0    0 S  0.0  0.0   0:00.00 netns
   14 root      20   0     0    0    0 S  0.0  0.0   0:00.00 async/mgr
   15 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pm
   16 root      20   0     0    0    0 S  0.0  0.0   0:00.70 sync_supers

 

Then, since we are in the ORACLE_HOME, we can search that file and we can see that there are some with that name:

oracle|laboratory|orcl$ find * -name 'oracle'
apex/utilities/oracle
bin/oracle
oc4j/j2ee/home/database/j2ee/jta/oracle
oc4j/j2ee/home/database/webservices/reliability/oracle
owb/rtasst/jrtaudit/oracle
owb/rtp/jrtaudit/oracle
owb/jrt/default-web-app/WEB-INF/classes/com/oracle
owb/wf/java/oracle

Now, the moment of truth, let’s delete the files and directories that we have in the current location, I mean, the ORACLE_HOME, I’ll delete them and see what happens:

oracle|laboratory|orcl$ rm -rf *
oracle|laboratory|orcl$

After that, I’ll review the instances that are still running in the server, we can see the same initial behaviour the same as its processes:

oracle|laboratory|orcl$ ins
SINCE INSTANCE USER
13:30 +ASM     grid
16:16 orcl     oracle
oracle|laboratory|orcl$ ps -fe | grep orcl
oracle 10446 1 0 16:16 ? 00:00:00 ora_pmon_orcl
oracle 10448 1 0 16:16 ? 00:00:00 ora_psp0_orcl
oracle 10468 1 2 16:16 ? 00:00:05 ora_vktm_orcl
oracle 10472 1 0 16:16 ? 00:00:00 ora_gen0_orcl
oracle 10474 1 0 16:16 ? 00:00:00 ora_diag_orcl
oracle 10476 1 0 16:16 ? 00:00:00 ora_dbrm_orcl
oracle 10478 1 0 16:16 ? 00:00:00 ora_dia0_orcl
oracle 10480 1 0 16:16 ? 00:00:00 ora_mman_orcl
oracle 10482 1 0 16:16 ? 00:00:00 ora_dbw0_orcl
oracle 10484 1 0 16:16 ? 00:00:00 ora_lgwr_orcl
oracle 10486 1 0 16:16 ? 00:00:00 ora_ckpt_orcl
oracle 10488 1 0 16:16 ? 00:00:00 ora_smon_orcl
oracle 10490 1 0 16:16 ? 00:00:00 ora_reco_orcl
oracle 10492 1 0 16:16 ? 00:00:00 ora_rbal_orcl
oracle 10494 1 0 16:16 ? 00:00:00 ora_asmb_orcl
oracle 10496 1 0 16:16 ? 00:00:00 ora_mmon_orcl
oracle 10498 1 0 16:16 ? 00:00:00 ora_mmnl_orcl
...

But, wait! After a litle period, when the process requires to access the file that we already saw and didn’t found it, the orcl instance goes down. It can see that it already gone!

oracle|laboratory|orcl$ ins
SINCE INSTANCE USER
13:30 +ASM     grid

Then, when I review the processes of that instance, it can see that they are not up neither, all of them got down too:

oracle|laboratory|orcl$ ps -fe | grep orcl
oracle 10804 10409 0 16:23 pts/0 00:00:00 grep orcl
oracle|laboratory|orcl$

In this case, we saw that there is an importante relation between the processes and database instance and the oracle file, but there are more files thatn can be related with processes. So, backup the ORACLE_HOME and don’t delete it!

Please, leave a comment if this post was useful for you or if you have any doubt about the contents, I will OrAnswer you as soon as possible.