dbca: Error in Process: /u01/app/oracle/product/12.2.0.1/dbhome_1/bin/orapwd

dbca is a very good tool compared to how we used to create databases back in the time with scripts and the CREATE DATABASE keyword, etc ... but as any tool, it sometimes has issue and doesn't work ... here are 2 workarounds I recently used to create a simple 12.2 RAC database for patch testing.

I first got the below error:

[oracle@exadatadb01]$ dbca -silent -createDatabase -templateName General_Purpose.dbc -gdbname july19 -sid july19 -responseFile NO_VALUE -characterSet AL32UTF8 -sysPassword Welcome1! -systemPassword Welcome1! -createAsContainerDatabase false -databaseType MULTIPURPOSE -automaticMemoryManagement false -totalMemory 50000 -storageType ASM -diskGroupName DATA -redoLogFileSize 50 -emConfiguration NONE -nodeinfo exadatadb01,exadatadb02 -ignorePreReqs
[FATAL] [DBT-08001] Unable to check for available memory.
[FATAL] [DBT-08002] Unable to check the value of kernel parameter {0}
[oracle@exadatadb01]$

I quickly found the below workaround to avoid this error message:

[oracle@exadatadb01]$ unset ORA_CRS_HOME

This one was easy and I then restarted my database creation:

[oracle@exadatadb01]$ dbca -silent -createDatabase -templateName General_Purpose.dbc -gdbname july19 -sid july19 -responseFile NO_VALUE -characterSet AL32UTF8 -sysPassword Welcome1! -systemPassword Welcome1! -createAsContainerDatabase false -databaseType MULTIPURPOSE -automaticMemoryManagement false -totalMemory 50000 -storageType ASM -diskGroupName DATA -redoLogFileSize 50 -emConfiguration NONE -nodeinfo exadatadb01,exadatadb02 -ignorePreReqs
Copying database files
DBCA Operation failed.
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/july19/july191.log" for further details.
[oracle@exadatadb01]$ cat /u01/app/oracle/cfgtoollogs/dbca/july19/july191.log
[ 2019-08-14 22:52:47.614 EDT ] Copying database files
[ 2019-08-14 22:52:50.477 EDT ] Error in Process: /u01/app/oracle/product/12.2.0.1/dbhome_1/bin/orapwd
[ 2019-08-14 22:52:56.450 EDT ] DBCA_PROGRESS : DBCA Operation failed.
[oracle@exadatadb01]$

Neither the error stack nor the trace file was verbose and strace didn't give me more clues; I tried to create a passwordfile and I could confirm that orapwd was working fine. I opened a SR and MOS gave me the workaround which was to . . . rename $ORACLE_HOME/dbs/oranfstab under another name, create my database and rename the file back to oranfstab. Thanks MOS, I would never thought about that myself!

Indeed, this server had a oranfstab file with DNFS stuff in it:

[oracle@exadatadb01]$  ls -ltr $ORACLE_HOME/dbs/*nfs*
-rw-r--r-- 1 oracle oinstall 762 Apr 30  2018 /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/oranfstab

System Time: 2019-08-15 03:19:14
[oracle@exadatadb01]$ cat /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/oranfstab
server: 192.168.1.2
path: 192.168.1.2
export: /export/blabla mount: /zfs/blablatoo
. . .
[oracle@exadatadb01]$

I then applied the workarounds:

[oracle@exadatadb01]$  mv /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/oranfstab /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/oranfstab.old
[oracle@exadatadb01]$  unset ORA_CRS_HOME
[oracle@exadatadb01]$

And it worked !

[oracle@exadatadb01]$ dbca -silent -createDatabase -templateName General_Purpose.dbc -gdbname july19 -sid july19 -responseFile NO_VALUE -characterSet AL32UTF8 -sysPassword Welcome1! -systemPassword Welcome1! -createAsContainerDatabase false -databaseType MULTIPURPOSE -automaticMemoryManagement false -totalMemory 50000 -storageType ASM -diskGroupName DATA -redoLogFileSize 50 -emConfiguration NONE -nodeinfo exadatadb01,exadatadb02 -ignorePreReqs
Copying database files
1% complete
2% complete
15% complete
27% complete
Creating and starting Oracle instance
29% complete
32% complete
36% complete
40% complete
41% complete
43% complete
45% complete
Creating cluster database views
47% complete
63% complete
Completing Database Creation
64% complete
65% complete
68% complete
71% complete
72% complete
Executing Post Configuration Actions
100% complete
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/july19/july194.log" for further details.
[oracle@exadatadb01]$

Then do not forget to rename the oranfstab back to its original name !

[oracle@exadatadb01]$ mv /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/oranfstab.old /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/oranfstab
[oracle@exadatadb01]$

I found afterwards that it was a regression which is documented in DBCA Fails To Create Database When DNFS Is Enabled And Oransftab Exists (Doc ID 2345083.1)

Once you reach that point with a newly dbca created database, watch out for this known bug which it is very worth to apply the workaround ASAP.

Hope it helps !