企业官网建设流程全解析

简介：这份资源面向具备Linux与Oracle数据库基础的技术人员，尤其是负责Oracle EBS系统安装、配置与维护的IT专业人员，用于指导生产环境下EBS R12.1.1至R12.1.3的部署与升级。内容覆盖Oracle Linux系统安装与配置、EBS安装与升级、数据库升级以及Oracle Application Server 10g的安装升级，并针对常见问题给出解决方案，从操作系统准备到应用服务器部署形成完整链路。资源包共1个PDF文件，约844KB，属于文档型资料，便于按目录检索与对照操作。目前已有952人学习下载，说明其在EBS运维群体中具有一定参考价值。读者可借此掌握生产环境部署的关键步骤与注意事项，理解各环节的配置要点与排错思路，适合作为实际安装升级时的操作参考与问题排查依据。

1. Oracle EBS R12.1 生产环境部署：为什么“装完能跑”和“敢上生产”是两回事

很多团队第一次接触 Oracle EBS R12.1 的安装，都会经历一个相似的错觉：在测试机上跟着文档点完 Rapid Install，看到登录页面出来了，就以为大功告成。结果一挪到生产环境，Linux 内核参数没调、数据库字符集对不上、并发管理器一跑就挂，升级补丁打到一半报错回滚，整个项目卡在“能演示但不能交付”的状态。Oracle EBS R12.1 系统安装与升级这件事，真正的难点从来不是安装程序本身，而是 Linux OS 配置、数据库迁移和升级路径这三块硬骨头能不能在生产约束下同时立住。这篇笔记面向的是需要把 R12.1 真正部署到生产环境、并且要完成数据库迁移和版本升级的运维与实施人员。我会按“环境怎么配、库怎么迁、补丁怎么打、坑怎么躲”的顺序，把一套可复现的路径讲清楚，参数和边界都会给到，新手能照着走，熟手能对着核。

2. Linux OS 配置：R12.1 对操作系统的硬性要求与调优参数

R12.1 是一个对操作系统相当“挑剔”的版本，它诞生在 RHEL/OEL 5、6 的时代，很多默认配置放到今天的新系统上会直接翻车。生产环境部署的第一步不是装 EBS，而是把 OS 这层地基打对。这一章讲清楚选型理由和具体配置步骤。

2.1 操作系统版本与内核参数为什么不能照搬默认值

R12.1 官方认证的 Linux 平台集中在 Oracle Enterprise Linux 和 Red Hat Enterprise Linux 的 5.x、6.x 系列。如果你手上只有更新的系统，常见做法是用容器或虚拟化把 OS 版本锁到认证范围内，而不是硬上新版本再逐个打补丁——后者往往在链接 Oracle 二进制时就会因为 glibc 版本不匹配而失败。

内核参数里最容易被忽略的是共享内存和信号量。EBS 的数据库实例和 Apache 层都依赖 System V 共享内存，默认的kernel.shmmax在很多发行版上只有物理内存的一小部分，数据库启动时就会报 ORA-27102 之类的错误。下面是我一般会写进/etc/sysctl.conf的一组基线值，按 16GB 内存的数据库服务器估算：

# /etc/sysctl.conf 追加，16GB 内存数据库节点基线 kernel.shmmax = 17179869184 # 约 16GB，通常设为物理内存的一半到全部 kernel.shmall = 4194304 # shmmax / 页大小(4096) kernel.shmmni = 4096 # 共享内存段最大数量 kernel.sem = 256 32000 100 142 # 信号量：每信号集信号数/系统上限/单次操作数/信号集总数 fs.file-max = 6815744 # 系统级文件句柄上限 net.ipv4.ip_local_port_range = 9000 65500 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576

逻辑说明：shmmax决定单个共享内存段的上限，数据库 SGA 必须能装进一个段里，否则实例起不来；shmall是所有共享内存段的总页数上限，设小了即使shmmax够大也会失败；sem四个值分别对应semmsl semmns semopm semmni，EBS 并发用户多的时候信号量不够会表现为连接随机失败，这种问题排查起来非常玄学，不如一开始就配足。改完执行sysctl -p生效，然后用ipcs -l核对实际值。

2.2 用户、目录与依赖包的最小配置清单

EBS 安装要求一个专用的 OS 用户（通常叫oracle）同时拥有数据库和应用层文件，并且这个用户要属于dba、oinstall等组。目录规划上，我习惯把数据库和应用层分开挂载，避免日志写满把数据库拖死：

# 创建组和用户 groupadd oinstall groupadd dba useradd -g oinstall -G dba -d /home/oracle -s /bin/bash oracle passwd oracle # 目录规划：数据库与应用层分离挂载 mkdir -p /u01/oracle/db # 数据库 ORACLE_HOME 父目录 mkdir -p /u01/oracle/app # EBS 应用层 mkdir -p /u02/oradata # 数据文件独立盘 chown -R oracle:oinstall /u01 /u02 chmod -R 775 /u01 /u02 # 依赖包（OEL/RHEL 6 系，用 yum 批量装） yum install -y binutils compat-libstdc++-33 elfutils-libelf \ gcc gcc-c++ glibc glibc-common glibc-devel libaio libaio-devel \ libgcc libstdc++ libstdc++-devel make sysstat unixODBC unixODBC-devel

逻辑说明：oinstall组管安装介质，dba组管数据库管理权限，两个组都要给到oracle用户。目录分盘是血泪经验——应用层日志和数据库归档如果共用一块盘，一次大批量补丁就可能把盘写满导致数据库挂起。依赖包里compat-libstdc++-33和libaio是 R12.1 链接阶段最容易缺的两个，缺了会在adrelink时报找不到符号。装完用rpm -q逐个核对，别信“装过了”的口头确认。

2.3 环境变量与资源限制的落地写法

环境变量写错是新手最常见的翻车点。ORACLE_HOME、ORACLE_SID、TNS_ADMIN这些必须和后续 Rapid Install 里填的路径完全一致，大小写都不能差。资源限制则通过/etc/security/limits.conf放开：

# /etc/security/limits.conf 追加 oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 4096 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 32768 # oracle 用户 ~/.bash_profile 关键片段 export ORACLE_BASE=/u01/oracle export ORACLE_HOME=$ORACLE_BASE/db/11.2.0 export ORACLE_SID=PROD export PATH=$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/usr/lib export NLS_LANG=AMERICAN_AMERICA.AL32UTF8

逻辑说明：nproc和nofile是并发管理器大量 fork 进程时的硬约束，soft 值给太小会在业务高峰期报“资源暂时不可用”。NLS_LANG要和数据库字符集一致，R12.1 生产库建议用AL32UTF8，如果这里写成ZHS16GBK而库是 UTF8，中文数据在迁移后会出现乱码，而且这种乱码往往在迁移完成后才暴露，属于典型的后悔药没处买。改完 limits 需要重新登录oracle用户才生效，用ulimit -a确认。

3. 数据库迁移：从源库到 R12.1 目标库的可复现路径

数据库迁移是 R12.1 部署里风险最高的一环，因为它同时牵扯字符集、数据量、停机窗口和 EBS 特有的 schema 结构。这一章把迁移方式选型和具体步骤讲透。

3.1 迁移方式选型：Data Pump、传输表空间还是物理拷贝

选哪种迁移方式，取决于源库版本、数据量和可接受的停机时间。我一般按下面的逻辑判断：

对大多数 R12.1 生产迁移，Data Pump 是最稳的选择，因为 EBS 的 schema 数量多但结构清晰，逻辑导出能顺带过滤掉源库的临时对象。传输表空间虽然快，但对 EBS 这种有大量依赖关系的库，跨平台字节序问题一旦踩中就是灾难，新手不建议一上来就用。

3.2 用 Data Pump 做全库导出的命令与参数

导出前先确认源库字符集和 EBS 版本，然后建目录对象、执行导出。下面是一套我常用的导出脚本：

# 源库上：创建导出目录并授权 sqlplus / as sysdba <<EOF CREATE OR REPLACE DIRECTORY dpdir AS '/u02/dump'; GRANT READ, WRITE ON DIRECTORY dpdir TO system; EOF # 全库导出，排除 EBS 临时 schema expdp system/密码@PROD \ directory=dpdir \ dumpfile=ebs_full_%U.dmp \ logfile=ebs_full_exp.log \ full=y \ parallel=4 \ filesize=8G \ exclude=SCHEMA:\"IN \('APPS_TMP','XX_TEMP'\)\" \ compression=all

逻辑说明：parallel=4要和dumpfile里的%U配合，否则并行写会冲突；filesize=8G控制单文件大小，方便分盘存放和传输；exclude把临时 schema 排掉，能显著减少导出体积；compression=all对文本型数据压缩比很高，但会吃 CPU，导出窗口紧张时可以去掉。导出完成后务必检查 log 末尾的 “successfully completed”，并核对 dump 文件数量和大小，别只看命令返回码。

3.3 导入到 R12.1 目标库与字符集校验

导入前目标库要先建好，字符集必须和源库一致或兼容。导入时用remap_schema和remap_tablespace处理路径差异：

# 目标库：建目录并导入 sqlplus / as sysdba <<EOF CREATE OR REPLACE DIRECTORY dpdir AS '/u02/dump'; EOF impdp system/密码@PROD \ directory=dpdir \ dumpfile=ebs_full_%U.dmp \ logfile=ebs_full_imp.log \ parallel=4 \ remap_tablespace=OLD_DATA:APPS_TS_TX_DATA,OLD_IDX:APPS_TS_TX_IDX \ transform=segment_attributes:n \ table_exists_action=replace

逻辑说明：remap_tablespace把源库表空间映射到 R12.1 标准表空间名，EBS 对表空间命名有约定，映射错了应用层会找不到对象；transform=segment_attributes:n让导入时忽略源库的存储属性，改用目标库默认值，避免把源库不合理的区大小带过来；table_exists_action=replace适合重跑场景，但生产首次导入建议用skip先验证，确认无误再换replace。导入后必须跑一遍字符集校验：

-- 校验字符集与无效对象 SELECT parameter, value FROM nls_database_parameters WHERE parameter IN ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET'); SELECT owner, object_type, COUNT(*) FROM dba_objects WHERE status = 'INVALID' GROUP BY owner, object_type;

如果NLS_CHARACTERSET不是AL32UTF8，而源库是 UTF8，中文数据在导入后可能已经损坏，这时候只能重新导出导入，没有捷径。无效对象数量如果集中在 EBS 的某些 schema，通常是导入顺序或依赖问题，用utlrp.sql重编译后再看。

4. 升级路径：R12.1 补丁应用与版本推进的实操要点

装完和迁完只是起点，R12.1 要推进到目标补丁级别，还要走一套升级流程。这一章讲补丁应用和升级中的关键操作。

4.1 升级前的必备检查与备份策略

升级前不备份，等于裸奔。EBS 的升级动辄几小时到十几小时，中途失败回滚的成本极高。我一般要求三份备份：数据库全备、应用层文件系统快照、以及$APPL_TOP/admin下的配置文件单独打包。检查项包括：

• 数据库版本是否满足目标补丁的最低要求
• adop或adpatch工具版本是否匹配
• 应用层是否有未完成的并发请求
• 磁盘剩余空间是否大于当前应用层体积的 2 倍

# 升级前检查并发管理器状态与磁盘 cd $APPL_TOP df -h /u01 /u02 sqlplus apps/密码 <<EOF SELECT COUNT(*) FROM fnd_concurrent_requests WHERE phase_code = 'R' AND status_code = 'R'; EOF

逻辑说明：并发请求还在运行时打补丁，会出现文件被占用导致补丁失败，必须先等请求跑完或取消。磁盘空间按 2 倍估算是给补丁解压和临时文件留余量，EBS 补丁解压后体积经常是压缩包的好几倍。

4.2 用 adpatch 应用补丁的标准流程

R12.1 时代主流还是adpatch，虽然adop在后续版本更常用，但 R12.1 的很多补丁仍以adpatch驱动。标准流程是先打前置补丁，再打主补丁：

# 以 applmgr 用户执行，先解压补丁到独立目录 mkdir -p /u02/patch/1234567 cd /u02/patch/1234567 unzip /u02/patch/p1234567_R12_LINUX.zip # 启动 adpatch，按提示输入 cd $APPL_TOP adpatch # 交互中输入： # 补丁目录: /u02/patch/1234567 # 是否运行 AutoPatch: yes # 并发 worker 数: 4

逻辑说明：补丁目录不要放在$APPL_TOP里面，否则adpatch扫描文件时会把补丁自身也当成应用文件，导致奇怪的错误。worker 数按 CPU 核数的一半到全部设置，设太多会争抢资源反而变慢。adpatch过程中会多次暂停等待输入，建议用nohup加日志重定向，避免终端断开导致补丁中断：

nohup adpatch options=nocopyportion,nogenerateportion \ patchtop=/u02/patch/1234567 \ driver=u1234567.drv \ workers=4 \ logfile=/u02/patch/adpatch_1234567.log &

4.3 升级后的验证：从应用登录到关键业务流

补丁打完不代表升级成功，必须做端到端验证。我一般按这个顺序走：先确认应用服务能起、再登录 EBS、再跑一个关键业务流、最后看并发管理器是否正常。

# 启动应用服务 cd $ADMIN_SCRIPTS_HOME adstrtal.sh apps/密码 # 检查服务状态 adopmnctl.sh status adcmctl.sh status apps/密码

逻辑说明：adstrtal.sh会按顺序拉起数据库监听、并发管理器、Apache 等组件，任何一步失败都会中断，日志在$INST_TOP/logs下。服务起来后登录 EBS，跑一个采购订单或总账过账流程，确认数据能正常写入。并发管理器状态用adcmctl.sh status看，如果显示未运行，检查$APPL_TOP/admin下的并发管理器日志，常见原因是FNDLIBR进程权限或环境变量问题。

5. 避坑与排查：R12.1 生产部署中最容易翻车的五个点

这一章是我这些年踩过的坑里挑出来最有代表性的五条，每条按现象、原因、解决写清楚。

坑一：Rapid Install 到 80% 卡住，日志无报错。现象是安装进度条长时间不动，日志最后一行停在某个链接步骤。原因通常是 OS 依赖包缺失或LD_LIBRARY_PATH没包含/usr/lib，导致链接器找不到 32 位库。解决是先tail -f安装日志确认卡在哪一步，再用ldd检查对应二进制缺哪个库，补装依赖后从该步骤重跑，不要整个重来。

坑二：数据库导入后中文全是问号。现象是导入成功，但查询中文数据显示为????。原因是目标库字符集与源库不一致，且导入时NLS_LANG设置错误。解决是导入前用SELECT * FROM nls_database_parameters核对两边字符集，必须一致；如果已经导入，只能清库重导，没有在线修复的可靠办法。

坑三：adpatch 跑到一半报“文件被占用”。现象是补丁在替换某个.class或.o文件时失败。原因是应用服务没停干净，Java 进程还持有文件句柄。解决是打补丁前用adstpall.sh停服务，再用ps -ef | grep java确认没有残留进程，必要时kill -9后重跑补丁。

坑四：并发管理器启动后立即退出。现象是adcmctl.sh start显示成功，但status显示未运行。原因是APPLCSF或APPLOUT目录权限不对，或者FNDLIBR的环境变量没继承。解决是检查$APPL_TOP/admin下并发管理器日志，确认目录属主是applmgr，并核对adcmctl.sh里引用的环境文件是否完整。

坑五：升级后应用登录报“职责无权限”。现象是能登录，但菜单空白或报权限错误。原因是升级过程中FND相关的权限表没同步，或者adpatch的某个 worker 失败被忽略。解决是查adpatch日志里是否有 “failed” 关键字，重跑失败的 worker，然后执行FNDLOAD重新加载职责配置。

6. 一个收尾技巧：用快照把“可回滚”变成部署习惯

前面五章讲的都是怎么把 R12.1 装起来、迁过去、升上去，但生产部署真正的底气来自“出问题能退回去”。我这些年养成的习惯是：在每一个高风险操作前，先给应用层和数据库各打一个可快速恢复的快照，而不是只依赖逻辑备份。

具体做法分两层。应用层用文件系统快照或tar打包$APPL_TOP和$INST_TOP，数据库层用RMAN做一次全备加归档日志备份。关键是记录清楚快照对应的补丁级别和时间点，写进一个简单的部署记录表：

这张表的价值在于，当补丁真的翻车时，你不需要现场想怎么恢复，照着表执行就行。我见过太多团队在补丁失败后手忙脚乱，最后因为恢复路径不清晰，把一个小问题拖成了停机事故。

还有一个细节：快照恢复后，数据库和应用层的环境变量、TNS配置、并发管理器队列要重新核对一遍，因为快照可能把某些运行时状态也带回去了。我一般会在恢复后跑一个最小验证脚本，确认数据库能连、应用能登、并发管理器能起，再宣布恢复完成。

这套习惯看起来笨，但它把“敢上生产”从一句口号变成了可执行的动作。R12.1 这种老而重的系统，拼的不是谁装得快，而是谁在出问题时退得稳。希望帮到你。

本文还有配套的精品资源，点击获取