一次数据库硬解析的分析全过程

最新推荐文章于 2024-04-26 07:38:25 发布
最新推荐文章于 2024-04-26 07:38:25 发布
阅读量442 收藏
点赞数
文章标签： 数据库
ps:其实这个case很常见，而且在正规的开发流程之下也不会出现这种情况，更不会出现在上线之后，这篇文章主要是体现一个发现问题和分析问题解决问题的思路。希望对大家能有多帮助。

说明：

经过开发方面的努力，以及对问题sql的优化之后，截止目前，之前发现的问题sql已经得到了缓解。之后，我们对数据库2个节点进行了整体分析，目前得出以下问题。

依据材料：2个节点的awr报告，见附件


经过对数据库2个节点的整体分析，发现2个节点的资源承载相差较大。以下为2个节点的对比:

 

负载情况比对

节点1


Per SecondPer Transaction
Redo size: 289,642.11 2,459.01
Logical reads: 20,588.01 174.79
Block changes: 1,452.02 12.33
Physical reads: 7.15 0.06
Physical writes: 47.59 0.40
User calls: 730.83 6.20
Parses: 268.36 2.28
Hard parses: 2.26 0.02
Sorts: 211.82 1.80
Logons: 0.51 0.00
Executes: 471.03 4.00
Transactions: 117.79 

节点2


Per SecondPer Transaction
Redo size: 115,937.47 4,102.67
Logical reads: 40,494.67 1,432.98
Block changes: 334.81 11.85
Physical reads: 19.53 0.69
Physical writes: 18.26 0.65
User calls: 4,874.41 172.49
Parses: 1,242.13 43.96
Hard parses: 2.03 0.07
Sorts: 203.80 7.21
Logons: 0.66 0.02
Executes: 4,298.22 152.10
Transactions: 28.26 

 

说明：

无论从redosize还是transactions明显可以看出节点1比节点2忙碌，虽然2个节点的hard parses相差貌似不是很大，但是从其executes数以及parses分析，初步断定是节点1的大量硬解析导致的。

 

实例效率比对

节点1

Buffer Nowait %: 99.94Redo NoWait %: 100.00
Buffer Hit %: 99.97In-memory Sort %: 100.00
Library Hit %: 57.85Soft Parse %: 99.16
Execute to Parse %: 43.03Latch Hit %: 99.94
Parse CPU to Parse Elapsd %: 20.39% Non-Parse CPU: 98.76

节点2

Buffer Nowait %: 100.00Redo NoWait %: 100.00
Buffer Hit %: 99.95In-memory Sort %: 100.00
Library Hit %: 99.92Soft Parse %: 99.84
Execute to Parse %: 71.10Latch Hit %: 99.96
Parse CPU to Parse Elapsd %: 2.62% Non-Parse CPU: 98.64

 

说明：

通过library hit%和parse cpu to parse elapsd%来看，基本能够确定是节点1的大量硬解析导致的。

 

经过以上分析，我们在sql统计中，节点1如下所示：

（注：SQL ordered by Elapsed Time）

Elapsed Time (s)CPU Time (s)Executions Elap per Exec (s) % Total DB Time SQL IdSQL ModuleSQL Text
8,866718865.6120.414y67m1n5ru9h9 timeTask@xjitnmapp2 (TNS V1-V3) begin PKP_XJ_BUSI_MONITOR_UPD...
2,017011183.324.64at30z235zpx7a timeTask@xjitnmapp2 (TNS V1-V3) begin xj_db_inas_proc; end;
1,3551,3120 3.12ax33m7btymb2r PL/SQL Developer begin PKP_XJ_CSD_TEST.agent_pe...
1,189365716,5550.002.74765mqyxhskk9d ValveMgmt@xjitnmapp2 (TNS V1-V3) insert into ne_perf_msg (ne_pe...
1,049010104.902.41cyyyswcsmvfqx timeTask@xjitnmapp2 (TNS V1-V3) SELECT COUNT(1), 'IOM-N' FROM ...
1,022398716,6290.002.359qfdgm3c702rs ValveMgmt@xjitnmapp2 (TNS V1-V3) begin Proc_NE_Perf_Msg_UpdateR...
94001094.002.16dzt58v2bnamc4 timeTask@xjitnmapp2 (TNS V1-V3) SELECT COUNT(1), 'T' FROM INAS...
9239352438.452.124uxbs8fhb6yv5 timeTask@xjitnmapp2 (TNS V1-V3) begin pkp_maint_job.hastenNot...
9239352438.452.12g2zqp9kt9fhhx timeTask@xjitnmapp2 (TNS V1-V3) SELECT A.JOB_NAME, B.DUTY_ID, ...
91692932,7170.032.11657k3nvp6d77r timeTask@xjitnmapp2 (TNS V1-V3) SELECT COUNT(*) FROM (SELECT :...
914293716,6270.002.10607t3jmh1rjgy ValveMgmt@xjitnmapp2 (TNS V1-V3) UPDATE NE_PERF_MSG_REAL SET PE...
51701517.191.193v8usax04tqx6 timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
51701516.511.19f3d7w5j1khh59 timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
49001490.141.132aw24jjhsbz1z timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
48201482.151.11frgk27g6p6auh timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
48201481.851.112mjp53agwxb10 timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
47901479.351.104ha87wy9k784t timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
47901478.681.10c8utt9uwda7mv timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
46601466.071.07g2s1s0vubjuba timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
46601465.991.0757pq01hujfa6d timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
46401463.931.074z5gn1sh2h3p9 timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
46301463.241.073xtjfvgq9hw3u timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
45401453.651.04cyc352n70sndr timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
44701447.391.036dz4h3cpngvfk timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
44501445.121.023maa9dy6ybfq0 timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
44501444.961.025pabqbfux2bdd timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
44301443.121.02cu3f3fwntq6q5 timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
44101440.931.025v6z9vx2anap4 timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
43801437.931.013skc5wbqaa13d timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...
43701437.221.01ffzq6ucvadp5n timeTask@xjitnmapp2 (TNS V1-V3) SELECT /*+parallel(t, 12)*/t.s...

说明：在上图（节点1）中发现，有大量的以下语句出现：

SELECT /*+parallel(t, 12)*/t.s…..

具体分析后，这种情况在节点2中不存在。

对上边的大量相同的sql具体分析如下：

SELECT /*+parallel(t, 12)*/

 t.source_id,

 t.start_date,

 SUM(t.num_cdrs),

 SUM(t.settlement_duration),

 SUM(t.sett_fee)

  FROM (SELECT d.source_id,

               substr(d.start_date, 1, 8) start_date,

               d.num_cdrs,

               d.settlement_duration,

               d.sett_fee

          FROM zhjs_app.tl_y_voice_sett_201208@xjzhjs d,

               (SELECT element_id

                  FROM zhjs_param.tp_relation_element@xjzhjs

                 WHERE rpt_code = '15'

                   AND tnode IN

                       ('415102', '415105', '415108', '416103', '416106')) c

         WHERE d.account_item = c.element_id

        UNION ALL

        SELECT d.source_id,

               substr(d.start_date, 1, 8) start_date,

               d.num_cdrs,

               d.settlement_duration,

               d.sett_fee

          FROM zhjs_app.tl_y_voice_sett_201209@xjzhjs d,

               (SELECT element_id

                  FROM zhjs_param.tp_relation_element@xjzhjs

                 WHERE rpt_code = '15'

                   AND tnode IN

                       ('415102', '415105', '415108', '416103', '416106')) c

         WHERE d.account_item = c.element_id) t

 GROUP BY t.source_id, t.start_date;

 

说明：

在节点1，存在这样大量的sql，其中除了在in 子句中的对象个数不同外，其他基本全部一致。这也是导致节点1大量硬解析，消耗主机资源，拖低节点1各种性能指标的原因。

 

建议：

对以上语句进行绑定变量处理。

 

总结：

这次对XXXX数据库性能的监控主要从其整体结构来进行分析的，并不是将全部精力放在盯某个或者某类sql上，我们认为这样可以避免瞎子摸象的问题产生，至于最后还是落在具体sql上，这个只是一种分析的结果，而非以往的一种惯性“有性能问题就找sql”这样的分析过程。

         最后，希望在和开发等同事的一起努力下，XXXX性能有所大的提高。

ps:很不习惯写文档，而且还那种给人家找事的文档，基本形成了格式，首先肯定人家前期的努力和结果，其次不但提出自己的见解，还得表明自己的分析依据和分析过程，完了再加以一定的鼓励和前瞻性。哎..真劳神，其实也就一句话的事儿..

Normal 0 false 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

转载于:http://blog.itpub.net/26143577/viewspace-745046/

cuiqu7295
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
mysql硬解析_MySQL笔记
weixin_26711801的博客
02-19 483
MySQL使用原则：自己扛住的自己扛，扛不住的使用中间件，比如：Redis；最佳的单表存储量是千万级别，超过这个级别采取分表分布的方式来存储表。MySQL体系架构MySQL语句在数据库的执行过程：经过parser进行词法解析和语法解析；解析之后经过优化器生成执行计划，MySQL不缓存执行计划(也叫做硬解析)；执行计划进入执行器执行，到存储引擎中找数据；返回数据。MySQL包括核心层(mysqld)...
二次解析源码(全开源)
09-08
1. **二次解析**：二次解析，也称为内容抓取或数据提取，是指从一个网站抓取信息并将其转换为另一种格式，通常是为了在不同的平台上展示或分析。这可能涉及到HTML、XML、JSON等格式的数据。二次解析常用于聚合新闻、...
数据库 硬解析
tiankongtiankong01的博客
06-04 1481
在执行和获取结果前，数据库系统对此sql将进行几个步骤的处理过程：  1、语法检查(syntax check)  检查此sql的拼写是否语法。  2、语义检查(semantic check)  诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。  3、对sql语句进行解析(prase)  利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(exe
Oracle数据库的硬解析（Hard Parse）
专注于数据库技术分享，包含但不限于Oracle，MySQL，PostgreSQL，ElasticSearch及国产数据库等
04-26 763
Oracle数据库的硬解析（Hard Parse）是SQL执行过程中的一个重要环节，涉及到对SQL语句的完整解析、编译和生成执行计划的过程。硬解析在数据库性能优化中扮演着重要角色，因为它相对软解析来说更为耗时且资源密集。
SQL语句解析类型---硬解析和软解析
远有青山
11-30 9980
Oracle的硬解析和软解析 提到软解析(soft prase)和硬解析(hard prase)，就不能不说一下Oracle对sql的处理过程。当你发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程： 1、语法检查(syntax check) 检查此sql的拼写是否语法。 2、语义检查(semantic check
mysql硬解析与软解析_详解Oracle数据库硬解析、软解析、软软解析联系与区别
weixin_33672838的博客
01-25 186
Oracle数据库硬解析和软解析有相同的一步，而软软解析与硬解析、软解析完全不一样。一、sql解析这里我们先简单sql语句执行步骤：语法检查(syntax check)语义检查(symantic check): 对象是否存在，是否有权限。sql解析(parse): 利用内部算法对sql进行解析，生成解析树及执行计划。执行sql，返回结果(execute and return)首先了解一下sql解析...
mysql硬解析与软解析_oracle 硬解析&软解析
weixin_31064353的博客
01-28 140
解析步骤:1.检查语法2.检查sql语句涉及object是否存在,不存在则推出，检查需要数据字典 加载row cache3.转换对象名,(例如翻译synonym 或实际名 test=xh.test)，有 问题退出parse4.检查发出sql的 user是否有对应权限，权限不足退出parse5.根据object的 统计信息optimizer会建立一个 执行计划6.将产生的执行计划装入shared p...
数据库概论ppt课程全解析
08-08
本课程的全解析通过PPT的形式，旨在帮助学习者深入理解和掌握数据库的核心知识。以下是对各章节内容的详细阐述： **第1章 数据库概述** 在这一章，我们将了解到数据库的基本定义，它是如何存储、管理和检索数据的...
时光机的秘密：Oracle数据库闪回技术全解析
最新发布
06-26
Oracle是一个大型关系数据库管理系统（RDBMS），由Oracle公司（之前称为Oracle Corporation，现在称为甲骨文公司）开发和提供。Oracle数据库是企业级解决方案，广泛应用于大型和中型企业中，因其强大的性能、可靠性...
数据可视化分析平台源码+数据库
08-27
总的来说，这个数据可视化分析平台源码提供了全面的数据管理工具，涵盖了从数据接入到分析展示的全过程。结合数据库的使用，用户可以构建个性化的数据分析环境，提升数据分析的效率和深度。对于IT专业人士而言，掌握...
Python 开发音乐播放(爬虫+可视化+数据分析+数据库)全套项目文件
10-30
在本项目中，"Python 开发音乐播放(爬虫+可视化+数据分析+数据库)全套项目文件"涵盖了四个关键领域：Python爬虫、数据可视化、数据分析以及数据库管理。这些技术是现代数据驱动应用开发的核心组成部分，下面将分别...
硬解析和软解析 mysql_SQL语句解析类型---硬解析和软解析
weixin_36026999的博客
01-19 224
一、Shared pool 作用：缓存SQL语句及SQL语句的执行计划SQL语句执行三步：解析(parse)------执行(exec)------获取数据(fetch)shared pool的组成：3块区域：free、librarycache、row cache(dictionary cache)library cache：缓存SQL语句以及SQL语句的执行计划dictionary cache：...
mysql 硬解析与软解析_SQL语句解析类型---硬解析和软解析
weixin_39929259的博客
02-02 219
一、Shared pool 作用：缓存SQL语句及SQL语句的执行计划SQL语句执行三步：解析(parse)------执行(exec)------获取数据(fetc一、Shared pool 作用：缓存SQL语句及SQL语句的执行计划SQL语句执行三步：解析(parse)------执行(exec)------获取数据(fetch)shared pool的组成：3块区域：free、library...
硬解析和软解析 mysql_Oracle硬解析和软解析的区别分析
weixin_30227789的博客
02-05 231
一、摘要Oracle硬解析和软解析是我们经常遇到的问题，所以需要考虑何时产生软解析何时产生硬解析，如何判断SQL的执行过程当发布一条SQL或PL/SQL命令时，Oracle会自动寻找该命令是否存在于共享池中来决定对当前的语句使用硬解析或软解析。通常情况下，SQL语句的执行过程如下：Step1. SQL代码的语法(语法的正确性)及语义检查(对象的存在性与权限)。Step2. 将SQL代码的文本进行哈...
Oracle 硬解析与软解析
anjichan4261的博客
02-19 389
--======================= -- Oracle 硬解析与软解析 --======================= Oracle 硬解析与软解析是我们经常遇到的问题，什么情况会产生硬解析，什么情况产生软解析，又当如何避免硬解析？下面的描述将给出 软硬解析的产生，以及硬解析的弊端和如何避免硬解析的产生。 一、SQL语句的执行过程 ...
Oracle数据库中的硬解析和软解析简介
weixin_34064653的博客
09-06 263
提到软解析(soft prase)和硬解析(hard prase)，就不能不说一下Oracle对sql的处理过程。当你发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程： 1、语法检查(syntax check) 检查此sql的拼写是否语法。 2、语义检查(semantic check) 诸如检查sql语句中...
查看硬解析次数
iteye_14759的博客
09-30 1135
TOM大叔的调优书中说过一句话，具体英文就忘了，大概意思就是：如果有人让我写本怎样让ORACLE性能最慢的书的话我会将取消绑定变量(bind variable)做为书的第一章和最后一章(他的意思是他很有幽默~~!)，可见绑定变量的重要性。绑定变量大多用在OLTP(online transaction process)中，在OLAP(online analizy process)中就没必要用BI...
【Oracle】硬解析、软解析和软软解析
As before 如初
08-12 3474
前言   在Oracle中，每条SQL语句在执行之前都需要经过解析（Parse），根据解析的过程可以分为3种类型：硬解析（Hard Parse）、软解析（Soft Parse）和软软解析（Soft Soft Parse），软软解析也叫快速解析（Fast Parse）。DDL语句每次执行都需要进行硬解析，DML语句和SELECT语句会根据情况选择是进行硬解析，还是进行软解析或者进行软软解析。 判断硬解析和软解析的依据在于sga中的 share cursor 的缓存情况 判断软解析和软软解析的依据在于pga

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值