热门标签 | HotTags
当前位置:  开发笔记 > 数据库 > 正文

oracle性能调优之-mysql教程

----共享池的调整与优化(SharedpoolTuning)--共享池(Sharedpool)是SGA中最关键的内存片段,共享池主要由库缓存(共享SQL区和PLSQL区)和数据字典缓存组成。

--======================================= --共享池的调整与优化(Sharedpool Tuning) --======================================= 共享池 ( Shared pool ) 是SGA中最关键的内存片段 , 共享池主要由库缓存 ( 共享SQL区和PL / SQL区 ) 和数据字典缓存组成。

--=======================================

-- 共享池的调整与优化(Sharedpool Tuning)

--=======================================

共享池(Shared pool)是SGA中最关键的内存片段,共享池主要由库缓存(共享SQL区和PL/SQL区)和数据字典缓存组成。其中库缓存的作用是存

放频繁使用的sqlpl/sql代码以及执行计划。数据字段缓存用于缓存数据字典。在内存空间有限的容量下,数据库系统根据一定的算法决定何

时释放共享池中的sqlpl/sql代码以及数据字典信息。下面逐一解释各个部件并给出调整方案。

一、共享池的组成

Library cache(库缓存) --存放SQL ,PL/SQL 代码,命令块,解析代码,执行计划

Data dictionary cache(数据字典缓存) --存放数据对象的数据字典信息

User global area(UGA) for sharedserver session --用于共享模式,可以将该模块移到laregpool来处理。专用模式不予考虑。

二、Library cache 作用与组成

Library Cache 由以下四个部件组成

Shared SQL areas

Private SQL areas

PL/SQL proceduresand packages

Various controlstructures

Library Cache 作用

存放用于共享的SQL命令或PL/SQL块

采用LRU算法(最近最少使用算法)

用于避免相同代码的再度解析

ORA-04031则表明共享池不够用

三、Data dictionary cache组成与作用

组成

Row cache

Library cache

作用

存储数据库中数据文件、表、索引、列、用户和其它数据对象的定义和权限信息

四、Shared pool的大小

Library cache与Data dictionarycache两者共同组成了shared pool的大小,由参数shared_pool_size来决定

查看:show parametershared_pool_size

修改:alter system set shared_pool_size=120m;

sys@ORCL> select * from v$version where rownum < 2;

BANNER

----------------------------------------------------------------

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

sys@ORCL> show parameter shared_pool_

NAME TYPE VALUE

----------------------------------------------- ------------------------------

shared_pool_reserved_size biginteger 3M

shared_pool_size biginteger 0 --为0,表明由系统自动分配

sys@ORCL> show parameter sga_

NAME TYPE VALUE

----------------------------------------------- ------------------------------

sga_max_size biginteger 176M

sga_target biginteger 176M --非零值,表示由系统自动调整sga

五、SGA_MAX_SIZESGA_TARGET

sga_max_size 决定了为Oracle分配内存的最大值

sga_target 决定了基于sga_max_size的大小来自动分配内存,sga_target <= sga_max_size

sga_target会为下列组件自动分配内存

Buffer cache

Shared pool

Larege pool

Jave pool

Streams pool

当设定sga_target参数为非零值,且又单独设定sga_target的五个组件为非零值,在这种情形下,这几个组件设定的值则为该组件所必须要

分配的最小值。

下列sga组件不受sga_target的管理和影响,即需要单独为以下几个组件分配大小

Log buffer(日志缓冲)

Other buffer caches,such as KEEP, RECYCLE, and other block sizes(保留池,回收池,nK 池)

Fixed SGA and otherinternal allocations

有关SGA的自动管理,更详细请参考:Oracle10g SGA 的自动化管理

六、Librarypool 共享SQL,PL/SQL 代码标准

当发布一条SQL或PL/SQL命令时,Oracle会自动寻找该命令是否存在于共享池中来决定对当前的语句使用硬解析或软解析。

SQL语句的执行过程如下:

a.SQL代码的语法(语法的正确性)及语义检查(对象的存在性与权限)

b.将SQL代码的文本进行哈希得到哈希值

c.如果共享池中存在相同的哈希值,则对这个命令进一步判断是否进行软解析,否则到e步骤。

d.对于存在相同哈希值的新命令行,其文本将与已存在的命令行的文本逐个进行比较。这些比较包括大小写,字符串是否一致,空格, 注释等,如果一致,则对其进行软解析,转到步骤f。否则到d步骤。

e.硬解析,生成执行计划。

f.执行SQL代码,返回结果。

有关硬解析与软解析请参考:Oracle 硬解析与软解析

七、共享池中闩的竞争

共享池中闩的竞争或Library cache闩的竞争表明存在下列情形

非共享的SQL需要硬解析

重新解析共享的SQL(由于Librarycache大小不足导致共享的SQL被LRU算法淘汰掉)

过多的负荷导致Librarycache 大小不足

八、v$librarycache视图

scott@ORCL > desc v$librarycache;

Name Null? Type

----------------------------- ----------------------

NAMESPACE VARCHAR2(15) --存储在库缓存中的对象类型,值为SQLarea,table/procedure,body,trigger

GETS NUMBER --显示请求库缓存中的条目的次数(或语句句柄数)

GETHITS NUMBER --显示被请求的条目存在于缓存中的次数(获得的句柄数)

GETHITRATIO NUMBER --前两者之比

PINS NUMBER --位于execution阶段,显示库缓存中条目被执行的次数

PINHITS NUMBER --位于execution阶段,显示条目已经在库缓存中之后被执行的次数

PINHITRATIO NUMBER --前两者之比

RELOADS NUMBER --显示条目因过时或无效时在库缓存中被重载的次数

INVALIDATIONS NUMBER --由于对象被修改导致所有参照该对象的执行计划无效的次数,需要被再次解析

DLM_LOCK_REQUESTS NUMBER

DLM_PIN_REQUESTS NUMBER

DLM_PIN_RELEASES NUMBER

DLM_INVALIDATION_REQUESTS NUMBER

DLM_INVALIDATIONS NUMBER

get表示请求条目或对象、获得对象句柄;

pin根据句柄找到实际对象并执行,但对象内容可能因为老化而pin不到所以出现reload;

一个session需要使用一个object时,如果是初次使用,则必然是先get然后pin并维护这个object的句柄。下次再使用这个object时,因为

已经维护该句柄,所以直接pin而没有了get过程。如果对象老化则移除共享池,再次请求则会出现reload。

有关Library cache的详细说明:V$LIBRARY

由上面所列出的字段可知,v$librarycache视图可以用来监控librarycache的活动情况。

重点关注字段

RELOADS列:表示对象被重新加载的次数,理论上该值应该接近于零。过大是由于对象无效或librarypool过小被换出。

INVALIDATIONS:列表示对象失效的次数,对象失效后,需要被再次解析。

GETHITRATIO:该列值过低,表明过多的对象被换出内存。

GETPINRATIO:该列值过低,表明会话没有多次执行相同的游标,即使对象被不同的会话共享或会话没有找到共享的游标。

下面查询v$librarycache的性能状况:

sys@ASMDB > select * from v$version where rownum < 2;

BANNER

----------------------------------------------------------------

Oracle9iEnterprise Edition Release 9.2.0.1.0 - 64bit Production

SELECT namespace,gets,gethits,ROUND(GETHITRATIO*100,2) gethit_ratio,pins,pinhits,

ROUND(PINHITRATIO*100,2) pinhit_ratio,reloads,invalidations FROM v$librarycache;

NAMESPACE GETS GETHITSGETHIT_RATIO PINS PINHITSPINHIT_RATIO RELOADS INVALIDATIONS

--------------- ---------- ---------------------- ---------- ---------- ------------ ---------- -------------

SQLAREA 336824947 326237186 96.861137146337 1113509653 97.92 1202492 38273

TABLE/PROCEDURE 15363106111536263944 10015914153431591166141 99.98 85574 0

BODY 144906 143990 99.37 144969 142474 98.28 128 0

TRIGGER 47765371 47765105 100 47765381 47765113 100 0 0

INDEX 1104164 1103706 99.96 1104133 1103467 99.94 0 0

CLUSTER 42341 42038 99.28 42860 42260 98.6 0 0

OBJECT 0 0 100 0 0 100 0 0

PIPE 0 0 100 0 0 100 0 0

JAVASOURCE 40 19 47.5 40 19 47.5 0 0

JAVARESOURCE 40 19 47.5 40 19 47.5 0 0

JAVADATA 116 71 61.21 237 147 62.03 0 0

分析上面的查询,在此仅仅分析SQL AREA对象,其余的类似分析

a.在SQL AREA中,执行的次数为次1137146337 (PINS 列)。

b.重载(RELOADS)的次数为1202492,表明一些对象无效或因librarycache过小被agedout,则这些对象被执行了重载。

c.无效的对象(INVALIDATIONS)为38273次。

d.基于查询的结果,可以用于判断shared_pool_size的reloads,invalidations的情况,是否调整share_pool_size请参考后面十,十一,十二点

九、数据字典缓存(data dictionary cache)

使用视图v$rowcache获取数据字典缓存的信息

该视图中包含字典对象的定义信息

gets: 请求对象的次数

getmisses:在data dictionarycache中请求对象失败的次数

调整目标:避免请求失败

也可根据statspack来调整data dictionary cache

通常情况下,应保证数据字典缓存命中率为95%或高于95%

--下面查询数据字典缓存的命中率与缺失率

SELECT ROUND(((1-SUM(getmisses)/(SUM(gets)+SUM(getmisses))))*100,3) "Hit Ratio"

,ROUND(SUM(getmisses)/sum(gets)*100,3) "Misses Ratio"

FROM v$rowcache

WHERE gets + getmisses <> 0;

HitRatio Misses Ratio

--------- ------------

99.865 .135

缺失率应当低于以下百分比

<2% 对于常用的数据字典对象

<15% 整个数据字典缓冲对象

整个数据字典的缺失率

SELECT ROUND((100*SUM(getmisses)/decode(SUM(gets),0,1,SUM(gets))),2) Getmiss_ratio

FROM v$rowcache;

GETMISS_RATIO

-------------

.14

不同的组件对象检查组件的缺失率及命中率的情况

SELECT parameter

,SUM(gets)

,SUM(getmisses)

,ROUND((100*SUM(getmisses)/decode(SUM(gets),0,1,SUM(gets))),2) Getmiss_ratio

,ROUND((100*SUM(gets-getmisses)/SUM(gets)),2) Hit_Ratio

,SUM(modifications) updates

FROM v$rowcache

WHERE gets>0

GROUP BY parameter

ORDER BY Getmiss_ratio DESC,Hit_Ratio DESC;

PARAMETER SUM(GETS) SUM(GETMISSES) GETMISS_RATIO HIT_RATIO UPDATES

------------------------------------------ -------------- ------------- ---------- ----------

dc_qmc_cache_entries 1 1 100 0 0

dc_constraints 54 31 57.41 42.59 54

dc_tablespace_quotas 976 198 20.29 79.71 976

dc_files 539 32 5.94 94.06 3

dc_global_oids 564058 2459 .44 99.56 0

dc_histogram_defs 185645793 223703 .12 99.88 0

dc_objects 73470326 30375 .04 99.96 2228

dc_segments 112544251 50126 .04 99.96 2198

dc_sequences 7814295 1453 .02 99.98 7814291

关于dc_qmc_cache_entries为100%还不清楚,请大家指正。

十、优化Library cache

总原则尽可能使代码解析最小化

确保用户尽可能使用共享的SQL执行计划

为Librarycache分配更多的空间以避免淘汰最老的代码与执行计划

避免无效的再度解析(如Librarycache已经存在某个对象的解析,而该对象结构发生了变化)

避免Library cache中过多的碎片

为Library cache使用保留空间

锁定一些频繁使用的对象到Librarycache中,以避免LRU算法淘汰掉

排除较大的PL/SQL匿名块或对其进行拆分

对于共享服务器模式可以分配largepool给UGA,避免对共享池的争用

十一、调整shared_pool_size

1.监控对象的重载情况

SELECT NAMESPACE,

GETS,

GETHITS,

round(GETHITRATIO * 100, 2) gethit_ratio,

PINS,

PINHITS,

round(PINHITRATIO * 100, 2) pinhit_ratio,

RELOADS,

INVALIDATIONS

FROM V$LIBRARYCACHE; --考虑是否存在过多的reloads和invalidations

2.当库缓存的重载率大于零,应考虑增大shared_pool_size

SELECT SUM(pins) "Executions",SUM(reloads) "CacheMisses while Executing",

ROUND(SUM(reloads)/SUM(pins)*100,2) AS "Reload Ratio, %" FROM V$LIBRARYCACHE;

ExecutionsCache Misses while Executing Reload Ratio, %

---------- -------------------------------------------

2777717625 1288253 .05

3.库缓存的命中率应保持在95%,否则应考虑增大shared_pool_size

SELECT SUM(pins) "Executions",SUM(reloads) "CacheMisses while Executing",

ROUND((SUM(pins)/(SUM(reloads)+SUM(pins)))*100,2)

"HitRatio, %" FROM V$LIBRARYCACHE;

ExecutionsCache Misses while Executing Hit Ratio, %

---------- ----------------------------------------

2777727542 1288257 99.95

4.估算Library cache占用大小,shared pool的可用空间,总大小

--查看共享池可用空间,当sharedpool有过多的可用空间,再调大shared pool则意义不大

SELECT pool,name,bytes/1024/1024 FROM v$sgastat WHERE name LIKE '%free memory%' AND pool = 'sharedpool';

POOL NAME BYTES/1024/1024

----------- -----------------------------------------

sharedpool freememory 97.6241302

--查询已使用的Library cache大小总和

WITH cte AS(

SELECT SUM(sharable_mem) sharable_mem_count --查询非SQL语句(包,视图)占用的Library cache大小

FROM v$db_object_cache

UNION ALL

SELECT SUM(sharable_mem) --查询SQL语句占用的Librarycache大小

FROM v$sqlarea

)

SELECT SUM(sharable_mem_count)/1024/1024 --查询已使用的Library cache大小总和

FROM cte; --实际上还有一部分为用户游标使用占用的空间,此处略去

SUM(SHARABLE_MEM_COUNT)/1024/1024

---------------------------------

820.59599971771

--查询分配的shared_pool_size的大小

SELECT SUM(bytes)/1024/1024 FROM v$sgastat WHERE pool LIKE '%shar%';

SUM(BYTES)/1024/1024

--------------------

1216

SELECT * FROM v$sgainfo WHERE name LIKE 'Shared%';

5.查看shared pool的分配大小,已使用空间,可用空间,已用空间的百分比

column shared_pool_used format 9,999.99

column shared_pool_size format 9,999.99

column shared_pool_avail format 9,999.99

column shared_pool_pct format 999.99

SELECT SUM(a.bytes) / (1024 * 1024) shared_pool_used,

MAX(b.value) / (1024 * 1024) shared_pool_size,

(MAX(b.value) - SUM(a.bytes)) / (1024 * 1024) shared_pool_avail,

(SUM(a.bytes) / MAX(b.value)) * 100 Shared_pool_per

FROM v$sgastat a, v$parameterb

WHERE a.name IN ('table definiti',

'dictionary cache',

'library cache',

'sql area',

'PL/SQL DIANA')

AND b.name = 'shared_pool_size';

SHARED_POOL_USEDSHARED_POOL_SIZE SHARED_POOL_AVAIL SHARED_POOL_PER

---------------- --------------------------------- ---------------

965.49 1,152.00 186.51 83.809699

6.根据上述的各个情况的判断,检查v$shared_pool_advice来判断增加shared_pool_size

SELECT shared_pool_size_for_estimate est_size,

shared_pool_size_factorsize_factor,

estd_lc_size,

estd_lc_memory_objectsobj_cnt,

estd_lc_time_saved_factorsav_factor

FROM v$shared_pool_advice;

EST_SIZESIZE_FACTOR ESTD_LC_SIZE OBJ_CNT SAV_FACTOR

--------- ----------- ---------------------- ----------

640 .5556 642 54947 1

768 .6667 769 80736 1

896 .7778 896 101860 1

1024 .8889 1023 135536 1

1152 1 1150 167927 1

1280 1.1111 1277 200423 1

1408 1.2222 1404 234144 1

1536 1.3333 1535 257042 1

1664 1.4444 1662 270800 1

1792 1.5556 1789 282202 1

1920 1.6667 1914 294138 1

2048 1.7778 2040 306570 1

2176 1.8889 2169 317104 1

2304 2 2299 327659 1

十二、共享池调优工具

1.几个重要的性能视图

v$sgastat

v$librarycache

v$sql

v$sqlarea

v$sqltext

v$db_object_cache

2.几个重要参数

shared_pool_size

open_cursors

session_cached_cursors

cursor_space_for_time

cursor_sharing

shared_pool_reserved_size

3.查询视图获得相关信息

--查询执行次数小于5的SQL语句

scott@ORCL> select sql_text from v$sqlarea

2 where executions < 5 order by upper(sql_text);

--查询解析的次数

scott@ORCL> select sql_text,parse_calls,executions from v$sqlarea order by parse_calls;

对于那些相同的SQL语句,但不存

推荐阅读
  • 本文探讨了MySQL性能优化的策略与实践方法,首先介绍了通过phpMyAdmin工具进行基础优化的简便途径。在数据库设计阶段,选择合适的存储引擎至关重要,如InnoDB支持事务处理,虽然查询速度略逊于MyISAM,但因其高可靠性和数据完整性,在现代应用中更为广泛采用。此外,文章还深入讨论了索引优化、查询优化及配置参数调整等高级技术,为提升MySQL数据库的整体性能提供了全面指导。 ... [详细]
  • 在《OWASP TOP 10 注入漏洞》中,详细探讨了注入攻击的发生机制:当应用程序未能有效识别和拦截恶意输入时,攻击者可以通过 SQL 注入等手段利用这一漏洞。本文将重点介绍 SQL 注入的基本原理及其防范措施,帮助读者全面了解并有效应对这一常见安全威胁。 ... [详细]
  • 程序连接MySQL数据库的多种方法详解 ... [详细]
  • 通过SQL Server的复制功能,可以实现高效的数据同步与更新。该技术允许在不同的数据库之间复制和分发数据及数据库对象,并确保这些数据保持一致性和实时性。SQL Server复制机制不仅支持单向数据传输,还支持双向同步,适用于多种应用场景,如分布式系统、灾难恢复和数据仓库更新等。 ... [详细]
  • 在现代Web开发中,Ajax技术扮演着至关重要的角色。当我们使用传统的请求库(如requests)抓取网页时,有时会发现返回的数据与浏览器中显示的内容存在差异。这是因为许多动态内容是通过Ajax异步加载的,而requests等工具无法模拟这种异步行为。了解Ajax的工作原理及其在Web开发中的应用,可以帮助开发者更有效地抓取和处理动态生成的数据。 ... [详细]
  • 本文将深入探讨Python的Tulip网络库(即3.4版本后更名为asyncio)的实现机制。通过详细解析Tulip的工作原理,旨在帮助读者理解其如何高效处理I/O阻塞问题,并展示其实现非阻塞流程的具体方法。 ... [详细]
  • 本文将深入探讨MySQL与MongoDB在游戏账户服务中的应用特点及优劣。通过对比这两种数据库的性能、扩展性和数据一致性,结合实际案例,帮助开发者更好地选择适合游戏账户服务的数据库方案。同时,文章还将介绍如何利用Erlang语言进行高效的游戏服务器开发,提升系统的稳定性和并发处理能力。 ... [详细]
  • MySQL 8.0 中的二进制日志格式详细解析及其官方文档参考。本文介绍了MySQL服务器如何使用不同的日志记录格式来记录二进制日志,包括早期版本中基于SQL语句的复制机制(即基于语句的日志记录)。此外,还探讨了其他日志记录方式,如基于行的日志记录和混合日志记录模式,并提供了配置和管理这些日志格式的最佳实践。 ... [详细]
  • Nginx入门指南:从零开始掌握基础配置与优化技巧
    Nginx入门指南:从零开始掌握基础配置与优化技巧 ... [详细]
  • 深入解析MySQL Replication中的并行复制机制与实例应用【MySQL进阶教程】
    本文深入探讨了MySQL 5.6版本后引入的并行复制机制,详细解析了其工作原理及优化效果。通过具体实例,展示了如何在实际环境中配置和使用并行复制,以提高数据同步效率和系统性能。 ... [详细]
  • 点击上方蓝色“程序猿DD”,选择“设为星标”回复“资源”获取独家整理的学习资料!来源|https:github.comwizardbyronprinci ... [详细]
  • 学术论文深度解析与评价
    本文深入探讨了基于摆线推进器的无人监测船系统的研发背景及其重要性。从环境保护的宏观视角出发,逐步聚焦至湖泊生态监测的具体需求,分析了现有生态监测技术的局限性,并提出了创新性的解决方案,旨在通过改进内部技术实现更高效、精准的生态环境监测。 ... [详细]
  • 在JSP页面中调用客户端本地应用程序(例如 `C:\netterm.exe`)时,可以通过使用 `Runtime.getRuntime().exec("c:\\netterm.exe")` 实现。然而,这种方法仅在服务器端有效,若要实现在客户端执行本地程序,需要采用其他技术手段,如Java Applet或ActiveX控件,以确保安全性和兼容性。 ... [详细]
  • 【IT168服务器学院】触发器是在数据库中特定事件发生时自动执行的代码段。与存储过程类似,但用户无法直接调用。其主要功能包括:1、限制对表的修改操作,确保数据完整性和一致性;2、自动记录日志,便于审计和追踪;3、实现复杂的业务逻辑,如级联更新或删除。通过合理设计和使用触发器,可以显著提升数据库系统的安全性和可靠性。 ... [详细]
  • 本文介绍了如何利用 `boost::asio` 库实现高效的异步 TCP 编程。与传统的同步方式不同,异步编程允许程序在发起 I/O 操作后立即返回,继续执行其他任务,从而显著提高系统的响应速度和整体性能。通过具体的代码示例和详细解释,本文展示了如何在实际应用中充分利用 `boost::asio` 的强大功能,实现高效、可靠的网络通信。 ... [详细]
author-avatar
lengmou
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有