oracle安装“未找到文件”错误的根本原因是database\stage\components目录未完整合并，必须手动将2of2中该目录下的所有子目录（如oracle.ctx、oracle.ordim等）复制合并到1of2对应路径下，否则安装程序构建dbhome_1时必然报错。
不是解压到“同一目录”就能解决问题，而是必须让 database\stage\components 目录下的所有子目录和文件完整合并——否则安装程序在构建 dbhome_1 时必然报“未找到文件”。
为什么“解压到同一目录”常失效？
多数人按教程把 winx64_12102_database_1of2.zip 和 winx64_12102_database_2of2.zip 同时拖进 WinRAR/7-Zip，选“解压到当前文件夹”，结果得到一个 database 文件夹，但里面只有 1of2 的内容，2of2 的关键组件被跳过或覆盖了。
根本原因在于：两个压缩包的 database\stage\Components 目录结构是互补而非重复的。2of2 不是补丁包，它包含多个独立子目录（如 oracle.ctx、oracle.rdbms），这些目录在 1of2 中根本不存在。解压工具遇到同名路径时若不强制“合并”，就会静默跳过整个 Components 下的新目录。
- WinRAR 5.x 及更早版本默认不合并同名文件夹，仅覆盖同名文件
- Windows 自带解压工具完全不支持跨压缩包路径合并
- 错误现象：安装卡在 50%–69%，报错路径指向
dbhome_1\ctx\admin\dr0ulib.sql.sbs或dbhome_1\demo\schema\mk_dir.sql.sbs等，本质都是2of2里缺失的组件没被释放
怎么确认解压是否真正完整？
别信“看起来解压完了”，直接检查 database\stage\Components 下的子目录数量和内容：
- 进入
winx64_12102_database_1of2\database\stage\Components，看有多少个oracle.xxx子目录（通常只有 3–5 个） - 再进
winx64_12102_database_2of2\database\stage\Components，你会发现多出至少 4–6 个新目录（如oracle.ctx、oracle.ordim、oracle.xdk） - 用资源管理器对比两个路径下
Components的总文件数：完整合并后应比单独1of2多出 200+ 个文件
如果 2of2 的 Components 内容没进主 database 目录，安装必失败。
手动合并 Components 目录才是可靠做法
与其赌解压工具行为，不如主动控制路径合并。这是目前最稳定、零依赖工具配置的操作方式：
- 先单独解压
winx64_12102_database_1of2.zip到任意位置（如D:\oracle_install\1of2） - 再单独解压
winx64_12102_database_2of2.zip到另一位置（如D:\oracle_install\2of2） - 打开
D:\oracle_install\2of2\database\stage\Components，全选所有子目录（不是文件！是文件夹） - 复制并粘贴到
D:\oracle_install\1of2\database\stage\Components—— Windows 会提示“是否合并文件夹”，点“是” - 此时
1of2\database\stage\Components才真正完整，双击其中的setup.exe启动安装
注意：setup.exe 必须从 1of2 目录下运行，因为它是主入口；2of2 里没有 setup.exe，也不能单独运行。
为什么不能跳过这步直接重装？
很多人中止安装后清空 dbhome_1 目录、删掉注册表项、甚至格式化盘符，再重跑 setup.exe，结果还是卡在同样位置——因为问题不在目标路径，而在源介质本身不完整。
Oracle 安装程序启动后，会先扫描 database\stage\Components 目录生成内部清单，再逐个复制到 dbhome_1。如果源里缺 oracle.ctx 这个目录，它根本不会尝试去复制 dr0ulib.sql.sbs，而是直接报错退出。所以修复动作必须发生在运行 setup.exe 之前，且只针对源目录。
真正容易被忽略的点是：这个缺失不是随机的，它固定出现在 Components 下特定子模块；而修复也只需聚焦这一层路径，不必动 install 或 response 目录。
