应优先查看$ORACLE_BASE/cfgtoollogs/dbca/<SID>/trace.log，该文件实时记录DBCA建库全过程的操作、参数校验、脚本执行及错误堆栈，是定位“正在进行数据库创建”卡顿问题的最直接有效日志。
卡在“正在进行数据库创建”时，先看哪个trace文件
oracle安装卡在“正在进行数据库创建”，说明已通过软件安装阶段，进入dbca建库流程。此时真正有用的日志不是orainventory/logs/下的installactions*.log，而是dbca自己生成的诊断日志：$oracle_base/cfgtoollogs/dbca/<sid>/trace.log。这个文件会实时记录建库每一步的操作、参数校验、脚本执行和错误堆栈。
常见误操作是直接翻oraInstall*.err或oui-*.log，它们只反映OUI图形界面行为，对建库失败几乎无用。
快速定位方法：
- 打开终端，执行：
ls -t $ORACLE_BASE/cfgtoollogs/dbca/*/trace.log | head -1，找最新生成的那个 - 用
tail -f实时观察，建库卡住时往往能看到类似Setting MEMORY_TARGET to 2G之后突然停止，或报出ORA-00845: MEMORY_TARGET not supported on this system - 若该路径下无
trace.log，说明dbca根本没启动成功——要回退查$ORACLE_HOME/cfgtoollogs/dbca/是否存在子目录，或确认ORACLE_BASE环境变量是否设错
ORA-00845错误本质是/dev/shm空间不足
ORA-00845不是Oracle配置错误，而是Linux内核级限制触发的硬性拒绝。从11g起，MEMORY_TARGET和MEMORY_MAX_TARGET依赖/dev/shm（tmpfs类型共享内存），而它的默认大小通常是64MB或128MB，远小于典型建库所需的2GB+。
验证当前值：
- 运行
df -h /dev/shm，看Available列 - 检查
cat /proc/mounts | grep shm，确认挂载参数是否含size=
临时修复（重启后失效）：
sudo mount -o remount,size=4G /dev/shm
永久生效需改/etc/fstab，加一行：shmfs /dev/shm tmpfs size=4G 0 0。注意：不能设为size=0或超过物理内存一半，否则可能引发OOM killer杀进程。
Windows上对应问题：AWE/PAE与/3GB开关
Windows Server 2003/2008 R2环境下，若物理内存≥4GB但Oracle实例仍报ORA-04030或建库卡死，大概率是未启用AWE支持。这时sga_max_size和pga_aggregate_target总和超过系统能映射的用户地址空间（默认2GB）。
关键动作只有两个：
- 编辑
boot.ini（Win2003）或使用bcdedit（Win2008+），添加/3GB和/PAE启动参数 - 重启系统——不重启，Oracle无法识别新地址空间布局
注意：/3GB会压缩内核空间，可能影响某些驱动；/PAE本身不增加单进程可用内存，必须配合AWE初始化（Oracle自动调用）。若已升级到Windows Server 2012+，此问题基本消失，因64位系统天然支持大地址空间。
别忽略trace里隐藏的权限和路径陷阱
即使trace.log没报内存错，也常出现静默失败：比如dbca尝试写$ORACLE_BASE/diag/rdbms/<SID>时因父目录权限不对而卡住，日志里只显示Creating database... [waiting]，无报错。
排查要点：
- 确认
$ORACLE_BASE所属用户和组是oracle:oinstall，且目录权限至少为755 - 检查
$ORACLE_HOME下bin/dbca是否可执行（chmod +x），尤其从NFS或共享盘拷贝的安装包容易丢掉执行位 - 如果安装路径含空格或中文（如
C:\Program Files\Oracle），dbca内部调用java时参数解析会出错，日志中可能看到Invalid argument但不明确指向哪段路径
最稳妥的做法：所有路径全用小写英文，不含空格，$ORACLE_BASE和$ORACLE_HOME都设在根分区（如/u01或C:\app\oracle），避免挂载点或符号链接干扰。
