Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2623115
  • 博文数量: 323
  • 博客积分: 10211
  • 博客等级: 上将
  • 技术积分: 4934
  • 用 户 组: 普通用户
  • 注册时间: 2006-08-27 14:56
文章分类

全部博文(323)

文章存档

2012年(5)

2011年(3)

2010年(6)

2009年(140)

2008年(169)

分类: 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           100032000 Number of milliseconds until the

                              cancel query button appears to the user.

FORMS60_LOV_MINIMUM           100032000 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 10005000

FORMS60_LOV_WEIGHT            032000 Value used to assist in determining network latency, in order

                              to adjust the polling period.

 

这三个参数必须设置在$APPL_TOP/.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

#

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 DiagnosticsTrace 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 explain=apps/

数据库的初始化参数_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。建议看看。

阅读(4607) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~