全部博文（323）
分类： Oracle
2012-06-02 11:46:06
第三章 监控和诊断
本章涵盖以下几个主题：监测的方法，数据库的监测，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
--这时验证的URL，需要你输入一些信息，比如apps密码，数据库名，监听器端口等。进去后可以点击Enter AOL/J Setup Test按钮进入另外一个界面，这个界面可以验证dbc文件设置，web agent设置，servlet设置，x server设置等等。我们也可以通过OAM进入这个页面。
测试java servlet配置：可以用以下格式的URL来测试：
监控jvm pool：5.10之前的版本可以用这个URL来监控： ；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/
举例：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
#
ExpiresActive On
ExpiresByType application/x-javascript "access plus 1 year"
ExpiresByType text/javascript "access plus 1 year"
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
数据库的初始化参数_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。建议看看。
