《Oracle数据库性能优化方法论和最佳实践》——2.4 基于工作单元的响应时间分析优化方法论

简介:

本节书摘来自华章计算机《Oracle数据库性能优化方法论和最佳实践》一书中的第2章,第2.4节,作者:柳遵梁 潘敏君 应以峰著,更多章节内容可以访问云栖社区“华章计算机”公众号查看

2.4 基于工作单元的响应时间分析优化方法论

2.4.1 UOWTBA优化方法论的导入
在RTA工作方法论的基础上,Craig Shallahamer结合吞吐量和响应时间关系曲线图提出了基于工作单元的响应时间分析方法论(Unit of Work Time Based Analyze,UOWTBA或者Unit of Response Time Analyze,UOWRTA)。UOWTBA方法论相较于RTA方法论而言,在强调响应时间时,同等强调了吞吐量的重要性,它通过衡量操作单元的响应时间而不是绝对时间来完成性能优化。
工作单元的最简单说法就是某个特定操作粒度之上的操作,比如一次逻辑读、一次物理读、一次latch gets、一次mutex gets、一次parse call等。工作单元的粒度根据需要分析的场景而定,相对来说,由于工作单元的时间响应需要作为顶层业务作业的可比较单元,所以需要选择相对基础的细粒度工作。
再次来看吞吐量和响应时间关系曲线。
吞吐量和响应时间关系曲线极为明确地揭示了一个本质现象:任何输出响应时间都是在特定的输入吞吐量下才会表现出其业务价值的。UOWTBA优化方法论强调了输入吞吐量单元,其响应时间总是标记为单个输入吞吐量单元的响应时间。
性能优化的目标就是延长曲线突变点,从而使其可以获得更高的吞吐量。TBA关键的问题在于缺乏衡量吞吐量的基础标准,或者对于每个业务系统都具有其特定吞吐量描述,这样就给TBA分析带来巨大的困难。比如CRM业务系统,其标准吞吐量为:每小时5000个受理、20000个开通等描述,但会发现你无法把这些描述和数据库的监控关联起来。
Oracle数据库有很多标记吞吐量的指标变量,比如executes、user calls、transactions等,事实上,Oracle 11gR2的RTA方法论中也涉及了衡量基于executes、user calls、transactions等输入吞吐量的输出响应时间。大家可以很明显地看到,虽然从业务输入层面上transactions、executes都是可以感知的输入吞吐量的,但是execute和execute、transactions和transaction之间的个体差异太大,使其输入吞吐量缺乏一致性比较的基础。比如执行10万次的SQL语句“select from dual”自然无法和执行10万次的SQL语句“select from dba_objects”相比较。transactions也是同样的道理,除了一些业务极为均匀的系统外,无法作为吞吐量输入衡量的基础。
为了获得一个通用的业务特征和吞吐量的描述,笔者在TBA的基础之上进行了进一步的研究,希望获得更好的描述访问特征和访问能力的监控指标,以更有效地完成TBA分析。Craig A. Shallahamer的研究成果正好和我所寻求的方向一致,基于工作单元的TBA分析方法可以很好地弥补TBA方法的不足。
2.4.2 输入吞吐量指标的选择
衡量任何一个业务系统的运行性能,可以从两个基本方面来进行考察:访问特征和访问能力。
访问特征体现了业务系统运行的负载特征,主要用来衡量吞吐量。当一个业务系统的访问特征发生了变化,特别是其访问特征预期在吞吐量突变点之上时,可以判断业务系统的性能将会发生变化。或者说业务系统的访问特征发生了明显的变化,可以猜测以下两点正在发生:
1)有新的业务正在加入,需要引起关注。
2)原有业务的访问特征发生了变化,可能会引起重大的性能问题。
访问能力体现了业务系统运行的响应时间特性,主要用来衡量响应时间。一个性能表现良好的系统,响应时间或者访问能力必须控制在可接受的范围之内,否则就表示业务系统性能不佳。
数据库应用系统在考虑数据库黑盒子的情况下,可以用两个基本性能指标来衡量访问特征和访问能力:LIO(逻辑I/O)和PIO(物理I/O)。Craig A. Shallahamer就是选择了LIO和PIO作为输入吞吐量操作单元,尤其是LIO输入指标。一般来说,数据库应用运算量很小,绝大部分数据库应用的运算转换消耗可以忽略不计,LIO基本可以代表CPU资源的消耗运行。
任何业务系统在不考虑运行和网络交互的情况下,都可以归类为两类基本的操作:LIO和PIO。每个业务系统不管其业务模式如何变化,SQL语句如何多变,其最终有效性都可以通过这两个指标来衡量。以每秒或者每分钟多少个LIO和PIO来衡量业务特征,LIO和PIO的数量和两者之间的比例就构成了现有业务系统的运行特征,而LIO和PIO具有相互转换的关系甚至可以归结为一个衡量业务系统运行的指标。
在引入LIO和PIO两个核心输入吞吐量指标之后,就可以构建UOWTBA响应时间分析方法论的基本形态。
访问特征:每秒运行的LIO和PIO数量。
访问能力:每个LIO和PIO的响应时间。
辅助描述:Transactions,User Calls,Execute数量。
响应时间(LIO)= 服务时间 + 等待时间
响应时间(PIO)= 服务时间 + 等待时间
对于PIO来说,可以进一步分解为:响应时间(PIO) = 服务时间 + I/O服务时间 + 其他等待时间。
再次查看吞吐量和响应时间曲线,以及图2-4基于输入吞吐量PIO的响应时间曲线。
screenshot

可以看出,UOWTBA和TBA最根本的区别在于,UOWTBA分析对吞吐量的描述比标准TBA分析更加清晰,使基于业务的TBA分析可以简单地转化为基于技术的TBA分析。
2.4.3 采用UOWTBA优化方法工作
简单观察基于输入吞吐量LIO或者PIO的响应时间曲线,从工作单元分析可以发现存在三类问题。
1)LIO或者PIO在没有达到基线标准的情况下发生了性能变异。
2)LIO或者PIO在达到或者超过基线标准的情况下发生了性能变异。
3)LIO或者PIO的特征发生了变化,从而导致了性能变异。
不同的性能问题可以有不同的考虑方向。
第一类问题:可以考虑配置变更或者资源提供者发生了故障,比如存储电池故障会导致cache失效。
第二类问题:期望的性能异变,可以从降低业务运行特征的数量(LIO和PIO)来考虑问题,使其回到突变点之下,并重新建立吞吐量突变曲线。这种变异基本可以考虑以下三个不同原因。
1)业务量发生变化。
2)数据规模发生变化。
3)访问的终端数量发生变化。
第三类问题:基本可以考虑两个原因。
1)原有业务的访问特征发生变化,比如SQL语句的执行计划发生变化。
2)有新的业务加入。
从以上分析可以看出,与TBA方法论的缺乏落地能力总是会导入OWI方法不同,UOWTBA优化方法论比较容易使用,很容易就可以获得系统出现性能问题的根本原因,从而进行高效率的性能优化工作。
UOWTBA优化方法论是本书介绍的核心工作方法之一,后面章节会引入更多的输入吞吐量压力描述,并且把UOWTBA优化工作方法全面作用在流程、资源和组件之中。

相关文章
|
20天前
|
Oracle 关系型数据库 Linux
【赵渝强老师】Oracle数据库配置助手:DBCA
Oracle数据库配置助手(DBCA)是用于创建和配置Oracle数据库的工具,支持图形界面和静默执行模式。本文介绍了使用DBCA在Linux环境下创建数据库的完整步骤,包括选择数据库操作类型、配置存储与网络选项、设置管理密码等,并提供了界面截图与视频讲解,帮助用户快速掌握数据库创建流程。
201 93
|
3月前
|
存储 Oracle 关系型数据库
服务器数据恢复—光纤存储上oracle数据库数据恢复案例
一台光纤服务器存储上有16块FC硬盘,上层部署了Oracle数据库。服务器存储前面板2个硬盘指示灯显示异常,存储映射到linux操作系统上的卷挂载不上,业务中断。 通过storage manager查看存储状态,发现逻辑卷状态失败。再查看物理磁盘状态,发现其中一块盘报告“警告”,硬盘指示灯显示异常的2块盘报告“失败”。 将当前存储的完整日志状态备份下来,解析备份出来的存储日志并获得了关于逻辑卷结构的部分信息。
|
1月前
|
SQL Oracle 关系型数据库
Oracle数据库创建表空间和索引的SQL语法示例
以上SQL语法提供了一种标准方式去组织Oracle数据库内部结构,并且通过合理使用可以显著改善查询速度及整体性能。需要注意,在实际应用过程当中应该根据具体业务需求、系统资源状况以及预期目标去合理规划并调整参数设置以达到最佳效果。
105 8
|
6月前
|
存储 缓存 数据库
数据库数据删除策略:硬删除vs软删除的最佳实践指南
在项目开发中,“删除”操作常见但方式多样,主要分为硬删除与软删除。硬删除直接从数据库移除数据,操作简单、高效,但不可恢复;适用于临时或敏感数据。软删除通过标记字段保留数据,支持恢复和审计,但增加查询复杂度与数据量;适合需追踪历史或可恢复的场景。两者各有优劣,实际开发中常结合使用以满足不同需求。
436 4
|
3月前
|
SQL Oracle 关系型数据库
比较MySQL和Oracle数据库系统,特别是在进行分页查询的方法上的不同
两者的性能差异将取决于数据量大小、索引优化、查询设计以及具体版本的数据库服务器。考虑硬件资源、数据库设计和具体需求对于实现优化的分页查询至关重要。开发者和数据库管理员需要根据自身使用的具体数据库系统版本和环境,选择最合适的分页机制,并进行必要的性能调优来满足应用需求。
132 11
|
4月前
|
存储 Oracle 关系型数据库
Oracle存储过程插入临时表优化与慢查询解决方法
优化是一个循序渐进的过程,就像雕刻一座雕像,需要不断地打磨和细化。所以,耐心一点,一步步试验这些方法,最终你将看到那个让你的临时表插入操作如同行云流水、快如闪电的美丽时刻。
203 14
|
3月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—服务器异常断电导致Oracle数据库报错的数据恢复案例
Oracle数据库故障: 某公司一台服务器上部署Oracle数据库。服务器意外断电导致数据库报错,报错内容为“system01.dbf需要更多的恢复来保持一致性”。该Oracle数据库没有备份,仅有一些断断续续的归档日志。 Oracle数据库恢复流程: 1、检测数据库故障情况; 2、尝试挂起并修复数据库; 3、解析数据库文件; 4、导出并验证恢复的数据库文件。
|
3月前
|
存储 Oracle 关系型数据库
【赵渝强老师】Oracle RMAN的目录数据库
Oracle RMAN默认将备份元信息存储在控制文件中,但控制文件损坏或丢失会导致恢复失败,且备份增多会使控制文件无限增长。为解决这些问题,Oracle引入了RMAN目录数据库(Catalog Database),专门用于存储RMAN备份的元信息。使用目录数据库可提升备份管理效率,支持多数据库共享、长期备份历史记录存储,并可保存RMAN脚本。本文详细介绍了如何创建目录数据库、注册目标数据库及其操作步骤。
|
6月前
|
Oracle 安全 关系型数据库
【Oracle】使用Navicat Premium连接Oracle数据库两种方法
以上就是两种使用Navicat Premium连接Oracle数据库的方法介绍,希望对你有所帮助!
1191 28
|
4月前
|
存储 Oracle 关系型数据库
oracle数据恢复—oracle数据库执行错误truncate命令的数据恢复案例
oracle数据库误执行truncate命令导致数据丢失是一种常见情况。通常情况下,oracle数据库误操作删除数据只需要通过备份恢复数据即可。也会碰到一些特殊情况,例如数据库备份无法使用或者还原报错等。下面和大家分享一例oracle数据库误执行truncate命令导致数据丢失的数据库数据恢复过程。

热门文章

最新文章

推荐镜像

更多