卡在2%是CPU核心数超限触发Oracle 11.2.0.1硬编码限制，唯一稳定解法是msconfig中将启动处理器数设为8，长期应升级至11.2.0.4或改用12c/21c XE。
Oracle 11g安装卡死不是随机现象，而是特定阶段触发的已知缺陷或资源瓶颈。直接看卡在哪个百分比，就能快速定位根因——2%、42%、68%、85% 各有明确技术指向，不能一概而论。
卡在 2%：CPU 核心数超限触发硬编码限制
这是 Windows 上 Oracle 11.2.0.1（尤其是公开版）最典型的初始化卡死，和网络、权限、杀毒软件完全无关。setup.exe 启动时读取逻辑处理器数量，超过内部阈值（常见于 16 核以上/超线程开启的机器）就无限等待。
- 验证方式：
msconfig→ 「引导」→ 「高级选项」→ 查看「处理器个数」是否 > 8 - 临时解法：勾选「处理器个数」并设为
8，重启后立即运行setup.exe - 别选 4（太低导致 DBCA 创建失败）或 16（仍可能卡住）；取消该设置后，已创建的实例可能无法启动
- 长期方案：改用
11.2.0.4（需 Oracle Support）或Oracle 12c XE/21c XE，无此限制
卡在 42%：win64_11gR2_database_2of2.zip 解压不完整
Oracle 安装器在 42% 阶段开始加载 owb、oc4j_applications 等可选组件，这些文件全部来自第二个压缩包。Windows 原生解压工具或部分第三方 ZIP 工具会跳过空目录或忽略长路径，导致 WFMLRSVCApp.ear 等关键文件缺失。
- 不要重新解压整个包——只需确认
database\stage\Components\oracle.owb\11.2.0.1.0\1\DataFiles下是否存在filegroup1.jar和filegroup2.jar - 若缺失，从原始
win64_11gR2_database_2of2.zip中手动解压出database\stage\全路径，覆盖到临时 staging 目录（通常是C:\Users\<user>\AppData\Local\Temp\OraInstall*</user>） - 禁用 Windows Defender 实时防护再解压，避免其静默拦截 .ear 文件
- Linux 用户用
unzip -o而非tar解压，确保空目录被创建
卡在 68% 或 85%：系统资源或环境配置不足
这两个节点分别对应 Linux 下链接器执行（68%）和 Windows 下数据库创建（85%），本质都是资源耗尽型卡死，但诱因不同。
-
68%（CentOS/Red Hat）：检查
swap是否达标（Oracle 要求 ≥ RAM 的 1.5 倍），运行free -m；若不足，用dd if=/dev/zero of=/tmp/swapfile bs=1M count=4096临时追加 -
85%（Windows）：不是数据库创建失败，而是
DBCA进程内存溢出。关闭所有 IDE、浏览器，释放至少 2GB 物理内存；同时检查%TEMP%所在盘剩余空间是否 - 路径含中文、空格或符号（如
C:\Program Files\）会导致 68%/85% 卡死，必须用纯英文短路径，如D:\oracle\product\11.2.0\dbhome_1 - CentOS 7.9 用户务必装
xorg-x11-utils，否则图形界面在 68% 附近闪退，看似卡死
真正麻烦的是混合型卡死：比如在 42% 卡住后强行终止，再运行 setup.exe 就可能因残留 staging 目录损坏，转而卡在 68%。此时不要重试，先删掉 %TEMP%\OraInstall* 和 $ORACLE_HOME 下未完成的目录，再从头解压——卡点背后是确定性的机制，不是玄学。
