Oracle 11g 安装卡在 2% 是因 CPU 核心数超限触发内部硬编码限制，非网络、磁盘或权限问题；唯一稳定解法是通过 msconfig 限制启动处理器数为 8，长期应升级至 11.2.0.4 或改用 12c/21c XE。
Oracle 11g 安装卡在 2% 是 CPU 核心数超限导致的典型症状
不是网络慢、磁盘慢，也不是权限不足——而是 oracle 11.2.0.1.0（尤其是公开版）内部硬编码了对逻辑处理器数量的容忍上限。windows 10 默认启用全部核心+超线程，40核/80线程的机器上，setup.exe 一启动就卡死在初始化阶段，日志里几乎不报错，只在 gui 进度条停在 2%。
为什么禁用服务和防火墙不能解决卡在 2% 的问题
禁用 TNSListener、OracleService* 等服务，或关闭 Windows Defender 防火墙，只能缓解后续启动慢、连接超时等问题；但安装程序本身卡在 2%，跟服务状态或防火墙规则完全无关。这类操作属于「治标不治本」，甚至可能掩盖真正瓶颈。
- 安装过程由
setup.exe单进程驱动，不依赖已存在的 Oracle 服务 - 防火墙拦截的是监听端口（如 1521），而 2% 阶段连监听器都还没创建
- 强行禁用
Windows Management Instrumentation (WMI)反而会让cvu（Cluster Verification Utility）校验失败，触发另一类报错
真正有效的临时修复：限制启动时可见的 CPU 核心数
这是所有实测案例中唯一稳定绕过该 bug 的方法，原理是让 Oracle 安装程序「以为」自己运行在低核数环境里，从而跳过内部核数检查逻辑。
- 按
Win + R，输入msconfig回车 - 切换到「引导」选项卡 → 点击「高级选项」→ 勾选「处理器个数」→ 从下拉菜单选
8（不要选 4 或 16，8 是最稳妥的兼容值） - 点击「确定」→ 「重新启动」电脑
- 重启后立刻运行
setup.exe，不再卡住
注意：Pagefile.sys 膨胀到上百 GB、内存溢出报错，都是该 bug 的连带现象——本质仍是初始化线程因核数过多陷入无限等待。
长期规避建议：别硬扛 11.2.0.1.0，升级或换版本
限制处理器数只是权宜之计。它会导致：
- 系统重启后所有程序都只能调度到 8 个逻辑核心，开发编译、IDE 启动、Docker 构建等明显变慢
- 若之后取消该设置，已创建的数据库实例可能无法启动（尤其使用 DBCA 创建时）
-
Oracle 11.2.0.4.0已修复此问题，但需有效 Oracle Support 合同才能下载；个人学习可直接用Oracle 12c Express Edition或Oracle 21c XE，无核数限制且免授权
最易被忽略的一点：这个 2% 卡死只发生在「首次安装软件」或「DBCA 创建数据库实例」两个环节，不是每次连接都会复现——所以很多人误以为是网络或监听配置问题，反复折腾 listener.ora 或 tnsnames.ora，白费时间。
