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很难提供有针对性的优化建议，所以技术顾问们，或许可以在这个领域深入一把。
Archives for Database
Loader Worker 和Sql*Loader 参数
之前介绍过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参数设置界面的相应字段，其他参数则对应于并发请求的相应参数。
RMAN和数据库管道(PIPE)
数据库管道(PIPE)是一种多SESSION间传递消息的机制，可以通过包DBMS_PIPE进行消息的发布和接收，主要用作外部服务消息接口，也可以用于多个独立进程之间的通讯。在Oracle EBS环境中，MRP的计算过程就用到了数据库管道技术。RMAN也可以通过数据库管道进行操作，通过管道接口，可以直接使用PL/SQL来操作RMAN行为并获得输出结果。通过数据库管道技术，可以设计出基于RMAN的第三方备份、恢复管理系统。 用于RMAN的必须是私有管道，这是出于安全考虑。私有管道有如下限制： 各SESSION用户(USERID)必须和管道创建者一致 存储过程的执行权限和管道创建者(USERID)一致 用户必须通过SYSDBA角色连接到数据库 RMAN拥有两个私有管道，一个用于接收，一个用于发布。在启动RMAN时可以通过PIPE参数指定管道名称(此处为ABC)，比如： [oradba@localhost ~]$ rman PIPE ABC TARGET / TIMEOUT 60 Recovery Manager: Release 11.2.0.1.0 – Production on Sun Mar 21 16:43:28 2010 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. 该进程会等待DBMS_PIPE传入指令，如果60秒后无任何指令传入，则自动退出。若不加TIMEOUT参数，则RMAN会一直等待指令传入。 RMAN会自动打开两个私有管道，ORA$RMAN_ABC_IN和ORA$RMAN_ABC_OUT，前者用于接收消息，后者用于发布消息，消息类型都是VARCHAR2。第一次启用时，RMAN会自动初始化这两个管道，如果需要在启动RMAN之前就存入指令，则需要首先手工使用DBMS_PIPE.CREATE_PIPE创建管道。 l_status := dbms_pipe.create_pipe(pipename =>l_pipename,private => true); private 参数必须为true，否则默认会创建公共管道，无法用于RMAN。 发布指令到RMAN: DECLARE l_status INT; BEGIN dbms_pipe.pack_message(‘show [...]
关于Forms转换到APEX小记
Oracle Forms是非常高效、健壮的开发工具，它的历史已经超过了20年，在今后几年里将会继续完善和支持下去。APEX已经具备了相当多的Web 2.0因素，它继承了Oracle Forms最大优势，那就是几乎可以用PL/SQL来完成所有的开发工作，对于企业内部应用，它无异成为了首选的平台。在这种趋势下，自APEX 3.2版本开始，就引入了Forms Converter，该工具用于将传统的Forms应用转换到APEX应用，对于一些Oracle Forms应用丰富、历史悠久的企业而言，它是相当吸引眼球的。 从FastForms到SQL*Forms，从CS架构到现在基于Web的WebForms，Oracle Forms的基础结构却变化不大，本质依旧是Java程序，程序逻辑的实现几乎完全基于SQL和PL/SQL。APEX则是非常纯粹的WEB应用开发平台，它需要的是PL/SQL、Java Script、CSS和最基础的HTML知识。对于开发人员而言，两者需要技术技能几乎相同。从Oracle Forms转移到APEX，对开发人员的技能培训几乎可以省略。Oracle Forms的几个核心组件：块(Block)、触发器(Trigger)、PL/SQL库、值列表(LOV)都可以交由Forms Converter完成转换。 转换器会生成XML格式的原数据文件，然后上传到APEX生成具体的Web应用。在这里，转换器的作用是“转换”，而不是“迁移”。两个平台在技术上是不同的，从而导致某些功能上的差异，比如Forms中的快捷键在目前的APEX中是不存在的，此外，Forms中某些java beans的应用也无法在APEX上实现。Oracle Forms和Oracle APEX各元素的差异主要如下表所示： Oracle Forms Oracle APEX Alerts 在应用层或页面上的验证逻辑中实现文本消息 Blocks 在APEX是区域(Region) Canvases 在转换过程中被忽略 Editors HTML编辑器 Lists of Values 记录组在转换过程中将会被调整 Program Units 对应PL/SQL程序单元 Triggers APEX中没有触发器，不过页面查询过程有相应的机制实现逻辑，比如Processes 对于APEX 4.0版本，或许还有另外一些特殊的差异，比如Websheets，内置的图表引擎（这是非常酷的，可以做简单的BI），加强的Web Services功能等。在用户界面上，Oracle Forms响应迅速，而APEX则可以通过AJAX特效实现类似功能。 关于转换的具体操作，可以参考《Oracle® Application Express Application Migration Guide，这本书《Oracle Application Express Forms Converter》有更详细的介绍。
Oracle Application Express Listener
在今日之前，APEX应用可以通过两种方式访问（架构），即： Oracle HTTP Server/mod_plsql XDB HTTP protocol server/embedded PL/SQL gateway 今天，Oracle发布了Oracle Application Express Listener，这是很早以前就预告要在APEX下一版本(4.x)提供的主要新特性之一。通过APEX Listener，Web层增加了对以下平台的支持： Oracle WebLogic Tomcat OC4J 尽管11g内置了PL/SQL gateway可以当做一个逻辑上独立的Web Server来用，Oracle的技术顾问认为在应用规模不大的环境下，该方式比DB + Web Server的两层架构性能更佳，但是在我个人的测试下，发现并非如此。对于正式环境，我强烈建议使用独立的Web Server。 下面是一个Tomcat的配置指导： Download Tomcat Download Unpack Tomcat Edit the Tomcat configuration file to increase the maximum header size (the default is 4k). Edit ….\apache-tomcat-6.0.18\conf\server.xml <Connector port=”8080″ protocol=”HTTP/1.1″ connectionTimeout=”20000″ maxHttpHeaderSize=”32676″ redirectPort=”8443″ [...]
