APEX Listener 增设管理界面
Posted on April 21, 2010 Filed Under APEX
最新版的APEX Listener修复了很多bug，并且提供了一个非常管用的新特性。
使用Listener最大的好处就是它支持各种主流应用服务器，比如WebLogic或Apache Tomcat，可以启用WEB服务器的压缩功能(HTTP Compress)。早先的版本对中文的支持很差，可以正常展示，但是一旦保存就会乱码，这导致我曾在一段时间内，开发和管理使用数据库内置XDB服务，普通用户则通过Listener访问，并且不提供中文字符的保存。这个版本完美解决了乱码问题。
此外，该版本最醒目的新特性是提供了一个管理界面：
以Tomcat为例，配置好后会在temp/apex 目录下生成 apex-config.xml 配置文件。该配置界面只在第一次使用时有效，如果之后需要修改参数，则需要先配置好WEB服务器的用户权限(admin role)。编辑tomcat-users.xml 文件：
<tomcat-users> <role rolename="Admin" /> <user username="admin" password="admin" roles="Admin" /> </tomcat-users>
Listener 参数修改后会立即生效。
基本上，APEX Listener 测试版已经相对完善了，希望下一个版本可以改进会话管理功能，省得时间久了一堆死进程非得重启才能清理干净。
P.S: 如果已经存在apex-config.xml，又需要登录管理界面，则请访问 http://host/apex/listenerAdmin
为什么Oracle 11g R2最低内存要求是1G?
Posted on April 8, 2010 Filed Under Uncategorized
Oracle公司最近采取了一些措施来保证只有真正的专家才能使用Oracle，这些措施包括：
- Oracle 11g R2 的所需内存至少1G
- 磁盘空间至少要达到10G
- 一些额外的特性，比如ASM和Oracle Restart需要额外的1G内存
很多名不副实的所谓Oracle专家，他们的知识可能仅仅来源于个人电脑上的单用户的Oracle系统，很多人甚至没有接触过真正的上规模的企业环境。Oracle将会继续贯彻这种政策来减少越来越多的半吊子和没有资格认证的外行人士，以避免行业陷于低水平境地。
我的看法是，今后所有企业版所需内存至少2G，ASM之类则需要额外的1G内存，这样效果会更好一些。 Joke 
(注：本消息可信度自行判断 
)
案例：主物料界面性能问题
Posted on April 6, 2010 Filed Under Database, E-Business Suite
案例：
物料查询主界面(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 read current = number of buffers gotten in current mode (usually for update) rows = number of rows processed by the fetch or execute call ******************************************************************************** SELECT WTG_ROWID,ROWID FROM DR$WAITING WHERE WTG_CID = :b1 AND WTG_PID = :b2 call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 2 0.00 4.85 0 0 0 0 Fetch 2 68700.00 68223.81 30187 30398 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 68700.00 68228.66 30187 30398 0 0 Misses in library cache during parse: 0 Optimizer goal: CHOOSE Parsing user id: 31 (recursive depth: 2)
DR$WAITING 是Oracle Text相关表之一，和DR$PENDING等一系列表一样，主要用于全文检索相关功能的正常运作。简单来讲，DR$PENDING用于索引同步，当同步完成时里面的记录会自动删除，如果同步过程中相关记录又被修改，则相关信息暂时存放于DR$WAITING。检查该表行数：
SELECT COUNT(1) FROM dr$waiting; SELECT COUNT(1) FROM dr$pending;
如果存在大量记录（比如百万级），通常意味着相关程序没有正常进行(同步)。针对EBS环境，Metalink 382809.1 中介绍了几个常规的用于清理无效记录的请求：
- Rebuild Help Search Index (AFLOBBLD)
- JTF Item InterMedia Index Optimizing operation (JTFOPTI)
- 参数p_optimize_level: FAST|FULL
- 参数p_runtime: 数值，默认为最大
- JTF Item InterMedia Index Sync Operation (JTFSYNC)
- MES InterMedia Index Optimizing operation (AMVOPTI)
- MES InterMedia Index Sync Operation (AMVSYNC)
- Knowledge Management Index Synchronization (CS_KB_SYNC_INDEX)
- Rebuilding Intermedia Index for Task Names (JTFTKIMD)
- Synchronize JTF_NOTES_TL_C1 index (JTF_NOTES_TL_C1_SYNC)
对于全文索引而言，所谓同步即加入新的关键词，而优化则意味着清理过期、失效的关键词。如果以上并发请求执行完毕后在DR$PENDING依旧存在记录，则可以手工进行同步：
SELECT du.username,
idx.idx_name
FROM ctxsys.dr$index idx,
dba_users du
WHERE du.user_id = idx.idx_owner#
AND EXISTS
(SELECT NULL FROM ctxsys.dr$pending pnd WHERE pnd.pnd_cid = idx.idx_id)
如：
SQL> exec ctx_ddl.sync_index('AMV.AMV_C_CHANNELS_DESC_CTX');
正常情况下，全部手工处理一遍后，DR$WAITING中记录数应该为0。从DBA角度，CTX_DDL包中有几个优化索引的Procedure，可以考虑定期执行优化程序(清理被删除的Term)。
Read more
三种有效的优化措施
Posted on April 2, 2010 Filed Under Database
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很难提供有针对性的优化建议，所以技术顾问们，或许可以在这个领域深入一把。
寒碜的会议
Posted on March 31, 2010 Filed Under Uncategorized
昨日赴上海Oracle公司参加了一次所谓的“Oracle商务智能应用推广体验活动”，主题是亲身试用Oracle BI产品。我参加过多次Oracle主办的各类会议，比如OOW，但是这次的体验真当是首次。
会议9:15分开始，我从杭州出发，坐了最早一班的动车，大概9:30左右到达会议地点。这种时间安排本身，就带着一点点的莫名其妙，因为这貌似不欢迎上海以外的客户。然后有了如下一些体验：
- 会议室很小，或者说人数太多，竟然没有足够的位子。
- 于是去外面找椅子，是自己动身去找了并推过来的。
- 坐下来后，发现主持人没用话筒，声音很轻。
- 体验时，网速超慢，打开首页要4、5分钟。
- 所谓的午餐，就是盒饭，没有位子的人需要自己找地方，不过地方不够。
因为体验不佳，所以我直接走人。
印象中，所有Oracle相关会议都是在五星级饭店举行的，即便不是如此，至少也有足够的位子；如果要体验，至少有足够的网速；如果要吃饭，至少不用手捧着盒饭吃。这次的组织者，显然没有上心。不过这是不是也说明，其他的会议都是交给专门的公司安排的，这是专业性的体现啊。
当然，最主要的问题还是在于自己，没事瞎凑热闹。
Loader Worker 和Sql*Loader 参数
Posted on March 25, 2010 Filed Under Database, E-Business Suite
之前介绍过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参数设置界面的相应字段，其他参数则对应于并发请求的相应参数。
Read more
