3.1分而治之

一个用于部署Web应用程序的典型架构：
客户端--反向代理--Web服务器--应用服务器--数据库服务器--存储

分析性能问题应该首先收集你所关心的执行程序请求的端到端的性能数据。

分治法(divide-and-conquer)：其主要思路是把端到端的响应时间分解为几个主要组件，然后只收集有意义的细节信息。

3.2分析路线图

目标是把响应时间分成主要的三类：
--不在数据库层运行的应用程序代码
--数据库层以及所依赖的存储
--所有在前两类中没包括在内的支撑应用程序的组件（比如，网络设备）

时间模型统计：10g，可以找出应用程序在哪一类数据库操作中消耗了最多的时间。v$sys_time_model, v$sess_time_model

3.3性能测量与剖析分析

要收集性能问题的信息，基本有如下两种方法：
#性能测量(instrumentation)--通过激活应用程序中的性能测量代码
#剖析分析(profiling analysis)--借助于剖析工具(profiler)，收集端到端的响应时间

两种方法的优缺点

3.4性能测量

执行性能测量代码是用来获取应用程序行为的。

要识别性能问题，我们应该着重关注运行了哪些操作、运行顺序、处理的数据量、执行次数、执行时间。某些案列如果知道使用了多少资源也是很有用的。

既然剖析工具已经在调用层或者代码层提供了信息，那么性能测量就可以重点关注业务相关的操作或是组件层之间的交互。

3.4.1应用程序代码

每一个应用程序都应该做性能测量，问题不在于是否该做而是如何去做。这是在应用程序开发的初始阶段架构师要做的重要决策。

日志框架、JMX(Java Management Extentions)

3.4.2数据库调用

对数据库调用进行性能测量以便给出数据库引擎中待执行程序的上下文信息。

数据库引擎为一个数据库会话动态关联了如下属性：
客户端标记(client_identifier)
客户端信息(client_info)
模块名称(module)
操作名称(action)

数据库会话相关属性的设定方法：
#PL/SQL

设定
dbms_session.set_identifier(client_id=>'kkk')
dbms_application.set_client_info(client_info=>'dss')
dbms_application.set_modual(module_name=>'mmmm',action_name=>'aaaa')

查询1
select sys_context('userenv','client_identifier'),
       sys_context('userenv','client_info'),
       sys_context('userenv','module'),
       sys_context('userenv','action'),
from dual;

查询2
select client_identifier,client_info,module,action
from v$session
where sid = sys_context('userenv','sid');

#OCI

使用函数OCIAttrSet()

#JDBC

使用OracleConnection.setEndToEndMetrics()

#ODP.NET

只能使用OracleConnection类的ClientId属性，赋值

3.5剖析应用程序代码

性能剖析工具应该提供如下核心功能：
--支持分布式应用程序的能力。意味着在代码执行处能独立的激活剖析工具。
--具备在调用层与代码行级别运行剖析分析的能力。
--具备针对部分应用程序代码或是特定请求来选择性地激活或者关闭剖析工具的能力。

3.5.1简明的性能剖析

剖析工具：
Quest-------> PerformaSure
Borland----->Optimizeit Enterprise Suit
Compuware--->Vantage Analyzer
dynaTrace--->dynaTrace Diagnostics
Oracle------>Grid Control
Synmantec--->i3

#PerfomaSure

三个主要组件：代理、Nexus、工作站。

代理：系统代理(system agent)、Web服务器代理(web server agent)、应用服务器代理(application server agent)。

每种类型的代理使用供应商提供的API来收集所监控组件的性能数据。应用服务器代理使用字节码性能测量收集调用层级的性能数据。

Nexus：作为中心组件，在收集剖析信息时不只是存储从代理接收到的性能数据，更重要的是针对每个请求重构了端到端的执行路径。在收集结束时，Nexus被工作站用做分析引擎。

工作站：作为表现工具。不只是管理与分析收集的数据，还用来启动和停止数据的收集及用户管理。

要对应用程序施加真实的负载压力，还安装了一个叫Grinder的压力测试工具。Grinder是个Java负载测试框架，能够和其他软件一起模拟Web浏览器。

#记录会话

记录等级：组件细节、全部细节
显式的包括或排除度量的范围
采样记录
正则表达式筛选
时间片的选择

#分析会话

从检查所调查操作的响应时间开始

如有必要，可以针对记录过程中多个收集指标来关联请求响应时间

分析请求树(request tree)

3.5.2细节化性能剖析

#Quest-->Jprobe

两个主要组件：分析引擎、控制台

分析引擎运行在应用程序的Java虚拟机内部，同Java虚拟机工具接口(JVMTI)收集剖析数据并发送到控制台，另外提供激活和禁止记录的功能。

#记录会话

限制剖析分析的范围

#分析会话

调用图

调用图以及只针对关键路径的相关统计

代码行级别的统计

3.6跟踪数据库调用

跟踪数据库调用的基本步骤：
激活SQL跟踪-->找到跟踪文件-->从跟踪文件中抽取相关信息-->运行剖析分析工具-->解释剖析工具输出内容

3.6.1SQL跟踪

SQL跟踪的目的有两方面：
其一：提供信息以在服务时间与等待时间之间分解响应时间
其二：给出所用资源与同步点的详细信息

使用TKPROF工具抽取跟踪文件或者直接查看跟踪文件，跟踪文件的内容是有格式的

从内部技术细节看，SQL跟踪是基于10046事件的。

10046调试事件的等级：0(禁止调试时间)，1(激活调试事件)，4(1+binds)，8(1+waits)，12(1+binds+waits)

10000～10999之间的事件号是保留的，专门用于调试事件。

#激活SQL跟踪：旧方法

9i：
三种方法：初始化参数sql_trace，dbms_session.set_sql_trace，dbms_system.set_sql_trace_in_session，都只能在等级1激活SQL跟踪。

在任意等级激活或禁止SQL跟踪的两个方法：
alter session set events '10046 trace name context forever, level 12' --激活
alter session set events '10046 trace name context off' --禁止
alter system set events....
dbms_system.set_ev --sys用户，其他用户可以使用dbms_support包

#激活SQL跟踪：现在的方法

10g：
dbms_monitor
数据字典：dba_enabled_traces

会话级：
dbms_monitor.session_trace_enable
dbms_monitor.session_trace_disable

客户端级：
dbms_monitor.client_id_trace_enable
dbms_monitor.client_id_trace_disable

组件级：
dbms_monitor.serv_mod_act_trace_enable
dbms_monitor.serv_mod_act_trace_disable

数据库级：
dbms_monitor.database_trace_enable
dbms_monitor.database_trace_disable

#触发SQL跟踪

自动触发跟踪：使用触发器启用SQL跟踪
在应用程序中直接添加代码启用SQL跟踪

#跟踪文件中的计时信息

动态初始化参数timed_statistics，设定TRUE或FALSE，控制计时信息是否可用。

timed_statistics的默认值依赖于另一个初始化参数statistics_level。

如果不提供计时信息，那么跟踪文件就没什么用了，所以启用跟踪之前要确认timed_statistics是否设置为TRUE。

动态初始化参数意味着无需重启实例就可以改变，是否可以在会话层级修改还是可以在系统层级修改，参照v$parameter的isses_modifiable与issys_modifiable。

#限制跟踪文件的大小

使用参数max_dump_file_size

#查找跟踪文件

user_dump_dest 专有服务器进程创建的跟踪文件位置
background_dump_dest 后台进程创建的跟踪文件位置

11g
引入了自动诊断资料库(Automatic Diagnostic Repository)
user_dump_dest，background_dump_dest失效，
使用diagnostic_dest设定基本目录，使用v$diag_info获得跟踪文件的准确位置

跟踪文件命名结构：
{instance name}_{process name}_{process id}.trc

3.6.2跟踪文件的结构

3.6.3使用TRCSESS

10g开始提供的命令行工具TRCSESS

trcsess [output=] [session=] [clientid=]

[service=] [action=] [module=]

仅支持10g及以上版本的跟踪文件，9i及之前的跟踪文件需要进行转换后方可使用。

3.6.4剖析工具

TKPROF(Trace Kernel PROFiler)：数据库和客户端都可以使用，Oracle7引入
TVD$XTAT
Hotsos Profiler
itfprof SQL Analyzer
OraSRP
Trace Analyzer

3.6.5使用TKPROF

#TKPROF参数

tkprof tracefile outputfile [explain= ] [table= ] [print= ] [aggregate= ] [insert= ] [sys= ]

[sort= ]

通常使用
tkprof {input trace file} {output file} sys=no sort=prsela,exeela,fchela

#解释TKPROF输出

call      parse/execute/fetch
count     number of times OCI procedure was executed
cpu       cpu time in seconds executing
elapsed   elapsed time in seconds executing
disk      number of physical reads of buffers from disk
query     number of buffers gotten for consistent read
current   number of buffers gotten in current mode(usually for update)
rows      number of rows processed by the fetch or execute call

行源操作(Row Source Operation)

cr    consistent read blocks
pr    physical read blocks
pw    physical write blocks
time total elapsed time in microseconds
cost estimated cost, 11g
size estimated operation data in byte, 11g
card estimated returning rows, 11g

未说明时间(unaccounted for time)产生原因分析。

要分析等待事件，关键是要知道哪些操作是相关的。

一些等待事件：
SQL*Net message to client
SQL*Net message from client
log file sync
db file sequential read
db file scattered read
direct path write temp
direct path read temp

3.6.6使用TVD$XTAT

TVD$XTAT：Trivadis扩展跟踪文件分析工具，命令行方式

http://top.antognini.ch 下载地址

3.7剖析PL/SQL代码

dbms_profiler

3.7.1安装剖析工具

sys用户执行 ../rdbms/admin/profload.sql

3.7.2安装输出表

执行 ../rdbms/admin/proftab.sql，不一定非要sys用户

3.7.3收集剖析数据

dbms_profiler.start_profiler
dbms_profiler.stop_profiler

3.7.4报告剖析数据

dbms_profiler.sql

3.7.5GUI方式

PL/SQL Developer(Allround Automations)
SQLDetective(Conquest Software)
Rapid SQL(Embarcadero)
SQL Insight(Isidian)
Toad
SQL Navigator(Quest Software)

3.8小结

ITPub博客

【Oracle性能诊断艺术】学习笔记----第三章：找出性能问题

最新文章