APEX 上传xls文件

Posted on August 22, 2010 Filed Under APEX

上一篇文章介绍了APEX中上传文件的方式，以纯文本文件为例说明了如何对上传的文件进行后续处理。PL/SQL可以直接对纯文本内容进行处理，那么如果直接上传xls二进制文件呢？通常，可以用Java Procedure做这件事，但是自APEX Listener 1.x 发布后，有更简单的方式实现对xls内容的处理。

1.10 版本之后，apex-config.xml 中多了下面这个参数：


false

将该参数设置为true则开启excel到collection的转换功能，简单设置步骤如下：
1. 添加File Browse…的Page Item，名字为P1_FILENAME，Storage Type 为 WWV_FLOW_FILES
2. 添加名为UPLOAD的Button Item，Button Request 设置为 xls2collection

运行该页面，选择一个xls后缀的Excel文件，点击UPLOAD按钮即可上传该Excel文件。

上传的文件和数据分别存放在wwv_flow_files和apex_collections中。其中COLLECTION_NAME的默认名称为Page Item的名称，此例中为P1_FILENAME，C001为Excel的TAB页名称，接下来的各字段为表格内容。

SELECT * FROM apex_collections a WHERE a.collection_name = 'P1_FILENAME'

apex_collections是视图，限制了security_group_id，你需要在应用程序中，并且是当前会话中使用。

删除Collection方式为：

apex_collection.delete_collection(p_collection_name => 'P1_FILENAME');

详细说明可参考APEX 4.0的API Reference文档中的APEX_COLLECTION章节。

有了APEX Listener，很多事情变得更简单了，当然，除了文档，APEX的文档令人吃惊的简单，很多内容都没有提及。

» Leave a Comment

APEX 4 中的文件上传功能

Posted on August 13, 2010 Filed Under APEX

有一个APEX小应用需要提供Excel数据上传功能，并且要对上传的数据进行后续加工处理，于是就有了下面这段有点通用的代码。

APEX 4.0中上传的存储位置有两个选择，一个是集中式的WWV_FLOW_FILES，一个是自定义的表。对于前者我不喜欢，所有应用上传的文件都存储在一个地方，有些时候管理起来不够方便；如果是自定义的表，每个应用单独存放，那么不论在迁移还是某些维护都相对简单，当然，对于上传功能的设计而言就需要多花几分钟时间了。下面是自定义表的一个例子。

1. 先创建存储表

attach_data blob 二进制数据
attach_mimetype varchar2(255) 文件类型
attach_filename varchar2(255) 文件名
attach_last_update date 上传时间
attach_charset varchar2(128) 字符集
attach_id number 文件ID

一般而言，最好将该表最小化，包含必须的几个字段即可，如果需要和其他表关联，则可以通过ATTACH_ID关联。

2. APEX页面中增加File…上传的item，属性设置如下：

3. 添加提交表单的按钮，提交时触发一次Automatic Row Processing (DML)的Process，设置表名和主键，系统会自动将相关数据（包括上传的文件）插入对应的表中。关于主键ID的自动生成，可以在After header位置增加一个自动fetch row的设置即可。

4. 文件上传功能本身是非常简单的，接下来是针对该上传文件的后续处理。在顺序上，要先有处理上传的Process(就是第3步)，然后再有后续处理的Process。手工在Page Process处再添加一个名为Parsing Attachment(名字随意)的Process，再Source处理加入匿名PL/SQL代码。例如我喜欢直接调用写好的包，那就写上：

process_upload.process_file_upload;

这里需要用户首先对Excel做一个另存问文本文件的操作，目前为止，我还没发现可以用PL/SQL来直接操作二进制Excel文件。如果有必要，可以考虑使用Java Procedure对Excel文件进行处理。

附上几段代码：

PROCEDURE process_file_upload IS
    l_blob_data       BLOB;
    l_blob_len        NUMBER;
    l_position        NUMBER;
    l_raw_chunk       RAW(2);
    l_raw_line        RAW(32767);
    l_line            VARCHAR2(32767) DEFAULT NULL;
    l_array           wwv_flow_global.vc_arr2;
    l_first_line_flag BOOLEAN;
  BEGIN
    SELECT s.attach_data
      INTO l_blob_data
      FROM sw_detail_attachment s
     WHERE s.attach_id = v('P7_ATTACH_ID');

    DELETE FROM sw_detail_attachment s
     WHERE s.attach_id = v('P7_ATTACH_ID');

    l_blob_len        := dbms_lob.getlength(l_blob_data);
    l_position        := 1;
    l_first_line_flag := TRUE;
    WHILE (l_position <= l_blob_len) LOOP
      l_raw_chunk := dbms_lob.substr(l_blob_data, 1, l_position);

      -- chr(10)
      IF l_raw_chunk = utl_raw.cast_to_raw(chr(10)) THEN
        l_line := utl_raw.cast_to_varchar2(l_raw_line);
        -- remove carriage return
        l_line  := REPLACE(l_line, chr(13), '');
        l_array := string_to_table(l_line);

        IF NOT l_first_line_flag THEN
          insert_data(l_array);
        END IF;
        l_raw_line        := NULL;
        l_first_line_flag := FALSE;
      ELSE
        l_raw_line := l_raw_line || l_raw_chunk;
      END IF;
      l_position := l_position + 1;

    END LOOP;
  END process_file_upload;

上传的文件是以TAB分割的Excel表格数据，我这里先取出文件数据放到l_blob_data中，然后针对换行符进行分割(Windows文件还需要清理掉回车符号)，再对每一行使用标准函数wwv_flow_utilities.string_to_table进行解析。该函数可能存在一个问题，就是如果Excel最后一列数据为空，将导致解析后的列数缺少一列，我用下面这种方式修复该问题：

FUNCTION string_to_table(x_str IN VARCHAR2) RETURN wwv_flow_global.vc_arr2 IS
    l_col_num NUMBER := 20;
    l_array   wwv_flow_global.vc_arr2;
  BEGIN
    -- CHR(9) is tab key
    l_array := wwv_flow_utilities.string_to_table(x_str, chr(9));

    IF l_array.count = l_col_num - 1 THEN
      l_array(l_col_num) := NULL;
    END IF;

    RETURN l_array;
  END string_to_table;

Excel数据还可以采用复制粘贴的方式直接通过表单提交上去，不过，如果Excel文件内容比较复杂，存在多个标签页，则直接上传导入Oracle数据库应该还是有相当大的需求的，如果有时间做一个配置性强的上传插件的话估计下载量会不少。

Update
APEX 4.0.1 的一个bug：如果采用非WWV_FLOW_FILES表存储上传的文件，如果用IE内核的浏览器，无法上传任何数据。

» 1 Comment

迎接变化

Posted on August 1, 2010 Filed Under Uncategorized

最近工作和生活都发生了些变化，参加新的团队，实施新的项目，也可能要投入新的ERP阵营。在企业信息化的工作经历中，我乐意了解并接触不同的产品。就像博客，保持独立性是重要的，不要把人生绑在一张船票上，也不要把企业绑在一个软件厂商上。

由于目前还处于ERP系统选型阶段，所以一切未知，一切也不便多说，但是一些通用的，依旧存在于那里。在工作变换的简短假期中有所憧憬，也有所忧虑，对之前走过的路和将来要走的路都有一些不算深入的思考。一些经验和体会零零碎碎的，整理出了下面几点：

纯属个人体会和感触，不具有任何其他意义。一旦选型结束，将重新投入到实施和技术分享中来，自然会忙，会觉得辛苦，但值得。

面对变化，迎接变化。

» Leave a Comment

EBS 11i升级到R12

Posted on July 5, 2010 Filed Under E-Business Suite

花了大概一周时间完成了一套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)

    12. - 出错

    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项目实施过程中，虽然每个人都知道文档的重要性，但是数年下来，回过头来整理时，往往会发现很多文档消失不见，或者有文档但是形同于无。这些是应用升级后需要耗费时间的地方。

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

» Leave a Comment

EBS 11i数据库升级(9i->10g)几点事项

Posted on June 9, 2010 Filed Under Database, E-Business Suite

最近几日在评估和测试EBS的系统升级(11i升级到R12)，虽然官方的升级文档里介绍的比较详细了，但是依旧会出现一些容易疏忽的问题，这里做一些记录。这里并不是单纯的数据库升级，需要考虑EBS的特殊应用。对于升级方案，标准的有三种：

  1. 同时升级数据库和应用。
  2. 先升级数据库到10gR2，然后升级应用到R12。
  3. 先升级数据库到11gR2，然后升级应用到R12。

其中第2和第3种方案有点类似，都是将整个升级方案划分为两个阶段，只是数据库版本不同。实际上，从技术上看，第1种方案也是两步走，只是在应用层跳过一些过渡性的补丁直接升级到R12。

在数据库升级方面，升级路线主要有下面两种：

  1. 路线1: 9.2.0.6 -> 9.2.0.8 -> 11.2.0.1
    如果是Solaris系统，则要求系统版本至少为 Solaris 10 Update 6。
  2. 路线2: 9.2.0.6 -> 10.2.0.1 -> 10.2.0.4
    注：最新patchset是10.2.0.5，只是升级文档依旧停留在10.2.0.4。

从一般认识上讲，Oracle数据库在下一个大版本出来后，上一个版本才被认为是相对更稳定的，所以此处选择第二条路线。

数据库升级方式简单而言有以下几种：

  1. DBUA，直接通过图形化工具升级，这个最简单。
  2. Manual，类似于上一种方式，只是手工进行各个步骤的升级操作。
  3. Export/Import
    有利于数据表的整理，重构数据库，比如修改字符集、数据文件、表空间参数等，在升级时间上，比DBUA和Manual两种方式都要长。
  4. 利用数据复制等技术，升级备用环境后再切换。

由于允许停机，并且暂无特殊的要求，所以这里使用DBUA做升级操作。

在升级之前，建议卸载statspack，并且先解决Invalid Objects的问题。此外，数据库升级后DBLINK需要重建，所以先准备相关重建脚本。下面按照文档步骤升级数据库9.2.0.6 至 10.2.0.4，每个步骤都列在下面，对几个步骤中需要额外关注的地方做了备注。

  1. Verify software versions
    检查现在软件版本，基本上应该不会有问题的，留意一下AD版本，最新版本是11i.AD.I.7，不过要求11i.AD.I.6就可以了。
  2. Migrate to Oracle Portal 10g (conditional)
  3. Deregister the current database server (conditional)
  4. Update application tier context file with new database listener port number (conditional)
  5. Export OLAP analytical workspaces (conditional)
  6. Prepare to create the 10.2.0 Oracle home
    设置ORACLE_HOME环境变量，如 export ORACLE_HOME=/u08/test/proddb/10.2.0
  7. Install the base 10.2.0 software
    安装10gR2软件，不要选择升级现有数据库，因为要先打一些补丁。这个过程最后会写oraclehomproperties.xml，要保证对应目录有可写权限。比如我曾遭遇了这个错误
    inventory/ContentsXML/oraclehomproperties.xml (Permission denied).
  8. Install Oracle Database 10g Products from the 10g Companion CD
  9. Perform 10.2.0.4 patch set pre-installation tasks
    这是正常的打数据库补丁操作，留意几个环境变量的修改就可以了。如：

    export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export PERL5LIB=$ORACLE_HOME/perl/lib:$ORACLE_HOME/perl/lib/site_perl:$PERL5LIB
  10. Perform 10.2.0.4 patch set installation tasks
  11. Create nls/data/9idata directory
  12. Apply additional 10.2.0.4 RDBMS patches
  13. Shut down Applications server processes and database listener
  14. Prepare to upgrade
  15. Upgrade the database instance
    执行utlu102i.sql查看升级后的变动情况，然后执行DBMS_STATS.GATHER_SCHEMA_STATS 收集统计数据以加快升级速度。在升级的时候如果没有列出所需的ORACLE_HOME，则需要检查并整理一下oratab。
  16. Modify initialization parameters
    对于sga_target等参数，最好先计算以下之前的SGA大小再设置，其余的参考文档设置即可。
  17. Additional database configuration
  18. Perform 10.2.0.4 patch set post-installation tasks
  19. Install Oracle Data Mining and OLAP
  20. Natively compile PL/SQL code (optional)
  21. Fix Korean lexers
    升级韩语分词，对于简体中文用户不必进行。
    注意：如果将来需要升级EBS至R12，则这一步是必须的，否则升级过程中会出错：

    Uploading from staging tables
  Error loading seed data for CS_KB_SOLN_CATEGORIES_VL:  CATEGORY_ID = 1,  ORA-29877: failed in the execution of the ODCIINDEXUPDATE routine
ORA-20000: Oracle Text error:
DRG-50857: oracle error in textindexmethods.ODCIIndexUpdate
ORA-20000: Oracle Text error:
DRG-10602: failed to queue DML change to column   for primary key
DRG-13201: KOREAN_LEXER is desupported
ORA-30576: ConText Option dictionary loading error
  22. Import OLAP analytical workspaces (conditional)
    同上，如果将来需要升级EBS至R12，则这一步是必须的，稍微不同的时，到时可以不必做“升级”操作，而是直接删除重建：

    exec dbms_aw.execute('aw delete zpb.zpbcode');
exec dbms_aw.execute('aw delete zpb.zpbdata');
exec dbms_aw.execute('aw delete zpb.zpbannot');
sqlplus '/ as sysdba' @$APPL_TOP/zpb/12.0.0/patch/115/SQL/zpbmakeaws.sql
  23. Start the new database listener (conditional)
  24. Run adgrants.sql (conditional)
  25. Grant create procedure privilege on CTXSYS
  26. Implement and run AutoConfig
    先检查TNS_ADMIN变量是否指向新的路径，并检查listener.ora，看SID_LIST_TEST中是否已经添加了相应的SID，netca创建的listener.ora可能会缺少这个信息。
    这里尤其需要留意的是，adbldxml.pl 创建配置文件后，如果做adconfig.pl会报错：

    Can't locate object method "runPipedCmd" via package "ADX::util::Sysutil" at /u08/test/proddb/10.2.0/appsutil/bin/adconfig.pl line 806.

    这是由于PERL5LIB没有包含新的appsutil中的perl lib所致，手工加上再执行就可以了。
    afdbprf.sh 这一步还会报错：

    ORA-12504: TNS:listener was not given the SID in CONNECT_DATA

    手工执行可以通过，可能是afdbprf.sh 中传递变量有问题。

  27. Gather statistics for SYS schema
    dbms_stats.gather_schema_stats这一步没有问题，但是执行dbms_stats.gather_fixed_objects_stats时会报错：

    declare
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [1350], [1], [13], [], [], [], [],
[]
ORA-06512: at "SYS.DBMS_STATS", line 13210
ORA-06512: at "SYS.DBMS_STATS", line 13517
ORA-06512: at "SYS.DBMS_STATS", line 14039
ORA-06512: at line 3
ORA-06512: at line 33

    这应该是个BUG，据说在11gR2中被修复了。

  28. Re-create custom database links (conditional)
    升级之前就已经准备好了DBLINK的重建脚本，直接重建即可。
  29. Re-create grants and synonyms
  30. Apply Oracle Receivables patch
  31. Restart Applications server processes (conditional)

按标准步骤做完后，数据库成功升级到10.2.0.4，升级后需要留意以下事项：

主要参考文档
Database Preparation Guidelines for an E-Business Suite Release 12.1.1 Upgrade [ID 761570.1]
Oracle Applications Release 11i with Oracle 10g Release 2 (10.2.0) [ID 362203.1]

» Leave a Comment

关闭功能顾问的那些诊断模式

Posted on May 28, 2010 Filed Under E-Business Suite

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

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

其中“初始化 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;

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

» Leave a Comment

keep looking »