DBCA卡在“正在配置数据库”本质是DNS或IPv6解析超时所致；需确保/etc/hosts正确定义hostname、SCAN、VIP的IPv4映射，/etc/resolv.conf非空且含有效nameserver，必要时临时禁用IPv6验证问题。
dbca 创建实例卡在“正在配置数据库”或长时间无响应，本质是 oracle 在启动阶段反复尝试解析主机名、scan、vip 等地址，而 dns 或 ipv6 配置不当导致超时重试（默认单次 30 秒，多次叠加可达数分钟）。
为什么 /etc/hosts 配置错误会让 DBCA 卡住
DBCA 启动时会调用 getaddrinfo() 查询本机 hostname、SCAN 名、VIP 名等。若这些名字未在 /etc/hosts 中明确映射到 IPv4 地址，系统就会 fallback 到 DNS 查询；若 DNS 不可用、响应慢或返回 IPv6 地址而网络不通，getaddrinfo() 就会阻塞。
- 必须确保
hostname命令输出的值（如rac1）在/etc/hosts中有对应 IPv4 行，且不能只写127.0.0.1 rac1—— 这会导致 Oracle 认为本机地址是 loopback，拒绝用于集群通信 - SCAN 名（如
rac-scan）必须映射到至少一个 IPv4 地址；如果 hosts 里只写了 IPv6 地址，而系统未启用或未配置好 IPv6 路由，DBCA 会等超时 - 不要在
/etc/hosts中为同一主机名同时写 IPv4 和 IPv6 地址（如192.168.31.115 rac1和fd15::115 rac1），getaddrinfo()可能按顺序尝试，IPv6 失败后才切回 IPv4，白白耗时
禁用 IPv6 不是万能解，但能快速验证问题
Oracle 19c 对 IPv6 的支持虽已完善，但实际环境中常因内核参数、网卡配置或路由缺失导致 IPv6 解析卡顿。禁用 IPv6 是最直接的排除手段，不是最终方案，但可立竿见影。
- 临时禁用（重启失效）：
sysctl -w net.ipv6.conf.all.disable_ipv6=1和sysctl -w net.ipv6.conf.default.disable_ipv6=1 - 永久禁用：在
/etc/sysctl.conf中添加上述两行，再执行sysctl -p - 注意：仅禁用 IPv6 协议栈，不影响 IPv4 功能；但若你确需双栈，请跳过此步，直接优化 IPv6 配置（见下一条）
真正要改的是 /etc/resolv.conf 和 DNS 行为
DBCA 卡顿最隐蔽的元凶其实是空的或无效的 /etc/resolv.conf。CVU（Cluster Verification Utility）和 DBCA 都会读取它，即使你没配 DNS —— 若该文件为空或只有注释，glibc 会默认尝试连接 127.0.0.1:53，超时后才放弃。
- 最稳妥做法：
echo "nameserver 192.168.31.1" > /etc/resolv.conf（填你局域网内可用的 DNS IP，哪怕只是路由器地址） - 若完全离线无 DNS，填一个假地址也比空着强：
echo "nameserver 10.0.0.1" > /etc/resolv.conf—— 至少避免连接 localhost:53 的等待 - 切勿删除
/etc/resolv.conf文件本身，Oracle 某些组件会检查文件存在性
静默安装时绕过 DNS 检查的实操参数
如果你用 dbca -silent 创建实例，可在响应文件或命令行中显式关闭 DNS 依赖：
- 在响应文件中设置：
responseFileVersion=/oracle/install/rspfmt_dbca_response_schema_v19.0.0+ignorePreReqs=true（慎用，仅限测试环境） - 更安全的方式是加参数：
dbca -silent -createDatabase ... -ignorePreReqs，配合已修正的/etc/hosts使用 - 关键点：
-ignorePreReqs不跳过所有检查，只跳过 CVU 中与 DNS、NTP、防火墙等外部服务相关的预检项，不影响核心创建逻辑
真正拖慢 DBCA 的从来不是磁盘或 CPU，而是网络栈里一次又一次的 30 秒超时。把 /etc/hosts 写对、/etc/resolv.conf 填实、IPv6 配置要么全关要么全通——这三件事做完，DBCA 从卡死到秒起，不需要重启服务器，也不需要重装软件。
