第二十期

上一期结束过后，经过了原厂培训、出差等一系列事件，同时加上之前那套一体机入网的事情和年底了本来杂事就很多，没有更新。从本期开始这个系列将改成不定期更新，且不讲仅限于Oracle数据库的相关知识，也会包含MySQL，NoSQL以及其他用于存放数据的数据库产品相关知识。同时尽量保证每一期的内容长一些。
在写这篇文章的时候又遇到了所在区域的疫情，进入封闭管理在家办公，所以又晚了些。。。哎。。。

之前想着20年12月份弄好，结果前前后后事情太多，也没有写多少，21年第一篇3月4日放出，不好意思。

RWP

Oracle RWP，全程Oracle Real-World Performance，是Oracle原厂中比较传奇的一个团队，团队成员在Oracle数据库上的经验累加起来超过400年，专注于Oracle数据库的各种场景下的性能优化。我有幸于11月10-12日参加了在成都进行的RWP培训。下面是一些来自本次培训的纯干货，我承认，有些内容的原理，我还需要消化一下。

1 CPU占用率

其实在培训过程中，RWP对各种硬件也进行了比较详尽的讲解，比如CPU的超线程、缓存内容交换、占用率真实代表了什么等进行了讲解。这些基础硬件知识也和后面的各种优化进行了关联，这里只是说明遇到时稍微讲一下，其余的有兴趣的可以自己查询相关知识。
这里先说明一个概念CPU物理核心在同一个时间点上只能处理一个进程，所谓超线程技术其实是当CPU物理核心在处理非计算操作时，比如读取缓存的时候，可以进行其他线程操作，以提升CPU使用效率。一般来说使用超线程技术的CPU相较于本身不开启超线程技术能拥有50%左右的性能提升。为什么要提这个概念，先抛出一个结论，对于OLTP系统来说，数据库系统的CPU占用不要超过66%。当数据库CPU占用在66%的时候，意味着每3个进程有一个能获取CPU资源，这样在OLTP系统中是比较合理的。当CPU占用率超过66%的时候就会出现较多的CPU争用、等待，影响系统效率。所以OLTP系统判定主机CPU资源是否还足够的标准就是66%。
然而，在OLAP系统中则应当充分使用CPU资源，使用到100%是正常的。

2 统计信息比你想象中的更重要

Oracle的优化器在生成SQL的执行计划时是十分依赖统计信息的，就跟之前某期一体机上的一个问题一样，一张新建的表仅有一条数据的统计信息，而实际数据有30W条，优化器使用统计信息信息选择了nest loop而不是hash join，造成了非常庞大的row by row的处理，加上分配资源较少，造成了这条SQL运行时间超长。
另一方面，当表中列的数据有倾斜的时候，还应当收集这一列直方图统计信息。当多列之间存在关联时，比如全球骑车列表，国家和厂商名称之间就存在固有关系，就应当收集这些列的附加统计信息。

3 干同一件事情应当批量处理

来自于宜宾出差的一个例子，由于HIS系统数据库上云，因此有了固有的10ms延迟，而HIS系统在进行功能模块查询的时候没有设计好，造成了近200条SQL语句是一条一条执行的。数据库在本地时，因为机房内传输几乎无延迟，而SQL执行又非常快，所以从前台响应来看没有什么影响。但是数据库一旦上云语句一条一条执行，每一条增加10ms延迟，累加起来前台响应就比较长了。加上写死了分页查询造成了70%的SQL语句data not found，因此前台响应非常慢。假设业务方能够修改分页查询机制，按照实际数据进行分页，那么查询语句数量会有显著减少，另一方面根据业务情况将多条语句整合在一起发往数据库减少10ms延迟带来的影响，那么是可以显著提升前台响应的。
在OLTP中AWR的TOP10前台等待时间中，经常会出现log file sync的等待时间，这种情况一方面可能是因为online redo logfile group不够大造成切换归档等待引起的，但大多数原因还是因为row by row的处理方式，当有一堆DML操作时，每次commit都会写入日志，我们不应该每条DML就commit一次，而应该根据实际情况在完成多条DML操作后一起commit。

4 Arry和Inmemory

Arry是这次培训接触到的概念，以前没有深究过，后面可能将研究后专门出一期，结论是能显著提升SQL性能。
Inmemory其实算是老朋友了，12.1.0.2.0引入，将数据列式存储到内存中，相较于传统cache方式行表缓冲到SGA buffer cache中，性能有百倍以上的提升。

5 SQL Monitor

SQL Monitor是11g引入的特性，数据库会自动记录执行5s以上SQL语句的执行计划、活动状态等信息，对于优化SQL有很大作用，也可以通过hint进行记录。数据库本身记录SQL Monitor结果不会太长，前面几期介绍EMCC的时候，EMCC会记录较长时间的SQL Monitor结果，所以建议大家使用EMCC。

6 如何使用连接池

连接池的作用是保持数据库长连接，减少数据库在建立或断开会话时的等待。关于连接池到数据库的连接数设置，在会话压力较小时提升连接数是可以提升TPS的，但如果陡然增加连接数可能会引起连接风暴，造成数据库在一段时间内性能下降，但一般都能够通过减少数据库建立或断开会话的等待最终提升TPS。当会话数达到一定数量时，提高连接数就可能不能得到想要的TPS提升了，因为数据库本身会出现各种SQL间的等待，在这种情况下我们就需要换一种思路。我们需要保留合理的会话建立或断开的等待，通过降低单条SQL执行时间来提高每秒执行SQL数量从而提升TPS，那么降低连接池连接数量则是比较可行的方案，减少同时涌入SQL数量，减少SQL间等待。

下期预告：

继续本期话题

数据库管理-第二十期（20210304）相关推荐

开发者论坛一周精粹(第二十期) ：晒往期云栖大会的照片或感想，赢2017杭州云栖大会门票...
第二十期(2017年8月21日-2017年8月27日 ) 2017杭州云栖大会即将震撼来袭,如果你参与过往期的云栖大会,不妨晒出你的参会照片和感想,我们将挑选10个优秀的分享送出2017杭州云栖大会的 ...
Csdn视频第二十期 : 测试工具与流程讨论
Csdn视频第二十期 : 测试工具与流程讨论 http://live.csdn.net/Issue22/LivePlay.aspx
智能化软件开发微访谈·第二十期暨2022新年特辑：AI软件架构实践
CodeWisdom 智能化软件开发沙龙是复旦大学CodeWisdom团队参与组织的专注于代码大数据与智能化软件开发的学术和技术沙龙,面向相关领域的学术界研究者和工业界实践者,通过各种线上和线下交流活 ...
前端知识小报第二十期
前端知识小报第二十期内容收藏自网络,本文只是聚合分享文章链接!侵删本期标签 CSS / 骨架屏 / js / VUE 文章列表 CSS 奇思妙想边框动画使用Chrome扩展程序生成网页骨架屏 [ ...
数据库管理-第二十四期数据库设计-硬件篇（20220610）
数据库管理 2022-06-10 第二十四期数据库设计-硬件篇 1 CPU 2 内存 3 存储 4 网络 5 总结下期预告: 第二十四期数据库设计-硬件篇上次与这次的更新间隔比之前短多了,主要 ...
数据库管理-第二十二期记一系列问题处理（20211109）
数据库管理 2021-11-09 第二十二期记一系列问题处理 1 背景和问题描述 2 问题分析及解决 3 锦上添花下期预告: 第二十二期记一系列问题处理距离上期更新已经快6个月了,中间还是一个 ...
《袁老师访谈录》第二十期[百万对话]@盐城
4月17日,在曹路宝校友.蔡永军校友.张文宇校友的精心安排和组织下,香港科大校友们欢聚盐城,在西伏河创新社区开启"思想行走",在"港科大校友交流会"活动中,&l ...
第二十期：想吃透监控系统，就这一篇够不够?
经济高速发展的今天,我们处于信息大爆炸的时代.随着经济发展,信息借助互联网的力量在全球自由地流动,于是就催生了各种各样的服务平台和软件系统. 经济高速发展的今天,我们处于信息大爆炸的时代.随着经济发展 ...
《罗辑思维》第二十期：为泡妞而读书　笔记
1.传统读书方式与现今互联网时代下的读书方式是不同的,互联网时代下,读书的本质是让知识重新回到悬疑和场景.现在读书不主张去攀爬金字塔,主张按照一个人的应用,用你的兴趣把自己的心当作一个种子,在你的环境 ...

数据库管理-第二十期（20210304）

数据库管理 2021-03-04