一般来说,调优的第一手资料,很可能就是典型业务期的一个statspack报告,那么如何根据statspack报告来判断是哪些SQL消耗了最多的系统资源?哪些SQL是最需要调整的呢?这里给出了一个大致的优化思路。当然,思路是死的,人是活的,优化也需要随需应变。
一般来说,需要关注下面四种Top SQL
消耗最多CPU的(逻辑IO过多)
导致过多物理I/O的
执行次数较频繁的
执行时间较长的
我们知道,一个语句的响应时间有个很著名的公式:
响应时间=服务时间+等待时间
其中服务时间就是CPU为执行该语句花费的时间。
服务时间=分析时间+递归时间+执行时间
分析时间是CPU用于分析语句的时间,递归时间是CPU用于语句的递归SQL的时间,剩下的则就是CPU用于执行语句的真正时间了。
那么,上面的这些时间信息从哪里来的?Oracle提供的系统统计信息中就有部分的时间统计信息:
服务时间=CPU used by this session
分析时间=parse time cpu
递归时间=recursive cpu usage
那么,执行时间就可以根据上面三个统计信息计算得出:
执行时间=CPU used by this session – parse time cpu – recursive cpu usage
如果执行时间在整个响应时间中占较大的比例,那么下一步就是找出那些造成了最多逻辑IO的SQL语句,可以从statspack报告的SQL ordered by Gets部分找到。
如果分析时间在整个响应时间中占较大的比例,那么下一步就是查找哪些SQL分析过多,这在statspack报告中在SQL ordered by Parse Calls中列出。
如果等待时间在整个响应时间中占较大的比例,并且主要是块读取相关的等待时,下一步就是找出哪些SQL造成了过多的物理读,可以查看statspack报告中的SQL ordered by Reads部分。
那么,根据上面列出的一个简单的原则,我们需要关注三个关于CPU时间的统计信息: CPU used by this session, parse time cpu和recursive cpu usage,以及top5等待事件中和IO相关的等待时间。如果是其他的一些等待事件出现在Top5中,那么可能需要根据不同的等待事件来分析原因了。然后优先调优时间消耗最多的相关SQL。
除了上面的SQL ordered by Gets(逻辑IO最多),SQL ordered by Parse Calls(软解析过多),SQL ordered by Reads(物理IO过多),statspack还按照其他的一些方式列出了Top SQL,这些Top SQL在某些情况下都是需要给予特别关注的。比如:
SQL ordered by Executions 执行次数超过100的
SQL ordered by Sharable Memory 占用library cache超过1M的
SQL ordered by Version Count 子cursor超过20的
如果没有statspack,那么根据v$sysstat/v$sesstat中的统计信息,结合v$sql/v$sqlarea,一样可以得到相关的SQL。
v$sql对于每一个子cursor都有一行统计记录,而v$sqlarea则对同一个父cursor只有一行统计记录,也就是v$sqlarea是对v$sql按照父cursor进行group by后的一个结果。这两个视图中都有诸如buffer_gets,parse_calls,disk_reads,,executions,sharable_mem等列,和上面提到的statspack中列出Top SQL的条件对应。
标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,670)
- DB2 (22)
- MySQL (73)
- Oracle (1,532)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (65)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (560)
- Oracle安装升级 (91)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (78)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
- ORA-01092 ORA-00604 ORA-01558故障处理
- ORA-65088: database open should be retried
- Oracle 19c异常恢复—ORA-01209/ORA-65088
- ORA-600 16703故障再现
- 数据库启动报ORA-27102 OSD-00026 O/S-Error: (OS 1455)
- .[metro777@cock.li].Elbie勒索病毒加密数据库恢复
- 应用连接错误,初始化mysql数据库恢复
- RAC默认服务配置优先节点
- Oracle 19c RAC 替换私网操作
- 监听报TNS-12541 TNS-12560 TNS-00511错误
- drop tablespace xxx including contents恢复
- Linux 8 修改网卡名称