最近几日在评估和测试EBS的系统升级(11i升级到R12)，虽然官方的升级文档里介绍的比较详细了，但是依旧会出现一些容易疏忽的问题，这里做一些记录。这里并不是单纯的数据库升级，需要考虑EBS的特殊应用。对于升级方案，标准的有三种： 同时升级数据库和应用。 先升级数据库到10gR2，然后升级应用到R12。 先升级数据库到11gR2，然后升级应用到R12。 其中第2和第3种方案有点类似，都是将整个升级方案划分为两个阶段，只是数据库版本不同。实际上，从技术上看，第1种方案也是两步走，只是在应用层跳过一些过渡性的补丁直接升级到R12。 在数据库升级方面，升级路线主要有下面两种： 路线1: 9.2.0.6 -> 9.2.0.8 -> 11.2.0.1 如果是Solaris系统，则要求系统版本至少为 Solaris 10 Update 6。 路线2: 9.2.0.6 -> 10.2.0.1 -> 10.2.0.4 注：最新patchset是10.2.0.5，只是升级文档依旧停留在10.2.0.4。 从一般认识上讲，Oracle数据库在下一个大版本出来后，上一个版本才被认为是相对更稳定的，所以此处选择第二条路线。 数据库升级方式简单而言有以下几种： DBUA，直接通过图形化工具升级，这个最简单。 Manual，类似于上一种方式，只是手工进行各个步骤的升级操作。 Export/Import 有利于数据表的整理，重构数据库，比如修改字符集、数据文件、表空间参数等，在升级时间上，比DBUA和Manual两种方式都要长。 利用数据复制等技术，升级备用环境后再切换。 由于允许停机，并且暂无特殊的要求，所以这里使用DBUA做升级操作。 在升级之前，建议卸载statspack，并且先解决Invalid Objects的问题。此外，数据库升级后DBLINK需要重建，所以先准备相关重建脚本。下面按照文档步骤升级数据库9.2.0.6 至 10.2.0.4，每个步骤都列在下面，对几个步骤中需要额外关注的地方做了备注。 Verify software versions 检查现在软件版本，基本上应该不会有问题的，留意一下AD版本，最新版本是11i.AD.I.7，不过要求11i.AD.I.6就可以了。 Migrate to Oracle Portal 10g (conditional) Deregister the current database server (conditional) Update application tier [...]
Archives for Oracle 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=’ [...]
计划管理器(Planning Manager)技术概要
计划管理器简介 计划管理器属于Immediate类型的可执行并发程序，作为MRP 管理器的子例程运行。MRP 管理器是一种特殊的并发管理器，和计划管理器是完全不同的存在。它主要作用在以下几个方面： 针对发运冲减MDS 针对完工产品冲减MPS 预测冲减 MRP接口数据的处理 相关数据清理 实际上，计划管理器和相关的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 [...]
Planning Manager诊断过程和10046事件
在一次Planning Manager性能问题的诊断中，用到了Oracle ERP环境中非常典型的诊断操作和过程，特全程记录于此。 当发现某个程序存在性能问题时，首先当然是快速检查一下SESSION的相关信息，看看主要在执行或等待些什么： SELECT stat.sid, n.name, n.class, stat.value FROM v$sesstat stat, v$statname n WHERE stat.statistic# = n.statistic# AND stat.sid = 121 ORDER BY upper(n.name); 这里观察到bytes received via SQL*Net from client, bytes sent via SQL*Net to client 和 SQL*Net roundtrips to/from client 都在飙升。这对应了两个events：SQL*Net message to client和SQL*Net message from client，这两个事件数值大并不意味着网络状况不好，前者仅仅表示Oracle数据库将数据放入TCP send buffer的时间，而后者表示从客户端接收到反馈指令的时间，两者反映了SQL*Net和数据库之间的时间消耗，而不是网络传输的时间消耗。基于对系统架构的了解，排除SQL*Net的性能问题，那么两个事件预示了什么呢？ SELECT * FROM v$sess_io [...]
案例：主物料界面性能问题
案例： 物料查询主界面(Master Item Screen)更新速度极慢，有时候需要数分钟才能保存。 诊断： 做Form Trace，诊断日志中可以发现下面一段SQL执行效率很低： Trace file: /……/udump/test_ora_16779_XZB.trc Sort options: fchela ******************************************************************************** count = number of times OCI procedure was executed cpu = cpu time in seconds executing elapsed = elapsed time in seconds executing disk = number of physical reads of buffers from disk query = number of buffers gotten for consistent [...]
