时光飞逝，不从事EBS DBA转眼已有两年多。很还念那段学习的时光。EBS DBA的中文资料很少，我将以前学习英文版管理员的笔记上传到blog，希望对正从事这个职业的朋友有所帮助。
第一章 ORACLE APPLICATIONS 的组件与架构
1.ebs组件的几大构成：客户端，form server，web server，concurrent processor，数据库。每个组件都可以分别在不同的节点跑。
2.几大EBS组件为客户提供服务的简单流程：客户通过浏览器（输入地址）跳转到用户登录界面（登录界面由web server提供）--》用户选择一个职责，进一步选择菜单（比如，用户-》定义） --》 用户开始工作。 （菜单选项会引导用户跳转到HTML,JAVASERVER PAGE（jsp page）或者是表单应用。web server负责对HTML,java servlet提供服务。如果启动了表单应用，forms servlet或者form server将对其提供服务。整个过程可以在后台数据库获得数据或执行包。）
3.Admin Node: Administrative tasks executed on the Admin Node
4.概叙几大组件
Client：为了运行ORACLE forms as java applets必须安装ORACLE JInitiator plug-in
Web Node: 对于oracle applications来讲，web server是oracle application server，它是基于APACHE技术的。我们通常称之为iAS，AS,Oracle HTTP Server（OHS),Simply Apache。iAS也可以跑JServs来响应JAVA的请求。iAS也可以配置成能跑Forms servlets，这样它也可以响应Forms sessions。
Forms Node：如果Forms servlets没有配置成由iAS来处理，那么FORM SERVER将提供这样的服务。
Concurrent Processing Node：并发处理是ebs的一个特色。EBS中会有很多请求，这些请求从类别上来说可以分oracle标准请求和自定义请求。从执行周期来说可以分一次性请求，周期执行请求。这些请求的调度由concurrent manager来进行管理。
Admin Node: 用来执行管理EBS的任务，比如：生成表单，jar文件，布置patch，重新编译弹性域。
Database Node：EBS的心脏，不多说了。
5.oracle application的架构
简 单/基础架构：在没有大量事务，和并发用户下使用的架构。所有的服务节点都运行在同一个物理服务器上。还有一种比较简单的架构叫两层架构，一个节点跑应 用，另一个节点跑数据库。多节点的架构环境不需要特殊的配置和设计，除非多个节点跑同一个组件。传统上来讲，ORACLE建议并发处理节点和DB应该在同 一个节点，但是考虑到这两个组件的快速网络连接性，现在ORACLE建议并发处理节点应该在应用层。两层结构比较受推荐，单层结构会导致应用和数据库进程 之间的竞争，从而导致性能下降。
复杂架构：同一组件由多个节点支持。多种服务由多个节点支持。这种结构称为复杂架构，节点的数量由事务数量和并发用户数来决定。
复杂架构的几种形式：Load Blancing，Shared APPL_TOP or Application Tier Filesystem，Distributed APPL_TOP，Secure Sockets Layer (SSL) Encryption。
Load Blancing：这个术语是来描述在不同的节点提供相同功能的服务，这些用户和事务怎样分布到这些节点的。当多于一个节点提供相同的功能服务时我们把它 叫做farm.比如说你有多个节点做web node，那么这些web node我们称之为web farm。web node的load balancing实现可以通过雇佣专门的load balancing硬件或者DNS load balancing来实现。如果实施多个forms nodes，那么要设置一个primary web node用来指向其它的forms nodes。forms的原始服务运行在primary web node并为发送请求到多个forms nodes提供load balancer的服务。Parallel Concurrent Processing的load balancing由internal concurrent manager来控制，共享文件系统也必须实现。（主要用来存放并发管理器产生的共享log，output file） oracle rac是DB的load balancing。
Shared APPL_TOP or Application Tier Filesystem: APPL_TOP,COMMON_TOP都放在共享存储上。这样就减小了停机维护时间。
Distributed APPL_TOP： 你可以定义一个或多个服务节点作为admin node，管理任务将分布在多个节点多个人工上完成，这样就加速了管理任务的完成。比如布置patche，patche session将跨越多个人工多个节点。
Secure Sockets Layer Encryption：主要是对比较敏感的数据（比如信用卡数据）在进行网络传输的时候进行加密。
5.EBS架构的最佳实践
如果考虑实施多节点的load balancing可以考虑用较便宜的intel架构的服务器然后安装linux。
oracle web cache的实施可以提高EBS的性能。
第二章 配置
1.60%的问题源于oracle application的配置，EBS DBA应该对配置熟悉。
2.关于配置的几个部分:
application context file: 这个文件涵盖了整个EBS的配置信息.
using AD configuration: 这是一个配置管理工具,可以自动配置应用和DB层.
web node configuration: 介绍关于web节点的几个重要配置文件.
forms node configuration: 介绍几个关于form server的几个重要配置文件
concurrent processing node configuration：
admin node configuration：
addtional service components：
database node configuration：
additional configuration topics
3.各配置部分的细节：
application context file：
oracle ebs有个全局的配置文件我们称之为：application context file 或者 application XML file。它位于$APPL_TOP/admin 下一般命名为：$SID.xml $SID_[HOSTNAME].xml 如果这个文件不存在我们也可以手工创建：$./$AD_TOP/bin/adbldxml.sh
修改这个文件的方法：
a editcontext 比较麻烦，需要运行X模拟软件，不好定位属性文件。
用法：export DISPLAY=MYCLIENT:0.0 -> cd $COMMON_TOP/util/editcontext ->./editcontext
b OAM;
c 标准的文本编辑器。我常用的一种方法，修改前最好做备份。
创建端口号：创建之前看看系统有没有使用这个端口号，用netstat实现：netstat -a|grep 8000
用context parameters验证节点类型。验证的目的是供AD UTILITIES使用这些参数执行创建控制脚本或维护必要的文件从而提供服务支持。
AD configuration:
修 改了context文件必须跑autocfg，这样才能使配置生效。跑autocfg前所有的应用进程都必须关闭。跑autocfg的脚本有两 种：11.5.10以前用$AD_TOP/bin/adconfig.sh 从11.5.10开始引进$COMMON_TOP/admin/scripts/$CONTEXT_NAME/adautocfg.sh。两者的用法有点 区别，前者需要contextfile和apps passwd，后者只需要apps passwd。举例如下：
$ ./$AD_TOP/bin/adconfig.sh \
contextfile=$APPLTOP/admin/$CONTEXT_NAME.xml \
appspass=password
$ ./$COMMON_TOP/admin/scripts/$CONTEXT_NAME/adautocfg.sh
如果你手工修改了某些配置文件那么相应contextfile里的内容也需要同步，否则下次autocfg的时候你原来手工改的配置就被覆盖了。
adconfig.sh的日志路径位于如下位置：应用层：$APPL_TOP/admin/$CONTEXT_NAME/log/MMDDhhmm/adconfig.log
数据库层：$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/MMDDhhmm/adconfig.log
--MM是月，DD是日，mm是分钟，
运行adconfig.sh后我们还可查看有哪些配置发生了改变，通过执行adchkcfg.sh可以获得一个HMTL格式的报告，这个脚本位于以下目录：
$AD_TOP/bin. cfgcheck.html位于以下目录：$APPL_TOP/admin/$CONTEXT_NAME/out/MMDDhhmm（应用层）
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/out/MMDDhhmm(数据库层）
当我们自动执行adconfig.sh的时候会自动产生备份文件，备份文件位于下列位置：
$APPL_TOP/admin/$CONTEXT_NAME/out/MMDDhhmm（应用层）
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/out/MMDDhhmm(数据库层）
如果你想恢复执行adconfig.sh时产生的备份文件，可以执行restore.sh这个脚本，脚本路径为：
$APPL_TOP/admin/$CONTEXT_NAME/out/MMDDhhmm/restore.sh(应用层）
$ORACLE_HOME/appsutil/out/$CONTEXT_NAME/MMDDhhmm(数据库层）
客制化配置文件：有时侯我们需要添加一些客制化参数和环境变量到配置文件，如果在跑完autocfg后我们还想保留这些配置，有两种方法可以实现：
a 添加客制化标记或模板文件：
Here is an example of using customizations by editing the adovars.env
application configuration file:
# Begin customizations
# The SCRIPT_TOP environment variable is used for ease of navigation
# to the startup and shutdown scripts of the application
SCRIPT_TOP=/vis/applcomn/admin/scripts/VIS
export SCRIPT_TOP
# End customizations
通过添加# Begin customizations，# End customizations我们可以保留客制化的配置。
另外后续版本的autoconfig可以在客制化的节点上利用adcustomizer.sh脚本来使AD utility 保留客制化配置。
b 利用OAM添加：site map -》administration -》autoconfig -》manage custom parameters
web node configuration:
关于WEB主要配置文件的路径主要在两个地方：$APACHE_ORACLE_HOME/Apache/Apache/conf $APACHE_ORACLE_HOME/Apache/Jserv/etc
有些文档会用这个路径:$APACHE_TOP
apache的配置文件主要是关于端口定义，内存设置，日志级别，日志文件路径等一些其它配置信息。当web服务启动的时候会生成一个http.pid文件，这个文件的路径由httpd.conf文件的PidFile参数指定。
httpd.conf比较重要的几个参数：
MinSpareServers：空闲进程的最小数
MaxSpareServers：允许的最大空闲进程数
Port
ServerName
LogLevel
MaxClients：并发客户端请求的最大数
在apache的配置文件里还有个文件值的注意，它叫wdbsvr.app。它记录了APPS的密码。该文件的路径为：$APACHE_ORACLE_HOME/Apache/modplsql/cfg
$APACHE_ORACLE_HOME/Apache/Jserv/etc的几个重要的配置文件如下：
jserv.conf,jserv.properties,zone.properties
注意zone.properties文件的session.timeout属性必须更应用的ICX:Session Timeout一样。一般建议这个值不应该超过30MIN，大于这个值将会导致JVM堆内存的问题。
forms node configuration: 两个重要的配置文件：$COMMON_TOP/html/bin/appsweb_$CONTEXT_NAME.cfg; $APPL_TOP/$CONTEXT_NAME.env
Forms Metric Server and Forms Metric Client是实现FROMS的load balancing需要的。Metric Client可以定义在多个节点也可以跟 Metric Server 在同一个节点。
我们要定义一个web node是primary forms Metric Server 。实现forms load balancing的其它方法需要web nodes定义成支持forms nodes
concurrent processing node configuration：基本的配置文件：$APPL_TOP/$CONTEXT_NAME.env 其中关键的参数：APPLCSF:描述并发管理器的log和output的路径。
FNDFS 的作用：它是一个文本阅读器，用来查看并发管理器的log和outfile。当用户有查看log文件的需求时，FNDFS启动FNDFS程序利用应用层的 监听（$ORACLE_HOME/network/admin)器来处理用户请求。FNDFS的监听器在$ORACLE_HOME/network /admin/listener.ora下进行配置。FNDFS的连接属性在$ORACLE_HOME/network/admin /tnsnames.ora文件配置。
admin node configuration：应用的环境配置文件有：adovars.env，APPLSYS.env，$CONTEXT_NAME.env 所有的应用TOP都定义在应用的环境变量文件里，比如AD_TOP。
管 理identify.obj文件：这个文件在应用用户的$HOME目录下。（11.10.5.2这个版本我没发现）如果这个文件出现问题，应用在打 PATCH的时候重新生成JAR文件将失败或者在应用的底部会出现一个黄色警告工具条。这个文件可以用adjkey命令重新生成：
$adjkey -initialize
管理数据库连接文件（DBC):这个文件位于$FND_TOP/secure/<host>_<context_name>.dbc 这个文件的作用是用来应用连接数据库的。
Generic Service Management（GSM):EBS11i版本（11.5.7及以后）里引进了GSM，用来管理中间层服务（比如http servers，forms listeners，workflow mailer及其它。这些服务在引入GSM前是手工由DBA进行管理的。），且这个服务是必需的。它跟ICM进行通讯，ICM是内部并发管理器，它控制着 必需的服务，当服务发生错误时它会自动去重启这些服务。我们可以通过OAM来管理这些服务。GSM最常见的就是配置错误，如FNDSM 监听器(主要作用：GSM连接应用）
其 它的服务组件：Thin Client Framework（TCF)它是个服务端进程，用JDBC瘦驱动管理应用的层次连接，比如对象浏览器。我们可以在context file找到有关它的属性，比如以s_tcf..开头的。我们可以使用以下连接来检测这个服务的有效 性：http://erptest.nj.chervon.com:8020/oa_servlets /oracle.apps.fnd.tcf.SocketServer
discoverer server：它是一个图形工具，主要用来对应用的数据做一些特别的查询。具体的使用信息可以参考MetaLink Note 313418.1 contextfile中以s_disco..开头的属性。
Fulfillment Server：JTF是构建CRM中HTML应用的重要技术基础架构。EBS中也包括安装JTF Fulfillment server。在contextfile中以s_jtff开头的属性。
数据库节点的配置：这一部分内容对纯DBA来讲比较简单，我会一带而过。DB的初始化参数比较重要，对与EBS系统来说，有些参数是推荐甚至是强制性的，metalink上有个详细的列表。MetaLink Note 216205.1 MetaLink Note 248857.1.
查询DB初始化参数除了查询v$parameter ,show parameter 外还可以运行bd_chk_cbo.sql脚本。具体怎么使用可以参考MetaLink Note 174605.1。 db的网络配置可以在应用端的$TNS_ADMIN这个变量路径中找到。检查oracle的网络连通性可以用tnsping命令。OATM（oracle applications tablespace model）为了简化对应用数据库的管理，oracle引进了OATM，它减少了表空间的数目，节省空间，易于管理。9.2.0.4及以后的oracle 版本才可以使用OATM。以下是EBS中的一些表空间：
APPS_TS_TX_DATA Contains transactional data
APPS_TS_TX_IDX Contains indexes for transactional tables
APPS_TS_SEED Contains reference and setup data and indexes
APPS_TS_INTERFACE Contains interface and temporary data and indexes
APPS_TS_SUMMARY Contains summary objects, such as materialized views
APPS_TS_NOLOGGING Contains materialized views not used for summary management
APPS_TS_QUEUES Contains Advanced Queuing dependent tables and indexes
APPS_TS_MEDIA Contains multimedia objects, such as video, sound, and spatial data
APPS_TS_ARCHIVE Contains purge-related objects
UNDO The Automatic Undo Management tablespace
TEMP The temporary tablespace, used for sorting and temporary tables
SYSTEM The system tablespace
创建客制化的数据库对象时建议单独建一个schema，这些对象都在这个schema之下，这个schema有自己的数据、索引表空间。这些对象与EBS的标准对象分离。
4.关于额外配置的一些主题
除了以上讲到的一些配置，EBS中还有一些混杂的配置。这一节将会介绍以下主题：Using the configuration wizards from OAM ；Using OAM to review licensed products and license new products；Configuring password security at the application and database level
Using the configuration wizards from OAM ：Navigate to the Site Map menu and select Administration -> AutoConfig -> Configuration Wizards 这个路径可以知道你配置比如loadbanlance，ssl这类的东西。
license管理器：可以查看已经注册的产品或想注册新的产品。具体路径如下：
Site Map ➤License Manager ➤License ➤Products ➤ License Applications Product
Site Map ➤License Manager ➤License ➤Reports➤ Licensed Products
Configuring password security at the application and database level：应用层密码的验证：可以以系统管理员的身份进入系统界面然后修改profile（系统级）属性以Signon开头。数据库层的密码验证：可以创建一个密码验证函数，一旦定义可以分配给数据库配置文件，然后再分配给用户。
其它的contextfile比较重要的配置：
s_contextname Context name used by system
s_dbSid Database SID name
s_jinit_ver_dot Version information for JInitiator
s_jdk_top Home directory for Java Development Kit
s_adperlprg Location of Perl program
oraInst.loc 和oratab的配置：这两个文件位于/etc或/var/opt这根据你特定的UNIX来决定。对于oraInst.loc来说Oracle Universal Install和AD CLONE都会用它来定位oracle安装的路径。如果在单个物理服务器上存在多个实例，我们应该确保这个文件含有正确的各实例信息。oratab这个文 件在app，db节点都会存在，app节点不含有实例名，只有$ORACLE_HOME。这个文件有时候会被oracle智能代理使用。oracle启动 和关闭脚本有时也会用到它。当我们的EBS系统clone或upgrades后会在这个文件写上一些条目，我们应该定期的去清楚这些无用的条目。
5.配置的最佳实践：我们在改变系统配置的时候最好创建一个文档来记录这些改变。
评论