知识大全复杂应用环境监控ORACLE数据库性能

Posted 2022-07-16 时间

篇首语：究竟什么是真理？——不可驳倒的谬误便是。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全复杂应用环境监控ORACLE数据库性能相关的知识，希望对你有一定的参考价值。

复杂应用环境监控ORACLE数据库性能 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　前言:　　　　　　在单一的应用环境或业务相对简单的系统下系统性能问题瓶颈所在往往是不言自明解决问题的前提定位问题是比较容易解决的但在一个复杂的应用环境下各应用系统对系统资源往往是一种共享和竞争的关系而且应用系统之间也可能存在着共生或制约的关系资源利益的均衡往往是此消彼长而这种环境下的应用系统一旦出现资源竞争系统的瓶颈往往难以断定甚至会发生不同应用设计人员之间互相推诿责任的扯皮现象本文仅就此问题对Linux平台下各应用系统对ORACLE数据库的使用情况作一探讨 ORACLE数据库的TUNING不是一个可以一言以蔽的主题本文无意概全内容仅涉及问题的定位及各应用对数据库资源的共享与竞争问题　　　　本文试验及问题取证的环境:　　　　RedHat Web server(Apache +PHP )+Client/Server(Pro*C)之Server端　　　　RedHat + Oracle 　　　　RedHat Web server(Apache +PHP ) + Oracle 　　　　　　为方便问题的讨论应用系统已做简化竞争方仅包括一个Pro*C的daemon程序作为C/S模式的服务端和由Apache+PHP所支持的WEB网站业务　　　　单个SQL语句的处理　　　　　　首先最简单的情况莫过于单个SQL语句的分析 SQL语句的优化也是数据库优化的一个最直接最立竿见影的因素 SQL语句的性能监控从监控工具来说大致可分为由高级语言提供和由ORACLE本身提供高级语言以典型的应用C 语言和WEB开发语言PHP为例 C语言中可以用gettimeofday函数来在某一数据库操作之前和之后分别获取一个时间值将两个时间值之差做为衡量该数据库操作的效率在PHP中也可以用gettimeofday 操作方法当然与C语言中有所不同当然 PHP中也有其它一些函数可以达到同样的时间精度关于时间精度的考虑不能简单以大小衡量微秒级的时间数值因为时钟中断的时间间隔从根本上决定了时间计算所能达到的精度此外操作系统本身对进程的时间片分配及进程切换的开销等因素也在一定程度上影响时间数据的意义所以以下时间的计算最理想的情况是对同一操作在尽可能避免缓存的情况下进行多次的循环操作取总的时间值加以平均从而得到比较接近真实情况的时间值　　　　C语言的例子:　　　　　　==========================================================　　#define TV_START 　　#define TV_END 　　int how_long(int cmd char *res);　　struct CMD_TIME　　int times;　　/* times occured within specified package number */　　struct timeval time;　　/* total time consumed by the cmd */　　;　　void foo()　　　　int id;　　how_long(TV_START NULL);　　EXEC SQL WHENEVER SQLERROR CONTINUE;　　EXEC SQL WHENEVER NOT FOUND CONTINUE;　　EXEC SQL select user_id into :id from users where name= slimzhao ; ;　　how_long(TV_END time_consume);　　puts(time_consume);　　　　int how_long(int cmd char *res)　　/* return value: error sucess res: bytes is enough */　　　　static struct timeval before after;　　if(cmd == TV_START) 　　gettimeofday(&before NULL);　　return ;　　 else if(cmd == TV_END) 　　gettimeofday(&after NULL);　　if(res) 　　if(after tv_usec > before tv_usec) 　　sprintf(res %ld %ld after tv_sec before tv_sec 　　after tv_usec before tv_usec);　　 else 　　sprintf(res %ld %ld 　　after tv_sec before tv_sec 　　 + after tv_usec before tv_usec);　　　　　　return ;　　 else 　　return ;　　　　　　==========================================================　　　　下面是一个PHP的例子(为简化起见程序的错误检查被忽略)　　　　==========================================================　　include /how_long inc ;　　how_long(TV_START $timestr);　　$conn = OCILogon( username password dblink );　　$stmt = OCIParse($conn select ID from users where name= slimzhao );　　OCIDefineByName($stmt ID $id);　　OCIExecute($stmt);　　OCIFetch($stmt);　　OCIFreeStatement($stmt);　　OCILogoff($conn);　　how_long(TV_END $timestr);　　echo 用户ID: $id 该操作消耗时间:$timestr　　 ;　　?>　　其中how_long函数的PHP版本如下:　　#作者: 　　#当前维护人: 　　#创建日期: : : 　　#目的在一个操作之前或之后调用该函数的不同版本将得到一个记载了该操作　　#耗费时间的字符串该函数本身的开销不计入其中　　define( TV_START );　　define( TV_END );　　function how_long($operation &$str)　　#返回值: 成功传递了非法的参数　　　　global $before_SQL $after_SQL;　　if($operation == TV_START) 　　$before_SQL = gettimeofday();　　return ;　　 else if($operation == TV_END) 　　$after_SQL = gettimeofday();　　if($before_SQL[ usec ] > $after_SQL[ usec ]) 　　$str = ($after_SQL[ sec ] $before_SQL[ sec ] ) 秒　　($after_SQL[ usec ] + * $before_SQL[ usec ]) 微秒 ;　　 else 　　$str = ($after_SQL[ sec ] $before_SQL[ sec ]) 秒　　($after_SQL[ usec ] $before_SQL[ usec ]) 微秒 ;　　　　 else 　　return ;　　　　　　?>　　==========================================================　　　　　　上面的数据库操作开销的计算仅限于对时间消耗的计算对同时使用同一数据库的其它应用软件的影响对磁盘操作的频繁程度数据库操作所采取的具体策略等等因素都未考虑在内高级语言也不可能提供这样的参考数据而数据库本身提供的监测手段弥补了这一不足最简单的操作控制台:sqlplus　　　　SQL> set timing on　　　　将为每次执行的数据库操作进行计时精度为 / 秒笔者对该功能的使用中发现其时间的计算也有一定的偏差而且时间偏差很大严格说来已不属于误差的范围该归错误了下面是一个例子中得到的数据:　　　　　　[bash$] cat tmp sql　　set timing on　　host date;　　select count(*) from users;　　host date;　　SQL> @tmp sql　　Wed Dec : : CST 　　　　COUNT(*)　　　　　　Elapsed: : : 　　Wed Dec : : CST 　　　　从系统的时间差来看为秒左右但ORACLE却报告了秒! 　　如果说ORACLE工具在时间计算上太差强人意的话在SQL语句的执行方案上可算是对SQL语句如何执行的最权威的诠释了解读这样的信息需要对ORACLE内部对SQL 操作的过程有一定了解下面是该功能的一样典型示例: 　　　　SQL> set autotrace on　　SQL> select count(*) from users;　　COUNT(*)　　　　　　Execution Plan　　　　 SELECT STATEMENT Optimizer=CHOOSE (Cost= Card= )　　 SORT (AGGREGATE)　　 INDEX (FAST FULL SCAN) OF USER_BASEINFO$NAME (UNIQUE)　　(Cost= Card= )　　Statistics　　　　 recursive calls　　 db block gets　　 consistent gets　　 physical reads　　 redo size　　 bytes sent via SQL*Net to client　　 bytes received via SQL*Net from client　　 SQL*Net roundtrips to/from client　　 sorts (memory)　　 sorts (disk)　　 rows processed　　　　　　Execution Plan下的信息显示ORACLE制定了一个什么样的计划来完成SQL操作的 SQL语言是一种 GL语言其特点是告诉系统做什么而不提供如何做的信息当然最终的具体工作总得有人做的只是由数据库自动制定而不是程序员人为指定一个具体的操作步骤制作这个步骤当然要有所依据 ORACLE有两个基本原则来决定如何优化: cost based(基于开销的优化)和rule based(基于规则的优化) 基于开销的优化的工作方式依赖于数据库对SQL语句所操作的数据对象(可简单认为就是表)的数据特征的统计特性进行收集和分析收集分析的工作由DBA来定期执行时间间隔依数据变化频率而定以保持统计数据一定的准确性具体操作请参照 analyze 语句 Oracle准备在将来的版本中取消对基于开销的优化方案的支持因为这种方案需要大量的数据收集与分析工作且总会有一定的误差这造成最终的执行方案往往不是最优的　　　　基于规则的优化则是依据一些数据操作效率的规则进行选择优化的核心在于效率时间上尽可能短空间上尽可能少进行IO 操作两种优化方案都绝非十全十美 ORACLE虽将其称为优化方案笔者的观察结果表明 ORACLE制定出一个不是最优或错误的执行方案也是完全可能的以上为例 Oracle的优化策略 cha138/Article/program/Oracle/201311/16785

知识大全 复杂应用环境监控ORACLE数据库性能

知识大全复杂应用环境监控ORACLE数据库性能