EBS DBA指南笔记(二)

第三章 监控和诊断

 

本章涵盖以下几个主题：监测的方法，数据库的监测，apache的监测，forms的监测，并发管理器的监测，服务器的监测，网络的监测，其它的一些监测和诊断方法。

 

1.监测的方法：主要启用脚本来监测。

2.数据库的监测：alert.log日志非常重要。数据库的监听日志位于$TND_ADMIN目录下，如果监听遇到故障，我们可以在listener.ora设置追踪级别。如：

TRACE_LEVEL_[LISTENER] = [OFF | USER | ADMIN | SUPPORT]

TRACE_FILE_[LISTENER] = [trace file name]

TRACE_DIRECTORY_[LISTENER] = [path to directory]

TRACE_TIMESTAMP_[LISTENER] = [ON or TRUE | OFF or FALSE]

这里的LISTENER为监听器名称。 当我们遇到oracle的网络问题时，我们可以作以下设置来诊断故障：TRACE_LEVEL_[LISTENER] = ADMIN 在oracle support下我们也可以将这个值设置为SUPPORT。

3.查询占用CPU高的会话：

select ss.sid,ss.value CPU ,se.username,se.program

from v$sesstat ss, v$session se

where ss.statistic# in

(select statistic#

from v$statname

where name = 'CPU used by this session')

and se.sid=ss.sid

and ss.sid>6 -- disregard background processes

order by CPU;

解决会话高CPU占用率的方法：布置应用补丁，重写查询语句，收集统计信息，重建index。当我们在应用层取消了这个会话，我们还应该在DB,OS级确认这个会话进程是否消失了。

在EBS系统中会有很多JDBC thin client connections。oracle建议周期性的重启apache来断开这些连接。

4.查询持续时间长的会话：

#This script is used to monitor long running sessions

#Threshold is the number of days a session may be active

#in the database. For example, for an 36 hour threshold use 1.5.

THRESHOLD=$1

LOGFILE=/u01/oradev/DBA_TEST_SCRIPTS/long_running_$ORACLE_SID.log

sqlplus -s apps/apps << EOF

set heading off

spool $LOGFILE

select distinct '$ORACLE_SID - Long Running Sessions above

Threshold.'

from v$session db_session,

v$process process,

v$session_wait wait

where process.addr = db_session.paddr

and db_session.sid = wait.sid

and type='USER'

and db_session.username is not null

and db_session.username not in ('SYS', 'SYSTEM')

and db_session.program not like 'JDBC%'

and logon_time<(sysdate - $THRESHOLD);

-- add data to logfile

select db_session.username,

db_session.osuser,

db_session.sid,

db_session.serial#

db_session.terminal,

wait.event,

db_session.program,

db_session.status,

to_char(logon_time,'dd-mm-yy hh:mi am') "LOGON"

from v$session db_session,

v$process process,

v$session_wait wait

where process.addr = db_session.paddr

and db_session.sid = wait.sid

and type='USER'

and db_session.username is not null

and db_session.username not in ('SYS', 'SYSTEM')

and db_session.program not like 'JDBC%'

and logon_time<(sysdate - $THRESHOLD)

order by logon_time;

spool off

exit

EOF

RETURN_CODE=`grep "Threshold" $LOGFILE | wc -l`

if [ $RETURN_CODE -eq 0 ]

then

exit 0

else

exit 1

fi

对于EBS系统来讲，只要iAS一启动，JDBC thin client sessions就会存在，而且会自动根据应用增加。持续时间较长的session如果没有什么用处，可以考虑将它kill掉。

5.查找blocking session：blocking session锁定了一些资源而这些资源又是其它session需要的。我们可以查询v$lock这个视图，条件设置为：block>0.

6.存储的一些监控：表空间，数据文件，段的一些限制。注意单个文件的大小是受操作系统限制的，我们可以修改OS的参数来改变这种限制。查询表空间的剩余空间可以用dba_free_space这个数据字典。查询段的使用情况用dba_segments。

几条关于表空间的语句：

The following statement will alter a datafile to automatically extend:

alter tablespace [tablespace_name]

datafile '[path/datafile_name]' autoextend;

The following statement will alter a datafile to extend to a given size:

alter tablespace [tablespace_name]

datafile '[path/datafile_name]' size [size]M;

The following statement will add a datafile to the tablespace:

alter tablespace [tablespace_name] add

datafile '[path/datafile_name]' size [size]M;

在表空间建立的时候，尽可能设置uniform extents，pct_increase=0,这样有利于被删除的对象占用的extents，段被重用的效率增加。

改变段存储参数的命令：alter [object_type] [object_name] storage (maxextents [number])    example：SQL>alter table FND_USERS storage (maxextents 500);

SQL>alter table FND_USERS storage (maxextents UNLIMITED);

 

7.Apache服务器的监控和诊断：

apache日志的路径：$IAS_ORACLE_HOME/Apache/Apache/logs(有些版本是$APACHE_TOP); $IAS_ORACLE_HOME/Apache/Jserv/logs/jvm

当遇到问题时，我们需要开启debug的级别来获得更详细的日志信息，debug级别的打开可以用以下方法：

1. Set LogLevel to DEBUG in $IAS_ORACLE_HOME/Apache/Apache/conf/httpd.conf.

2. Set ApJservLogLevel to DEBUG in $IAS_ORACLE_HOME/Apache/Jserv/etc/jserv.conf.

3. Make the following changes to $IAS_ORACLE_HOME/Apache/Jserv/etc/jserv.properties:

• Add wrapper.bin.parameters=-Djbo.debugoutput=console

• Set log=true

• Set log.channel=true

• Set log.channel.info=true

• Set log.channel.debug=true

我们也可以指定debug_output参数来指定debug信息输出的位置。这个参数所在的文件在$IAS_ORACLE_HOME/Apache/Jserv/etc/ssp_init.txt中。

一定要记住在诊断完问题后要关闭debug开关，以免引起性能问题。

apache状态的检查：$APPLCSF/admin/scripts/*_hostname/adapcctl.sh status

验证iAS的配置可以用AOL/J工具来进行测试。5.10的版本可以用OAM。更多AOL/J的信息可以参考metalink文档：275875.1

http://erptest.nj.chervon.com:8020/OA_HTML/jsp/fnd/aoljtest.jsp   --这时验证的URL，需要你输入一些信息，比如apps密码，数据库名，监听器端口等。进去后可以点击Enter AOL/J Setup Test按钮进入另外一个界面，这个界面可以验证dbc文件设置，web agent设置，servlet设置，x server设置等等。我们也可以通过OAM进入这个页面。

测试java servlet配置：可以用以下格式的URL来测试：http://erptest.nj.chervon.com:8020/oa_servlets/oracle.apps.fnd.test.HelloWorldServlet

监控jvm pool：5.10之前的版本可以用这个URL来监控：http://erptest.nj.chervon.com:8020/servlets/OAAppModPoolMonitor ；5.10开始不支持这个URL，取代它的是全局诊断按钮或OAM。使用全局诊断按钮时需要设置profile FND:diagnostic 为yes。OAM的路径为：site map -》monitoring -》JServ Usage

 

8.forms的监控和诊断：可以使用OAM，具体路径为：Site Map -> Monitoring -> Current Activity 可以看到forms session的一些详细信息。forms 的dump文件命名格式：f60webmx_dump_xxxx  xxxx表示进程号。文件所在的路径：$COMMON_TOP/admin/log/*_hostname/f60webmx_dump_xxxx

 

9.并发管理器的监控。

监控并发管理器日志文件：log和out的路径：$APPLLOG,$APPLOUT

查看正在运行的并发请求：OAM或$FND_TOP/sql/afcmrrq.sql（这个脚本要用apps帐户在admin node上执行）

监测暂挂的并发请求：OAM或脚本（查询fnd_concurrent_requests）

取消正在运行的并发请求：我们可以在应用中取消，但有时候在数据库级的session还没有结束。这时你运行$FND_TOP/sql/afcmrrq.sql已经看不到这个请求。怎么处理这种情况？我们可以根据请求号来查询它的DB级的SID，脚本如下：然后kill这个session。我们也可以通过OAM来处理。

select r.request_id "Request ID",

s.sid "Session ID" ,

g.concurrent_program_name "Concurrent Program"

from applsys.fnd_concurrent_requests r,

applsys.fnd_concurrent_queues_tl qt,

applsys.fnd_concurrent_queues q,

applsys.fnd_concurrent_processes p,

applsys.fnd_concurrent_programs g,

v$session s

where r.controlling_manager=p.concurrent_process_id

and q.application_id=p.queue_application_id

and q.concurrent_queue_id=p.concurrent_queue_id

and qt.application_id=q.application_id

and qt.concurrent_queue_id=q.concurrent_queue_id

and r.phase_code='R'

and qt.language in ('US')

and p.session_id=s.audsid

and g.concurrent_program_id = r.concurrent_program_id

and r.request_id = &request_id

监测并发请求的运行时间：如果运行时间较长的并发请求阻碍了运行时间较短的并发请求，就要考虑增加并发管理器的数量了。长时间运行的并发请求DBA也需要关注，看看它是否正常。OAM可以很好的查询出哪些请求占用了较长时间，哪些请求占用的时间短。

 

10.服务器的监控和诊断。

CPU,内存，文件系统的监控。这里主要是UNIX系统管理员的任务。

 

11.网络的监控。

两个有用的命令：ping，tracert。  以系统管理员的身份进系统，应用-》网络测试 这个工具也可以测试网络。

 

12.其它关于监控和诊断的主题。

监控profile的改变：打patch的过程会有新的属性值覆盖旧的属性值或增加新的属性值。有些用户或管理员也会修改profile，但往往没有意识到这些修改对系统所带来的影响。DBA对这些就需要关注。下面这个脚本是用来监控profile改变的，我们可以定义一个阀值比如7天，来查看7内修改过的profile。

#Script used to monitor for application profile changes

#Threshold is the number of days to query for profile changes

#For example, if you set it to 7, all profile changes that

#have occurred in the past 7 days will be displayed.

THRESHOLD=$1

LOGFILE=/tmp/profile_changes_$ORACLE_SID.txt

sqlplus -s apps/apps << EOF

set heading off

spool $LOGFILE

select '$ORACLE_SID - Profile Changes Past '||

'Threshold of $THRESHOLD days - '||count(1)

from fnd_profile_option_values

where last_update_date > (sysdate-$THRESHOLD)

having count(1) > $THRESHOLD

union

select 'no rows'

from fnd_profile_option_values

where last_update_date <= (sysdate-$THRESHOLD)

having count(1) <= $THRESHOLD;

spool off

exit

EOF

RETURN_CODE=`grep "Threshold" $LOGFILE | wc -l`

if [ $RETURN_CODE -eq 0 ]

then

exit 0

else

exit 1

fi

我们可以通过fnd_profile_option_values，fnd_profile_options，fnd_user这三个表来确定被修改的profile属性是什么以及是被谁修改的。其中fnd_user的user_id=fnd_profile_option_values的LEVEL_VALUE。OAM提供了更好的图形查看方法。

解决JInitiator的问题：当客户端运行forms程序出问题时，可以尝试清空JAR cache。在控制面板里可以找到JInitiator的图标。我们也可以打开java的控制台来显示一些有用的信息。如果清空JAR缓存还不能解决问题，可能需要重新安装JInitiator。

 

13.监控与诊断的最佳实践

DBA需要主动，多了解系统的架构和EBS的工作原理，这样在遇到问题的时候才会快速定位。另外，需要对系统周期性的监测，防止问题的发生。

 

 

第四章 性能优化

 

1.性能优化的步骤。

收集信息-》指定优化步骤。

定位性能问题，DBA可以以问答的形式，收集一些信息。

问：性能问题是会经常性的重现还是没有任何规律？

问：性能问题是否只在某一场合（实例，情况）出现？

问：在同一网段的所有应用用户是否都遇到了性能问题？

问：性能问题的发生是否在指定的时间段发生？

问：是不是整个应用的性能都在下降？

问：是不是只有单个模块的性能在下降？

问：是不是只有单个用户遇到性能问题？

 

根据以上的问题发现问题并制定优化步骤，优化步骤以文档的方式体现。调优的过程也要求记录下来，如果以后遇到同样的性能问题可以作参考。

 

2.性能调优的工具。

性能调优可以分四大块：数据库，服务器，应用，用户。

数据库的调优：9i性能数据收集的工具有statspack。10g有AWR,ADDM. 在做statspack的时候有些阀值是可以调节的，EBS系统推荐以下这些阀值：

sql>exec statspack.snapshot ( -

>i_snap_level => 6, -

>i_executions_th => 1000, -

>i_parse_calls_th => 1000, -

>i_disk_reads_th => 10000, -

>i_buffer_gets_th => 100000, -

>i_sharable_mem_th => 1048576, -

>i_version_count_th => 20, -

>i_all_init => 'TRUE' -

>)

注意，做statspack的时候timed_statistics参数应该是TRUE。

分析statspack报表：这里不多讲了。

 

在10g里使用ASH（active session history):MMNL后台进程负责写session数据到内存，然后每隔一小时将内存的数据写到表。我们可以通过$ORACLE_HOME/rdbms/admin/ashrpt.sh这个脚本来查看ASH所搜集到的信息。我们也可以将ASH缓冲的内容DUMP到trac文件，语句如下：SQL>alter session set events 'immediate trace name ashdump level 10';

 

在10g里使用AWR(automatic workload repository):AWR通过MMON后台进程每隔60分钟收集性能数据，性能数据默认在系统保留一周。他不仅仅是statspack的代替，他还收集一些OS的信息。我们可以在v$OSSTAT这张视图看到。AWR收集的性能数据存放在sys的schema下，表空间为：SYSAUX。大约有100张表来存放这些信息，表的通用名为：DBA_HIST_%。通过EM我们也可方便的管理AWR，同时我们也可以使用DBMS_WORKLOAD_REPOSITORY包来管理。比如要修改快照间隔为两个小时一次，数据保留的时间为10天。可用以下方法：

sql>exec dbms_workload_repository.modify_snapshot_settings ( -

>interval => 120, -

>retention => 14400)

我们还可以创建快照的基线（baseline of snapshot）来比较不同基线的差别，从而确认性能问题。举个创建的例子：

sql>exec dbms_workload_repository.create_baseline( -

>start_snap_id => 1, -

>end_snap_id => 2, -

>baseline_name => 'Test')

最后我们可以运行awrrpt.sql来获得性能报告，这个脚本需要两个快照。sql>@$ORACLE_HOME/rdbms/admin/awrrpt.sql 这个报告可以人工分析也可以用oracle 10g提供的ADDM自动分析。

 

在10g使用ADDM(automatic database diagnostic monitoring）：用ADDM来分析AWR收集的性能数据。addmrpt.sql这个脚本将产生一个ADDM报告。这个脚本的使用跟生成statspack报告有点相似，都需要输入开始和结束的AWR快照。而且如果期间数据库DOWN了，那分析出来的数据也就无效了。当然我们也可以手工的分析和产生这些报告，只要你有ADVISOR的权限使用DBMS_ADVISOR package。跟ADDM相关的视图有这样的通用名：DBA_ADVISOR_%。最后为了能让ADDM工作，我们需要在初始化参数里设置statistics_level=typic or all。oracle推荐在进行数据库诊断的时候最好设置成all。

 

3.服务器的调优

top;sar;vmstat;ps

 

4.应用层的调优

应用层的调优主要包括以下几大组件：FORMS,APACHE SERVER,JSERV,CONCURRENT MANAGER.

FROMS调优：在服务器查看forms的进程：#ps -ef|grep f60webmx|grep PROD  --假设PROD为instance。如果forms进程属于服务器top几的进程，我们就应该对他进行观察。可以进OAM界面进行查看，如果是无用的进程我们可以kill掉它或者是重新启动form server。当死连接存在服务器上的时候，froms的性能问题就显现出来了。我们可以设置FORMS60_TIMEOUT这个参数来控制死连接，这个参数的单位是分钟。还有个参数在做FORMS性能诊断的时候会用到：FORMS_CATCHTERM.将它的值设置为1表示将forms的错误dump到FORMS_TRACE_PATH这个目录下。它在context file对应的值如下：

Context File Parameter Environment Variable Recommended Value

s_f60time FORMS60_TIMEOUT 10

s_f60catchterm FORMS60_CATCHTERM unset or 1

有时候EBS用户想取消forms的查询，这可以通过FND: Enable cancel query这个profile option来设置。如果没有设置想取消forms的查询就只能kill form session，如果值为yes，将弹出一个对话框，让用户选择取消。启用这个功能将会消耗client，middle-tier，db的一些CPU资源。跟这个功能有关的一些参数如下：

Environment Variable             Value Description

FORMS60_LOV_INITIAL           1000–32000 Number of milliseconds until the

                              cancel query button appears to the user.

FORMS60_LOV_MINIMUM           1000–32000 Value in milliseconds between polling of the client from the

                              middle tier to check whether the query cancel dialog box should be

                              popped. Recommended values are 1000–5000

FORMS60_LOV_WEIGHT            0–32000 Value used to assist in determining network latency, in order

                              to adjust the polling period.

 

这三个参数必须设置在$APPL_TOP/<SID>.env里面。如果你使用了Forms Servlet Listener，也可以设置在formservlet.ini文件里。

举例：export FORMS60_LOV_INITIAL=32000

export FORMS60_LOV_MINIMUM=5000

export FORMS60_LOV_WEIGHT=0

要想参数生效记得重启forms server。为避免被autocfg覆盖，请添加到context file里。

在formservlet.properties文件里MAXBLOCKTIME的值必须大于maximum query polling interval的值。默认值是1000ms。特别是使用Forms Servlet Listener的时候这是必须的，否则会占用大量的CPU，引起性能下降。

 

apache的调优：LogLevel=warn   SSLLogLevel=warn这时建议的设置，详细的日志记录会导致性能下降。缓存一些非HTML的对象也有助于apache性能的提升。如果使用了autocfg缓存的指令会自动设置。或者你也可以在httpd.conf文件或apps.conf文件里设置。例如：

# enable caching for OA_HTML/cabo/jsLibs

#

<Directory substitute_path_to_OA_HTML/cabo/jsLibs>

ExpiresActive On

ExpiresByType application/x-javascript "access plus 1 year"

ExpiresByType text/javascript "access plus 1 year"

</Directory>

 

JServ的调优：JServ进程是httpd进程的子进程，它的日志级别也应该和apache保持一致，以下是推荐值：

jserv.conf:

ApJServLogLevel warn

 

jserv.properties:

Log=false

Log.channel.info=false

Log.channel.debug=false

Log.channel.warning=true

 

ssp_init.txt:

Debug_switch=OFF

 

FND: View Object Max Fetch Size这个配置文件可以限制HTML应用返回给用户的行数。如果这个值大于200，JServ的内存将会耗尽。如果200这个值对你来说不够，那么可以在应用层设置这个配置文件大于200。

zone.properties文件里的session.timeout参数如果值大于30MIN，将导致性能的下降。根据用户最低接受需求合理的设置这个值。

如果JServ日志或浏览器报：out of memory 说明jvm的内存使用已达到了极限，我们需要调整jvm heap memory 这个值在jserv.properties里面，如下所示：wrapper.bin.parameters=-mx(new_size)m

zone.properties文件里的autoreload.classes默认值是true应该改成false以提高性能。

在重启apache或删除缓存的时候，缓存的东西需要重构，这也将导致性能下降。我们可以在zone.properties里设置以下参数来缓存经常使用的类：

#servlets.startup=oracle.apps.fnd.framework.OAStartupServlet   --默认是注释的，可以解除注释。

JDK版本的提升往往会带来性能的提升。

修改了以上参数记住在context file里也修改，以免autocfg的覆盖。

 

并发管理器的调优：job的调度很重要，要避免在业务高峰期跑一些运行时间较长的请求。如果性能问题跟某个特定的并发管理器有关而且与之相关的CPU占用率很高，说明你系统的ICM sleep time的值设置的较低，关于设置的信息可以查看metalink Note 178925.1

 

用户的调优：Help ➤Diagnostics Menu ➤Client System Analyzer. 可以查看客户端的详细信息。

 

5.trace file：产生和分析跟踪trace文件是性能调优的重要手段。

生成forms的trace file：确认一些配置文件的设置：Hide Diagnostics menu entry=no；Utilities： Diagnostics=yes。登录应用选择Help ➤Diagnostic ➤Trace ➤Trace with Binds and Waits menu option.

Help ➤Diagnostics➤Trace ➤Unlimited Trace File Size --这个选项在10.5.2的版本找不到。这样就打开了FORMS的跟踪文件，跟踪文件会在db的udump下产生。

生成自己的trace file： profile-》system 选择user并输入自己的用户名，然后设置FND: Diagnostics=yes。然后用这个用户登录，设置trace级别就可以了。然后使问题重现，这样就会产生trace文件了。

 

6.分析trace文件：分析工具tkprof，trcanlzr。

tkprof：$tkprof <raw trace file name> <output filename> explain=apps/<apps password>

数据库的初始化参数_user_files_public可以设置trace文件的访问权限除了instance owner外其它的用户也可以访问并使用tkprof分析它。

trcanlzr：跟tkprof一样，但产生的报告是HTML形式的。这个工具需要从oracle support那下载，并进行安装。具体请参考MetaLink Note 224270.1

 

7.10g里分析SQL语句：

SQL Tuning Advisor：SQL调优专家，进入EM可以看到。我们也可以用DBMS_SQLTUNE package来手工进行。举个例子：

sql>exec dbms_sqltune.create_tuning_task( -

>sql_text => 'select * from emp where emp_id=101', -

>user_name => 'SCOTT', -

>scope => 'COMPREHENSIVE', -

>time_limit => 60, -

>task_name => 'tune_emp', -

>description => 'Task to tune a query on the EMP table')

sql>exec dbms_sqltune.execute_tuning_task (task_name => 'tune_emp')

sql>select dbms_sqltune.report_tuning_task('tune_emp') from dual;

 

SQL Access Advisor：SQL Tuning Advisor用来调整单个SQL，处理多个SQL的使用用这个工具。一组被调优的查询语句被称为SQL Tuning Set。除了进EM使用这个工具，也可以手工执行。

 

8.性能调整的其它一些选项：参考书146页。

 

9.普通的性能问题：一些预防性的维护工作没有做好往往会导致性能问题。这其中包括统计数据的收集，编译无效对象。通常用户使用一项新的功能的时候，如果没有做压力测试直接在生产上使用往往会导致性能问题。

 

10.性能调整的最佳实践

一些patches和最新版本的technology stack往往会提高应用的性能。MetaLink Note 244040.1专门介绍oracle推荐的能使性能提高的一些patches。建议看看。