EBS 11i数据库升级(9i->10g)几点事项
Posted on June 9, 2010 - Filed Under Database, E-Business Suite | Leave a Comment
最近几日在评估和测试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 [...]
Planning Manager诊断过程和10046事件
Posted on May 26, 2010 - Filed Under Database, E-Business Suite | Leave a Comment
在一次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 [...]
我们需要监控什么？
Posted on May 24, 2010 - Filed Under Database | 1 Comment
今天一个很偶然的时间里，我想看看我们的系统有没有异常，其中某个检查点是通过下面这个SQL进行的： SQL> SELECT local_tran_id, 2 state, 3 fail_time 4 FROM dba_2pc_pending 5 / LOCAL_TRAN_ID STATE FAIL_TIME ———————- —————- ——— 31.16.528671 collecting 25-FEB-10 通常情况下，我关注更多地是业务数据异常，很少动手检查此类底层的问题，也不会发现任何异常，但是这次，它来了。当然，在我发现下面这个错误之前，它丝毫不是个问题： SQL> commit force ’31.16.528671′; commit force ’31.16.528671′ * ERROR at line 1: ORA-02058: no prepared transaction found with ID 31.16.528671 SQL> exec dbms_transaction.purge_lost_db_entry(”); BEGIN dbms_transaction.purge_lost_db_entry(”); END; * ERROR at line 1: ORA-30019: [...]
案例：主物料界面性能问题
Posted on April 6, 2010 - Filed Under Database, E-Business Suite | Leave a Comment
案例： 物料查询主界面(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 [...]
三种有效的优化措施
Posted on April 2, 2010 - Filed Under Database | Leave a Comment
Oracle EBS作为一款打包好的ERP应用产品，绝大多数情况下是无法通过修改程序来实现优化目的。因而对于多数人而言，提到优化往往意味着成本，意味着投入，比如购买更好更多地硬件，设计N层(通常是两层，数据库和Apps分开)架构，通过BI将报表负担和日常业务剥离开来，上点层次的企业或许可以考虑弄个高可用性方案(RAC/DG)等等，这些投入从某种意义上来说，是昂贵的。很多没有想通的用户，往往在3年、5年这些坎上活得非常痛苦，好不容易磨合的差不多了，可偏偏这系统似老牛破车慢得不行了。等想通这个环节了，又可以迎来新的春天。 我们知道，经过优化的OLTP应用，毫无疑问可支持TB级的数据量，但是这种优化是需要一定功夫的。Oracle EBS宣称其本身便是经过优化的，这是常规而言，实际应用下来，却还有不小的调整余地。如何在当前的IT预算之内，做出显著的性能提升呢？其实从DBA的角度来看，还是有一些免费的实用的优化方案可供选用的： Purging/Archive，清理或归档过期数据。Oracle EBS内置了很多过期数据删除程序，比如删除过期工作流数据、日志、接口表数据等。11i中有将近214个类似程序，R12中约有260个。可以在Purge Portal配置一些常规的清理/归档程序。 Partition，数据表分区。合理的分区，可以优化大多数查询语句访问路径，减少备份、恢复时间，更合理的分配存储空间。比如总帐数据按会计期间进行分区，工作流数据按类型进行分区等。 ILM，信息生命周期管理。Oracle ILM方案是免费的，可以通过APEX提供一个图形化的助理界面。所谓生命周期是指数据按照时间线索区分的重要性分级，比如三年前的数据，本月的数据等，将一些很久以前的基本不访问但是又必须保留的数据存放到相对廉价的存储设备上。 Oracle EBS中已经对于某些类型的表进行了分区，还有一些则提供了备选的分区方案（比如工作流相关表，参考《工作流之大表分区》），这些都是常见的情形。每家企业情况不同，某一类数据在一些企业里数据量很小，但是在另一些企业里却极大，这时就需要自行分析功能和相关表结构，针对数据访问特点进行分区。一般而言，一个表的数据如果超过了2G，应当开始考虑一下分区方案。 Oracle ILM方案向对于很多第三方解决方案而言，虽然简单了些，但是无需额外费用。作为代价之一，Oracle EBS没有现成的解决方案，所以也需要技术顾问自行分析功能特点将数据进行分类，这是有点难度的工作。 在这些方面，一个不了解Oracle EBS产品的DBA很难提供有针对性的优化建议，所以技术顾问们，或许可以在这个领域深入一把。
Loader Worker 和Sql*Loader 参数
Posted on March 25, 2010 - Filed Under Database, E-Business Suite | Leave a Comment
之前介绍过MRP技术概览，其中有一个过程便是Loader Worker(装入程序工作流程)，该过程实际上是通过Sql*Loader从操作系统数据文件中将数据加载到数据库中。而在主计划设置选项中，其中一项是设置Sql*Loader参数： 那么这些参数究竟是什么含义？我们又如何通过调整这些参数来优化Loader Worker的性能呢？ 先来观察Loader Worker，会发现其执行时有两个或三个参数，如： CTRL_FILE=/u08/test/prodcomn/admin/out/TEST/M1922497MRLD_ITEMS.ctl DATA_FILE=/u08/test/prodcomn/admin/out/TEST/M1922497MRLD_ITEMS.dat DISCARD_FILE=/u08/test/prodcomn/admin/out/TEST/M1922497MRLD_ITEMS.dis 其中CTRL_FILE和DATA_FILE是每个并发请求都会有的，DISCARD_FILE会在部分并发请求中存在，比如载入MRP_SYSTEM_ITEMS表数据时就有该参数。想要理解这些参数的含义，便要先了解Sql*Loader参数的含义。 Sql*Loader 参数有数十个，相关的有如下几个： CONTROL 该参数指定了一个决定Sql*Loader行为的配置文件，它决定了需要从哪个数据文件读取数据，载入到哪张表里，分别有哪些字段等等。对应于Loader Worker的参数CTRL_FILE。 DATA 该参数指定了数据来源，也就是从哪个数据文件中读取记录。指定的数据文件每行的数据往往有特定的格式，有特定的分隔符区分每个字段的值。对应于Loader Worker的参数DATA_FILE。 DISCARD 该参数指定了一个文件用于记录那些未被正常导入到数据库中的记录。对应于Load Worker的参数DISCARD_FILE。 BINDSIZE Sql*Loader分批从数据文件中读取记录并提交到数据库中，每批的大小是有限制。该参数决定了Sql*Loader从数据文件读取记录大小的上限，除了每次读取的记录数必须小于ROWS指定的数目外，大小上不得超过BINDSIZE所指定的数值。该参数计量单位是Byte。 ROWS (每次Commit的记录数) 在Conventional Path模式时，它限定了bind array最大记录数。在Direct Path模式时，它限定了保存之前从数据文件中读取的最大记录数。它的作用和BINDSIZE类似，只是一个限制了记录数，一个限制了记录大小。 READSIZE (读缓存大小) 该参数仅针对从数据文件载入数据的方式时有效，默认值为64k，最大值因系统平台各有不同。在Conventional Path模式时，bind array 受限于读缓存，也就是说，在系统内存和bind array足够大的前提下，如果读缓存越大，则可以有更多的记录在commit前被读取，这也就意味着载入性能越好。当READSIZE小于BINDSIZE时，则READSIZE会被自动加大。 上述参数中，BINDSIZE和ROWS对应于Sql*Loader参数设置界面的相应字段，其他参数则对应于并发请求的相应参数。
