Troubleshooting Missing ASM Disk Groups During Oracle Database Creation with DBCA - A Step-by-Step Analysis and Solution

| Added: May 3, 2025 | Total views: 43


Header image

 

When creating a new Oracle database using the Database Configuration Assistant (DBCA), users might encounter a frustrating issue where available ASM disk groups are not displayed. This prevents the selection of storage locations for database files and halts the creation process. This article outlines a detailed troubleshooting process and solution based on a real-world scenario.

 

Initial Signs of the Problem - DBCA Logs

The first step in diagnosing such issues is always to analyze the logs generated by DBCA. The location of these logs can vary depending on the system, but they are typically found under the cfgtoollogs/dbca directory within the Oracle installation home. In our case, the path to the logs was:

/u01/app/oracle/cfgtoollogs/dbca

Analysis of the DBCA logs revealed the following entries:

[AWT-EventQueue-0] [ 2025-05-01 14:12:43.355 EDT ] [OsUtilsBase.execProgInheritAddEnvNReturnOutput:2268]  Exec prog return code: 1
[AWT-EventQueue-0] [ 2025-05-01 14:12:43.355 EDT ] [KfodUtil.kfodOutput:393]  Kfod result
KFOD-00300: OCI error [-1] [OCI error] [ORA-12547: TNS:lost contact
] [12547]

KFOD-00105: Could not open pfile 'init@.ora'
INFO: May 01, 2025 2:12:43 PM oracle.assistants.common.lib.asm.ASMInfo load
INFO: Loading  the diskgroups. exception using kfod
KFOD-00300: OCI error [-1] [OCI error] [ORA-12547: TNS:lost contact
] [12547]

KFOD-00105: Could not open pfile 'init@.ora'

INFO: May 01, 2025 2:12:43 PM oracle.assistants.common.view.DiskGroupTableModel setDiskGroups
INFO: Empty diskGroup list is specified

INFO: May 01, 2025 2:12:51 PM oracle.install.commons.util.Application pause
INFO: Pause Database Configuration Assistant

INFO: May 01, 2025 2:12:53 PM oracle.install.commons.util.Application pause
INFO: Resume Database Configuration Assistant

INFO: May 01, 2025 2:12:53 PM oracle.install.commons.util.ExitStatusSet add
INFO: Adding ExitStatus USER_CANCELLED_INSTALL to the exit status set

This log excerpt points to a network connectivity issue with the ASM instance, as indicated by the ORA-12547: TNS:lost contact error. Additionally, the attempt to open the initialization parameter file 'init@.ora' suggests an attempt to connect to a remote ASM instance. The failed connection results in the inability to load information about the disk groups.

Further analysis focused on the kfod utility, which DBCA uses to interact with ASM.

 

 

Step 1: Verifying the kfod Executable

The initial suspicion fell on the kfod executable itself, typically located in the Grid Infrastructure $ORACLE_HOME/bin directory. In a clustered environment, this file was checked on all nodes. On one of the nodes (node03-7), the listing of the kfod file appeared as follows:

-rwxrwxr-x. 1 grid oinstall        0 04-25 11:44 kfod

The file size of 0 bytes clearly indicated that the file was corrupted. The issue was temporarily resolved by copying a working version of the kfod file from another node.

 

 

Step 2: Further Diagnosis using strace

After repairing the corrupted kfod executable, the problem persisted. To obtain more detailed information about the kfod utility's operation, the strace command was used:

strace kfod op=groups verbose=true

Analysis of the strace output revealed permission-related errors when accessing the GPNP wallet directory:

stat("/u01/app/19.0.0/grid/gpnp/node03-7/wallets/peer/ ", 0x7ffc58cfc150) = -1 EACCES (Permission denied)

lstat("/u01/app/19.0.0/grid/gpnp/node03-7/wallets/peer/cwallet.sso", 0x7ffc58cfc3c0) = -1 EACCES (Permission denied)

In response to these errors, appropriate permissions were added to the directory:

/u01/app/19.0.0/grid/gpnp/node03-7/wallets/peer/

 

 

Step 3: Direct Analysis of kfod Logs

As the problem continued, the next step involved analyzing the dedicated logs of the kfod utility, located in the following directory:

/u01/app/oracle/diag/kfod/node01-7/kfod/trace

Analysis of these logs revealed the following critical entry:

************************************************************

Fatal NI connect error 12547, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=beq)(PROGRAM=/u01/app/19.0.0/grid/bin/oracle)(ARGV0=oracle+ASM1_kfod)(ENVS='ORACLE_HOME=/u01/app/19.0.0/grid,ORACLE_SID=+ASM1,ORA_SERVER_BROKER_MODE=NONE')(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(ORACLE_HOME=/u01/app/19.0.0/grid)(SID=+ASM1)(CID=(PROGRAM=kfod.bin)(HOST=node01-7)(USER=oracle)))(SECURITY=(AUTHENTICATION_SERVICE=beq))(enable=setuser))

VERSION INFORMATION:
        TNS for Linux: Version 19.0.0.0.0 - Production
        Oracle Bequeath NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production
Version 19.3.0.0.0
Time: 03-MAY-2025 08:20:27
Tracing not turned on.
Tns error struct:
  ns main err code: 12547

TNS-12547: TNS:lost contact
  ns secondary err code: 12560
  nt main err code: 517

TNS-00517: Lost contact
  nt secondary err code: 32
  nt OS err code: 0
KFOD-00300: OCI error [-1] [OCI error] [ORA-12547: TNS:lost contact
] [12547] 

This log directly indicated a problem with the local connection (BEQ protocol) to the ASM instance (+ASM1). Suspecting an issue with the permissions of the Oracle executable used for the BEQ connection (/u01/app/19.0.0/grid/bin/oracle), an attempt was made to change its permissions:

chmod 6751 /u01/app/19.0.0/grid/bin/oracle

Missing setuid permissions for the Oracle binary suggested that the BEQ protocol requires the setuid (SUID) bit to be set on this file.

 

 

Solution

Setting the permissions 6751 on the file /u01/app/19.0.0/grid/bin/oracle resolved the issue. After this change, the DBCA utility was able to connect to the ASM instance correctly and display the available disk groups, allowing the database creation process to proceed.

 

Conclusion

This troubleshooting process highlights the importance of a systematic approach when dealing with Oracle software issues. Analyzing various logs, understanding the functionality of key utilities (such as kfod and strace), and having knowledge of connection protocol specifics (like BEQ and its permission requirements) are crucial for effectively identifying and resolving problems. In the future, it is advisable to pay close attention to the permissions of Oracle executables, especially in environments where local connections to instances are utilized.

 



[photo]
Aleksander Legkoszkur
Database Administrator

A technology fan who likes to stayes at night until he finds a solution. A small handyman who tries to fix everything he can get his hands on. Worked with technologies like:

Windows Server / Linux

Oracle Cloud

Python / T-SQL / PL-SQL / HTML / CSS 

Oracle / SQL Server

and knows how to deal with hardware repairment.