Fans Or Not

花了大概一周时间完成了一套11i系统(到12.1.1)的升级，之所以耗费如此多时间，简单归纳了一下大致有以下原因：

1. 历史遗留的配置问题（比如用中文做关键词），此类问题导致数据转换错误。
2. 客户化（索引，物化视图等）导致升级错误。
3. 测试机性能差，耗时颇巨。期间多次由于内存的原因，导致java程序出错。
4. 很多R12本身的升级过程中的bug需要处理。
5. 部分业务数据升级时出错，可能是旧数据完整性被破坏所致。
6. 一些前期工作跳过没错，这本来可以缩短升级过程的一部分排错时间。
7. 其他的一些可在升级之前就预先解决的问题。

整体上说，机器的性能问题很关键，有些步骤运行动辄数个小时，有些是升级程序有优化余地而事先没有发现，这些一般都在metalink上有了解决办法。对于升级，很多人第一反应就是克隆环境升级，然后导入最新数据并进行主备切换，其实这种方案对于多数企业而言很难，因为升级过程中会修改大量的表结构，甚至很多应用级别的调整，我很怀疑有哪家公司能够做到对Oracle EBS的数据结构了解的如此洞彻明晰，至少国内没有。这是我第一次对11i进行升级，积累了一些经验，在此分享。

升级前的准备

升级前的准备包括三方面，一个是应用本身的准备工作，这个在升级手册里已经详细说明；另一个就是对服务器性能做一个充分的评估，确保整个升级过程不会跳到deadline之外；还有一个，就是将所有能提前做的工作都做好，比如invalid objects，韩语分词补丁，OLAP升级等等，这些在数据库升级阶段不是必须的，但是EBS升级时却是无法直接忽略的步骤，此外可靠的网络连接也很重要，patching过程中断线后虽然可以继续，但是光启动就要花不少时间。

升级过程中的注意事项

这里依旧按照升级步骤来进行说明。

1. Disable AOL Audit Trail (conditional)
   关闭所有审计功能，包括标准功能提供的，以及客户自行在DB级别上添加的。
2. Shut down application tier listeners and concurrent managers (required)
3. Migrate database to at least Oracle10g Release 2 (conditional)
   这一步之前已经做了，考虑到停机时间，分两步走是比较合适的方案。
4. Update init.ora with upgrade parameters (required)
   同上，升级数据库时已经基本做好了。
5. Disable custom triggers, constraints, and indexes (conditional)
   注意：最好将所有直接关联到标准表的客户化索引和Materialized View都drop掉，这很可能和升级程序有冲突。比如客户化索引，很可能升级过程中就会创建同样的索引（不同名），也可能修改表结构，这些操作都可能引起错误。
6. Drop MRC schema (conditional)
7. Back up the database (recommended)
8. Ensure that Maintenance Mode is enabled (required)
   在11i环境中启用维护模式，如果数据被一些外部程序所用，则最好在升级期间停掉。
9. Apply AD 12.1.1 upgrade driver (required)
   先取消appltest的环境变量(.profile)，然后source新的APPS_host.env，该文件在新的$APPL_TOP目录下，如apps/apps_st/appl/APPSTEST_erptest.env。
   adpatch 时可能会报如下错误：

   ld.so.1: adpatch: fatal: .../apps/tech_st/10.1.2/lib/libclntsh.so.10.1: wrong ELF class: ELFCLASS64
   

   原因是如下错误所导致的：
   进 apps/tech_st/10.1.2/lib32 目录ls -l

   ldflags -> /d4/R12/ab/apps/R1211XB9/apps/tech_st/10.1.2/lib/ldflags

   ldflags链接到了一个不存在的文件上，这是R12本身的bug，解决办法：

   $ rm $ORACLE_HOME/lib32/ldflags
   $ ln -s $ORACLE_HOME/lib/ldflags $ORACLE_HOME/lib32/ldflags
   

   然后 $ORACLE_HOME/bin/genclntsh -32 重新生成libclntsh.so.10.1。
   注意：$ORACLE_HOME请指向10.1.3目录，否则在Post-Upgrade还得一番折腾。

10. Run the American English upgrade patch driver (required)
    这一步耗时最长，问题也最多。在我的测试环境中，因为机器内存小(有两套克隆环境)，patching 过程经常报java错误，需要留意检查adworkxxx.log日志，若发现错误可以尝试用adctrl去failed该job等待其重新处理即可通过。该步骤会把测试机拖得非常慢，每个adworker会带出一个java进程，占用内存非常大，所以将worker设定为一个比较小的数值会更好，比如8个，等之后运行sql等占用内存较少的步骤时，再将adworker数目调大。

    错误：

    CREATE OR REPLACE SYNONYM APPS.CST_ACCRUAL_ACCOUNTS FOR
    	 BOM.CST_ACCRUAL_ACCOUNTS
    
    	AD Worker error:
    	The following ORACLE error:
    
    	ORA-00955: name is already used by an existing object
    

    同义词和一个视图名称一样了。这个错误很低级，我的解决办法是 DROP VIEW APPS.CST_ACCRUAL_ACCOUNTS。

    错误:

    A database error occurred:
      ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column
    
    The error occurred while executing the following statement:
      INSERT INTO FND_SEED_STAGE_ENTITY (SEQ, CONFIG_ID, TOP_ENTITY_SEQ, LAST_DB_UPDATED_BY, LAST_DB_UPDATE_DATE, LAST_FILE_UPDATED_BY, LAST_FILE_UPDATE_DATE, ACTION, EXEC_STATUS, COMMIT_FLAG, BIND_VAR_METADATA, PARENT_PK_VALUE ,BIND_VALUE0 ,BIND_VALUE1 ,BIND_VALUE2 ,BIND_VALUE3 ,BIND_VALUE4 ,BIND_VALUE5 ,BIND_VALUE6,BIND_VALUE7 ,BIND_VALUE8 ,BIND_VALUE9 ,BIND_VALUE10 ,BIND_VALUE11 ,BIND_VALUE12 ,BIND_VALUE13 ,BIND_VALUE14 ,BIND_VALUE15 ,BIND_VALUE16 ,BIND_VALUE17 ,BIND_VALUE18 ,BIND_VALUE19 ,BIND_VALUE20 ,BIND_VALUE21 ,BIND_VALUE22 ,BIND_VALUE23 ,BIND_VALUE24 ,BIND_VALUE25 ,BIND_VALUE26 ,BIND_VALUE27 ,BIND_VALUE28 ,BIND_VALUE29 ,BIND_VALUE30) VALUES (:seq, :config_id, :top_entity_seq, NULL, NULL, NULL, NULL, 'IGNORE', '0', NULL, :bvar_metadata, :parent_pk_value ,:bind_value0 ,
    	:bind_value1 ,:bind_value2 ,:bind_value3 ,:bind_value4 ,:bind_value5 ,:bind_value6 ,:bind_value7 ,:bind_value8 ,:bind_value9 ,:bind_value10 ,:bind_value11 ,:
    	bind_value12 ,:bind_value13 ,:bind_value14 ,:bind_value15 ,:bind_value16 ,:bind_value17 ,:bind_value18 ,:bind_value19 ,:bind_value20 ,:bind_value21 ,:bind_va
    	lue22 ,:bind_value23 ,:bind_value24 ,:bind_value25 ,:bind_value26 ,:bind_value27 ,:bind_value28 ,:bind_value29 ,:bind_value30)
    

    旧的NLS_LANG是American_America.ZHS16GBK，新的NLS_LANG是American_America.UTF8（这是rapidwiz默认赋值的），如果在安装就设置NLS_LANG和旧的一致，则不会出现问题，但是也无法转换form等编码了。
    解决办法：用另一用户登录，修改NLS_LANG，手工执行fndload，然后adctrl用隐藏选项8来跳过该步骤。

    错误:
    如果升级数据库时没有升级OLAP，则会出现一个OLAP相关的错误，此时需要升级OLAP到64位。也可以通过重建AW来解决：

    exec dbms_aw.execute('aw delete zpb.zpbcode')
    exec dbms_aw.execute('aw delete zpb.zpbdata')
    exec dbms_aw.execute('aw delete zpb.zpbannot')
    @appl_top/zpb/12.0.0/patch/115/SQL/zpbmakeaws.sql
    

    Note:
    EPB AW’s Cannot Be Attached Or Do Not Exist [ID 795247.1]

    错误4:
    eamsnupd.sql 步骤出错，此步进行前需要预先设置好Installed Base中相关参数和配置文件。
    Note:
    Enterprise asset Management (EAM) Upgrade Notes to R12 – Integration and Licence [ID 884201.1]

    注：自R12起，IB和eAM将紧密集成。Oracle 真应当将这部分内容写到升级文档中，不了解Installed Base就尝试升级是个悲剧。

    phase=A232 eamdffup.sql出错：

    sqlplus -s APPS/***** @.../apps/apps_st/appl/eam/12.0.0/patch/115/sql/eamdffup.sql
    DECLARE
    *
    ERROR at line 1:
    ORA-06501: PL/SQL: program error
    ORA-06512: at "APPS.FND_FLEX_DSC_API", line 1626
    ORA-06501: PL/SQL: program error
    ORA-06512: at "APPS.FND_FLEX_DSC_API", line 298
    ORA-01403: no data found
    ORA-06512: at line 177
    

    仔细检查问题sql，发现由以下数据引起的：

    SELECT *
      FROM fnd_descr_flex_contexts_tl f
     WHERE f.application_id = 426
       AND f.descriptive_flex_context_code IN ('PE', 'PG');
    

    解决办法：将弹性域名称从中文（能源计量：电能/能源计量：气体）修改为英文。

    phase=A250 apilnupg.sql有严重的性能问题，1天都跑不完
    解决办法：

    create index AP_INVOICE_DISTRIBUTIONS_N25 on AP_INVOICE_DISTRIBUTIONS_ALL(PARENT_REVERSAL_ID);

    Note:
    R12 : Performance Issue While Runing apilnupg.sql (Upgrade to 12.1.1) [ID 942694.1]

    phase=A260 appdstln.sql 报错

    sqlplus -s APPS/***** @.../apps/apps_st/appl/ap/12.0.0/patch/115/sql/appdstln.sql &un_ap &batchsize 7 16
    DECLARE
    *
    ERROR at line 1:
    ORA-01400: cannot insert NULL into
    ("AP"."AP_PAYMENT_HIST_DISTS"."INVOICE_DISTRIBUTION_ID")
    ORA-06512: at line 38
    

    解决办法：修改AP_PAYMENT_HIST_DISTS.INVOICE_DISTRIBUTION_ID 和 AP_PAYMENT_HIST_DISTS.AMOUNT 允许为空，找到那些为空的数据查明原因。正式环境升级时应当避免该情况发生。
    注：这其实不是真正意义上的“解决”办法，关键是找到哪些数据有问题，为什么有问题。

    phase=A322 csxruprf.sql 报错

    sqlplus -s APPS/***** @.../apps/apps_st/appl/cs/12.0.0/patch/115/sql/csxruprf.sql
    DECLARE
    *
    ERROR at line 1:
    ORA-20002: ORA-20001: -28102-ORA-28102: policy does not exist.
    ORA-06512: at line 146
    

    解决办法：

    SELECT nvl(sr_agent_security, 'XXXX') FROM cs_system_options;

    如果查询结果为ANONE，那么它认为已经创建policy，此处只需要生效即可，而实际上系统中并未存在这些policy。通过手工执行相关sql，并跳过该job继续。

    phase=A327 FNDFFVGN 报错

    .../apps/apps_st/appl/fnd/12.0.0/bin/FNDFFVGN &ui_apps 0 Y 2 401 'MTLL' 'MTL_ITEM_LOCATIONS_KFV' 'Y'
    Log filename : .../apps/apps_st/appl/admin/TEST/log/l9017672.req
    
    Report filename : .../apps/apps_st/appl/admin/TEST/out/o9017672.out
    Segmentation Fault - core dumped
    
    AD Worker error:
    The above program failed with error code -117.
    See the AD Worker log file and/or the program log file for details.
    

    解决办法：这个只是编译弹性域，可以跳过该步骤，应用起来后重新编译弹性域。

11. Run the NLS upgrade patch driver (conditional)

- 出错

FRM-30064: Unable to parse statement select upet.type_name EPC_type_name, upec.name category_name, upet.type_id, upec.category_id
from mgd_idencoding_category upec,
     mgd_idencoding_type upet
where upec.category_id = upet.category_id
and ((NVl(upet.partition_value,0)= 0 and upet.category_id = 1 ) or upet.category_id <> 1)
order by upec.category_id,type_name.
ORA-00942: table or view does not exist
Record Group EPC_RULE_RG
Form: WMSLABEL
FRM-30085: Unable to adjust form for output.

解决办法：这个用不到，当作成功继续下一步。
- 出错

.../apps/tech_st/10.1.2/bin/rwconverter userid=APPS/***** source=.../apps/apps_st/appl/xtr/12.0.0/reports/ZHS/XTRTMBLT.rdf dest=.../apps/apps_st/appl/admin/TEST/out/tmp001.rdf stype=rdffile dtype=rdffile overwrite=yes batch=yes compile_all=yes
ld.so.1: rwconverter: fatal: librw.so: open failed: No such file or directory
Killed

ERROR [code=-119] generating report "XTRTMBLT.rdf" from input file
.../apps/apps_st/appl/xtr/12.0.0/reports/ZHS/XTRTMBLT.rdf

是编译rdf的程序有问题，参考文档：
On R12.1.1/Solaris Platform , Generating Oracle Reports Files failed on : " ld.so.1: rwconverter: fatal: librw.so: open failed: No such file or directory", How to get a Potential quick Solution ?. [ID 1067786.1]

12. Apply latest product patches (required)
13. Synchronize NLS and American English product patches (conditional)
14. Disable Maintenance Mode (required)
15. Reset init.ora parameters (required)
    数据库升级时已经做了
16. Back up Oracle E-Business Suite (recommended)

标准功能的升级并不难，虽然中途有很多问题，但是整体上没有多大难度(事实上这世界上的事情只有烦的，没有难的)。最耗精力和时间的，估计反而是那些凌乱的客户化应用。在ERP项目实施过程中，虽然每个人都知道文档的重要性，但是数年下来，回过头来整理时，往往会发现很多文档消失不见，或者有文档但是形同于无。这些是应用升级后需要耗费时间的地方。

对于客户化应用的升级，没有标准答案。

相对于SAP而言，Oracle ERP的另一个显著特征或许就是大量的BUG和补丁吧，也或许正因为如此，Oracle ERP中的故障诊断越来越便捷，方式也越来越，有Server级的诊断（如Form Server），有DB级的诊断，也有功能级的诊断（输出程序步骤和关键业务数据）。对于Form/Report Server之类的故障诊断，通常有专门的技术顾问负责，多数情况下，功能顾问在Oracle Support的建议下也会进行各种形式的、针对各个模块和功能的诊断，有的记录在表里，有的形成日志文件，也有的直接显示在页面上。对于不影响用户操作的诊断，事后很容易就忘记了关闭，于是大量的五花八门的被遗弃的debug和trace偷偷占用着宝贵的系统资源。

通常，功能顾问们涉及的诊断功能可直接通过配置文件启用，主要有下面这些：

• FND：启用调试日志 启用日志。如果为否 (‘N’)，则运行时不会进行记录和发出预警。
• OE：调试 选择“是”以激活 Oracle 订单分录管理系统表单用户退出和并发程序中的调试信息
• OE：调试跟踪 选择“是”以激活 oracle 订单分录管理系统并发程序的跟踪输出
• OSO：启用调试消息 用于显示/隐藏调试消息的 Sales Online 配置文件
• PA：调试模式 指明是否按调试模式运行项目会计管理系统报表和流程；在调试模式下运行时，线索会被打开，附加信息会打印至日志文件
• PO：将调试工作流设置为“打开” 启用/禁用 PO 工作流调试模式
• PO：启用对接收处理程序的 SQL 跟踪 启用数据库 SQL 跟踪，以便调试接收事务处理程序。
• RCV：调试模式 如果将此模式设置为“是”，则将在日志文件中打印消息。
• 初始化 SQL 语句 – 自定义 初始化会话的自定义 SQL 语句

其中“初始化 SQL 语句 – 自定义”比较特殊，可以自行设置event。它的格式如：

BEGIN fnd_ctl.fnd_sess_ctl('','','','TRUE','','ALTER SESSION SET TRACEFILE_IDENTIFIER=' || '''' ||'4269824.999' || '''' || ' EVENTS =' || '''' ||' 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12 ' || '''');END;

其实就相当于每次开启会话时自动执行了类似如下的命令：

alter session set events='10046 trace name context forever, level 12' ;

用下面的SQL可以查询到各个级别的配置文件设置情况：

SELECT n.user_profile_option_name NAME,
       to_char(v.last_update_date, 'yyyy-mm-dd') "Last Updated",
       decode(v.level_id,
              10001,
              'Site',
              10002,
              'Application',
              10003,
              'Responsibility',
              10004,
              'User',
              10005,
              'Server',
              10007,
              'SERVRESP',
              'UnDef') level_set,
       decode(to_char(v.level_id),
              '10001',
              '',
              '10002',
              app.application_short_name,
              '10003',
              rsp.responsibility_key,
              '10005',
              svr.node_name,
              '10006',
              org.name,
              '10004',
              usr.user_name,
              '10007',
              'Serv/resp',
              'UnDef') "CONTEXT",
       v.profile_option_value VALUE
  FROM fnd_profile_options       p,
       fnd_profile_option_values v,
       fnd_profile_options_vl    n,
       fnd_user                  usr,
       fnd_application           app,
       fnd_responsibility        rsp,
       fnd_nodes                 svr,
       hr_operating_units        org
 WHERE p.profile_option_id = v.profile_option_id(+)
   AND p.profile_option_name = n.profile_option_name
   AND usr.user_id(+) = v.level_value
   AND v.level_id = 10004 -- User
   AND rsp.application_id(+) = v.level_value_application_id
   AND rsp.responsibility_id(+) = v.level_value
   AND app.application_id(+) = v.level_value
   AND svr.node_id(+) = v.level_value
   AND org.organization_id(+) = v.level_value
 ORDER BY n.user_profile_option_name,
          level_set;

对于懒人们，不妨做成自动预警，每周末检查一次就可以了。

计划管理器简介

计划管理器属于Immediate类型的可执行并发程序，作为MRP 管理器的子例程运行。MRP 管理器是一种特殊的并发管理器，和计划管理器是完全不同的存在。它主要作用在以下几个方面：

1. 针对发运冲减MDS
2. 针对完工产品冲减MPS
3. 预测冲减
4. MRP接口数据的处理
5. 相关数据清理

实际上，计划管理器和相关的MPS/MRP冲减工作流程是通过下列存储过程完成的：

• MRP_MANAGER_PK 这个包里面的各个过程执行不同的任务。
• MRP_UPDATE_MRP_INFO_PK.mrp_update_mrp_cols 该过程用于MPS Relief Worker
• MRP_AUTO_REDUCE_PK.mrp_auto_reduce_mps 该过程用于每日清理

计划管理器的启动

进入供应链管理员(Supply Chain Planner)职责，在设置菜单里有计划管理器的设置。

间隔时间是指计划管理器每次隔多久处理一次数据，它是指每次的开始时间的间隔长度，如果执行时间超过间隔时间，则执行结束后等待该时间后再次执行。若间隔时间太短，则可以近乎当作不间断执行，这时的冲减也是最及时的，但是系统资源消耗较大。同时，间隔时间过短，日志会更加大，如果启用了DEBUG模式，则每日的日志将可能多出数百兆(视业务数据多少有所不同)。

如果计划管理器处于Active状态，则设置窗口中的Messages界面会显示每次执行的时间。该界面仅仅告知每次的执行时间，并没有多大保留意义，可以安全删除。如果想停止计划管理器，则直接根据请求号取消相应的并发请求即可。需要留意的是，由于计划管理器是依附于MRP管理器执行的，因此在异常诊断时，应当先确认MRP管理器是正常运行的。

每次重新启动计划管理器时，都会自动提交“Planning Manager Worker (once-a-day tasks)”。每天，计划管理器都会分配一个新的请求号，开始新的请求号时，“Planning Manager Worker (once-a-day tasks)”工作流程也会被自动提交。这也是个并发程序（派生类型）， 该程序主要执行各类清理工作。其中，对于MRP相关接口表的清理，主要取决于配置文件 MRP:Interface Table History Days 设置的保留天数。涉及的MRP接口表包括：

• MRP_FORECAST_INTERFACE
• MRP_SCHEDULE_INTERFACE
• MRP_RELIEF_INTERFACE
• MRP_FORM_QUERY
• MRP_WORKBENCH_CRITERIA
• MRP_WORKBENCH_QUERY
• MRP_LOAD_PARAMETERS

MDS Relief
创建新的订单时，会有记录插入到MTL_DEMAND，当发运确认后，相关记录会插入MTL_TRANSACTIONS_INTERFACE，接口数据被验证通过才会在MTL_MATERIAL_TRANSACTIONS产生新的纪录，在此同时，如果库存事务管理器判断出所处理的记录是销售订单，就会插入记录到MRP_RELIEF_INTERFACE以供冲减MDS。

在MRP_RELIEF_INTERFACE中的MDS待冲减条目的各字段含义如下：

• RELIEF_TYPE 为1
• PROCESS_STATUS 为2，表示等待处理
• DISPOSITION_ID 为MTL_DEMAND.DEMAND_ID

对于MDS冲减，计划管理器仅仅处理符合以上条件的记录。

MPS Relief
之前介绍过 MPS Relief Worker，这里补充一下MPS冲减的数据来源。

当采购申请、采购订单、接收事务等采购相关数据产生时，会有记录插入到MTL_SUPPLY，这些数据都作为供应用于MPS冲减。当然离散任务的发放、完工时，会有记录插入到WIP_DISCRETE_JOBS，此时也会触发冲减。对于冲减记录的产生，在系统内部实际上是通过Trigger来实现的，大致有以下Trigger:

• MTL_SUPPLY_T 作用于表MTL_SUPPLY
• WIP_DISCRETE_JOBS_BRI 作用于表WIP_DISCRETE_JOBS，针对新增离散任务
• WIP_DISCRETE_JOBS_BRU 作用于表WIP_DISCRETE_JOBS，针对离散任务状态的修改
• WIP_DISCRETE_JOBS_BRD 作用于表WIP_DISCRETE_JOBS，针对离散任务的删除

在MRP_RELIEF_INTERFACE中的MPS待冲减条目的各字段含义如下：

• RELIEF_TYPE 为2
• PROCESS_STATUS 为2，表示等待处理
• DISPOSITION_ID 为若来源于MTL_SUPPLY，则该字段视来源分别可能是REQ_HEADER_ID, SHIPMENT_HEADER_ID, PO_HEADER_ID，若来源于WIP_DISCRETE_JOBS，则该字段对应于WIP_ENTITY_ID。

相关的配置文件

MRP:Interface Table History Days 接口数据保留日期，仅删除已完成的记录
MRP:Planning Manager Batch Size 指定每个Worker的处理记录数量
MRP:Planning Manager Max Workers 最大同时启动多少个Worker
MRP:Perform Planning Manager Functions in Loads 让主计划程序执行计划管理器的相关功能
MRP:Consume MDS 启用MDS冲减
MRP:Consume MPS 启用MPS冲减
MRP:Debug Mode 启用诊断模式，会在日志中输出运行过程中的相关信息
MRP:Trace Mode DB级的诊断，Trace文件产生在USER_DUMP_DEST目录下